対象試験と出題頻度
スコープクリープは、応用情報技術者試験（AP）のプロジェクトマネジメント分野で出題されるテーマです。
プロジェクトマネジメントにおけるスコープ管理の失敗例として、PMBOKの考え方とあわせて問われます。
「変更管理プロセスを経ずに作業範囲が膨らむ現象」という核心を押さえれば、選択問題には十分対応できます。
詳細をクリックして確認
応用情報技術者
★★☆☆☆
ランクC（応用）余裕があれば覚える
用語の定義
プロジェクトマネジメントを勉強していると、「スコープクリープって、要するに仕様変更のこと？それともサボった結果？」と混乱しがちです。
スコープクリープ（Scope Creep）とは、一言で言うと
「正式な変更管理を経ないまま、プロジェクトの作業範囲がじわじわ拡大していく現象」
のことです。
イメージとしては、「家のリフォーム工事中の追加注文」です。
キッチンだけ直すはずだったのに、「ついでに洗面所も」「壁紙も貼り替えたい」と工事中に頼み続けた結果、予算と工期が大幅にオーバー。
一つ一つは小さな依頼でも、積み重なると別物の工事になってしまう、あの感覚です。
「Creep（クリープ）」は英語で「忍び寄る」「徐々に進む」という意味。気づかないうちに膨らんでいく、というニュアンスが込められています。
📊 スコープクリープの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Scope Creep |
| 分類 | プロジェクト・スコープ・マネジメントのリスク事象 |
| 関連知識体系 | PMBOK（スコープ・コントロール） |
| 主な影響 | 納期遅延、コスト超過、品質低下 |
解説
プロジェクトには「スコープ」と呼ばれる作業範囲が必ず存在します。
WBSや要件定義書で明文化され、納期・コスト・品質の見積もり根拠となる重要な境界線です。
ところが実際の現場では、ステークホルダーから「これも追加で」「あの機能も欲しい」という小さな要望が次々と舞い込みます。
一つ一つは些細でも、正式な手続きを踏まずに受け入れ続けると、当初の計画とは別物のプロジェクトに変質してしまう。これがスコープクリープの正体です。
なぜ起きるのか：主な原因
| 原因 | 具体的な状況 |
|---|---|
| 要件定義の曖昧さ | 初期の合意が抽象的で、後から解釈の余地が広がる |
| 変更管理プロセスの欠如 | 追加要求を承認・記録する仕組みがなく、口約束で受け入れる |
| ステークホルダーの圧力 | 顧客や上層部の追加要望を断れない関係性 |
| ゴールドプレーティング | 開発側が「サービスで」機能を盛り込んでしまう |
要件定義の失敗から工数が膨らむまで
ECサイト構築プロジェクト（当初見積：6人月）を例に、スコープクリープが進行する典型的な流れを追ってみます。
📈 ECサイト構築プロジェクトでの工数膨張シナリオ
① 要件定義フェーズ：曖昧な合意でスタート
顧客「商品が買えるサイトが欲しい」／開発「了解しました」で着手
合意した作業：商品一覧・カート・決済機能 ／決済手段や会員機能の範囲は未定義のまま
見積工数：6.0人月 （基準）
② 設計フェーズ：「ついでに」が積み上がる
顧客「クレカ決済だけじゃなくPayPayも対応して」「会員ランク機能も欲しい」
追加された作業：+ 決済手段3種対応（+1.0人月）／+ 会員ランク管理（+0.8人月）
累計工数：7.8人月 （+30%） 口約束で受領、変更管理書なし
③ 実装フェーズ：仕様の解釈ズレが発覚
顧客「カートは当然、お気に入り保存もあるよね？」「在庫切れ通知メールも標準でしょ？」
追加された作業：+ お気に入り機能（+0.5人月）／+ メール通知基盤（+1.2人月）／+ 既存機能の改修（+0.7人月）
累計工数：10.2人月 （+70%） PMが断れず受容
④ テストフェーズ：手戻りと品質低下で破綻
追加機能同士の結合バグが多発／テスト工数も当初想定の倍に
追加された作業：+ 結合不具合の修正（+0.8人月）／+ テスト再実施（+0.7人月）
累計工数：11.7人月 （+95%／当初の約2倍） 納期遅延・赤字確定
📊 フェーズごとの工数推移（人月）
▲ 要件定義時の「曖昧な合意」が原因で、フェーズが進むほど追加要求が雪だるま式に増加
類似用語との違い
混同しやすい用語を整理しておきます。
| 用語 | 違いのポイント |
|---|---|
| スコープクリープ | 変更管理を経ずに作業範囲が拡大する「失敗事象」 |
| 変更管理 | 追加要求を正式に評価・承認する「プロセス」 |
| ゴールドプレーティング | 開発側が依頼されてもいない機能を追加する行為 |
| スコープキープ | スコープを維持する取り組み（スコープクリープの対義的概念） |
防止策
PMBOKでは、スコープ・コントロール・プロセスとして以下の対策が示されています。
✅ 主な防止策
① スコープ記述書とWBSを明文化し、何を作り何を作らないかを合意する
② 変更管理委員会（CCB）を設置し、追加要求は必ず審議を通す
③ 変更による影響（コスト・納期・品質）を定量的に提示し、依頼者に判断材料を渡す
④ ベースラインとの差分を定期的にモニタリングし、早期に逸脱を検知する
では、この用語が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
スコープクリープは応用情報技術者試験の午前問題で、プロジェクトマネジメント分野のキーワード問題として登場します。出題されたとき確実に得点できるよう、頻出パターンを押さえておきましょう。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R元秋 午前 問52 |
プロジェクトのスコープに関わる事象の説明として適切なものを選ぶ問題。 | ・「正式な変更管理を経ずに、スコープが少しずつ拡張する現象」が正解 ・スコープ・クリープという用語そのものを問う形式 |
| AP H29秋 午前 問51 |
スコープ・コントロールで実施する活動として最も適切なものを選ぶ問題。 | ・「スコープのベースラインに対する変更を管理する」が正解 ・WBS作成・スコープ定義はスコープ計画側でひっかけ |
📝 出題パターンと攻略法
パターン1：用語の定義を問う
「少しずつ」「徐々に」「正式な変更管理を経ずに」「気づかないうちに」というキーワードが選択肢に並んでいたら、スコープクリープが正解の合図です。逆に「計画的に」「承認された」という表現が混ざる選択肢はダミーです。
パターン2：対策の選択
「スコープ・コントロール」「変更管理プロセス」「ベースラインとの差分監視」が正解の選択肢に来ます。「要員追加」「予算増額」は対症療法であって根本対策ではないため、正解にはなりにくいです。
ひっかけ注意
「ゴールドプレーティング」（開発者が善意で機能を追加する行為）と混同させる選択肢が出ます。主体が顧客側か開発側かで見分けてください。深追いは不要、ここまでで十分得点できます。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. プロジェクトマネジメントにおける「スコープクリープ」の説明として、最も適切なものはどれでしょうか？
- A. プロジェクトの開始時にWBSを用いて作業範囲を体系的に分解し、見積もり精度を高める活動のこと。
- B. 正式な変更管理プロセスを経ないまま、プロジェクトの作業範囲が少しずつ拡大していき、納期やコストに影響を及ぼす現象のこと。
- C. 開発担当者が依頼されていない機能や品質向上を独自の判断で追加してしまい、結果的に工数が膨張する行為のこと。
正解と解説を見る
正解：B
解説：
スコープクリープは、ステークホルダーからの追加要求や曖昧な要件が積み重なり、変更管理の手続きを踏まないままプロジェクトのスコープが拡張してしまう現象を指します。「Creep（忍び寄る）」という語のとおり、気づいたときには手遅れになる点が問題の本質です。
選択肢Aは「スコープ定義／WBS作成」の説明であり、スコープ計画プロセスの活動です。スコープクリープのような失敗事象ではなく、健全な計画策定を指します。選択肢Cは「ゴールドプレーティング」の説明です。要求されていない付加価値を開発側が独断で盛り込む行為であり、スコープが拡大する原因の一つではあるものの、スコープクリープそのものではありません。主体が顧客側の追加要求の蓄積であるか、開発側の独自判断であるかで区別してください。
よくある質問（FAQ）
Q. アジャイル開発でもスコープクリープは発生しますか？
発生します。むしろ「変更を歓迎する」アジャイルだからこそ油断するとリスクが高まります。アジャイルではスプリント単位でスコープを区切り、プロダクトバックログの優先順位を整理することで対処します。スプリント中のスコープ追加は原則禁止というルールが、スコープクリープ対策として機能します。
Q. スコープクリープが起きたとき、プロジェクトマネージャーは何から手をつけるべきですか？
まず現状のスコープと当初計画の差分を可視化することから始めます。次に、追加された作業を分類し、本当に必要なものと削減できるものを整理。最後にステークホルダーに対して納期・コスト・品質のトレードオフを数値で提示し、再ベースライン化の合意を取り付けます。気合いで巻き返そうとせず、まず事実を並べることが鉄則です。
Q. スコープクリープと「クリープ現象」（材料力学）は関係ありますか？
直接の関係はありませんが、語源は同じ「Creep（じわじわ進む）」です。材料力学では金属が一定の応力下で時間をかけて変形する現象を指し、プロジェクトマネジメントでは作業範囲が時間とともにじわじわ膨らむ現象を指します。どちらも「気づきにくい持続的変化」という共通点があるため、語のイメージはつかみやすいはずです。
Q. 顧客との関係を悪化させずに追加要求を断るコツはありますか？
「断る」のではなく「条件を示す」のがコツです。追加要求に対して即答するのではなく、影響評価のうえで「実施した場合の納期は◯週間延長、追加コストは◯万円」と数字で返します。顧客自身に判断を委ねる形にすれば、関係を保ちつつ無秩序な拡張を防げます。これはPMBOKの「統合変更管理」の考え方そのものです。
