スコープクリープとは?
スコープクリープ(scope creep)は、正式な承認を経ずに、プロジェクトのスコープが少しずつ広がっていく現象です。creep は「忍び寄る」という意味の英語です。気づいたときには大きく広がっている様子を表しています。
1つ1つの追加は小さく見えます。「画面に項目を1つ足すだけ」「帳票を1種類増やすだけ」。しかし、それぞれに設計・試験・文書の更新が伴います。積み重なると、予算超過と遅れの大きな原因になります。
大事なのは、スコープが変わること自体は悪くないという点です。問題は、影響を分析せず、承認も受けずに変わることです。正式な手続きを経た変更は、スコープクリープとは呼びません。
追加の工数 = 1件あたりの工数 × 件数
- 11件の小さな修正:設計1時間+実装2時間+試験2時間+文書1時間=6時間
- 22か月で40件:6時間×40件=240時間
- 31人の月の作業時間を160時間とすると:240÷160=1.5人月
- 4どれもベースラインに無いので、計画上の進み具合には表れない
1件6時間の追加でも、40件で1.5人月。予算と納期への影響は小さくない
架空の数値
追加分はベースラインに無いので、EV(出来高)は増えず、AC(実際の費用)だけが増えます。その結果 CPI が下がり、原因の分からない予算超過に見えます。
スコープクリープが起きる主な原因は?
当サイトで整理した主な原因は次のとおりです。
| 原因 | 具体例 | 対策の方向 |
|---|---|---|
| スコープの定義があいまい | 「使いやすい画面」など、解釈の幅が広い表現 | 受入基準を測定できる形で書く |
| 除外事項が書かれていない | データ移行が含まれるか誰も確認していない | やらないことを明記して合意する |
| 関係者からチームへの直接の依頼 | 顧客の担当者が開発者に「ついでに」と頼む | 依頼の窓口と流れを決めて周知する |
| 変更管理の手続きが無い・守られない | 小さな変更は手続き不要という空気 | 変更はすべて記録し、影響を分析する |
| 要求事項の収集の不足 | 後から本当のニーズが出てくる | 初期に関係者を広く巻き込み、試作で確かめる |
| 関係者の期待を管理していない | 顧客が「この程度は込み」と考えている | 定期的にスコープと期待を確認する |
要求事項の集め方が不十分だと、後から「本当はこれも必要だった」が出てきます。集める段階の工夫は要求事項の収集方法で扱います。
スコープクリープを防ぐ仕組みは?
防ぐには、個人の注意力より仕組みに頼ります。予測型のプロジェクトでよく使う仕組みを順に挙げます。
- スコープを測定できる形で合意する:成果物、受入基準、除外事項をスコープ記述書に書きます。スポンサーと主要な関係者の承認を得ます。
- WBSで全体を見える化する:WBSに無い作業はスコープ外、という線を引けるようにします。
- 依頼の窓口を決める:関係者の要望は、チームに直接ではなく、決められた窓口を通します。窓口は PM やプロダクトオーナーです。キックオフで、この流れを説明します。
- 変更はすべて手続きに乗せる:小さな変更も記録し、影響を分析し、決められた権限者が判断します。PM が決めてよい範囲を決めておくと、速く回ります。
- 追加の依頼には選択肢を示す:時期をずらす、他の項目と入れ替える、費用と期間を足す、などを示して判断してもらいます。
- 定期的にスコープを確認する:進捗報告の場で、スコープの状態と変更の状況を共有します。
2026年版の ECO は、Process タスク2のイネーブラーに「スコープについて関係者の合意を得る」を挙げています。旧版(2021年版)のスコープのタスクには無かった項目です。合意そのものが、スコープ管理の一部だと示しています。
変更を受け付けてから反映するまでの手順は、PMPの変更管理の手順で詳しく解説しています。新しい ECO では変更管理が Business Environment のタスク3にあり、スコープの管理と組み合わせて問われます。
スコープクリープが起きたら何をする?
すでに広がってしまったときの対応は、次の順番が基本です。PMP の状況問題でも、この筋で選択肢を見分けます。
- 事実を記録し、状況を確かめる:何が、誰の依頼で、どこまで進んでいるかを確かめます。承認の無い作業は、いったん止めます。
- 影響を分析する:コスト・スケジュール・品質・リスクへの影響を、数字で示します。
- 正式な判断に乗せる:予測型なら変更要求として、権限者に判断を仰ぎます。アジャイルならプロダクトオーナーに渡し、バックログの優先順位で判断します。
- すでに行った追加も整理する:まとめて変更として扱い、残すか戻すかを決めてもらいます。
- 再発を防ぐ:依頼の窓口と流れを、関係者に改めて説明します。
「顧客が喜ぶから作る」「小さいから手続きは省く」「依頼をすべて断る」という選択肢は、ほぼ誤りです。前の2つは承認を飛ばし、最後の1つは必要な変更まで拾えなくします。
ゴールドプレーティングとの違いは?
似た言葉にゴールドプレーティング(gold plating:金メッキ)があります。どちらも承認の無い追加ですが、誰が持ち込むかが違います。
スコープクリープ
- 追加の出どころ顧客や関係者の要望
- 起き方外から少しずつ持ち込まれる
- 典型的な言い分「ついでにこれも」
- 主な防ぎ方依頼の窓口と変更管理
ゴールドプレーティング
- 追加の出どころチーム(またはPM)自身
- 起き方内側から自発的に足される
- 典型的な言い分「喜ばれると思って」
- 主な防ぎ方要求どおりに作る文化と確認
当サイトの整理
ゴールドプレーティングは善意から起きますが、PMP ではやるべきではない行為とされます。頼まれていない機能にも、試験と保守の負担が生じます。リスクが増え、コストと時間も使います。顧客が本当に必要としているかも分かりません。
よいアイデアが浮かんだら、黙って作らず、提案として出して通常の手続きで判断してもらいます。詳しくはゴールドプレーティングとは?で扱います。
アジャイルではスコープクリープは起きない?
アジャイルは変化を歓迎するので、スコープクリープとは無縁と思われがちです。しかし、似た問題は起きます。
アジャイルでは、時間(スプリントの長さ)とチームの規模をおおむね固定し、その中で価値の高い順に作ります。新しい要望はプロダクトバックログに加え、プロダクトオーナーが並べ替えます。追加した分、優先度の低い項目は後ろに回ります。これがアジャイルのスコープ管理です。
問題になるのは、スプリントの途中で作業を割り込ませることや、プロダクトオーナーを通さずにチームへ直接頼むことです。スプリントの目標が揺らぎ、チームの見通しが崩れます。優先順位を付けずに「全部やる」と約束するのも、形を変えたスコープクリープです。
PMP試験ではどう問われる?
試験では、スコープクリープという言葉を答えさせるより、承認の無い追加にどう対応するかが問われます。新しい ECO では、Process タスク2(スコープ)と Business Environment タスク3(変更管理)の両方に関わります。
選択肢を見分けるときは、前の節の「起きたら何をする?」の順番に当てはめます。分析の前に承認を求める、承認の前に作業を続ける、といった順番の誤りがよく紛れています。こうした場面の判断は無料模試30問で確かめられます。
POINT
よくある誤答:「顧客の担当者が頼んだので、記録せずに対応する」「変更要求を出し、承認を待つ間に作業を進めておく」。どちらも、決められた判断の手続きより先に作業が進んでいます。
確認問題1
チームが自発的に機能を足した
(当サイトの独自問題)開発チームのリーダーから報告がありました。「空いた時間で、要件に無いデータの一括出力機能を作っておいた。顧客は喜ぶはずだ」という内容です。この機能はスコープに含まれておらず、試験もまだ行っていません。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:1。これはゴールドプレーティングです。頼まれていない追加は、試験・保守の負担やリスクを生みます。チームに理由を説明したうえで、含めるかどうかは顧客と正式な手続きで決めます。
2・3:承認の無いスコープの追加を、そのまま認めています。4:承認の前に、追加分の作業を進めています。
確認問題2
小さな依頼が積み重なっている
(当サイトの独自問題)予測型のプロジェクトで、実績工数が計画を15%上回っています。調べると、顧客の担当者が開発者に個別に頼んだ画面の小さな修正が、この2か月で40件以上ありました。どれも変更要求は出ていません。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:4。スコープクリープが起きています。まず影響を分析して、関係者に見えるようにします。そのうえで、依頼を変更の手続きに乗せる流れを顧客と合意し直します。すでに行った変更も、まとめて正式に扱います。
1:原因が残り、超過が続きます。2:依頼の中に必要な変更があっても、拾えなくなります。3:仕組みの問題を、個人の問題にすり替えています。
確認問題3
スプリント途中の割り込み
(当サイトの独自問題)スクラムで開発中、スプリントの3日目に、マーケティング部長がチームに直接頼みました。「来週の展示会のデモ用に、新しい画面を今のスプリントで作ってほしい」という内容です。スプリントの作業は計画どおり進んでいます。プロジェクト・マネジャー(サーバント・リーダー)が次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:2。何を作るかの優先順位を決めるのは、プロダクトオーナーです。依頼をバックログに入れ、スプリントの目標への影響も含めて判断してもらいます。
1:チームの持続可能なペースを崩します。3:スプリントの中止はプロダクトオーナーが判断する、まれな手段です。4:要望を検討もせずに断り、関係者との協働を損ねます。