スコープクリープ すこーぷくりーぷ
簡単に言うとこんな感じ！
最初に「これだけ作ってね」って決めたのに、後から「あ、これも追加で」「こっちもお願い」が積み重なって、気づいたら最初の2倍の作業量になってた！っていう現象だよ。予算も納期もズルズル伸びる、IT開発あるあるの大敵なんだ！
スコープクリープとは
スコープクリープ（Scope Creep）とは、プロジェクト開始時に合意した作業範囲（スコープ）が、正式な承認プロセスを経ずに少しずつ拡大していく現象のことです。「creep（クリープ）」は英語で「じわじわ這い進む」という意味で、まさに気づかないうちにじわじわと範囲が広がっていく様子を表しています。
例えば、社内の勤怠管理システムを発注したはずが、途中から「有給申請機能も欲しい」「シフト管理も入れて」「給与計算とも連携させよう」と追加要求が積み重なり、当初の3倍の工数になってしまう——これがスコープクリープです。一つひとつの追加は小さく見えますが、積み重なると納期遅延・コスト超過・品質低下という深刻な問題を引き起こします。
ビジネスパーソンがシステム発注を行う立場では、「ちょっとした追加くらいいいだろう」という感覚が最大の落とし穴です。スコープクリープはプロジェクト失敗の最大要因のひとつとして、世界中のIT現場で認識されています。
スコープクリープの発生パターンと構造
スコープクリープにはいくつかの典型的な発生パターンがあります。
| パターン | 具体例 | 発生しやすいタイミング |
|---|---|---|
| 追加要求型 | 「この画面にボタンをもう一個追加して」 | 開発中盤〜後半 |
| 仕様変更型 | 「やっぱりこの項目は任意入力じゃなくて必須にして」 | テスト工程 |
| 前提漏れ型 | 「そっちでやってくれると思ってた」 | 要件定義後 |
| 範囲解釈ずれ型 | 「〇〇機能って当然スマホ対応も含むよね？」 | 設計工程 |
| 善意の追加型 | ベンダーが「ついでに」良かれと思って機能追加 | 開発中 |
🔑 覚え方：「じわじわカエル理論」
「熱湯に入れたカエルはすぐ逃げるが、水から少しずつ温めると逃げ遅れる」というたとえ話がありますよね。スコープクリープもまったく同じ構造です。一気に「3倍の作業を追加します」と言われれば発注者も気づきますが、小さな追加が少しずつ積み重なると誰も気づかないまま危機的状況に陥る——これがスコープクリープの本質です。
📊 スコープクリープの影響規模（業界統計）
- PMI（プロジェクトマネジメント協会）の調査では、プロジェクト失敗の原因としてスコープの不明確さ・変更が常に上位にランクイン
- スコープクリープが発生したプロジェクトでは、コストが平均20〜50%超過するケースが報告されている
- IT予算の約30%は当初計画外の追加要件に費やされているという試算もある
歴史と背景
- 1970年代〜 ウォーターフォール型開発が主流になるにつれ、要件定義段階での「合意」の重要性が認識され始める
- 1980年代 ソフトウェア開発の大規模化・複雑化とともに、スコープ管理の失敗によるプロジェクト崩壊が社会問題化。アメリカ国防総省の大規模システム開発での失敗事例が注目を集める
- 1996年 PMI（プロジェクトマネジメント協会）が PMBOK（プロジェクトマネジメント知識体系） 初版を発行。スコープ管理が独立した知識エリアとして体系化される
- 2000年代 アジャイル開発の普及により、変更を「悪」とみなさず反復的に管理する考え方が広まる。ただし、アジャイルでもバックログ管理の失敗によるスコープクリープは発生し続ける
- 2010年代以降 DX（デジタルトランスフォーメーション）推進で非IT部門が発注者になるケースが増加。スコープ管理の重要性が改めてクローズアップされる
スコープクリープを防ぐ対策と変更管理プロセス
スコープクリープへの最大の対策は「変更管理プロセス（チェンジコントロール）」を最初から仕組みとして組み込むことです。
発注者として押さえるべきポイント
ベンダーへの発注者として、以下の点を意識するだけでスコープクリープのリスクを大幅に下げられます。
- 「やること」だけでなく「やらないこと」を契約書に明記する
- 追加要求は必ず書面（メール・チケット）で記録し、口頭指示を避ける
- 「ちょっとだから無料でやって」は厳禁。小さな変更でも必ず工数確認する
- フェーズを分ける：まず必須機能だけでリリースし、追加機能は次フェーズへ
- 「要件定義凍結日」を設けて、それ以降の追加は次バージョンに先送りするルールを作る
関連する規格・RFC
| 規格・番号 | 内容 |
|---|---|
| PMBOK（PMI標準） | プロジェクトマネジメント知識体系。スコープ管理が独立した知識エリアとして定義されている |
| ISO 21500 | プロジェクトマネジメントに関する国際標準。スコープ管理プロセスを含む |
関連用語
- 要件定義 — システムに何をさせるかを明確化する工程。スコープクリープはここが甘いと起きやすい
- WBS（作業分解構造） — 作業を細かく分解してリスト化したもの。スコープの可視化に使う基本ツール
- 変更管理 — スコープ・コスト・スケジュールへの変更を正式プロセスで管理する仕組み
- プロジェクトスコープ — プロジェクトで実施する作業と成果物の範囲そのもの
- デスマーチ — スコープクリープなどが積み重なり、無謀な状態で続くプロジェクトの俗称
- アジャイル開発 — 反復的に開発を進める手法。変更を柔軟に受け入れるが、バックログ管理が重要
- ステークホルダー管理 — 関係者の要求・期待をコントロールする活動。スコープクリープの発生源管理に直結
- プロジェクト憲章 — プロジェクトの目的・スコープ・権限を定義する最初の公式文書