フレームワーク活用ガイドひとことで言うと#
プロジェクトで「やること（In Scope）」と「やらないこと（Out of Scope）」を明確に定義し、途中で範囲がジワジワ広がる「スコープクリープ」を防ぐ管理手法。
押さえておきたい用語#
- スコープクリープ（Scope Creep）
- プロジェクトの範囲が管理されないまま徐々に拡大していく現象のこと。プロジェクト失敗の最大原因の一つ。
- スコープベースライン（Scope Baseline）
- WBS完成時に確定するプロジェクト範囲の基準線のこと。以後の変更はすべて変更管理プロセスを通す。
- 変更管理プロセス（Change Control Process）
- スコープ変更が発生した際に影響を評価し、承認を得るための手続きのこと。口頭依頼を排除する仕組み。
- ゴールドプレーティング（Gold Plating）
- チームが善意で要件以上の機能や品質を追加してしまう行為のこと。隠れたスコープクリープの一種。
スコープ管理の全体像#
こんな悩みに効く#
- 「ついでにこれも」が積み重なって、いつの間にか当初の2倍の作業量になっている
- 何がプロジェクトの範囲内かメンバーの認識がバラバラ
- 追加要件を断れず、スケジュールも予算もオーバーする
基本の使い方#
プロジェクトの範囲を文書で明確に定義する。
- In Scope（やること）: 具体的に何を含むかリストアップ
- Out of Scope（やらないこと）: 明示的に範囲外であることを宣言する
- 前提条件と制約条件も記載する
ポイント: 「やらないこと」の明記が特に重要。書いてないことは「やる」と解釈されることがある。
スコープ記述書をもとに、WBSで作業を階層的に分解する。
- スコープ記述書のIn Scopeをすべて作業に落とし込む
- WBSに含まれない作業は「範囲外」として扱う
- WBSの完成をもって「スコープベースライン」を確定する
ポイント: WBSがスコープの「設計図」。ここが曖昧だと、後で解釈の違いが生まれる。
スコープの変更が必要になった場合の手続きを事前に決めておく。
- 変更要求の提出方法とフォーマットを定義する
- 変更の影響（コスト・スケジュール・品質）を評価するプロセスを設ける
- 変更承認の権限者（プロジェクト委員会やスポンサー）を明確にする
ポイント: 変更を禁止するのではなく、変更のコストを可視化して合理的に判断する仕組みを作る。
プロジェクト進行中、スコープが意図せず拡大していないか常に監視する。
- 定例ミーティングでスコープの逸脱がないか確認する
- 「これもやっておきます」という善意の追加作業にも注意する
- スコープ変更が承認された場合は、WBSとスケジュールも更新する
ポイント: スコープクリープは悪意ではなく善意から起きることが多い。だからこそ仕組みで防ぐ。
具体例#
スコープ記述書:
- In Scope: 商品一覧ページ、商品詳細ページ、カート、決済機能、マイページのリニューアル
- Out of Scope: ブログ機能の新規追加、アプリ版の開発、物流システムの改修
WBS作成: In Scopeの5機能をWBSで分解し、全42のワークパッケージに展開。これをスコープベースラインとして確定。
変更発生: 開発中に営業部門から「レコメンド機能も追加したい」と要望。変更管理プロセスに従い影響を評価。
| 項目 | 影響 |
|---|---|
| 追加コスト | 300万円 |
| スケジュール延長 | 3週間 |
| 品質リスク | テスト工数20%増加 |
判断: スポンサーが「リリース日は変えられない」と判断し、レコメンド機能はフェーズ2に先送り。当初のスコープどおりにリリースを完了し、フェーズ2で2ヶ月後にレコメンド機能を追加した。
背景: 自治体向けシステムの受託開発。過去の類似案件ではスコープクリープにより予算を30%超過した教訓あり。
対策: 契約書にスコープ記述書を添付し、法的拘束力のある「範囲」を明確化。変更管理委員会（PMO＋顧客代表＋ベンダーPM）を設置。
変更管理の実績:
| 変更要求 | 影響評価 | 判断 |
|---|---|---|
| 帳票フォーマットの追加（5種類） | +40時間・+50万円 | 承認（予備費から充当） |
| ワークフロー機能の追加 | +200時間・+250万円 | 却下（フェーズ2に延期） |
| 画面デザインの微修正 | +8時間・追加費用なし | 承認（バッファ内） |
| データ移行対象の拡大 | +80時間・+100万円 | 承認（顧客予算追加） |
結果: 8ヶ月で予算超過3%（過去は30%超過）で完了。変更管理プロセスにより、全15件の変更要求を合理的に処理。顧客から「コスト影響が事前にわかるので意思決定しやすかった」と高評価。
背景: 社内の業務管理ツールを内製開発。5名チーム、3ヶ月。前回の開発では、エンジニアが「もっと良くしよう」と仕様以上の機能を追加し、2ヶ月遅延した。
スコープ管理の工夫:
- スコープ記述書に「ゴールドプレーティング禁止」を明記
- DoDに「スコープ記述書に記載された機能のみを実装」を追加
- スプリントレビューごとにスコープ逸脱チェックを実施
ゴールドプレーティングの検出事例:
| スプリント | 検出内容 | 対処 |
|---|---|---|
| Sprint 2 | ダークモード対応（スコープ外）を実装中 | 作業停止、バックログに移動 |
| Sprint 4 | APIレスポンスの過剰最適化 | 「十分な性能」の基準を明確化 |
Before/After:
| 指標 | 前回PJ（対策なし） | 今回PJ（対策あり） |
|---|---|---|
| スケジュール | 2ヶ月遅延 | 1週間前倒し |
| スコープ外の作業時間 | 推定200時間 | 12時間（検出・停止） |
| 予算超過 | 25% | 0% |
結果: ゴールドプレーティングの検出・停止により200時間近い無駄を削減。1週間前倒しで完了し、余剰時間を次スプリントの準備に活用できた。
やりがちな失敗パターン#
- Out of Scopeを書かない — In Scopeだけ定義して、範囲外を明記しない。グレーゾーンが生まれ、「含まれていると思った」「いや含まれていない」の争いが発生する
- 変更管理プロセスがない — 口頭で「これもお願い」と言われて受けてしまう。必ず変更要求書を出してもらい、影響を評価してから判断する仕組みを作る
- ゴールドプレーティング — チームが「もっと良くしよう」と善意で仕様以上のことをやってしまう。品質向上に見えるが、コストとスケジュールを圧迫する隠れたスコープクリープ
- スコープ記述書を書いて放置する — プロジェクト開始時に作っただけで定例で参照しない。スプリントレビューごとにスコープの逸脱がないか確認する習慣をつける
まとめ#
スコープ管理は、プロジェクトの「やること」と「やらないこと」を明確にして、範囲の膨張を防ぐ管理手法。スコープクリープはプロジェクト失敗の最大原因の一つ。スコープ記述書の作成、WBSでの分解、変更管理プロセスの整備の3つをセットで実施することで、プロジェクトを計画通りに完了させよう。