＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
なぜ「スケジュール」を立てなければ行けないの？
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-05-28 11:54
NAL-6295です。
＞はにまるさん 誰にでもできる簡単な事を言ったつもりだったのですが・・・。 ・駄目だったら駄目なりに、駄目な原因を修正して次に繋ぐ。 (子供が逆上がりできるまで何回も頑張るように。） ・駄目そうだったら、早めに周囲に相談する。（シグナルをあげる。） （ホテルの当日キャンセルはキャンセル料取られるように遅ければ遅いほどコストがかかる。） 誰にでもできませんか？ ＞はゆるさん 全くもって同意です。 [ メッセージ編集済み 編集者: NAL-6295 編集日時 2004-05-28 11:55 ] | ||||||||||||
|
投稿日時: 2004-05-28 12:26
前半部分の意図している所がわかりませんでした。 何故そう思われたのでしょうか？ とりあえず返答すれば、「計画」を話たいのです。
別なのでしょうか？別であれば、どう別なのでしょうか？ 私の実体験（基幹系システムＰＧ）と先程の投稿文書を利用して説明すると、 新人の見積は、「個人予測技法」を鍛える為です。 これは例えリーダや管理職であっても、 個人依頼作業が消える事は無いので一生使います。 次にリーダになると、「チーム予測技法」が必要とされます。 ここで最初にぶつかる難関は、自分（「個人予測技法の情報」）と他人の生産量の違いです。 そして、「約束の為の計画」を要求されますが、 これは「チーム予測技法」から直ぐに、若しくは同時に周囲から要求されます。 ここで痛感するのが、開発工程以外の工程／工数の抜け落ちです。 その結果を反省として「チーム予測技法」へフィードバックします。言わば、 「約束の為の計画」のバックボーンは、「チーム予測技法」で、 「チーム予測技法」のバックボーンは、「個人予測技法」です。 後、「見積り」 と「スケジュール」の作成タイミングが異なるならば別でしょうが、 同時タイミングで作成したにも関わらず、内容が別物とは如何の様な状態でしょうか？ 若しくは、全く別のプロセスから２つは生成されとの意味でしょうか？ そうでなければ、なぜ別けて考えるのでしょうか？ ここも理解出来ませんでした。説明宜しく御願い致します。 | ||||||||||||
|
投稿日時: 2004-05-28 13:29
------------------------------------------------------------------ 言いたい事のマトメ。 ・「計画」や「スケジュール」は重要だ！ しかし、現在の計画技法では不充分なのだ！ ・現在の「計画」は多くが「約束を守る為の計画」で、守りの計画である。 ・当初の計画上で必要十分なメンバーと期日が確保出来る事は稀である。 ・ＩＴ業界では管理（監視じゃ無いよ）が、まだ不充分でその悪条件の なかで、現場の人間がどの様に考え、行動するか重要である。 ・その様な中で、「約束を守る為の計画技法」は不充分であり、 「効率的な計画技法」が求められている。 ・「約束を守る為の計画技法」が不充分なのは、その性質が−要素（失敗）の回避であり、 当初予定で要件が満たせない場合、＋要素の計画「効率化の為の計画」が必要だからである。 ------------------------------------------------------------------ 過去投稿の説明 2004-05-28 00:22の投稿（ＩＴで考えると変だから一般的に考えて．．．）は、 2004-05-28 10:23の投稿の伏線です。 スネていた訳では、ありません。 ------------------------------------------------------------------ ご返答します。 ・駄目だったら駄目なりに、駄目な原因を修正して次に繋ぐ。 ・駄目そうだったら、早めに周囲に相談する。（シグナルをあげる。） 仰る事は出来るのです。ですが効果が無いと言う説明をず〜と一貫して 御話をしているのです。だから、 駄目だったら駄目なりに、駄目な原因を修正して次に繋ぐ。 な話を求めている訳です。 実際の現場では上記の２点の説明で解決する様な問題ばかりでしょうか？ それは、「約束を守る為の計画」では有効かもしれません。 仰っていましたよね、
と、、、 簡単に出来る事を「試行錯誤」とは言いません。 NAL-6295さんも、簡単に出来ない事を知っているから「試行錯誤」と仰ったのでは無いでしょうか？ 前投稿で私がステージを別ける考えの説明が不充分なのでしょうか？ | ||||||||||||
|
投稿日時: 2004-05-28 13:55
意味不明な文書の補足
の所について
これは、 今まで、約束を守る計画に重点に置いて改善して来た。 しかし、悪条件では直ぐに限界がくる。
そして「効率化の計画」に切替えたと言う事です。 通じますかね？ う〜ん平たく言えば、 プロジェクトの立上当初に、システムの完成図が存在しない様に、 プロジェクトの立上当初に、全スケジュールの完成図が存在しないのです。 でも、実際の計画管理は、アタカモ最初から全スケジュールの完成図が 存在する様な管理をしてきた訳です。 それを改め、全スケジュールの完成図は存在しない物とした 計画手段に切替えたと言えば通じるかな？ 最初から、切替えている環境で働いている方々は理解出来ないかもしれません．．． | ||||||||||||
|
投稿日時: 2004-05-28 13:57
あくまで雑感です。批判的に聞こえたらごめんなさい。
IT系でなくても、「上司が使えないくせにつまらないことばかりやらせて 仕事の邪魔」って話よく聞きます。 そういうとき、会社という社会だと、「人間関係」というのが最優先事項なのですよね。 仕事の成功のために上司に直言するような人は物凄く嫌がられます。 こういった「ダメな管理者のもとで人間関係を守りながら現場は円滑に仕事を進める計画技法」と、 「優秀な管理者のもとで仕事の成功のために最善をつくす計画技法」は別物と 思うのですが、、、。 | ||||||||||||
|
投稿日時: 2004-05-28 14:34
それは、計画技法とかテクニックの問題では無く、積み上げ計画か逆算計画かの 違いだけではないでしょうか？ やるべき内容と期間を出してそれを順番に（単純に言えばですが）並べて行って 納期（最終完成時期）を出すのと、納期から逆算すればここまでにこれだけはや っておかなければならないといった基点の違いだと思うのですけどね。 これは、どんなときでも両方共作成しますよ。（完成形としてではなく） その両方が全く重なればほとんど問題無いのですが、大抵積み上げの時に納期が 後ろに行き、逆算では人的リソースを増やさないとこなせないという結果になる のですが、ここでこの２つを落ち着かせるポイントを、効率を上げる為の何か、 人的リソース不足を補う何かをあれこれと考えるものではないでしょうか。 | ||||||||||||
|
投稿日時: 2004-05-28 15:04
るぱんです。
自分の周りでは、 「計画＝約束」と勝手に同義語にされているケースが非常に多いです。 提出した時点で内容の精査など無しで「即約束」になるケースが多いです。 言って言いっぱなしの人も多いですし。 その中で、効率的な管理手法としての「計画」にたどり着く為には、 「周囲の計画に対する認識」ごと変えてしまう必要に迫られます。 それを下からボトムアップで意識を変えていくとなると非常にきついですね。 でも、それを僕みたいに続けてしまうと 「あいつは使いづらい・・・。」とかって言われますし。 お客さんは「システムを横流しする会社」だったりするし。 責任は全部持たされるケースも多いし。 はっきり言って辛いです。 責任持たなくていいと言われる事もありますけど、 問題が噴出したらやっぱり巻きなおすのは自分で、 「お前が作ったんだから責任をもて」ってな具合になるんですよね。 ・・・最近、孤軍奮闘が多くなりました。（汗） | ||||||||||||
|
投稿日時: 2004-05-28 15:37
ＩＴ業界の管理って見えない物を管理するから他業種以上に難しい物と捉えていましたが、 程度の差はあれ、他業界でも一緒なんですね。（変な安心感が．．．  ）
同じでは無いですよね。 明らかに前者の方が高度な計画技法を要求されます。
積上計画、逆算計画どちらも未来の話なので予測の域を越える事が出来ません。 勿論、高確率で的中出来る予測能力を持つ組織や可能な物件もあるでしょう。 大切なのは、積上計画、逆算計画の差を知る事、告知する事と思います。 ただ、話をさせてもらった通り、人的リソースが十分で、 その対処をして頂ける組織ならば、ここで御話は終了なのです。 それが不充分だから、 効率を上げる為の何か、人的リソース不足を補う何かをあれこれ考えるのです。 ただ、 その「あれこれ」を会議室で「計画」若しくは「スケジュール」と言う キーワードで話す事は出来ないのでしょうか？ 例えば、 皆様は、設計時に「外部システム・インタフェース」に細心の注意を払いませんか？ 外部システム・インタフェースは、互いの組織が無責任に成り易く、また、 エラー時のリカバリ如何するか？連携タイミングは？等などの決定が、 多く抜け落ち、またその仕様違いの結果、大きな変更を伴う恐れがあります。 これって、スケジュールでも良くある話では無いでしょうか？ その様な御話が、出来無いのでしょうか？ね 
| ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.