フレームワーク活用ガイドひとことで言うと#
プロジェクト進行中に発生するスコープ・スケジュール・予算などの変更要求を、決められたプロセスで評価・承認・記録し、無秩序な変更（スコープクリープ）を防ぐ管理手法。
押さえておきたい用語#
- スコープクリープ（Scope Creep）
- 正式な承認なしにプロジェクト範囲が少しずつ拡大していく現象である。「ついでにこれも」の積み重ねが典型的な原因。
- 変更管理委員会（CCB: Change Control Board）
- 変更要求の承認・却下・保留を判断する権限を持つ委員会のこと。PM・スポンサー・技術リードなどで構成する。
- 変更ログ（Change Log）
- すべての変更要求とその処理結果を時系列で記録する台帳である。「誰が・いつ・何を・なぜ」変更したかの唯一の記録。
- トレードオフ分析（Trade-off Analysis）
- 変更を受け入れた場合に失うもの（期間・コスト・品質）を明示的に比較する分析手法のこと。「この機能を追加するならスケジュールが2週間延びる」のように示す。
変更管理の全体像#
こんな悩みに効く#
- 「ついでにこれも」の追加要望が積み重なり、いつの間にかスコープが膨れ上がっている
- 変更の影響を十分に検討せずに受け入れて、スケジュールが破綻する
- 誰がいつ何を変更したか記録がなく、責任の所在が曖昧になる
基本の使い方#
変更要求をどのように扱うかのプロセスを明文化する。
- 変更要求の提出方法（フォーム、チケットなど）
- 影響評価の担当者と評価基準
- 承認権限（誰が承認できるか）のレベル分け
- 変更管理委員会（CCB: Change Control Board）の設置を検討する
ポイント: プロジェクトの規模に合ったプロセスにする。小規模なら軽量に、大規模なら厳格に。
変更要求を正式に記録する。
- 変更の内容と目的を明確に記述してもらう
- 変更要求に一意のIDを付与して追跡可能にする
- 口頭の依頼でも、必ず書面（チケット）に起こしてから受け付ける
ポイント: **「口頭で受けた変更は存在しない」**というルールを徹底する。
変更要求の影響範囲を分析し、受け入れるか判断する。
- スケジュールへの影響: 納期はどう変わるか
- コストへの影響: 追加の工数・費用はどれだけか
- 品質・リスクへの影響: 技術的リスクは増大しないか
- 評価結果をもとに、承認・却下・保留を決定する
ポイント: 「変更を受け入れない場合のリスク」も合わせて評価する。変更しないことが最大のリスクである場合もある。
承認された変更を計画に反映し、完了まで追跡する。
- WBS、スケジュール、予算を更新する
- ステークホルダーに変更内容と影響を通知する
- 変更の実施状況を追跡し、計画通り反映されたか確認する
- 変更ログを最新状態に保つ
ポイント: 変更承認後の計画更新を忘れない。計画と実態の乖離を防ぐ。
具体例#
状況: 従業員100名のIT企業。Webアプリ開発プロジェクト（予算2,000万円・4ヶ月）の開発フェーズ中に、クライアントから「検索機能にAI搭載の自然言語検索を追加してほしい」という変更要求。
変更要求の記録: 変更管理チケット CR-015 として登録。目的: ユーザー体験の向上。
影響評価:
| 項目 | 影響 |
|---|---|
| スケジュール | +3週間 |
| コスト | +120万円（外部AI API + 追加開発） |
| 品質リスク | 中（AI検索の精度検証が必要） |
| 変更しない場合のリスク | 低（既存キーワード検索で最低限対応可能） |
CCBでの判断: Phase 1は既存キーワード検索で予定通りリリース、Phase 2でAI検索を追加する折衷案を採択。
トレードオフを定量的に示すことで、クライアントも「Phase 2で対応」に合意。変更管理プロセスがなければ「すぐやります」と受けてしまい、3週間の遅延と120万円の予算超過が発生していた。
状況: 従業員2,000名の自動車部品メーカー。工場の生産管理システム刷新プロジェクト（予算8,000万円・18ヶ月）。規制対応のため変更管理の厳格な運用が求められる。
CCB構成: PM、品質保証部長、製造部長、IT部長の4名。月2回定例開催。
12ヶ月間の変更管理実績:
| 区分 | 件数 | 影響工数合計 | 影響コスト |
|---|---|---|---|
| 承認（即時） | 8件 | 45人日 | 540万円 |
| 承認（Phase 2移行） | 5件 | 80人日 | — |
| 却下 | 6件 | 95人日 | — |
| 保留中 | 2件 | 15人日 | — |
却下6件の内訳: 品質リスクが高すぎる（2件）、ROIが低い（3件）、代替手段で対応可能（1件）
この取り組みが示すように、却下した6件（95人日相当）をそのまま受け入れていた場合、プロジェクトは3ヶ月遅延し、追加コスト1,140万円が発生する見込みだった。変更管理の「NOと言える仕組み」がプロジェクトの予算内・期限内完了を実現した。
状況: 子ども食堂ネットワークを運営するNPO。ボランティアエンジニア3名が運営管理システムを開発中（予算50万円・3ヶ月）。ステークホルダー（NPO代表・現場スタッフ）からの要望が週に5〜6件届き、開発が進まない状態。
軽量プロセスの導入:
- Google Formで変更要求を受付（5項目のみ: 要望内容・理由・緊急度・期待効果・代替案）
- 毎週月曜のオンライン定例（30分）で優先度を合意
- 「1スプリント（1週間）で新規要望は最大2件まで」のWIP制限
導入前後の比較:
| 指標 | 導入前 | 導入3ヶ月後 |
|---|---|---|
| 週あたり新規要望 | 5.6件 | 5.2件（変わらず） |
| 週あたり着手数 | 3.8件（すべて中途半端） | 1.8件（すべて完了） |
| 週あたり完了数 | 1.2件 | 1.8件 |
| 要望の平均完了日数 | 21日 | 9日 |
予算50万円のNPOプロジェクトでも変更管理は有効。「すべてに対応する」ではなく「優先度の高いものから確実に完了する」に切り替えたことで、完了数が1.5倍、完了速度が2.3倍に改善。変更管理の本質は「選ぶこと」にある。
やりがちな失敗パターン#
- 「小さい変更だから」とプロセスを省略する — 小さな変更の積み重ねがスコープクリープの正体。どんなに小さくても変更要求として記録する
- 影響評価なしに承認する — ステークホルダーの圧力で評価を飛ばして承認すると、後から大きな問題になる。評価のステップは絶対に省略しない
- 変更ログを更新しない — 変更の履歴が残っていないと、後から「なぜこうなったのか」が追えなくなる。変更ログは生きたドキュメントとして常に更新する
- 変更を全て拒否する — 変更管理は「全て断る」仕組みではない。正当な変更を適切に受け入れ、不要な変更を防ぐバランスが重要
まとめ#
変更管理はプロジェクトの「免疫システム」。すべての変更を拒否するのではなく、正当な変更を適切に評価・承認し、無秩序な変更を防ぐ仕組み。プロジェクトの規模に合った軽量なプロセスから始め、変更要求の記録・影響評価・承認・追跡のサイクルを確実に回すことが、スコープクリープを防ぐ最善の方法となる。