ひとことで言うと#
プロジェクト進行中に要件が少しずつ追加・拡大する「スコープクリープ」を仕組み(プロセス)と文化(チームの習慣)の両面から防止するアプローチ。気づいたときには手遅れになる前に、変更を検知し評価するゲートを設ける。
押さえておきたい用語#
- スコープクリープ(Scope Creep)
- プロジェクトのスコープが正式な承認プロセスを経ずに少しずつ拡大していく現象。1つ1つは小さいが、積み重なると納期とコストを破壊する。
- スコープベースライン
- プロジェクト開始時に合意したスコープの基準線のこと。すべての変更はこのベースラインとの差分で評価する。
- 変更管理プロセス(Change Control)
- スコープ変更の申請・評価・承認・却下を行う正式な手続き。口頭の「ちょっとした追加」を防ぐための仕組み。
- ゴールドプレーティング
- 依頼されていない機能や品質をチームが勝手に追加する行為を指す。善意のスコープクリープとも呼ばれる。
スコープクリープ防止の全体像#
こんな悩みに効く#
- 「ちょっとだけ追加で」が積み重なって納期が2か月延びた
- 誰がいつスコープを変えたのか、記録がない
- 開発チームが良かれと思って余計な機能を作ってしまう
基本の使い方#
具体例#
従業員30名の受託開発会社。飲食店向け予約管理アプリの開発(予算 800万円、期間4か月)で、過去3案件連続でスコープクリープによる赤字が発生していた。
今回は開始時にスコープ定義書で「やらないこと」を 12項目 明記。変更リクエストフォームをNotionで運用した。
| 月 | 変更リクエスト件数 | 承認 | 却下 | 延期 |
|---|---|---|---|---|
| 1か月目 | 6件 | 2 | 1 | 3 |
| 2か月目 | 4件 | 1 | 1 | 2 |
| 3か月目 | 2件 | 1 | 0 | 1 |
| 4か月目 | 1件 | 0 | 0 | 1 |
変更リクエストの件数自体が月を追うごとに減少。クライアント側も「変更には影響分析が必要」と理解し、不要な追加を自ら抑制するようになった。プロジェクトは予算内・納期通りに完了し、粗利率は 28% を確保(過去3案件平均は -5%)。
従業員2,000名のメーカー。ERP導入プロジェクト(予算 3.5億円、期間24か月)。過去のERP導入では現場部門からの追加要望で予算が 1.8倍 に膨張した経験がある。
今回はPMOが3つの対策を実施した。
- スコープ定義書に各部門の部門長が署名
- 変更リクエスト1件ごとに「追加コスト」と「既存機能の何を削るか」を提示
- 月次のスコープレビュー会議を設定し、累積変更量を可視化
24か月で受けた変更リクエスト 87件 のうち、承認は 23件(26%)。却下・延期の 64件 がそのまま通っていた場合、追加コストは 1.1億円 に達する計算だった。最終的な予算超過は 5%以内 に抑えられ、経営層から「初めてERP導入を予算内で完了できた」と評価された。
従業員8名のデザイン事務所。中小メーカーのブランドリニューアル(予算 250万円)で、デザイナーが「せっかくだから」とパッケージデザイン案を 3案→7案 に増やし、撮影カットも 20枚→35枚 に拡大。結果、工数が 1.6倍 に膨張し利益がほぼゼロになった。
対策として、プロジェクト開始時に成果物一覧とその数量をスコープ定義書に明記するルールを導入。「デザイン案は3案まで」「撮影は20カットまで」と数字で上限を設定した。
追加したい場合はクライアントに追加費用を提示する。導入後6か月で5案件を完了し、ゴールドプレーティングによる工数超過は 0件。平均粗利率が 12%→31% に回復した。
やりがちな失敗パターン#
| パターン | 何が起きるか | 対策 |
|---|---|---|
| 「やらないこと」を定義しない | あらゆる追加が「スコープ内かもしれない」と曖昧になる | スコープ定義書に「スコープ外」セクションを必ず設ける |
| 変更プロセスが重すぎる | 面倒がられてプロセスを迂回される | 小規模変更は簡易フォーム(5分で記入可能)を用意する |
| PMが1人で全部断る | 「PMが頑固」というレッテルを貼られ孤立する | 影響分析の結果を見せて、ステークホルダー自身に判断してもらう |
| ゴールドプレーティングを放置する | チームの善意が赤字の原因になる | スプリントレビューで「依頼された範囲に収まっているか」を毎回確認する |
まとめ#
スコープクリープ防止は、要件の膨張を仕組みと文化の両面から食い止めるアプローチ。開始時のスコープ定義書(特に「やらないこと」の明示)、進行中の変更管理プロセス、チーム内のゴールドプレーティング禁止が3本柱。変更を完全に拒否するのではなく、影響を可視化して合理的に判断する仕組みが、プロジェクトとステークホルダーの信頼を守る。