ベースラインとは？
ベースラインは、関係者に承認された計画のうち、進捗を測る基準として固定したものです。「何を（スコープ）」「いつまでに（スケジュール）」「いくらで（コスト）」の約束を、比べられる形で残しておきます。
計画そのものは、実行中に細かく更新されていきます。しかし、比較の基準まで動いてしまうと、予定より遅れているのか、予算を超えているのかが分からなくなります。
そこで、基準となる版だけを別に固定し、正式な手続きでしか変えないようにします。これがベースラインです。
3つのベースラインとは？
| ベースライン | 中身 | 比べるもの |
|---|---|---|
| スコープ・ベースライン | 承認されたスコープ記述書・WBS・WBS 辞書 | 実際に作った成果物と作業 |
| スケジュール・ベースライン | 承認された作業の開始日・終了日・マイルストーン | 実際の開始日・終了日、進み具合 |
| コスト・ベースライン | 時期ごとに配分した承認済みの予算（コンティンジェンシー予備を含む） | 実際に使ったお金 |
3つを統合したものを、パフォーマンス測定ベースラインと呼ぶことがあります。EVM の PV はこの基準から読み、総額が BAC（完成時総予算）になります。
コスト・ベースラインには、特定済みのリスクに備えるコンティンジェンシー予備が含まれます。一方、マネジメント予備は含まれません。マネジメント予備は使うときに承認が必要で、使った分はコスト・ベースラインに組み込まれます。
ベースラインはいつ・どうやって作る？
ベースラインは、計画の段階でスコープ → スケジュール → コストの順に作り、最後に承認を得て固定します。前のベースラインが次の土台になるので、順番が大切です。
- 1
スコープを確定する
スコープ記述書・WBS・WBS 辞書を作り、何を作るかを決める
- 2
スケジュールを作る
作業の順序と期間を決め、クリティカルパスを求める
- 3
コストを積み上げる
作業の見積りにコンティンジェンシー予備を加え、時期ごとに配分する
- 4
3つの整合を確かめる
同じ作業・同じ期間を前提にしているかを照らし合わせる
- 5
承認を得て固定する
スポンサーなどの承認を得る。以後は変更管理でしか変えない
当サイトの整理。承認者は組織のガバナンスで決まる
スケジュール管理のツールでは、「ベースラインを保存」のような機能で、承認時点の版を残しておくのが一般的です。以後は、計画の最新版とベースラインを並べて差を見ます。
ベースラインと実績はどう比べる？
ベースラインと実績の差が「差異」です。差異は決めた周期で測り、あらかじめ決めた許容範囲（しきい値）を超えたら、原因を分析して対応します。
差異 ＝ ベースラインと実績（または予測）の差（EVM の SV・CV は「EV − 基準」で、マイナスが悪い）
- 1スケジュール：ベースラインの完了日 6月30日、現在の予測 7月10日 → 10日の遅れ
- 2コスト：ベースラインの総額（BAC）5,000万円、完成時の見込み（EAC）5,300万円 → 300万円の超過見込み
- 3EVM：PV 2,000万円、EV 1,800万円 → SV ＝ 1,800 − 2,000 ＝ −200万円、SPI ＝ 0.9
- 4しきい値（例：±5％）と比べる：SPI 0.9 は10％の遅れ → しきい値を超える
しきい値を超えたので、原因を分析し、是正策を検討して報告する
当サイトの架空の例
差異が出たときの第一歩は、原因の分析です。計画の範囲内で取り戻せるなら、是正処置を行います。ベースラインそのものを変える必要があるなら、変更要求を出す流れです。スケジュールの立て方と差異の分析は スケジュール管理の手順 で扱っています。
ベースラインを変える？変えない？判断の早見表
試験で迷いやすいのは、「この場面でベースラインを変えてよいか」です。よく出る場面を、プロジェクト・マネジャー（PM）がすることとあわせて表にまとめました。
| 場面 | ベースライン | PM がすること |
|---|---|---|
| 変更管理委員会などが変更を承認した | 変える | ベースラインと計画を更新し、関係者に伝えて実施する |
| 作業が遅れた・費用が超過した（変更要求なし） | 変えない | 差異として報告し、原因を分析して是正策を考える |
| 変更要求を出したが、まだ承認されていない | 変えない | 承認されるまでは、今の基準で測り続ける |
| 特定済みのリスクが起き、コンティンジェンシー予備を使う | 変えない | 予備はコスト・ベースラインの中にあるので、総額は変わらない |
| 想定外の事態で、マネジメント予備の使用が承認された | 変える | 承認された額をコスト・ベースラインに加える |
| 大きな変更が重なり、比較の基準として意味を失った | 引き直す | 承認を得て、ベースラインを作り直す（再ベースライン化） |
表の「変える」はすべて、権限のある人の承認が前提です。PM が自分の判断だけでベースラインを動かす場面はありません。
ベースラインを変更する手続きは？
ベースラインは、統合的な変更管理の手続きで承認された変更があったときだけ更新します。流れは次のとおりです。
- 1
変更要求を記録する
誰が・何を・なぜ変えたいかを文書にする
- 2
影響を分析する
スコープ・スケジュール・コスト・品質・リスクへの影響を評価する
- 3
承認者が判断する
変更管理委員会（CCB）やスポンサーなど、決められた権限者が承認・却下する
- 4
ベースラインと計画を更新する
承認された内容を、ベースラインと関連する文書に反映する
- 5
関係者に伝え、実施する
変更の結果を伝え、新しい基準で作業と測定を続ける
当サイトの整理。承認者や手順は組織のガバナンスで決まる
変更管理の詳しい進め方は 変更管理の手順 で解説しています。ベースラインは計画全体の一部なので、統合された計画との整合も確かめます（統合計画 を参照）。
POINT
大きな変更が重なると、元のベースラインは比較の基準として意味を失います。その場合は計画を作り直し、ベースラインを引き直すこともあります（再ベースライン化）。これも承認を得て行います。
アジャイルでは何を基準にする？
アジャイルでは、予測型のような作業単位の詳しいベースラインは作らないのが一般的です。代わりに、合意した「枠」を基準にします。
予測型
- 基準スコープ・スケジュール・コストの3つのベースライン
- 中身を変えるとき変更要求を出し、変更管理委員会などが承認する
- 進み具合の測り方EVM や計画との差異で測る
アジャイル
- 基準リリースの目標時期・予算の枠・プロダクトゴール
- 中身を変えるときプロダクトオーナーがプロダクトバックログを並べ替える
- 進み具合の測り方バーンアップチャートやベロシティで測る
当サイトの整理
プロダクトバックログの並べ替えは、プロダクトオーナーの判断で行えます。進行中のイテレーションの中身を変えるときは、チームとの話し合いが必要です。ただし、予算やリリース時期など、合意した枠を超える変更はガバナンスの手続きに乗せます。
試験ではどう問われる？
- 遅れや超過を理由に、承認なしでベースラインを動かす選択肢は誤り。差異は差異として報告する。
- 変更が承認されたら、ベースラインと計画を更新し、関係者に伝える。更新を忘れると、以後の比較が誤る。
- 承認前の変更要求は、まだ実施しない。チームや顧客の依頼でも、手続きを飛ばさない。
- アジャイルの優先順位の入れ替えに、予測型の変更管理は通常いらない。合意した枠を超えるときだけ手続きに乗せる。
ECO 2026年版の Process タスク8は「スケジュールの計画と管理」です。2026年版では「スケジュールをベースラインにする」と「差異を分析する」が明記されました。Business Environment タスク3は「変更の管理とコントロール」です。変更管理の手続きの実行、承認された変更の実施、文書の更新が含まれます。
旧版（2021年版）のスケジュールのタスク（Process タスク6）には、ベースライン化の項目はありませんでした。変更の管理も、旧版では Process タスク10 でした。
確認問題1
変更が承認された後にすること
（当サイトの独自問題）顧客から依頼された帳票の追加について、変更管理委員会が承認しました。追加によって、完了日は2週間延び、コストは300万円増えます。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。承認された変更は、ベースラインと計画に反映し、関係者に伝えてから実施します。帳票の追加でスコープも変わるので、3つとも更新します。以後の進捗の基準は、新しいベースラインです。
1：承認済みの変更を反映しないと、比べる基準が誤ったままになります。2：費用の扱いは承認の過程で決める事項で、承認後の最初の行動ではありません。4：分析と承認は、すでに終わっています。
確認問題2
報告を良く見せるための変更
（当サイトの独自問題）クリティカルパス上の作業が3週間遅れています。チームリーダーは、「ベースラインを実績に合わせて引き直せば、報告書の状態が緑に戻る」と提案しました。変更要求はまだ出ていません。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。ベースラインは、承認された変更があったときだけ更新します。遅れは差異として正直に報告し、原因を分析して、是正策や必要な変更要求を検討します。
1：チームと合意しても、権限者の承認がないベースライン変更は、遅れを隠すことになります。2：判定基準を後から変えるのも、透明性に反する行為です。3：報告を遅らせると、関係者が判断する材料を奪います。
確認問題3
スコープ・ベースラインの構成
（当サイトの独自問題）新しく加わったメンバーから質問を受けました。スコープ・ベースラインとして、承認済みのどの文書を見ればよいかという質問です。プロジェクト・マネジャーが示すべき組み合わせはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。スコープ・ベースラインは、承認されたスコープ記述書・WBS・WBS 辞書の3つで構成されます。
2：プロジェクト憲章と要求事項文書は、スコープを定める元になる文書で、ベースラインそのものではありません。3：スケジュールとコストは、別のベースラインです。4：リスク登録簿は、プロジェクト文書の1つです。
次に何をすればいい？
ベースラインの問題は、「承認の有無」を確かめる癖をつけると解きやすくなります。変更が承認されていれば更新、承認されていなければ差異として報告、が基本です。
変更管理やベースラインの判断を状況問題で練習したい人は、無料模試30問で本番の形式を試せます。