スコープクリープ防止

英語名 Scope Creep Prevention
読み方 スコープ クリープ プリベンション
難易度
所要時間 仕組み構築に2〜3時間、運用は都度15分
提唱者 プロジェクトマネジメント全般 / PMBOK
目次

ひとことで言うと
#

プロジェクト進行中に要件が少しずつ追加・拡大する「スコープクリープ」を仕組み(プロセス)と文化(チームの習慣)の両面から防止するアプローチ。気づいたときには手遅れになる前に、変更を検知し評価するゲートを設ける。

押さえておきたい用語
#

押さえておきたい用語
スコープクリープ(Scope Creep)
プロジェクトのスコープが正式な承認プロセスを経ずに少しずつ拡大していく現象。1つ1つは小さいが、積み重なると納期とコストを破壊する。
スコープベースライン
プロジェクト開始時に合意したスコープの基準線のこと。すべての変更はこのベースラインとの差分で評価する。
変更管理プロセス(Change Control)
スコープ変更の申請・評価・承認・却下を行う正式な手続き。口頭の「ちょっとした追加」を防ぐための仕組み。
ゴールドプレーティング
依頼されていない機能や品質をチームが勝手に追加する行為を指す。善意のスコープクリープとも呼ばれる。

スコープクリープ防止の全体像
#

スコープクリープ防止:3つの防御層で要件の膨張を食い止める
第1層:予防(開始時)スコープ定義書「やること」と「やらないこと」変更管理ルール変更の申請・承認手順ステークホルダー合意書面での署名それでも変更要求は来る第2層:検知・評価(進行中)変更リクエスト口頭NG、書面で申請影響分析コスト・納期・品質への影響承認 or 却下トレードオフを踏まえて判断チーム内部からの膨張も防ぐ第3層:文化(チームの習慣)ゴールドプレーティング禁止「ちょっとだけ」の口頭依頼を断る── 仕組み × 文化の両面でスコープを守る ──
スコープ変更リクエストの処理フロー
1
変更の検知
「ちょっとした追加」を見逃さず変更として認識する
2
書面で申請
変更内容・理由・期待効果をチェンジリクエストに記載
3
影響分析
コスト・納期・品質への影響を数字で評価する
承認 / 却下 / 延期
トレードオフを踏まえて意思決定しベースラインを更新

こんな悩みに効く
#

  • 「ちょっとだけ追加で」が積み重なって納期が2か月延びた
  • 誰がいつスコープを変えたのか、記録がない
  • 開発チームが良かれと思って余計な機能を作ってしまう

基本の使い方
#

スコープベースラインを明文化する
プロジェクト開始時に「やること」と「やらないこと」を明記したスコープ定義書を作成する。特に「やらないこと」の明示が重要。例:「多言語対応は今回のスコープ外」「管理画面のUI改善はPhase 2」。ステークホルダーの署名を取る。
変更管理プロセスを設定する
スコープ変更を申請する手続きを決める。変更リクエストフォーム(変更内容・理由・影響範囲・必要工数)を用意し、口頭での「ちょっとした追加」は受け付けないルールを全員に周知する。
変更リクエストを影響分析で評価する
変更リクエストが来たら、PMがコスト・納期・品質への影響を数字で分析する。「この変更を入れると納期が 2週間 延びるか、既存の機能Bを削る必要がある」というトレードオフを提示し、ステークホルダーに判断を委ねる。
ゴールドプレーティングを防ぐ文化を作る
チーム内部からの「こっちの方がいいと思って追加した」を防ぐ。スプリントレビューでスコープ外の作業が含まれていないかを確認し、「依頼されていない改善はバックログに入れてから判断する」をチームの約束にする。

具体例
#

例1:受託開発会社がWebアプリ開発でスコープクリープを防止する

従業員30名の受託開発会社。飲食店向け予約管理アプリの開発(予算 800万円、期間4か月)で、過去3案件連続でスコープクリープによる赤字が発生していた。

今回は開始時にスコープ定義書で「やらないこと」を 12項目 明記。変更リクエストフォームをNotionで運用した。

変更リクエスト件数承認却下延期
1か月目6件213
2か月目4件112
3か月目2件101
4か月目1件001

変更リクエストの件数自体が月を追うごとに減少。クライアント側も「変更には影響分析が必要」と理解し、不要な追加を自ら抑制するようになった。プロジェクトは予算内・納期通りに完了し、粗利率は 28% を確保(過去3案件平均は -5%)。

例2:メーカーのIT部門がERP導入でスコープを守り切る

従業員2,000名のメーカー。ERP導入プロジェクト(予算 3.5億円、期間24か月)。過去のERP導入では現場部門からの追加要望で予算が 1.8倍 に膨張した経験がある。

今回はPMOが3つの対策を実施した。

  • スコープ定義書に各部門の部門長が署名
  • 変更リクエスト1件ごとに「追加コスト」と「既存機能の何を削るか」を提示
  • 月次のスコープレビュー会議を設定し、累積変更量を可視化

24か月で受けた変更リクエスト 87件 のうち、承認は 23件(26%)。却下・延期の 64件 がそのまま通っていた場合、追加コストは 1.1億円 に達する計算だった。最終的な予算超過は 5%以内 に抑えられ、経営層から「初めてERP導入を予算内で完了できた」と評価された。

例3:デザイン事務所がブランディング案件のゴールドプレーティングを止める

従業員8名のデザイン事務所。中小メーカーのブランドリニューアル(予算 250万円)で、デザイナーが「せっかくだから」とパッケージデザイン案を 3案→7案 に増やし、撮影カットも 20枚→35枚 に拡大。結果、工数が 1.6倍 に膨張し利益がほぼゼロになった。

対策として、プロジェクト開始時に成果物一覧とその数量をスコープ定義書に明記するルールを導入。「デザイン案は3案まで」「撮影は20カットまで」と数字で上限を設定した。

追加したい場合はクライアントに追加費用を提示する。導入後6か月で5案件を完了し、ゴールドプレーティングによる工数超過は 0件。平均粗利率が 12%→31% に回復した。

やりがちな失敗パターン
#

パターン何が起きるか対策
「やらないこと」を定義しないあらゆる追加が「スコープ内かもしれない」と曖昧になるスコープ定義書に「スコープ外」セクションを必ず設ける
変更プロセスが重すぎる面倒がられてプロセスを迂回される小規模変更は簡易フォーム(5分で記入可能)を用意する
PMが1人で全部断る「PMが頑固」というレッテルを貼られ孤立する影響分析の結果を見せて、ステークホルダー自身に判断してもらう
ゴールドプレーティングを放置するチームの善意が赤字の原因になるスプリントレビューで「依頼された範囲に収まっているか」を毎回確認する

まとめ
#

スコープクリープ防止は、要件の膨張を仕組みと文化の両面から食い止めるアプローチ。開始時のスコープ定義書(特に「やらないこと」の明示)、進行中の変更管理プロセス、チーム内のゴールドプレーティング禁止が3本柱。変更を完全に拒否するのではなく、影響を可視化して合理的に判断する仕組みが、プロジェクトとステークホルダーの信頼を守る。