スコープクリープ：原因、例、防止策

スコープクリープとは何ですか？

スコープクリープ とは、時間、コスト、資源を相応に調整しないまま、プロジェクトのプロダクトスコープまたはプロジェクトスコープがコントロールされずに拡大することです。スコープの合意後に新しい機能、成果物、タスクが追加されたのに、誰もその影響を評価せず、正式に承認せず、それを反映して計画を更新しない場合に起こります。

PMIの用語集もほぼこのとおりの捉え方をしており、これは有用な判断基準になります。作業が追加されたのに、 スコープベースライン、スケジュール、予算が変わっていなければ、スコープクリープが起きています。

2種類のスコープを区別すると役立ちます。 プロダクトスコープ は、検索機能や購入手続き機能を備えたWebサイトなど、作るものの機能と特性です。 プロジェクトスコープ は、それを提供するために必要な作業で、設計、構築、テスト、研修、ローンチなどです。スコープクリープはどちらにも影響しえます。クライアントがライブチャット機能を求めればプロダクトスコープが拡大し、スポンサーがチームに10年分のアーカイブデータの移行も求めればプロジェクトスコープが拡大します。

「クリープ（忍び寄る）」という言葉がポイントです。1つの大きな変更は通常気付かれ、話し合われます。スコープクリープは、正式な手続きを取るには小さすぎるように見える多数の小さな変更の積み重ねです。レポートをもう1つ、修正をもう1回、ログインページのちょっとした調整。1つひとつは無害に見えても、合わさると数週間分になることもあります。

スコープクリープはよくあることでもあります。PMIの*Pulse of the Profession*2018年版レポートによると、過去12か月間に完了したプロジェクトの52%がスコープクリープを経験しており、5年前の43%から増加しています。

当サイトの プロジェクトスコープ のガイドでは、そもそもスコープを適切に定義する方法を解説しています。

スコープクリープとスコープ変更、金メッキ、フィーチャークリープの違い

スコープの変更がすべてスコープクリープというわけではありません。プロジェクトは進めながら学ぶものであり、価値を高める承認済みの変更は優れたプロジェクトマネジメントの一部です。違いはコントロールの有無です。

金メッキ（ゴールドプレーティング） は、チーム内部から生じるスコープクリープの一種です。通常は善意によるものですが、時間と予算を消費し、リスクを増やし、顧客が求めてもいない部分に不具合を持ち込むこともあります。 フィーチャークリープ は、同じパターンをプロダクト開発の観点から表した用語で、プロジェクトではなくプロダクトに焦点を当てています。

スコープクリープの原因は？

スコープクリープには、ほぼ必ず複数の原因があります。ここでは特によく見られるものを紹介します。

不明確なスコープと要求事項

もし スコープ記述書 が曖昧（「モダンなWebサイト」「レポートの改善」など）だと、ほぼどんな依頼もスコープ内だと主張できてしまいます。欠落していたり大まかに書かれていたりする 要求事項 や受入基準は解釈の余地を残し、その余地は追加作業で埋まりがちです。

正式な変更管理がない

明確に定められた 変更管理 プロセスがないと、「はい、ただしこれだけのコストがかかります」と伝える合意された方法がありません。依頼はひっそりと受け入れられるか、気まずく断られるかのどちらかになり、ひっそりと受け入れられたものがスコープクリープになります。

ステークホルダーがプロジェクトマネージャーを飛ばす

メール、チャット、会議でデザイナーや開発者に直接送られる依頼は、プロジェクトマネージャーを経由しません。チームメンバーは助けたいと思って作業を行い、計画にはそれが一切反映されません。

金メッキと善意

チームは顧客を感心させるために、機能を追加したり仕上げにこだわったりすることがあります。良いサービスのように感じられますが、計画に含まれていない時間を使い、今後のプロジェクトへの期待値を上げてしまうこともあります。

長期のプロジェクトと変化するビジネスニーズ

プロジェクトが長引くほど、それを取り巻くビジネスは変化します。新しい規制、新しい競合、新しい経営陣などです。そうした変化の中には正当なものもありますが、そのまま吸収するのではなく評価する必要があります。

弱いスポンサーシップと商業的なプレッシャー

トレードオフの判断に関与しないスポンサーでは、プロジェクトマネージャーが押し返すための後ろ盾がありません。クライアント案件では、クライアントを怒らせることへの恐れ（あるいは曖昧な 作業範囲記述書を伴う固定価格契約）から、依頼を提起するよりも吸収してしまいたくなります。

スコープクリープの例

以下の例は、さまざまな種類のプロジェクトでスコープクリープがどのように現れるかを示しています。いずれの場合も、最初の依頼は妥当なものでした。問題は、それが時間とコストに照らして評価されなかったことです。

実例：小さな依頼が積み重なる仕組み

公開日が固定された12週間のWebサイトプロジェクトを想像してください。6週間の間に、クライアントが5つの「小さな」依頼をし、それぞれが非公式に合意されます：

• ランディングページの追加（3日）。
• クライアントのメール配信プラットフォームと連携したニュースレター登録（2日）。
• ホームページのデザイン修正の3回目（3日）。
• Cookieバナーのカスタマイズ（1日）。
• 過去のブログ記事40本のインポート（4日）。

どれも単独では大したことがないように見えますが、合わせると12週間の計画に13営業日、つまり3週間近くが加わります。スケジュールも予算も何も変わっていないため、チームは残業し、テストは短縮され、公開は遅れるか、不具合を抱えたまま公開されることになります。

では、同じ依頼を変更管理に通してみましょう。それぞれが記録され、影響が示され、クライアントが選択します。ランディングページとニュースレター登録は1週間の延長と追加予算を伴って承認され、ブログのインポートはフェーズ2に移され、追加のデザイン修正は優先度の低いページと入れ替えられます。プロジェクトは依然として拡大しますが、それは意図的な拡大です。

スコープクリープの影響

スコープクリープがプロジェクトに打撃を与えるのは、 三重制約があるためです。スコープ、時間、コストは連動しています。スコープが拡大し、他の2つが動かなければ、何か別のもの、多くの場合は品質かチームが犠牲になります。

• スケジュールの遅延： 追加作業によってマイルストーンが後ろにずれ、多くの場合まずクリティカルパスがその影響を受けます。
• 予算超過： 工数、資材、サプライヤーの費用が増えるのに、それを賄う予算がありません。
• 品質の低下： 期限を守るために、テスト、レビュー、ドキュメントが圧迫されます。
• チームの燃え尽き： どの計画にも載っていない作業のために長時間働くことになり、士気が損なわれます。
• 信頼の低下： 自分たちが追加を依頼したにもかかわらず、ステークホルダーは日程が遅れると驚きます。
• 便益の遅れ： プロジェクトの中核的な価値がユーザーに届くのが、本来よりも遅くなります。
• 報告の質の低下： ベースラインが実際の作業を反映しなくなるため、進捗率が意味を失います。

商業プロジェクトでは、さらに請求されない作業というコストがあります。スコープクリープを吸収する代理店やコンサルティング会社は、それが起きるプロジェクトのたびに利益を失います。

スコープクリープの警告サイン

スコープクリープは早期に発見するほど対処しやすくなります。次のサインに注意しましょう：

• ボードやタイムシートに、次に含まれていないタスクが現れる： WBS（ワーク・ブレークダウン・ストラクチャー）.
• 依頼が合意された受付ルートではなく、メール、チャット、会議で届く。
• 「ついでに」「5分で済むはず」「それは含まれていると思っていた」といった言葉を耳にする。
• 作業開始後に受入基準が書き換えられる。
• チームは残業しているのに、スケジュールに変化がない。
• 成果物が何週間も「ほぼ完了」のままになっている。
• バーンアップチャートのスコープ線が上がり続ける、またはバックログがチームの提供速度を上回るペースで増える。
• 内容がよく理解されているタスクで、実際の工数が見積りを大きく上回る。
• 計画に関わっていなかったステークホルダーが、プロジェクトの終盤になってソリューションの方向性に口を出し始める。

スコープクリープを防ぐ方法

防止の要点は、スコープについて明確に合意し、変更の扱い方について事前に合意することです。以下の手順は、規模を問わず従来型やハイブリッド型のプロジェクトで効果があります。

1. 明確な目標について合意する。 次の文書に測定可能な目標を書き、 プロジェクト憲章 すべての依頼をそれに照らして検証できるようにします。その依頼は目標の達成に役立つか、と。
2. 要求事項を適切に収集する。 費用を払う人だけでなく、成果を使う人も巻き込み、優先順位付きで次を記録します： 要求事項 。
3. 除外事項を含むスコープ記述書を書く。 スコープ内のものと、同じくらい重要なスコープ外のものを列挙します。除外事項があれば、「それは含まれていると思っていた」という会話を防げます。
4. 作業を分解する。 次を作成します： WBS（ワーク・ブレークダウン・ストラクチャー） とWBS辞書を作成し、スコープ全体を見えるようにして、すべての 成果物 に定義を持たせます。
5. 受入基準を定義する。 各成果物について、完了をどのように判断するかに合意します。受入基準を動かすことは、最も目立たないスコープクリープの1つです。
6. 承認を得てベースラインを設定する。 スポンサーまたはクライアントに、スコープ記述書、WBS、WBS辞書を承認してもらいます。これらが合わさって、変更を測定する基準となるスコープベースラインになります。
7. 必要になる前に変更管理を整える。 依頼をどのように記録し、誰が評価し、誰が承認し、計画をどのように更新するかについて合意します。小規模なプロジェクトでは軽量にしておきましょう。
8. 受付ルートを一本化する。 ステークホルダーには、すべての依頼をプロジェクトマネージャーに送るか依頼フォームを使うよう求め、チームには、ルート外の依頼を丁寧に正規ルートへ誘導するよう求めます。
9. 定期的にコミュニケーションを取る。 一定のリズムで 状況報告書 とレビューを行い、ステークホルダーが進捗を確認でき、意見を聞いてもらえていると感じられるようにします。これにより非公式な依頼が減ります。
10. 契約に変更条件を盛り込む。 クライアント案件では、作業範囲記述書に変更の依頼、価格設定、承認の方法を明記すべきです。

なお、 プロジェクトスコープのテンプレート は、目標、成果物、対象範囲、対象外、受入基準、制約条件、前提条件を網羅しており、上記の下準備の大部分を1つの文書で行えます。

変更管理は、この一覧の中で最も重要なコントロールです。

スコープクリープが起きたときの対処法

よく計画されたプロジェクトにも新しい依頼は来ます。目的は変更を拒むことではなく、すべての変更を可視化し、意図的なものにすることです。

新しい依頼への段階的な対応

1. 合意する前に一呼吸置く。 依頼者に感謝し、影響を確認すると伝えます。その場での即答は避けましょう。
2. 記録する。 依頼を変更ログまたは次に記録します： 変更要求テンプレート。何が、誰から、なぜ求められているかを記録します。
3. ベースラインと照合する。 本当に新しいものか、それとも既存の要求事項や受入基準ですでにカバーされているものか？
4. 影響を評価する。 スケジュール、コスト、資源、品質、リスクへの影響を見積もります。作業を行うことになる人々を巻き込みましょう。
5. 選択肢を用意する。 単一の答えではなく、現実的な選択肢を提示します（下表を参照）。
6. 適切な人から決定を得る。 決定するのは、依頼を受けたチームメンバーではなく、スポンサー、クライアント、または変更管理委員会です。
7. 計画を更新する。 承認された場合は、スコープ記述書、WBS、スケジュール、予算、リスク登録簿を更新し、ベースラインを再設定します。
8. 結果を伝える。 依頼者、チーム、その他のステークホルダーに、何が決まり、何が変わるかを伝えます。

ステークホルダーに「いいえ」（または「はい、ただし」）と伝える方法

きっぱり断ると、特にクライアントや上級のステークホルダーとの関係を損なうことがあります。通常は、トレードオフを示して意思決定者に選んでもらうほうがうまくいきます：

個人の好みではなく、プロジェクトの目標について話すようにし、結果は文書に残しましょう。当サイトの ステークホルダー・マネジメント のガイドでは、さまざまなタイプのステークホルダーとこうした会話を進める方法を解説しています。

アジャイルのプロジェクトにおけるスコープクリープ

アジャイルのアプローチは、スコープが変わることを前提としています。これはアジャイルチームがスコープクリープと無縁だという意味ではなく、変化の扱い方が異なるという意味です。

スクラムでは、既知の作業はすべて プロダクトバックログに置かれ、 プロダクトオーナー が順序を付けます。スクラムガイド2020によると、スプリント中はスプリントゴールを危うくする変更は行わず、理解が深まるにつれてプロダクトオーナーとスコープを明確化・再交渉できます。そのため、新しいアイデアは開発者に直接ではなくバックログに送られ、十分な価値があれば将来のスプリントで スプリントプランニング の際に取り込まれます。

通常、時間とコストはイテレーションごとに固定され、スコープが変数になります。アジャイルにおけるスコープクリープは、従来型のプロジェクトとは異なる形で現れます：

• ステークホルダーが開発者に、現在のスプリントへ作業を紛れ込ませるよう頼む。
• スプリントの途中で計画外の作業が取り込まれ、スプリントゴールが繰り返し未達になる。
• バックログが順序付けもリファインメントもされないまま膨らみ、何も優先度が下げられない。
• リリース日と全機能のリストの両方が固定として扱われる。
• 共有された次がないため、「完成」の意味がいつの間にか変わる： 完了の定義.

スコープ線を別に描いたバーンアップチャートを使えば、これが見えるようになります。スコープ線が完了作業の線と同じ速さで上がっていれば、リリース日は永遠に来ません。ベロシティの追跡もここで役立ちます。当サイトのガイドをご覧ください： アジャイルのベロシティチャート.

スコープのコントロールに役立つツールとテンプレート

スコープのコントロールに専門ソフトウェアは不要ですが、いくつかの文書があるとずっと楽になります：

• プロジェクトスコープテンプレート：目標、成果物、対象範囲、除外事項、受入基準、制約条件、前提条件。
• 変更要求テンプレート：スコープ、スケジュール、コストへの影響を記録する変更要求フォームと変更ログ。
• WBSテンプレート：WBSコード、階層、成果物、担当者、工数、コスト。
• RAIDログテンプレート：リスク、前提条件、課題、依存関係。スコープが依存する前提条件も含みます。
• ビジネス要求文書テンプレート：構築前に合意した要求事項と優先順位。

多くの人から依頼が寄せられる場合は、プロジェクト管理ソフトウェアが役立ちます。依頼フォーム、承認ワークフロー、可視化されたベースラインにより、ルート外の作業が減ります。当サイトのランキング第1位のツール Wrikeは、複数のプロジェクトにまたがる構造化された依頼フォームと承認を求めるチームに適しています。他のツールもこれをうまく扱えることは、当サイトの プロジェクト管理ソフトウェアランキング で説明しています。

避けるべきよくある間違い

• あらゆる変更を悪とみなす。 すべての依頼を拒否するとステークホルダーの不満が募り、誰も必要としないものを提供するプロジェクトになりかねません。変更は阻止するのではなく、コントロールしましょう。
• 口頭での承認を受け入れる。 文書に残っていなければ、後で違う形で記憶されています。
• 小さな変更を無視する。 上の実例は、記録されない小さな依頼が何週間分もの作業になる様子を示しています。
• 除外事項を書かない。 スコープ外の一覧がないスコープ記述書は、思い込みを招きます。
• チームに金メッキをさせる。 その意図は認めつつ、追加のアイデアは変更要求やバックログに回しましょう。
• ベースラインを再設定せずに変更を承認する。 計画が更新されなければ、進捗報告は誤解を招くものになります。
• プロセスを重くしすぎる。 1日分の変更に10ページの様式を求めると、人々はそれを迂回するようになります。プロセスは変更の規模に合わせて調整しましょう。

変更管理と組織変革の違いについて全体像を知りたい場合は、次をお読みください： チェンジマネジメントと変更管理.

このトピックの無料テンプレート

すべてのテンプレートを見る

よくある質問