予算の作成（Develop Budget）とは？コスト・ベースラインを軸にPMBOK第8版のプロセスを理解する

前回は「コストの見積り」について取り上げましたが、個々の作業のコストが見積れたとしても、それだけではプロジェクトのお金の管理はできません。見積もった金額を積み上げ、「このプロジェクトはこの通りにお金を使っていく」という基準を作ってはじめて、実際の支出と比較しながらコストをコントロールできるようになります。

その基準を作るプロセスが、PMBOK第8版の財務パフォーマンス領域における3番目のプロセス「予算の作成（Develop Budget）」です。今回はこのプロセスを、インプット・ツールと技法・アウトプットの流れに沿って整理していきます^[1]Project Management Institute, Inc., The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition, 第2部 … Continue reading。

予算の作成とは何か

「予算の作成」とは、個々のアクティビティやワークパッケージの見積りコストを集計（合算）し、承認された「コスト・ベースライン」を確立するプロセスです。
目的は、プロジェクトのパフォーマンスを監視・コントロールするための基準を決定することにあります。この基準があってはじめて、実際の支出が計画に対してどのような状態にあるかを客観的に比較・評価できるようになります。

実施タイミングは、通常はプロジェクトの初期計画時、あるいはフェーズゲートなど事前に定義された特定のポイントで行われます。コストの見積りと同様、一度作って終わりではなく、プロジェクトの進行にあわせて見直されるものだと捉えておくとよいでしょう。

何を材料に予算を作るのか：主なインプット

予算の作成では、これまでのプロセスで積み上げてきた情報を材料にします。

プロジェクトマネジメント計画書からは、財務管理計画書、資源管理計画書、スコープ・ベースラインを参照します。

プロジェクト文書としては、見積り根拠、コスト見積り、プロジェクトスケジュール、リスク登録簿を使います。ここは「コストの見積り」プロセスのアウトプットがそのまま次のインプットになっている、という流れを意識すると理解しやすいところです。

加えて、ビジネス文書（ビジネスケースやベネフィット管理計画書）や、契約・SLAなどの合意書も material になります。プロジェクト単体の都合だけでなく、経済的な実現可能性や契約条件といった、一段上の視点からも予算は制約を受けるということです。もちろん市場環境や組織のポリシーといった外部要因（EEF）・組織のプロセス資産（OPA）も考慮に入れます。

予算をどう組み立てるのか：主なツールと技術

専門家の判断を仰ぎながら、コスト集計（Cost aggregation）によって、下位のワークパッケージから上位のコントロールアカウントへと見積りコストを積み上げていきます。

このとき欠かせないのが予備分析（Reserve analysis）です。
既知のリスクに備えるコンティンジェンシー予備や、想定外の事態に備えるマネジメント予備を、どのように配分するかを検討します。また、過去の履歴データをもとに構築した見積りモデルが信頼できるかどうかを履歴情報の検討で確認し、計画支出額が資金供給の限度額を超えないよう調整する資金限度測定（Funding limit reconciliation）を行います。大規模かつ長期のプロジェクトでは、外部から資金を調達・調整する融資（Financing）も技法の一つとして位置づけられています。

予算の骨格を決める：コンティンジェンシー予備とマネジメント予備の関係

予算をどのような構造で積み上げるかは組織のガバナンスによって異なりますが、PMBOK第8版では代表的に2つの考え方が示されています。

一つは、コンティンジェンシー予備をコスト・ベースラインに含めるケースです。この場合、以下の関係になります。

• コスト・ベースライン ＝ ワークパッケージ見積り合計 ＋ コンティンジェンシー予備
• プロジェクト予算 ＝ コスト・ベースライン ＋ マネジメント予備

PMBOKではこちらが最も一般的とされており、コスト・ベースラインにはコンティンジェンシー予備が含まれる一方、マネジメント予備は含まれません。

もう一つは、コンティンジェンシー予備をベースラインの外側で管理するケースです。この場合、ベースラインには純粋な見積り合計のみを含め、コンティンジェンシー予備・マネジメント予備の両方をベースラインの外（予算枠の範囲内）で別管理します。

どちらの構造を採るかによって「ベースラインからの逸脱」が意味するものが変わってくるため、プロジェクト開始時にどちらの考え方を採用するのかをチーム内ですり合わせておくことが大切です。

資金の「波」と限度額を調整する：資金限度測定

プロジェクトの支出は、時間軸に沿って均等に発生するわけではありません。特定のフェーズに支出が偏るなど「波」があるのが普通です。一方で、資金の供給側には「年間予算の上限」や「四半期ごとの出資枠」といった限度が課されることが一般的です。

計画支出額が一時的にでもこの限度額を超えてしまう場合は、タスクの実行時期を遅らせたり、マイルストーンを再スケジュールしたりして、支出の発生ペースを限度額の範囲内に平準化します。これが資金限度測定であり、スケジュール側に日付の制約を設ける作業を伴います。

予算作成のアウトプット

一連のプロセスを経て、最終的に次のようなアウトプットが得られます。

コスト・ベースライン（Cost baseline）は、承認されたプロジェクトの時間軸別のコスト予算であり、プロジェクトのパフォーマンスを監視・コントロールするための基準そのものです。

プロジェクト資金調達要件（Project funding requirements）は、コスト・ベースラインに、必要に応じてマネジメント予備を加えた、プロジェクトが必要とする資金の総額と時期ごとの要件です。実際の支出（Expenditures）は日々の作業に伴い滑らかに累積していく一方、コスト・ベースラインは時間軸に沿って配分された計画上の累積Sカーブとして描かれます。そして資金の供給自体は、期首の一括支給やマイルストーンごとの分割提供など、階段状に行われるのが一般的です。資金調達要件は、実支出のカーブやコスト・ベースラインのSカーブを常に上回るよう、バッファを組み込んだ「階段状の要件」として設定されます。

そのほか、コスト見積りやプロジェクトスケジュール、リスク登録簿といったプロジェクト文書も、このプロセスを通じて更新されます。

実務で頼りになるのは、やはり「コスト・ベースライン」

ここまでプロセス全体を見てきましたが、実務で最も重要になるのは、やはりコスト・ベースラインだと思います。これがなければ、そもそも「予算通りに進んでいるのか、それとも逸脱しているのか」を判断する物差しがありません。

日々のプロジェクト運営では、このコスト・ベースライン（累積のSカーブ）に対して、実際の支出やアーンド・バリュー（出来高）がどの位置にあるかを定期的に見比べていくことになります。予算が計画より膨らんでいないか、逆に進捗の割に使いすぎていないかは、この比較があってはじめて客観的に語れるようになります。コンティンジェンシー予備・マネジメント予備をどこまで使ったか、あとどれだけ残っているかを合わせて追っていくと、単なる「使った・使っていない」以上に、プロジェクトの健全性が見えてくるはずです。

見積りを積み上げて終わりにせず、コスト・ベースラインを「その後も見続ける指標」として運用していくことが、予算作成というプロセスを最大限に活かすポイントだと感じています。

まとめ

「予算の作成」は、コストの見積りを積み上げてコスト・ベースラインという基準を確立し、資金限度測定や予備の配分を通じて、実行可能な資金計画に落とし込むプロセスです。コンティンジェンシー予備・マネジメント予備をどう位置づけるかという構造の理解と、できあがったコスト・ベースラインを実務でどう使い続けるかという視点の両方を持っておくと、プロジェクトのコスト管理がぐっとやりやすくなります。