概算見積もりの難しさ

投稿日:2007年06月05日作成者:yasunaka

もし顧客から、まだ内容が明確になっていない新しいシステムについての概算見積もりが欲しいといわれたら、あなたはどうしますか？　リスクを回避するために、システムの設計フェーズと実装フェーズを分けて、最初はシステムの設計フェーズのみを確定金額で受注し、実装フェーズは別途見積もりを行う、というのが教科書的な答えになるのですが、問題なのは上記のような手続きになるにせよ、顧客側では最初の概算見積もりに基づいてシステムに必要な予算を立てるため、結局その最初の概算見積もりが上限になってしまうことが多い、ということです。私も今までなんども、これで痛い目にあってきました。

概算見積もりの難しさの主因は、情報の少なさにあります。見積もり精度の良い手法というのがいろいろと編み出されていますが、結局その手の手法は何を作るのかがかなり具体化していないと適用できないものがほとんどで、概算見積もりが必要な段階では用を成さない場合がほとんどです。何を作るのかが確定していないのに正確な見積もりなどできるわけがありません。以前、概算見積もりの段階でソースコードの行数をベースに費用を見積もったベンダーを見たことがあるのですが、その思い切りの良さにある意味すげーっ（褒めたわけではないですよ）と思いました。

知人のプロジェクトマネージャの話では、「いろいろ考えて積み上げて算出した数字を、最後に3倍する」と答えてくれました。この最後の3倍というのが味噌で、そうすると経験的に収支トントンになる場合が多い、ということです。最後の倍率は状況によってはいろいろ異なるのかもしれませんが、少なくとも概算時に積み上げた数字というのは、まだ内容が見えてない分、大きな穴が開いている場合が多いので、かなり余裕度を見ておかないと痛い目に合うよ、ということを物語っているのだと思います。