クライアント要望の「後出し変更」に対応するためのプロジェクト防衛術｜現場で使える実践テクニック

2026年08月03日

クリオ

Web制作ディレクター / フロントエンジニア

こんにちは！

今日は「クライアント要望の後出し変更にどう対応するか」という、ほんま現場あるあるのテーマについて話していきます。

後出し変更が発生する本当の理由を理解する

僕も最初の頃、後出し変更にめっちゃイラついてました。
「なんで企画段階で決めとかんの？」って思ってたんです。
でもね、経験を積んでいくうちに気づいたことがあります。

クライアントは多くの場合、悪意で後出し変更をしてるわけじゃないんです。
むしろ、以下のような理由があるんですよ：

つまり、後出し変更は「プロジェクト管理の失敗」というより「ビジネス環境の変化への適応」なんです。
そう捉えられるようになると、対応の仕方も大きく変わります。

むしろ大事なのは、その変更がプロジェクト全体に与える影響を冷静に分析して、クライアントに伝えることなんですよ。

実務では、クライアントからいきなりSlackやメールで「あ、ここ変えたいんですけど」と来ることがほとんどです。
ここで焦って「わかりました、対応します」って返事しちゃうと、後でめっちゃ後悔します。

僕がおすすめするフローはこんな感じです：

「かしこまりました、確認させていただきます」くらいに留める。
ここで即答すると、後で「こんな工数かかるんですか？」って揉める原因になります。

その変更要望が以下の項目にどう影響するかをまとめます：

影響範囲の分析が終わったら、クライアントとの正式ミーティングを設定します。
ここで大事なのは「報告」の形にすることです。

「〇〇の変更ご要望ですね。
影響を分析した結果、△△の工程で最低××日程の延期が見込まれます。
コスト面では追加で〇〇万円程度かかります。
それでもよろしければ、優先度の調整をさせていただきたいのですが」

という形で。
この時点で、クライアント側も「あ、そんなに影響あるんだ」と気づきます。
すると、本当に必要な変更と「あれば嬉しい」レベルの変更が自動的に分別されていくんです。

優先度が整理できたら、変更をカテゴリ分けします：

これをドキュメント化して、クライアントに承認をもらいます。
この承認が最大の防衛になります。

ここからが本当に大事な部分なんですが、全ての後出し変更が防げるわけではないんです。
だからこそ、どこまでは対応可能な範囲で、どこからがオプション扱いかを最初に決めておく必要があります。

これは営業の話になっちゃうんですが、企画提案の段階で以下を明確に書いておくといいですよ：

僕の失敗談ですけど、昔は「修正何回まで無料」という条件をつけずに仕事してたんです。
そしたら、もう永遠に修正がくるんですよ。
クライアント側も「あ、無料でやってくれるんだ」と思っちゃう。
この悪循環に陥るとほんま地獄です。

プロジェクト開始後も、毎週のミーティングで現在のスコープを確認するといいですよ。

「現在のスコープはこちらの状態です。
何か追加でご希望がありましたら、お知らせください」

という形で、クライアント側に「今の状態はこれだ」という認識を共有する。
そうするとね、後出しで「やっぱりここも変えたい」って来にくくなるんです。

それでも時々、明らかに契約外の要望が来たりします。
そういう時は、丁寧だけど明確に「対応外」を伝えるといいですよ。

「ご要望ありがとうございます。
こちらは当初のスコープ外の機能になるため、別途プロジェクトとして対応させていただきたく思います。