はじめに
エンジニア2年目になると、コードを書くことには少しずつ慣れてきます。しかし、多くの若手エンジニアが次にぶつかるのが「クライアントやディレクターからの、突然の仕様追加や納期短縮の要求」という壁です。
「簡単でいいから、ついでにこれも作っておいてよ」 「バグが出そうだけど、そこをなんとかするのがプロでしょ？」
こうした無茶振りに、「頑張って残業して作ります…」と安請け合いしてしまい、チームや自分自身を疲弊させてしまいます。
技術書には「バグの直し方」は書いてあっても、「理不尽な要求への対処法」は書いてありません。そこで私は、AI（Gemini）を「わがままなクライアント」に仕立て上げて、リアルな交渉のロールプレイング（模擬戦）をやってみることにしました。
今回は、そのAIとの修羅場ロープレや実務の議事録から学んだ、明日から使える「要件交渉の4つの鉄則」をシェアします。
🔥 実戦の前に：AI（Gemini）を「わがままクライアント」にして特訓してみた
実務でいきなり顧客と戦うのは怖いので、まずはGeminiに以下のような設定を与えてロープレを開始しました。
AIの設定：IT知識はあまりないが、他社のトレンドに敏感で思いつきで喋るWeb担当者。開発が佳境（リリース3週間前・来週から最終テスト）のタイミング。
すると、AIクライアントからさっそく冷や汗ものの無茶振りが飛んできました。
💬 AI：「他社サイトにある『お気に入り機能』、うちにも絶対欲しいなと思って！見た目だけならハートマークのボタンをサクッと追加するだけでしょ？来週のテストに間に合うよね、お願い！」
「ボタンを置くだけ」に見えても、裏側ではデータベースの変更、APIの新規作成、マイページの改修、そして何より既存機能の破壊のリスクが潜んでいます。
私はGemini相手に、「裏側のDBや上限を考慮しないと動いた分だけお金がかかる」ことや「急いで作るとバグの原因になり、逆にユーザーが離脱すること」を必死に言語化してぶつけました。そして、「今回はこのままリリースして、1ヶ月後にアップデートとして大々的に告知しませんか？」と提案したのです。
結果、AIクライアントから「確かに初日に炎上したらマズいね。じゃあ、1ヶ月後のアップデートというスケジュールで社内を調整するよ！」という完璧な合意（コミット）をもらうことができました。
このロープレを通して見えてきた、「無理難題」を「前向きな提案」に変えるための4つの鉄則がこちらです。
1. 感情で返さず、必ず「トレードオフ（2択）」を提示する
無理な要求をされたとき、「それは無理です」「工数が足りません」と感情的・感覚的に否定すると、相手は「やる気がないのか」と受け取ってしまい、不毛な衝突が生まれます。
プロとしての正しい返し方は、「やるための条件（トレードオフ）」を提示して、相手に選んでもらうことです。
- 【スコープ調整案】：今回その機能を入れる代わりに、優先度の低い〇〇機能の実装を次回に回す（追加費用なし）
- 【スケジュール・予算調整案】：納期（リリース日）を延ばし、追加工数分の費用をいただく
システム開発は「予算」「納期」「スコープ（機能）」の三角形で成り立っています。どれか1つを増やすなら、他のどれかを調整しなければならないという「物理法則」を、選択肢として提示するのがコツです。
2. 機能を「使い捨て」にするか「フェーズを分ける」か
限られた期間とリソースの中で、どうしても顧客が「今すぐやりたい」と譲らない場合、以下の2つのアプローチで「落としどころ」を探ります。
① スピード優先の暫定対応（使い捨てロジック）
納期に間に合わせるために、既存の仕組みを流用した簡易的な形（拡張性のない、いわば使い捨てのロジック）で実装します。ただし、「将来的に必ず改修が必要になるリスク」をあらかじめ顧客と握った上で着地させます。
② フェーズ分け（段階的リリース）
今回のロープレでも使った技です。「今回はバグのない完璧な基盤を作ることに集中し、オープンから1ヶ月後に『新機能登場！』としてアップデートする方が、ユーザーにとっても投資対効果が高い」と提案します。「未完成のまま出す」のではなく、「段階的に進化させる」というポジティブな見せ方に変えるテクニックです。
3. 技術的リスクは「ビジネスの不利益（顧客の言葉）」に翻訳する
エンジニアはついつい「データベースの構造が〜」「デグレードのリスクが〜」と技術用語でリスクを説明しがちですが、IT知識のないクライアントには響きません。リスクは「相手（ビジネス）にとってどんな損害が出るか」の言葉に翻訳する必要があります。
- 「テスト期間が短くなる」 ➡️ 「十分な検証ができず、リリース初日にシステムが停止して顧客が離脱（売上損失）するリスクがあります」
- 「仕様がふんわりしている」 ➡️ 「後から手戻りが発生し、結果的に余計な追加費用が膨らんでしまいます」
相手が最も恐れている「売上の減少」「ユーザーの離脱」「費用の高騰」に結びつけて説明することで、初めて説得力が生まれます。
4. 最強の防衛術：「その場で即答せず、持ち帰る」
経験のない機能や、一見シンプルに見えるボタン1つでも、裏側には他の機能への影響やテストの工数が必ず隠れています。若手エンジニアがやりがちな最大のミスは、打ち合わせや電話のその場で「あ、多分それくらいならできます」と答えてしまうことです。
無茶振りをされたら、笑顔でこう言って持ち帰りましょう。
「貴重なご意見ありがとうございます！ぜひ前向きに検討したいので、プログラムへの影響度と追加工数を一度チームで精査させてください。明日までに回答いたします」
その場は1分で切り上げ、デスクに戻ってからAIを活用して例外パターンを洗い出したり、先輩エンジニアに相談したりして、ロジカルな反論（または見積もり）を作る時間を稼ぐ。これこそが、自分の身とプロジェクトを守る最強の防衛術です。
おわりに：エンジニアは「言われた通りに作る人」ではない
エンジニア2年目になって痛感したのは、「言われた通りの機能を無理に作って、バグだらけのシステムを納品すること」は、クライアントのためにも自分のためにもならないということです。
時にはプロとして「今のタイミングでの実装は危険である」とブレーキをかけ、現実的な代替案を出す。それこそが、ただのコード書きではない、信頼される「ビジネスパートナーとしてのエンジニア」への第一歩なのだと思います。
そして、こうしたソフトスキルを磨く上で、「無茶振りを再現してくれるAIロープレ」は最高の練習相手になってくれます。皆さんもぜひ、Geminiをわがままなクライアントにして、一足先に「修羅場」を経験してみてはいかがでしょうか？