プロジェクトベースラインとは：スコープ・スケジュール・コストを解説

プロジェクトベースラインとは、正式に承認されたプロジェクト計画のバージョンであり、実行を通じてパフォーマンスを測定するために使用されます。これがなければ、プロジェクトが順調なのか、逸脱しつつあるのか、あるいは静かに破綻へ向かっているのかを判断する信頼できる方法がありません。

ベースラインを設定すべきだと知っているチームは多いものの、そこに3つの異なるベースラインが存在し、それぞれがプロジェクトの異なる側面を扱い、それらが組み合わさってパフォーマンス測定ベースラインと呼ばれるものを形成することを理解しているチームは少数です。

プロジェクトベースラインとは何か

プロジェクトベースラインとは、実際のプロジェクトパフォーマンスを測定する基準となる、承認済みの時系列計画です。プロジェクトが何を届けるべきか（スコープ）、いつ届けるべきか（スケジュール）、いくらかかるべきか（コスト）を捉えます。プロジェクトスポンサーと関連するステークホルダーがこの計画を正式に承認した時点で、それはプロジェクト期間全体にわたる固定の参照点となります。

ここで「承認された」という言葉が重要です。スプレッドシートに置かれたドラフトのスケジュールはベースラインではありません。ベースラインは、プロジェクト憲章や署名済みのスコープ文書などを通じて記録される正式な承認プロセスを経て初めて存在し、その時点で計画がロックされます。

それ以降の変更には正式な変更要求が必要です。この規律を省略して計画を非公式に調整し続けると、ベースラインは合意された現実のどのバージョンも表さなくなり、意味を失います。

主要データ

PMIの「Pulse of the Profession 2021」レポートによると、プロジェクトマネジメントの成熟度が高い組織はプロジェクトの77%を期日通りに、76%を予算内に完了させているのに対し、成熟度の低い組織ではそれぞれ56%、52%にとどまる。

PMBOKガイド（第7版）は**パフォーマンス測定ベースライン（PMB）**を、アーンドバリューマネジメントにおける比較に使用される、統合されたスコープ・スケジュール・コスト計画と定義している。

2020年のKPMGによるグローバルプロジェクトマネジメント調査では、組織の69%が過去3年間に少なくとも1件のプロジェクト失敗を経験したと報告しており、スコープクリープと不十分なベースライン管理が主要な根本原因として挙げられている。

3つのプロジェクトベースライン

完全なプロジェクトベースラインは、実際には3つの別々のベースラインが連携して機能するものです。それぞれが特定の知識エリアをカバーし、それぞれ異なる計画成果物から作られます。

各ベースラインは個別に承認されますが、実務上は計画フェーズの終わりにまとめてレビューされることが多くあります。これらを合わせたものがパフォーマンス測定ベースライン（PMB）であり、アーンドバリュー計算への入力となります。

プロジェクトベースラインとパフォーマンス測定ベースラインの違い

この二つの用語は近い関係にありますが同一ではなく、混同するとアーンドバリューのレポーティングに入った際に問題を引き起こします。

プロジェクトベースラインは、承認された参照計画全般を指す一般的な用語です。「コストベースライン」や「スケジュールベースライン」という言葉は、一つの側面のみを指して使われることがあります。

**パフォーマンス測定ベースライン（PMB）**は、スコープ・スケジュール・コストの3つすべてを組み合わせ、時系列予算として構造化した特定の組み合わせです。これは、スケジュール差異（SV）やコストパフォーマンス指数（CPI）といったアーンドバリュー指標を計算する際に、実際に比較対象とするものです。

こう考えるとわかりやすいでしょう。3つのベースラインはそれぞれ単独で一つの問いに答えます。PMBはそれらをまとめて答えるものであり、アーンドバリューマネジメントによる統合的なパフォーマンス測定に必要なものです。

プロジェクトベースラインが重要な理由

ベースラインは単なる書類ではありません。それは説明責任を可能にする仕組みです。

ロックされたベースラインがなければ、「順調に進んでいるか」という会話のすべてが、そもそも「順調」とは何を意味するのかという論争になってしまいます。プロジェクトマネージャーは前倒しだと言い、スポンサーは当初の計画は違ったはずだと考え、財務チームはプロジェクトマネージャーが見たことのない更新済み予算をもとに動いている。誰も嘘をついているわけではありません。ただ、共有された参照点がないだけなのです。

ベースラインがあれば、次の3つの具体的な問いに数字で答えられます。

1. 正しいスコープを届けられているか。 完了した成果物をスコープベースラインと比較し、スコープクリープを早期に捉えます。
2. スケジュール通りに進んでいるか。 実際の終了日をスケジュールベースラインと比較します。スケジュール差異（SV）のような単一の指標は、方向性だけでなく規模も教えてくれます。
3. 予算内に収まっているか。 実際のコストを期間ごとにコストベースラインと比較します。コスト差異（CV）の数値は、「支出が少し多い気がする」という曖昧な感覚よりもずっと役立ちます。

これらの比較は、多くのプロジェクトスポンサーが状況レビューで期待するトリプル制約分析にも活かされます。スコープ、スケジュール、コストのベースラインが大きく逸脱したとき、それは小さなずれが納期の危機になる前の早期警告となります。

プロジェクトベースラインの設定方法

ベースラインの設定は連続したプロセスです。各ステップは前のステップに依存します。

ステップ1：スコープを定義し承認する

プロジェクトが届けるものすべてと、届けないものすべてを文書化します。成果物はプロジェクトスコープ記述書と作業分解構成図です。WBSはスコープを、見積もりと割り当てが可能な大きさのワークパッケージに分解します。次に進む前に、プロジェクトスポンサーから正式な承認を得ましょう。

ステップ2：スケジュールを策定する

WBSのワークパッケージをプロジェクトスケジュールへと順序立てます。依存関係を特定し、期間を見積もり、リソースを割り当て、クリティカルパスを計算します。その結果がスケジュールベースラインであり、すべてのアクティビティとマイルストーンの計画上の開始日・終了日を示す文書です。ステークホルダーが作業量の裏付けがないタイムラインを求めることが多いため、これはベースライン設定の中でもっとも議論になりやすい部分です。

ステップ3：予算を見積もり承認する

各ワークパッケージに金額の見積もりを付け、それをプロジェクトのタイムライン全体に配分することでコストベースラインを構築します。その結果は、各報告期間にどれだけの支出が計画されているかを示す時系列予算です。これは「予算承認」という一括の数字ではありません。プロジェクト支出の自然な立ち上がりと収束を反映した、Sカーブと呼ばれることもある曲線です。

ステップ4：統合された計画を文書化し正式に承認する

3つのベースラインをすべてまとめてプロジェクトマネジメント計画にします。それをプロジェクトスポンサーと関連するステークホルダーに提示します。プロジェクト憲章への署名、正式なステージゲートの承認、あるいはプロジェクトマネジメントツール内での記録された意思決定など、書面での承認を得ましょう。その承認の日付がベースライン日となります。

ステップ5：プロジェクトマネジメントツールでベースラインをロックする

スケジューリングおよびコスト追跡ソフトウェアにベースラインを記録します。多くのツールには「ベースラインを保存」する機能があり、計画値を凍結して、プロジェクトが進むにつれて実績と並べて表示できるようにします。ツールでロックしなければ、誰かがスケジュールを更新した瞬間にベースラインは上書きされてしまいます。

ステップ6：ベースラインをチームに伝える

プロジェクトチームの全員が、ベースラインとは何か、なぜそれが重要なのかを理解しているべきです。逸脱は隠すのではなく報告すべきであること、そしてスコープやスケジュールへの非公式な変更は、計画に反映される前に変更管理プロセスを経る必要があることを知っておく必要があります。

ベースラインの変更を管理する方法

ベースラインは永久不変ではありません。プロジェクトは変化します。クライアントの気持ちは変わります。サプライヤーは納期を守れないことがあります。新たなリスクが顕在化します。問題は、ベースラインが変更を必要とするかどうかではなく、その変更をどう扱うかです。

変更は正式な変更管理を経なければなりません。 スコープ、スケジュール、コストへの変更提案はすべて正式な変更要求として提出され、3つのベースラインすべてへの影響が評価され、適切な権限を持つ者によって承認または却下され、その上で文書化されるべきです。変更管理プロセスと統合変更管理の手順は、まさにこの目的のために存在します。

変更が承認されたら、ベースラインを更新します。これをベースライン改訂（極端な場合はリベースラインとも呼ばれます）と言います。重要な規律は、その変更とその理由を記録することです。そうすれば、後からそれを見た人が、なぜベースラインが移動したのかを理解できます。文書化された理由で正式に2回リベースラインされたプロジェクトは、何かがずれるたびに「ベースライン」がひっそりと更新されるプロジェクトよりも、はるかによい状態にあります。

決してやってはいけないのは、変更要求を経ずに計画を実績に合わせて更新することです。この慣行は「ラバーベースライニング」と呼ばれることもあり、差異を測定する能力を失わせ、事実上ベースラインの説明責任機能を破壊します。

よくある間違い

スコープが安定する前にベースラインを設定する。 ステークホルダーがまだプロジェクトの成果物について交渉している段階であれば、スコープベースラインの設定は時期尚早です。未確定のスコープの上にスケジュールと予算をロックしても、数週間のうちに改訂が必要になる文書ができるだけです。

ベースラインを一度きりのイベントとして扱う。 一部のチームはプロジェクト開始時にベースラインを設定し、その後二度と見返しません。ベースラインは、すべての報告サイクルで実績と積極的に比較されて初めて価値を持ちます。

WBSを省略する。 適切な作業分解構成図なしで構築されたコストとスケジュールのベースラインは、作業の見落としが起きがちです。作業の見落としはコストベースラインの過小評価を意味し、プロジェクトが実際の問題に直面する前から予算超過を確実なものにします。

非公式なベースラインの変更。 変更要求なしに「今回だけ」スケジュールを調整するプロジェクトマネージャーは、ベースラインを蝕んでいます。非公式な調整を何度か重ねると、ベースラインはもはやスポンサーが合意した何かを反映しなくなり、アーンドバリュー指標は信頼できなくなります。

承認された変更の記録がない。 変更管理に従っていても、なぜそうしたのかを記録せずに計画を更新してしまうチームがあります。半年後には、なぜスケジュールベースラインが当初の計画と異なる日付を示しているのか、誰も説明できなくなります。

よくある質問

プロジェクトベースラインを簡単に言うと何ですか？

何を作るか、いつ作るか、いくらかかるかを網羅した、承認済みのプロジェクト計画のバージョンです。承認されると、プロジェクトを通じて実際のパフォーマンスを比較する固定の参照点として機能します。

プロジェクトベースラインはいつ設定すべきですか？

スコープ、スケジュール、コストが十分に計画され、プロジェクトスポンサーによって正式に承認された後に設定します。これは通常、計画フェーズの終わりで、実行が始まる前です。スコープが安定する前に早すぎるタイミングで設定すると、すぐに改訂が必要になるベースラインができてしまいます。

設定した後でプロジェクトベースラインを変更できますか？

できますが、正式な変更管理を通じてのみです。変更要求を提出し、影響を評価し、承認を得てから、ベースラインを更新する必要があります。そのプロセスを経ずにベースラインを変更することはラバーベースライニングと呼ばれ、パフォーマンス測定を無意味にしてしまいます。

プロジェクトベースラインとプロジェクト計画の違いは何ですか？

プロジェクト計画は、プロジェクトを通じて更新され続ける生きた文書です。ベースラインは、その計画の特定時点における承認済みのスナップショットであり、安定した参照として機能するよう凍結されています。計画は進化しますが、ベースラインは正式な変更管理を通じてのみ変わります。

プロジェクトベースラインはアーンドバリューマネジメントとどう関係しますか？

スコープ・スケジュール・コストのベースラインを組み合わせたパフォーマンス測定ベースラインは、すべてのアーンドバリュー計算への入力です。スケジュール差異、コスト差異、コストパフォーマンス指数といった指標はすべて、実際のパフォーマンスをこの統合されたベースラインと比較することで算出されます。ロックされたベースラインがなければ、アーンドバリューには比較する対象が何もありません。

プロジェクトベースラインの設定は、プロジェクトマネジメントの中でもとりわけ慎重さが求められる行為の一つです。計画よりも構築を始めたくなる開始時点での規律と、実際に起きていることに合わせて計画をこっそり調整したくなる実行中を通じての規律が求められます。その両方で一線を守り抜くチームは、見返りとして貴重なものを手に入れます。実際に学びを得られるプロジェクトの記録と、納期の状況について真実を語ってくれる数字です。