ウォーターフォル開発の見積り手法については昔から議論されてきました、COCOMOのようなステップ数による見積りから始まり、外部入出力から見積りを行うファンクションポイント法(FP法)、ユースケース図から見積りを行うユースケースポイント法等さまざまな工数見積の手法が提案されてきました。しかし私がたどり着いた最善な見積り方法は
KKD法＋積み上げ法
という至って原始的な方法です。
KKD法とは、感(K)と経験(K)と度胸(D)で見積りを行う方法で、熟年経験者の完全なる感に頼るというヒューマンスキルに依存した見積り手法です。
積み上げ法とは、実施する作業を出来るだけ細分化して個々のタスクについて見積りを行った後、それをすべて合計する事で全体の工数とする見積り手法です。
私も昔、だれでも見積りを行える見積り手法というものを目指して様々な方法を模索してきました。その模索の中でわかったことはそもそもFP法のような定型的な手法ではシステムの規模は見積れないということです。近年、新しい技術やプロダクトが毎年のように出てくる中で、今までのように単純なファイルの入出力や画面数等では簡単に見積りを行う事が出来ないという現状があります。また、立ち上がるプロジェクトに参加するメンバーのスキルや求められる納品物の精度もプロジェクト毎にさまざまなため、定型だった見積りを行うということ自体がそもそも間違っているのです。
熟年経験者の見積りスキルはかなりの精度になる
実は様々なプロジェクトをこなしてきた熟年のプログラマであれば要件がある程度明確であれば、開発言語やフレームワーク、動員する社員、開発プロセス等すべてを加味した上での見積りを提示する事ができます。さらにそれが既にお付き合いのあるお客さんであればその精度はさらに上がります。
見積りの誤差が20%以内であれば開発者が努力や采配でなんとか調整してくれるという指標があります。要件の80%の仕様を洗い出しておきそれを100%の精度で見積る事が出来れば、20%のぶれが発生したとしてもなんとか円満にプロジェクトを遂行することができるということです。逆に言うと要件定義の時点で80%程度の仕様が明確にならない場合はどんなに熟年の経験者がプロジェクトの見積りを行おうと問題が発生する可能性は残ってしまうという事になります。
プロのプロゴルファーが小さなカップでもホールインワンを狙えるように、プロのプログラマであればかなりの精度で見積りを行う事ができるようになります。それを精度を積み上げ法によりタスクを細かく分割することで見積りの誤差を減らしさらに100%に近づける事が可能になるのです。
平均値ではそもそも勝負にならない
FP法等の定型的な見積り手法が利用できない理由として結果が平均化してしまうという問題があります。定型的な見積り手法では数年の蓄積による開発実績の成果をフィードバックして値の調整を行います。値の調整を行うという事は定型的な見積り手法で導きだされる見積り値が平均値に近づくという事です。そうすると他の企業と見積り金額を争うような場合、当然相手はギリギリの金額を狙ってくると思います。その場合、どうやっても勝てなくなってしまうという問題が発生してしまいます。
また、定型的な見積り手法ではインプットの情報が細かくないためどうしてもバッファを積む必要が出てきます。積み上げ法のようなタスクを出来るだけ細かくして精度を上げるようなことが難しいのです。
開発者は手法の模索よりも積み上げ法のスキルを磨くべき
あなたが開発者で今後見積りを行うような立場になりたいと思っているのであれば、見積りのスキルを磨くべきです。積み上げ法は細かく細分化すればするほど見積り精度があがります。しかしやらなければ行けないタスクを挙げていないとその工数は丸ごと追加工数として重くのしかかってくるという欠点もあります。ウォーターフォル開発で実施する手順はアジャイル開発とは違いかなり細かく定義されているので、残らず作業タスクを挙げるという事は比較的やりやすい方です。見積りスキルを確実に身につける事で、多くの問題プロジェクトを減らす事ができるようになるのです。
Next >> 実は近くに落ちていた工数見積の銀の弾
