2.4コスト見積りと予算

プロジェクトの初期段階でPMが直面するのは、「見積りに使える時間も情報も限られているのに、一定の精度でコストを見積もらなければならない」というジレンマです。見積り技法にはそれぞれ得意な局面があり、「精度を求めるなら常にボトムアップ」という単純な選択は誤り——プロジェクト初期の企画段階で詳細なボトムアップ見積りを行うのは工数の浪費になりかねません。この節では、3つの見積り技法の使い分けと、予算に組み込む予備費の性質の違いを学びます。

2.4.1見積り技法の使い分け

• 類推見積り＝過去の類似プロジェクトの実績コストを基準に、規模や複雑さの違いを補正して見積もる技法。少ない情報・短時間で見積もれるが精度は低い。プロジェクト初期の概算見積り（ラフオーダー）に向く。係数見積り（パラメトリック見積り）＝ファンクションポイント法やCOCOMO等、統計的関係式やパラメータから算出する技法。類推見積りより精度が高いが、信頼できるパラメータ・過去データの蓄積が前提となる。
• ボトムアップ見積り＝WBSの最下層（ワークパッケージ／アクティビティ）ごとに個別見積りを行い、それらを積み上げて全体コストを算出する技法。3技法の中で最も精度が高いが、見積りにかかる工数・時間も最大となる。WBSが十分に詳細化された計画段階以降で使うのが妥当。

2.4.2コストベースラインと予備費

• コストベースライン＝承認された、時間軸に対応づけたプロジェクトの予算（アクティビティごとのコスト見積りの積み上げ＋コンティンジェンシ予備）で、実際のコスト実績（AC）や出来高（EV）と比較する基準となる。コンティンジェンシ予備＝リスク登録簿に記載された既知の（識別済みの）リスクに対応するために、コストベースラインへ組み込む予備費。PMの裁量で使用できる。
• マネジメント予備＝未知のリスク（プロジェクトのスコープ外の想定外事象）に備えるための予備費で、コストベースラインには含まれず、プロジェクト全体予算（コストベースライン＋マネジメント予備）にのみ計上される。マネジメント予備の使用にはコストベースラインの変更を伴うため、通常はPMの裁量だけでなく上位のガバナンス（スポンサー等）の承認が必要。

あるPMが、新規のクラウド移行プロジェクトのコストを見積もる局面ごとに異なる技法を使い分けています。企画承認の段階では、詳細な要件がまだ固まっていないため、過去に実施した類似規模のオンプレミス→クラウド移行案件3件の実績コストを基準に、今回のシステム規模の違いを補正した類推見積りで概算予算（数千万円のレンジ）を算出し、経営層への提案に用いました。計画段階に進み、WBSが詳細化されると、移行対象のサーバ台数やデータ量から統計的な変換式を用いる係数見積り（クラウド移行工数の実績データに基づくパラメトリックモデル）でより精度の高い見積りに更新しました。さらに詳細計画の最終段階では、WBSの最下層である個々の移行タスク（サーバ単位・アプリケーション単位）ごとに担当チームから見積りを取り、積み上げるボトムアップ見積りで最終的なコストベースラインを確定しました。この過程で、リスク登録簿には「特定の3台のレガシーサーバでOS非互換の問題が起こる可能性がある（発生確率中）」という既知のリスクが識別されていたため、その対応コストとしてコンティンジェンシ予備200万円をコストベースラインに組み込み、PMの裁量で使用できる予備として計上しました。一方、「クラウドベンダー側の大規模障害でプロジェクト全体の前提が崩れる」といったプロジェクトのスコープ外にある未知のリスクに備えるため、コストベースラインには含めないマネジメント予備500万円を別枠でプロジェクト全体予算に計上し、その使用にはスポンサーの承認を要する運用としました。このように、見積り技法はプロジェクトの進行段階に応じて粗いものから精緻なものへ切り替え、予備費は「既知か未知か」「誰の承認で使えるか」で明確に区別して予算を組み立てます。

2.4.3この節のまとめ

• 類推＝速いが粗い、係数＝データ前提でより精度高い、ボトムアップ＝最も精度が高いが最も工数要
• コンティンジェンシ予備＝既知リスク・コストベースラインに含む・PM裁量
• マネジメント予備＝未知リスク・コストベースライン外・上位承認要