プロジェクト変更管理のコツ｜「ついでに」の要望が招くスコープクリープの防ぎ方

本連載について
この記事は、難解なプロジェクトマネジメントのノウハウを、誰もが経験したことのある「家族旅行」に例えてわかりやすく解説する全12回のシリーズです。（※どの回からでも単独でお読みいただけます）

第11回となる今回は、「ついでにお願い」が招く要件肥大化を防ぐ「変更管理（スコープクリープの防ぎ方）」についてお届けします！

「『ついでにこれもお願い』と軽く頼まれた作業が、実は数日かかる重労働だった……」
「断りきれずにお客様の要望をすべて受け入れていたら、納期に間に合わなくなってしまった」

プロジェクトの終盤、ゴールが見えてきた頃に必ずやってくるのが「変更の嵐」です。お客様や他部署からの「ちょっとした追加要望」を安易に受け続けてしまうと、気づいたときには作業量が制御不能なほど膨れ上がってしまいます。これを専門用語で「スコープクリープ（要件の肥大化）」と呼びます。

今回は、プロジェクトを崩壊の危機から救う「変更管理」の極意と、角を立てずに要望をコントロールする交渉術を解説します。

なぜ「ちょっとした寄り道」が命取りに？スコープクリープの恐怖

家族旅行の帰り道、目的地まであと少しというところで「あ、せっかくだからあそこの有名なパン屋さんも寄っていこうよ！」と誰かが言い出したとします。

「パンを買うだけなら10分で済むし、いいよ」と二つ返事で寄り道を決めた。ところが……

結果として、レンタカーの返却時間に間に合わず追加料金を払うことになり、家族全員が疲れ果ててしまう。これがプロジェクトにおける「スコープクリープ（変更管理の失敗）」の典型例です。

一つの小さな変更（機能追加や仕様変更）は、単体では小さく見えても、スケジュールやコスト、他のシステムとの整合性に「連鎖的な悪影響」を及ぼします。

追加要望が来たとき、PMが条件反射で「やります（YES）」や「できません（NO）」と答えるのは危険です。まずは冷静に、以下の4ステップで状況を判断してみてはいかがでしょうか。

その寄り道（変更）に、あと何時間（何円）かかるのか？他のタスクにどう響くのかを計算します。

第2回の計画書で決めた「この旅で一番大事な目的」と照らし合わせます。

何かを追加するなら、何かを削る。これが変更管理の鉄則です。

PM一人で抱え込まず、予算や納期に責任を持つ人と合意します。

さらに詳しく知りたい方へ
変更要求を評価する際の具体的な判断基準や、スケジュール遅延を最小限に抑えるための実戦的な運用フローについては、こちらの記事「【台帳項目・フロー付】プロジェクト変更管理の鉄則｜「ついでに」の仕様変更から炎上を防ぐ4ステップ」で詳しく解説しています。

お客様からの要望を「ムリです」と無下に断ると、信頼関係が悪化してしまいます。そんな時は、相手の面目を保ちつつプロジェクトを守る「代案」を提示して交渉しましょう。

代案A：次期フェーズへ回す（時期をずらす）
- 交渉の例：「非常に素晴らしいアイデアですね！ただ今のスケジュールに入れるとリリースが遅れてしまうため、次のアップデート（第2フェーズ）の目玉機能として実装しませんか？」
代案B：段階的に導入する（機能を絞る）
- 交渉の例：「ご要望の高度なダッシュボード画面を今から実装するのは時間がかかりますが、まずはCSVデータのダウンロード機能のみ先行して提供する（＝簡易的な機能でまずはリリースする）形ではいかがでしょうか？」
代案C：トレードオフ（作業を入れ替える）
- 交渉の例：「その機能、ぜひやりましょう！ただリソースが限界なので、代わりに予定していた〇〇の機能を今回は見送る（＝等価交換する）ということで進めてよろしいでしょうか？」