「これくらいなら入れてもらえますよね？」と発注者から言われ、その場の空気で「はい」と返してしまった経験はありませんか。受託開発のPMにとって、追加要望の積み重ねは納期崩壊と利益の蒸発に直結します。それでも断れないのは、線引きの基準が自分の中にも、チーム内にも、契約書の中にも明確に存在しないからです。
本記事では「スコープ内なのか、スコープ外の変更要求なのか」を判定する3つの問いと、発注者との信頼を壊さずに線引きを合意するための伝え方を、メール文例まで含めて整理します。読み終えたら、次に追加要望が来たときに迷わず判断と説明ができる状態を目指します。
なぜスコープクリープは「断れない」のか
スコープクリープが止められない現場には、共通する3つの構造があります。
ひとつは、契約と前提条件が曖昧なまま見積もりだけが一人歩きしていること。提案書には機能一覧があるのに、契約書には「別途協議」としか書かれていない、というパターンです。ふたつめは、判断がPM個人の感覚に委ねられていること。同じ要望をAさんは「サービス対応」と判断し、Bさんは「変更要求」と判断する。これではチームとして一貫したスタンスが取れません。
そして3つめが、「断る＝関係が悪化する」という思い込みです。実際には、その場で曖昧に飲み込んだ要望ほど、後から「なぜこれが追加費用なのか」と揉めます。線引きを先送りすることは、優しさではなく将来の炎上の予約に近いのです。
詳しい背景はなぜあなたの要件定義はエンジニアに伝わらないのか？元エンジニアPMが明かす5つの根本原因と処方箋でも整理していますので、要件定義の段階から崩れているケースは合わせて確認してください。
スコープ内/外を判定する3つの問い
追加要望を受けた瞬間に、PMが頭の中で回すべきチェックは次の3つです。順番に答えれば、ほぼすべての要望は「スコープ内」「スコープ外（有償変更）」「再見積もり対象」のどれかに分類できます。
問い1：契約書・提案書に書かれているか（契約）
最初に立ち返るべきは、契約書・発注書・提案書に明記された成果物の範囲です。要望が「明記されている機能の品質を満たすために必要な作業」なら、それはスコープ内。「明記されていない機能や、明らかに別目的の作業」ならスコープ外の出発点に立ちます。
ここで重要なのは、PMが「契約書に何が書かれているか」を即答できる状態にしておくこと。契約書を開かずに会話するから、空気で押し切られるのです。
問い2：見積もり時の前提と矛盾しないか（前提）
次に、見積もり時に置いた前提条件を確認します。「対象データは月次で1万件まで」「外部API連携は2系統まで」「画面パターンは想定3種類」といった前提を超える要望は、見積もりの土台が崩れているサインです。
前提が変わるなら、工数も品質基準もスケジュールも揺らぎます。これは「断る」というより、「前提が変わったので再見積もりが必要です」という事実の通知です。前提条件こそが、PMが感情ではなく事実で線を引くための武器になります。
問い3：他のタスクや品質に影響するか（影響範囲）
最後に、その要望を受け入れたときに、既存のスケジュール・既存機能の品質・他メンバーの作業にどんな影響が出るかを確認します。
「コードを1行足すだけ」に見える要望でも、テスト範囲・リリース手順・ドキュメント更新まで含めれば半日仕事になることは珍しくありません。影響範囲をブラックボックスのまま「やります」と返すのは、PMがチーム全体に未払いの負債を負わせる行為です。
この3つの問いを、判定シートとしてチーム共通で持つだけでも、判断のばらつきはかなり小さくなります。WBSの粒度と影響範囲の見える化については【炎上を防ぐWBSの作り方】私が大炎上プロジェクトで学んだ３つの原則も参考になります。
発注者への伝え方：信頼を壊さずに線を引くメール文例
判定が終わったら、次は伝え方です。線引きで関係が悪化するのは、「できません」だけを伝えてしまうときです。プロのPMは、断る前に必ず「前提・影響・選択肢」をセットで提示します。
以下は、追加要望を受けた際に使えるメール文例です。
件名：◯◯機能追加のご相談につきまして（影響範囲のご確認）
◯◯様
いつもお世話になっております。テックエイド プロジェクトマネージャーの△△です。 先ほどご相談いただいた「◯◯機能の追加」につきまして、まず前提のすり合わせをさせてください。
- 当初契約書のスコープ：本機能は提案書・契約書のスコープには含まれていない認識です。
- 見積もり時の前提との関係：本機能を加えた場合、当初前提（△△）が変わり、設計と試験範囲が広がります。
- 影響範囲：現行スケジュールに約◯人日の追加が見込まれ、◯◯機能のリリース日が△△まで後ろ倒しになります。
上記を踏まえて、以下の3案をご提案します。
A：別途お見積もりのうえ、追加開発として今期内に対応 B：次フェーズの要件として整理し、改めて提案書を提出 C：現行スコープ内の優先度を見直し、別機能と差し替えて対応
◯月◯日までにご希望の方向性をいただけますと、現行スケジュールへの影響を最小化できます。お手数ですがご検討よろしくお願いいたします。
ポイントは3つです。前提・影響・選択肢の順で構造化すること。判断と期限を発注者側に返すこと。そして「No」ではなく「条件付きYes」の形式にすること。これだけで、同じ内容でも受け取り方が大きく変わります。
社内合意やステークホルダー対応のテンプレ化については受託開発で赤字を出さないPMの判断基準｜案件進行中の利益管理5つのチェックポイントでも触れていますので、利益管理の側面から押さえたい方は併読をおすすめします。
チームに線引きを定着させる3つの仕組み
判定基準とメール文例ができたら、最後はチームへの実装です。個人の頑張りに頼ると、PMが疲弊した瞬間に元の状態に戻ります。
ひとつめは、変更要求ログ（CR管理表）の運用。日付・要望内容・判定結果（スコープ内、スコープ外、再見積もり）・対応方針を1行で残すだけで十分です。ふたつめは、週次の発注者定例での共有。「先週はこの要望を有償対応として整理しました」と毎週渡せば、線引きが「特別なこと」ではなく「いつもの運用」になります。
3つめは、判定基準の文書化。前述の3つの問いを社内Wikiに置き、新人PMでも同じ判定にたどり着ける状態を作ります。属人化したスコープ管理は、PMの離脱と同時に崩壊するからです。
迷ったらこの講座から始める
スコープ管理の理屈は本記事で押さえられても、実案件で「契約・前提・影響範囲」を切り分けて発注者と合意できるかは、ケース演習の量で決まります。テックエイドの「IPJ-102 スコープマネジメント実践」は、追加要望が連発する受託案件のケースを使い、変更要求の判定と合意形成を反復で鍛える講座です。あわせて「FFF-102 追加要望で納期崩壊」では、すでに崩れかけたプロジェクトで線引きを取り戻す対処法を扱います。
判断軸を自分の中に染み込ませたい方は、こちらのコース詳細から内容と受講形式を確認してみてください。
まとめ
追加要望を断れないのは、優しさでも度量の問題でもなく、判定基準と伝え方の準備不足です。本記事の要点は次の3つです。
- スコープ内か外かは「契約・前提・影響範囲」の3つの問いで判定する
- 発注者には「前提・影響・選択肢」をセットで返し、判断を相手に戻す
- 個人技ではなくCR管理表と週次共有でチームに仕組みとして根づかせる
次に「これくらい入れてよ」と言われたとき、3つの問いと文例を思い出してください。線引きは、発注者との信頼を守るための実務であり、PMがプロとして果たすべき役割です。