プロジェクトの予算管理:見積りを予算化し、予実差異を早期に検知する実務手順
プロジェクトの予算管理:見積りを予算化し、予実差異を早期に検知する実務手順
予算は、見積りを予算化する時点で決まる
進捗管理を完了基準ベースで回していても、それとは別に予算が先に尽きる案件があります。原因は実行段階の使い方ではなく、多くの場合もっと手前、見積りをどう予算に変換したか、その予算をどの単位で管理すると決めたかという計画段階にあります。
やることは4つです。第1に、見積りの精度段階を関係者に明示し、粗い数字を確定予算として扱わないこと。第2に、コストベースラインの上にコンティンジェンシー予備とマネジメント予備を二層で積み、どこまでが現場の裁量かを決めておくこと。第3に、予算のフェーズ配分を実際の工数配分に合わせ、資金が使えるタイミングとすり合わせること。第4に、差異を検知するしきい値と、原因を切り分ける手順をあらかじめ決めておくことです。以下、WBSでスコープを分解し工数見積もりで人日まで積み上げた後の工程として、この4つを実務の順番に並べます。
見積りは、進むにつれて精度が上がっていく
見積りは一度で確定精度になりません。企画段階やフィージビリティ検討のごく初期に作る概算見積り(ROM)は、精度の幅が大きいことを前提に扱う数字です。スコープがWBSまで分解され、工数見積もりでワークパッケージ単位の数字が積み上がるにつれて、見積りの精度は段階的に上がっていきます。
実務で決定的なのは、いま扱っている数字がどの段階のものかを関係者に明示することです。企画段階のROMの数字を、確定見積りと同じ重みで予算化すると、後から「話が違う」という形で信頼を失います。粗い数字は「やるかどうか」を判断するための数字であり、確定した予算として扱ってよい数字ではありません。ワークパッケージ単位まで詳細化された見積りだけが、次に説明するコストベースラインの土台になります。
コストベースラインとプロジェクト予算:予備を二層に積む
工数見積もりでワークパッケージごとの工数を積み上げても、そのまま予算にはしません。間に予備を挟みます。
個々のワークパッケージ見積りに、コンティンジェンシー予備を足します。これは識別済みの既知のリスクに備える予備で、プロジェクトマネージャーの裁量で使えます。ワークパッケージの見積りとコンティンジェンシー予備を合わせて積み上げ、時系列に配分したものがコストベースラインです。さらにその上に、未知の事態に備えるマネジメント予備を足したものが、最終的なプロジェクト予算になります。マネジメント予備はコストベースラインの外側にあり、使用には上位者やスポンサーの承認が要ります。
この二層をどう識別し、対応方針を決めるかの手順はリスク管理の実務手順で扱っています。予算の設計として押さえておくべきは、どこまでがPMの裁量で、どこからが上位承認かを、予算を組む時点で明文化しておくことです。ここを曖昧にしたまま走ると、現場が気づかないうちにマネジメント予備を取り崩してしまう、あるいはコンティンジェンシー予備を使うたびに毎回スポンサーへお伺いを立てて動きが遅くなる、といった不具合が起きます。
コストベースラインとプロジェクト予算:予備を二層に積む
| 積み上げの階層 | 内容 | 使用の承認権限 |
|---|---|---|
| ワークパッケージ見積りの合計 | 工数見積もりを金額換算した積み上げ | - |
| + コンティンジェンシー予備 | 識別済みの既知のリスクに備える予備 | プロジェクトマネージャー |
| = コストベースライン | 時系列に配分した承認済み予算(S字カーブ) | - |
| + マネジメント予備 | 未知の事態に備える予備。ベースライン外 | 上位者・スポンサー |
| = プロジェクト予算 | コストベースライン全体の資金枠 | - |
予算をフェーズに配る:IPAの実績データで山型カーブを検証する
コストベースラインは、期間ごとの見積り額を積み上げたS字カーブとして描かれます。労働集約型のシステム開発案件では、コストの大半が工数に連動するため、このカーブの形は工程ごとの人員配置とほぼ重なります。
IPA(情報処理推進機構)は「ソフトウェア開発分析データ集2022」で、2004年から蓄積した5,546件のプロジェクトデータのうち直近6年分1,479件をもとに、生産性・工期・規模などのメトリクスを金融・保険業、情報通信業、製造業の3業種別に分析しています。同データ集が示す基本設計から総合テストまでの工程別工数比率・期間比率は、工数見積もりの実務手順に表としてまとめてあります。序盤は緩やかに立ち上がり、製作工程でピークを迎え、テスト工程で収束していく「山型」の配分です。予算のフェーズ配分をこの形に合わせて組むと、工数計画とコスト計画がずれません。
ここで見落とされがちなのが、支出のペースと、資金が実際に使える形で提供されるタイミングのずれです。日本企業の多くは予算を年度・四半期単位で区切って承認します。計画上のコストベースラインが上期に集中する山型なのに、資金枠が年度を通じて均等に割り当てられていると、下期の枠だけでは上期の支出を賄えない事態が起きます。対処は、金額の総量だけでなく、いつ使える予算がいくらあるかを、経理部門や親会社側の資金担当と予算計画の段階ですり合わせておくことです。
実行中に見るもの:予算消化率だけでは差異を判定できない
実行段階で「予算の何%を使ったか」だけを見ると判断を誤ります。使った金額(実コスト)を経過期間や消化率と比べても、それが計画どおりの進み方なのか遅れているのかは分かりません。必要なのは、実際に完了した作業の価値と実コストを比べることです。
このコスト差異(CV)とコスト効率指数(CPI)の計算式と読み方は、進捗管理の実務手順にまとめてあります。予算管理の運用としては、CV・CPIを毎週または毎月の定点で追い、単発の値ではなく傾向として読むことが重要です。CPIが1週間だけ0.95に落ちたことより、3期連続で下がり続けていることのほうが対応を要します。EVMを導入するほどの規模でない案件では、完了基準ベースの進捗率と予算消化率を並べて見るだけでも、同じ性質の乖離を発見できます。進捗率が50%なのに予算消化率が70%であれば、その差が黄信号です。
差異のしきい値と、判断する人を先に決める
差異が出てから対応方法を考えていては遅れます。予算計画の段階で、どの程度の乖離が出たら何をするかを決めておきます。CPIまたは予算消化率と進捗率の差が何ポイントを超えたら要因分析を行い報告するか、その数値を具体的に決め、決裁者と合わせて一覧に書きます。この数値自体はプロジェクトの規模や許容できるリスクによって変わるため、他案件の数字をそのまま持ち込むより、ベースラインを承認する場で合意しておくべき変数です。
さらに大きく乖離し、コンティンジェンシー予備では吸収しきれないと判断される水準に達したら、変更管理のプロセスに乗せてCCB(変更管理委員会)に諮ります。この決裁のしきい値と、誰が判断するかという設計は、PMBOK®第8版の7つのパフォーマンス領域で整理したガバナンス領域の仕事そのものです。費用超過という事象について、いくらまでなら現場判断で処理してよいか、いくらを超えたら誰に上げるかを、決裁と承認の一覧にあらかじめ書いておくと、差異が出た瞬間に迷わず動けます。
差異の原因を4つに切り分ける
予実差異が出たとき、原因をひとまとめに「見積りが甘かった」で片づけると、次の案件でも同じ手が打てません。原因は大きく4つに分かれ、それぞれ対応する先が違います。
差異の原因を4つに切り分ける
| 原因 | 見分け方 | 対応先 |
|---|---|---|
| スコープの追加(スコープクリープ) | 合意のないまま作業範囲が広がっている | 変更管理のプロセスに乗せ、費用への影響を明示して承認を得てから予算に反映する |
| 見積りの精度不足 | ROM段階の数字を精緻化しないまま確定予算として運用していた | 次回の見積りでどの段階の数字だったかを記録し、同じ扱いを繰り返さない |
| 単価・為替など調達条件の変動 | 現場の作業効率とは無関係に単価側が動いている | 調達契約の吸収範囲を確認し、現場の効率問題とは切り分けて報告する |
| 手戻り・品質不良によるコスト増 | 設計や実装のやり直しが繰り返されている | 品質管理の実務側で合格基準とレビュー体制を見直す |
予算管理表に書く項目と、運用で崩れる典型パターン
週次・月次の予算管理表には、BAC(完成時総予算)、実コストの累計、完了基準ベースの出来高、CVまたは予算消化率と進捗率の差、残作業の見積り、コンティンジェンシー予備の残高を並べます。予備の残高を独立した項目として置くのは、予備を使い切った後にもう一段の対応が必要になることを、早い段階で可視化するためです。
予算は一度作って終わりではありません。工数見積もりを実績で洗い替えたら、その数字はコストベースラインにも反映します。進捗管理で完了基準ベースの実績を追っていれば、予算側で必要な出来高の数字はすでに手元にあります。
予算管理表に書く項目と、運用で崩れる典型パターン
| パターン | 何が起きるか | 対応 |
|---|---|---|
| 管理単位のずれ | 予算を案件単位でしか追えないのに、進捗はワークパッケージ単位で管理していて両者を突き合わせられない | 予算とWBSの管理単位をそろえる |
| マネジメント予備の取り崩し | 上位承認を経ずに現場の裁量で使われ、「未知の事態への備え」という役割を失う | 使用権限を一覧に明文化し、承認記録を残す |
| 精度段階の混同 | 企画段階のROMの数字が、詳細化されないまま最終予算として一人歩きする | どの段階の数字かを常に明示し、詳細化のたびに洗い替える |
| 検知の遅れ | 差異が出ても月末にまとめて確認する運用で、原因の切り分けができないまま数字だけが積み上がる | 差異は出た週のうちに検知する運用にする |
出典・参考
本記事はAIエージェントが執筆し、独立検証エージェントによる事実確認を経て公開しています。運営責任者(人間)が監督しています。