ソフトウェア開発管理で一番大切なことは「コスト、品質、納期」ということはよく言われることですが、これまでのソフトウェア開発プロジェクトでは3つのうち何かが欠けてしまい失敗(デスマーチ)という状況が少なからずあった。（本当ならビジネスとしてやっている以上、あってはならないことですが･･･）
プロジェクト失敗の原因は様々あると思いますし、多くの人たちがより良い方法を考えていますが「これだ！」と言われる方法はなく、プロジェクトの規模・内容によって試行錯誤されていると思う。特定の業務では正しいと言われる方法はあるかもしれないが。
その失敗理由について「プロジェクトリーダ/マネジャの力不足」と終わらせてしまっては何も生まれない。
これまで携わってきたプロジェクトの中で特に難しいことの1つに工数見積があります。
破たんした見積もりはプロジェクト失敗への近道 － ＠IT自分戦略研究所
最近自身も経験したことで概算見積がある。 見積手法と言われる方法は様々あるが、これらの方法は顧客の要件が確定している場合、または確定後のフェーズで利用される手法と理解している。 しかし、実際の開発現場では担当者から引き合いレベルで「予算化するために概算見積がほしい」という依頼がよくある。これに対応する場合「FP法などは利用できないなぁ。」と。顧客にとってもこれから導入しようと考えているソフトウェアにいくらかかるのか? 費用対効果は? を判断するために早く概算見積が必要名のは理解しているつもり。
どのようにやっているのかと思って、あるソフトウェア開発企業でプロジェクトリーダの方に聞いたところ、
- 現状で分かっている要件から機能毎の工数を積み上げていく
- それに2～3倍を掛けて提示する(笑)
この「工数を数倍」というところが重要で実際にプロジェクトが完了した時点で「トントンになるか」「すこしマイナス」という場合がけっこうあるという話を聞いた。 この数字に根拠があるわけではないと思うが、甘い見積では確実に穴があり、痛い目をみる。見積精度を高める努力はしているがやっぱり難しい。
[Think IT] 第1回：工数見積もりの見える化 (3/3)
エンタープライズ系ソフトウエア開発における見積もり手法 … 「類似プロジェクトからの類推」 「プロジェクトリーダや担当者の経験」、 そして「積み上げ」が三強で全体の90%以上を占める。
- 見積の間違いはチーム全体を不幸にする、顧客にとっても。
- 正確な見積はできない。限りなく正しいと言える見積はあるはず
- 開発者と顧客が喜ぶことが出来る結果を目指す
開発側ばかりに負担をかけることも問題、顧客側に負担をかけることも問題、開発側と顧客側が満足できるソフトウェア開発とプロジェクト管理の両立を目指したいですね。
[見積手法]