フレームワーク活用ガイドひとことで言うと#
プロジェクトの承認済みスコープ（ベースライン）を基準点とし、以降のすべての変更をこの基準との差分として管理する手法。「当初の約束は何だったか」を常に参照可能にすることで、スコープの拡大も縮小も統制する。
押さえておきたい用語#
- スコープベースライン
- スコープ記述書・WBS・WBS辞書の3つを合わせた承認済み文書セットのこと。プロジェクトの「約束した範囲」を定義する。
- スコープ記述書（Scope Statement）
- プロジェクトの成果物・受入基準・除外事項を記述した文書を指す。
- 変更ログ
- 変更要求の受付日・内容・影響・判定結果・実施状況を記録する一覧表である。
- 差分分析
- ベースラインと現在のスコープを比較して変更の累積影響を把握する作業。定期的に実施する考え方。
スコープベースライン管理の全体像#
こんな悩みに効く#
- 「当初の約束は何だったか」を誰も正確に覚えていない
- プロジェクト終盤で「これも含まれていたはず」と揉める
- 変更が積み重なっても基準が更新されず、実態と乖離している
- プロジェクトの完了基準が曖昧で、いつ終わりか分からない
基本の使い方#
具体例#
従業員200名のSIerが保険会社の契約管理システムを開発。過去の同種案件では、検収時に「この機能も含まれていたはず」というクレームが頻発し、追加開発のコストが 契約額の15% を占めていた。
スコープベースライン管理を導入。要件定義完了時にスコープ記述書（全48ページ）・WBS（3階層152項目）・WBS辞書をクライアントと共同で作成し、双方の部長が署名。
プロジェクト中盤で12件の変更要求が発生したが、すべてベースラインとの差分として管理。
| 項目 | 導入前（前案件） | 導入後（本案件） |
|---|---|---|
| 検収時のスコープ紛争 | 8件 | 0件 |
| 追加開発コスト | 契約額の15% | 契約額の3% |
| プロジェクト遅延 | 6週間 | 1週間 |
「全部書いてあるので、揉めようがない」とPMはコメントしている。
化学メーカー（従業員1,200名）が新素材の事業化プロジェクトを推進。当初のスコープは「研究開発→パイロット生産→市場テスト」の3フェーズだったが、途中で市場環境が変わり、用途を変更する方向転換が2回発生。
ベースラインをv1.0（当初計画）→ v2.0（用途変更1回目）→ v3.0（用途変更2回目）と更新し、各バージョンの差分を記録。
- v1.0 → v2.0: WBS項目の変更率 28%、追加コスト +2,400万円
- v2.0 → v3.0: WBS項目の変更率 15%、追加コスト +800万円
方向転換の累計影響を経営会議で報告できたため、「これ以上の方向転換は費用対効果が合わない」と経営判断が速まった。ベースラインのバージョン管理がなければ、累計影響の把握は不可能だったという。
ゼネコン（従業員2,000名）の商業施設新築プロジェクトで、設計変更が頻発して工期が遅れるパターンが常態化していた。過去5件の平均工期遅延は 11% 。
スコープベースライン管理を厳格化。基本設計完了時にベースラインを凍結し、以降の設計変更は変更管理委員会（CCB）の承認が必要とした。
変更要求のハードルが上がったことで、設計変更件数は 月平均23件 → 8件 に減少。やむを得ない変更はベースラインを正式に更新して追跡。
工期遅延率は 11% → 3% に改善。「変更管理が面倒」という声もあったが、工期遵守のメリットのほうが圧倒的に大きかったと所長は評価している。
やりがちな失敗パターン#
- ベースラインを作っても参照しない — 作成しただけで棚にしまうと意味がない。月次の差分分析で定期的に参照するルーティンを組み込む。
- 変更をベースラインに反映しない — 承認された変更を反映しないと、ベースラインが実態と乖離して使い物にならなくなる。変更承認後48時間以内に更新するルールを設ける。
- 3点セットのうち1つだけ作る — スコープ記述書だけ作ってWBSを作らない、またはその逆。3点セットが揃わないとベースラインとして機能しない。
- バージョン管理をしない — 古いバージョンを上書きすると「元はどうだったか」が分からなくなる。v1.0, v1.1, v2.0 と履歴を残すことが必須。
まとめ#
スコープベースライン管理は、スコープ記述書・WBS・WBS辞書の3点セットを「基準点」として変更を統制する仕組み。月次の差分分析で「当初の約束からどれだけ変わったか」を定量的に把握し、承認された変更のみベースラインに反映する。バージョン管理と変更ログにより、プロジェクトの履歴がトレース可能になり、検収時の紛争も防げる。