プロジェクト内容
|
中堅ＳＩベンダーＸ社。ホテルＶ社の客室予約システムの見積もり場面
登場人物 Ａさん 今回のシステムのプロジェクトマネージャー。辣腕ＳＥ。
Ｃさん 今回のプロジェクトの承認をするＡさんの上司
Ｄさん 今回のシステムの営業担当
Ｄさん「Ｖ社さんは１千万までだと考えているようですが、どうでしょう？今までの付き合いで、うちにしか引き合いしていないので、まあある程度までならいけると思うんですが」
Ａさん「ハードは入っていないんですよね。だったら、楽勝です。ｐｈｐとｄｂだけのシステムだし、予約ならワークフローが明確なので、仕様決定でトラブルこともないだろうし」
Ｄさん「どのくらいでできますか」
Ａさん「私がやるとしたら、要件分析に１ヶ月、設計に１ヶ月、開発が３ヶ月ってところですね。お客さまは開発ドキュメントはどういっています？」
Ｄさん「開発後の運用・保守もすべてわが社にお任せしたいといっていますので、基本的にはそんなに丁寧なものは要らないでしょう」
Ａさん「それなら、１千万で十分にいけますよ」
Ｃさん「君が開発作業を担当つもりなのか？」
Ａさん「いえ、私はこの時期はＳ社の案件がピークで、時間がありません。Ｂ君をリーダーにしようと思いますよ」
Ｃさん「じゃあ、見積もりについてはＢ君の意見も聞いた方がよくないか？」
Ａさん「まあ、誰がやってもこんなものですよ。彼は、ｐｈｐやデータベースはかなり経験があるし、早いですよ。それより、お客様は急いでいらっしゃるんでしょう？」 |
| このプロジェクトの結末 |
プロジェクトマネージャーのＡさんより、リーダーを任されたＢさんは、開発作業こそ、３ヶ月で終わったものの、予約業務の細部が分からず、要件分析に２ヶ月、設計に３ヶ月かかってしまい、納期遅れ、大幅赤字。 |
| 問題点 |
人間がもっとも手っ取り早くものごとを想像する方法は、自分のことに置き換えてしまうという方法である。これは悪いことではない。しかし、プロジェクトの見積もりに関していえば、そのような危険をするのは極めて危険だ。実際によく、このような現象は見かける。特に、できるエンジニアがマネジャーとして見積もりをして、このパターンにはまったときには厄介である。思っていたようなスケジュールやコストで開発できないからである。実際のところ、ソフトウエアの生産性では、人により１０倍程度の差があることは珍しくないとよく言われる。それが、そのまま、見積もり誤差として効いてくる危険性があるのだ。 |
| 処方箋 |
・組織としての標準的な見積もり基準を持つ
・プロジェクトマネージャーが自分を基準にした係数を持つ |
| 解説 |
この問題、担当者に見積もりさせればいいじゃないかと思われるかもしれないが、そんなに単純な問題ではない。ＳＥで自分の作業の見積もりが正確にできるのは、この例のプロジェクトマネージャー同様できるＳＥである。したがって、担当者が正確に見積もりできるという保証はなく、見積もりをさせることは、ある意味で責任転嫁である。プロジェクトマネジメント組織成熟度を向上させ、組織として標準的な工数算出基準を持つしか、本質的な解決方法はないだろう。
ただし、これは時間がかかる。即効性のあるやり方はプロジェクトマネージャーが自分を基準にして考え、メンバーごとに能率計数のような係数を持ち、計画を策定することである。実際に小さなソフトウエアハウスでそのようにしているプロジェクトマネージャーがいるが、うまくいっているそうだ。
また、本質的には同じであるが、要員に関するリスクマネジメントを行い、実際にリスクが現実になったときのオプションを持っていることも重要である。 |
| ワンポイント |
自分を客観視してみよう |
| 参考文献： |
