「ちょっとこの機能も追加してもらえる？簡単でしょ？」
金曜日の午後、顧客からのメッセージ。私の心臓が止まりそうになった瞬間でした。
当初3ヶ月の見積もりだったECサイトリニューアルプロジェクト。「ちょっとした追加」の連続で、最終的に8ヶ月、約3倍の予算に膨張。チームは疲弊し、品質は低下、顧客満足度も目標を大きく下回りました。
私はプロジェクトマネージャーとして、完全に失敗したのです。
でも、この失敗から学んだことがあります。それは「スコープクリープは防げる」ということ。そして何より大切なのは「断る技術」だということ。
今では多くのプロジェクトを支援する中で、スコープクリープを効果的に防ぐ方法を身につけることができました。今回は、その経験から培った実践的な「断り方」と「防ぎ方」をお話しします。
なぜ私たちは「断れない」のか
「お客様のためだから」 「これくらいなら大丈夫だろう」 「関係性を壊したくない」
断れない理由はいくつもあります。でも本当の理由は、もっと深いところにありました。
「悪者になりたくない」心理
ある製造業のシステム開発プロジェクトでの出来事です。
顧客の担当者から「CSVダウンロードに部署名も追加してほしい」という要望がありました。1列追加するだけに見えましたが、実はその部署名データは別システムとの連携が必要で、権限管理、データ整合性、パフォーマンスの問題が山積みでした。
私は影響範囲を説明しようとしましたが、顧客の期待に満ちた表情を見て、結局「わかりました」と言ってしまいました。
結果、2日かかるはずだった作業が5日に。さらに、それを見た顧客は「こんなに簡単にできるなら」と次々と要求を追加してきました。
私は「いい人」でいたかったんです。でも、それがプロジェクトを破綻させる第一歩でした。
「簡単そうに見える」罠
「画面にボタンを1個追加するだけでしょ？」
この言葉、何度聞いたことでしょう。確かに見た目は簡単です。でも実際には、以下のような作業が必要になります。
- データベース設計の変更
- API実装と修正
- 画面実装とレイアウト調整
- 単体テスト・結合テストの追加
- ドキュメント更新
- リリース手順の見直し
気づけば5日分の作業に。しかも、これらの作業で既存機能にバグが混入するリスクも。
「簡単そうに見える」と「簡単である」は全く違うのです。
スコープクリープの本当のコスト
スコープクリープの怖さは、目に見えるコストだけではありません。
チームのモチベーション低下
あるWebサービス開発で、度重なる仕様変更にエンジニアが疲弊していました。
「また変更ですか...」 「どうせまた変わるんでしょ」 「もう適当でいいや」
優秀だったエンジニアが、次々と投げやりになっていく。最終的に、2名が転職してしまいました。
採用コスト、教育コスト、引き継ぎコスト...目に見えない損失は計り知れません。
品質の犠牲
「とりあえず動けばいい」
追加要求に追われ、テストを省略し、レビューを簡略化し...そして本番でバグが発生。緊急対応でさらに疲弊し、また品質が下がる。負のスパイラルです。
ある金融系プロジェクトでは、スコープクリープが原因で重大なセキュリティホールが発生。結果的に、全システムの見直しが必要になりました。
「断る」ための実践的テクニック
では、どうやって断ればいいのか。これまでの経験で編み出した、実践的な方法をお伝えします。
テクニック1：数字で現実を見せる
「この機能を追加すると...」
感情ではなく、数字で語ります。私が使っているテンプレートを紹介します。
「ご要望は理解しました。ただし、この変更により納期が2週間延長し、追加費用が300万円発生します。また、既存機能のテスト期間が不足するため、品質リスクが中から高に上昇します。それでも実施されますか？」
冷たく聞こえるかもしれません。でも、これが現実なんです。
実際、この方法で伝えると、ほとんどの追加要求は取り下げられるか、次フェーズに延期されます。
テクニック2：代替案を必ず用意する
「NO」だけでは関係性が悪化します。だから、必ず代替案を用意します。
「現在のスコープでは難しいですが、こんな方法はどうでしょう？」
- Phase 2での実装（次回予算で）
- 簡易版での対応（80%の要件を20%のコストで）
- 既存の外部ツール活用（開発不要）
ある小売業のプロジェクトでは、高度な在庫管理機能の要求に対して、既存のSaaSツールとの連携を提案。開発コスト2000万円が、月額10万円のサービス利用で解決しました。
テクニック3：「トレードオフ」を明確にする
「この機能を追加するなら、何か他の機能を諦める必要があります」
リソースは有限です。この当たり前の事実を、視覚的に示します。
私は「機能天秤」という図を使っています。天秤の片側に新機能、もう片側に削る機能を載せて、バランスを取る。これを見せると、顧客も「そうか、何かを諦めないといけないのか」と理解してくれます。
スコープクリープを「予防」する仕組み
断るだけでなく、そもそもスコープクリープを発生させない仕組みも重要です。
仕組み1：変更管理プロセスの可視化
すべての変更要求を必ず文書化し、影響分析を実施し、承認を得る。このプロセスを最初に合意します。
「変更は悪いことではありません。でも、きちんと管理しましょう」
このメッセージが大切です。
実際に使っている変更要求書のフォーマットは以下のとおりです。
- 変更内容（具体的に）
- 変更理由（なぜ必要か）
- 影響範囲（スケジュール・コスト・品質）
- 代替案の検討結果
- 承認者と承認日
面倒に見えますが、これだけで「ちょっと追加」は激減します。
仕組み2：週次レビューの徹底
毎週金曜日、15分だけでいいので「スコープ確認会」を実施します。
「今週、スコープに変更はありましたか？」 「来週の作業内容に認識の齟齬はありませんか？」
たったこれだけ。でも、小さな変更の芽を早期に発見できます。
仕組み3：「含まれないこと」を明記する
要件定義で「やること」だけでなく「やらないこと」も明記します。
例えば、このような項目を明記します。
- スマートフォンアプリ開発は含みません
- 既存データの移行は含みません（別途見積もり）
- 24時間サポートは含みません
「含まれないことリスト」を作ることで、後から「これも当然含まれていると思っていた」という誤解を防げます。
失敗から学んだ「黄金ルール」
これまでの経験から、私は3つの黄金ルールを作りました。
ルール1：最初の「ちょっと」で線を引く
最初の小さな変更要求。ここが勝負です。
「今回だけ特別に...」は絶対にダメ。一度例外を作ると、すべてが例外になります。
ルール2：断る理由を「顧客のため」にする
「このまま進めると、品質が下がってお客様にご迷惑をかけます」 「納期が遅れると、お客様のビジネスに影響が出ます」
自分のためではなく、顧客のために断る。この姿勢が信頼を生みます。
ルール3：記録を残す
口頭での約束は、忘れられます。必ずメールなり議事録なり、記録を残します。
「本日お話しした通り、○○機能は次フェーズでの実装ということで合意しました」
後から「言った言わない」のトラブルを防ぐためにも、必須です。
それでも断れないあなたへ
「理屈はわかるけど、やっぱり断れない...」
その気持ち、よくわかります。私も最初はそうでした。
でも、思い出してください。あなたが「断れない」ことで、誰が不幸になっているかを。
- 疲弊するチームメンバー
- 品質低下に苦しむユーザー
- 予算超過に悩む経営層
- そして、信頼を失うあなた自身
本当の「お客様のため」とは何か。それは、約束した品質で、約束した期限に、約束した予算で完成させることです。
明日から始める第一歩
まず、明日から始められることがあります。
- 現在進行中のプロジェクトで、スコープの変更がないか確認する
- 変更要求があったら、必ず影響分析をする（たとえ5分でも）
- 「検討させてください」と即答を避ける
小さな一歩ですが、これがスコープクリープを防ぐ第一歩です。
私があの大失敗プロジェクトから10年。今では「断り上手なPM」として知られるようになりました。でもそれは、顧客との関係を壊すことなく、むしろ信頼を深めながら実現したことです。
「断る」ことは「守る」こと。
プロジェクトを守り、チームを守り、品質を守り、そして顧客の成功を守ることなのです。
まとめ
スコープクリープを防ぐ3つのポイントは以下のとおりです。
- 「断る」技術を身につける（数字で語る、代替案を出す、トレードオフを示す）
- 予防の仕組みを作る（変更管理プロセス、週次レビュー、除外事項の明記）
- 黄金ルールを守る（最初が肝心、顧客のために断る、記録を残す）
「ちょっと」の積み重ねが、プロジェクトを破綻させます。でも、適切に断ることで、プロジェクトは成功へと向かいます。
