クライアント要望の「後出しじゃんけん」に振り回されない進行管理術｜現場で使える実践テクニック

こんにちは！

今日は「クライアント要望の『後出しじゃんけん』に振り回されない進行管理術」について解説します。

「開発中の仕様変更」はなぜ起こるのか

僕も最初のころめっちゃ悔しい経験があるんですけど、企画段階で「完璧に仕様書作ったぞ」と思っていても、開発が進むにつれて「あ、こういう場合はどうするの？」みたいなクライアント側の気づきが出てくるんですよね。
これ、実はクライアント側が悪いわけじゃなくて、企画段階では見えないディテールって本当にあるんです。

現場でよく見るのは、こんなパターンです。

• デザイン案を見たら「あ、こういう表示方法だと管理画面では大変だ」と気づく
• 実装の途中で「モバイルでこの機能使う人いるのか？」という質問が出る
• ステージング環境での動作確認で「これなら〇〇みたいにしたほうがいいんじゃ」という新しい案が浮かぶ

つまり、クライアント側も実は「想定の外」の要件に気づくわけです。
だから、これを「要望の後出し」として責める姿勢だと、関係がギクシャクしてしまいます。

スコープ確定フェーズで防ぐ現実的な方法

大事なのは「変更を完全に防ぐ」ではなく「どうやって変更に対応するか」をあらかじめ決めておくことです。
僕が実際にやってる方法を紹介しますね。

1. 「3段階スコープ確認書」を用意する

最初の企画打ち合わせで、こんな形の資料を作るといいですよ。

• スコープIN：絶対に実装する機能（例：ユーザー登録、ログイン機能）
• スコープOUT：今回は実装しない機能（例：AI推奨機能、多言語対応）
• スコープ保留：実装の進行状況で判断する機能（例：高度な検索フィルタ）

これをクライアントにも渡して「このリストで間違いないか確認してください」と言うわけです。
ほんま、これを最初にやるだけで後々のトラブルが減ります。

2. 「変更要望シート」を作る

開発中に変更要望が来た時点で、こういう情報を記録するようにするんです。

• 変更内容は何か
• その変更に必要な工数は何時間か（概算）
• 実装タイミングはいつか（次フェーズ？それともすぐ？）
• この変更によるスケジュール/予算への影響

これをクライアント側にも共有することで「あ、この変更には3日かかるんだ」という現実が見えてきます。
すると、クライアント側も「それなら優先度の低い要望は保留にしよう」という判断ができるようになるんです。

3. 「仕様確認セッション」を定期的に入れる

僕がよくやるのは、デザイン完成時、開発中盤、ステージング環境への上がり前、この3タイミングで「仕様確認会」を入れることです。
その時点での成果物を見ながら「ここで気づきはありますか？」と聞く。
すると、大きな変更は早期に発見できます。

変更要望が来たときの対応フロー

それでも変更要望は来ます。
その時は、こういう流れで対応するといいですよ。

ステップ1：内容をちゃんと理解する

クライアント側から「〇〇を変更したい」と来たとき、絶対に後手に回らないための質問リストです。

• その変更は「必須」か「あると嬉しい」か（優先度を明確に）
• その変更が必要な背景は何か（単なる思いつきか、ユーザーからの要望か）
• 実装期限はいつまでか

これを聞くことで、本当に重要な変更と「なんとなくの思いつき」が分けられます。

ステップ2：影響度を整理する

その変更が「どこに」「どれくらい」影響するのかを整理します。

• フロントエンド側の実装工数
• バックエンド側の実装工数
• 既存機能への影響（他の機能が壊れないか）
• スケジュールへの影響（何日遅れるのか）

ここまで来たら、チーム内で「この変更するのに3日かかります」って結論を出すわけです。

ステップ3：選択肢を提示する

クライアント側に「こういう影響がありますが、どうしますか」と3択くらい提示するんです。

• 案A：今すぐ実装する（スケジュール3日遅れ、追加費用なし※事前契約による）
• 案B：次フェーズで実装する（本リリース後の改修版で対応）
• 案C：別案で対応する（同じ目的を別の方法で実装、工数1日で済む）

大事なのは「No」と言うのではなく「こういう選択肢があります」という説明の仕方です。
そしたらクライアント側も「あ、工数がかかるなら次フェーズでいいや」って判断できるわけです。

ステップ4：合意を文書に残す

クライアント側が「案Aで行きます」と言ったら、メールなり資料なりで「スケジュール3日遅れることに同意します」という内容を残しておくんです。
これめっちゃ大事です。
後から「こんなに遅れるはずじゃなかった」と言われないようにするためです。

まとめ

結局のところ、クライアント要望への振り回されを減らすには、こういうポイントが重要です。

• 企画段階での「スコープ確定」をちゃんとやる
• 変更要望が来たときは、焦らず「影響度」を計算してから対応する
• クライアント側に「現実」（工数やスケジュール）をちゃんと見せる
• 最終的な判断はクライアント側に委ねる（No ではなく「こういう選択肢があります」）

僕も経験上、このフローで対応してたら、クライアント側も「あ、そういう工数がかかるんだ」と理解してくれて、無理な要望は自動的に減るんです。
要は「透明性」と「選択