見積もりをする上での大原則があります。それは、
どんな方法を使っても完璧な見積もりは作ることは出来ない。
と言う事。
とはいえ、勘に頼って見積もりをするのは危険すぎます。
少しでも見積もりのブレをなくすためにも、見積もりの方法論を学ぼうと思い、整理してみました。
見積もりの流れ
見積もりは３つの段階があります。- 規模の見積もり
- 工数の見積もり
- コストの見積もり
類推法
経験値による見積もりであり、過去の類似の開発事例から開発規模を類推する手法です。 主に規模の見積もりをする際に有効です。- メリット
- 過去に同様のプロジェクトが有れば精度はそこそこ
- 精密な資料が無くても見積もり出来る
- 過去の経験からリスクを想定し易い
- 過去の案件の精緻な情報が必要（大企業向け）
- 見積もり担当者によりブレが生じる
- 新規の案件には対応出来ない
プログラムステップ法、LOC法
プログラムステップ数(LOC:Lines Of Code)に生産性を掛け合わせておこなう見積もり。要求仕様から開発するプログラムのコード数を推定し、そのコード数と１コード当りの生産性から全体の工数を見積る。工数見積もりに向く。- メリット
- 既存コードの改修の場合は精度が高い
- コードが有れば見積もり出来る
- 要求仕様からプログラムステップ数を推定する確実な方法は存在しない
- 新規開発に使用することはあまりない
- 類推法に頼る部分も出てくる
積算法、WBS法
WBS(Work Breakdown Structure)等によって 細分化されたタスク毎に工数(作業時間)を求めて、それらの推定した工数を積上げることにより 見積もりを行う手法。工数見積もり向け。- メリット
- タスク自体の見積もり精度が高い
- １つ１つの見積もり範囲細かいので見積もりやすい
- スケジュール感が掴みやすい
- 見積もりのベースになる資料自体に手間がかかる
- 資料が大量に必要
- 概算見積もりに使うのは現実的に無理
- 意外と過小見積もりになりがち
FP法(Function Point）,標準値法
FPという共通の指標で開発規模を表す。入出力ファイルの数、画面や帳票、バッチなどの処理プロセスなどの機能面から工数を算出する。工数見積もり向け。機能数 × 重み付け係数 = FP
FP ÷ 生産性基準(FP/人月) = 工数（人月）
- メリット
- 精度が高い
- 組織も算出項目に入るので工数が出しやすい
- 利用者の視点から見積もりできる
- 要求仕様書が無いと使えない手法
- 組み込み系の見積もりには合わない
- 技術的な物を視野に入れられない
COCOMO /COCOMO ２
Constractive Cost Modelの略。開発するソフトウェアの行数を把握し、その行数に補正係数を掛け合わせて開発工数に換算する手法。 FP法の手法を入れるとCOCOMO IIになる。工数見積もり向け。最大の特徴は、スケール変動要因や、リスク項目が定義されていること。- メリット
- 精度が非常に高い
- 組織も算出項目に入る
- リスクを想定しやすい
- 係数の算定が難しい
- 計算方法が煩雑
KKD法
じつは手法でもなんでもない。エンジニアの経験と間に頼った見積もりのこと。 K（勘）、K（経験）、D（度胸）の略。規模見積もり向けではあるが、単体で用いるのは危険。- メリット
- 熟練した人であれば精度は高い・・かも？
- 他の技法でカバーできないものはコレで見積もる
- まったく根拠が無い場合はこれしかない
- 算出根拠が薄弱
- 勘が外れると氏ねる
- 見積もる人によって見積もりが大きく変わる
精度を上げるために
どの技法も一長一短有りですが、あくまで一視点でしかない事に注意。 複数の手法を組み合わせて使ったり、複数手法で見積もりを出して検討するとより良いでしょう。 可能であれば、複数の人で見積もりを出して議論する方が誤りは少なくなります。 ユーザーの為にも、プロジェクトメンバーの為にも、そして何より自分の為に、皆様よいお見積もりを。 最後に、見積もりの参考になる本で、良く聞くのが此方。参考までに。
コメント