「技術的に難しいと説明したのに、顧客やPMが納得してくれない」
エンジニアがよく感じるもどかしさの一つです。「できない」という事実は正確なのに、どう伝えても「何とかならないの？」という反応が返ってくる。
問題の多くは「できません」の伝え方にあります。技術的な制約を説明することと、相手が求める「次の手」を示すことは別のことです。
「できません」が対立を生む理由
「できません」という言葉は、それだけで終わると「断られた」という印象になります。
相手が求めているのは「この課題を解決すること」です。「できません」は課題の解決にならない回答のため、「では誰に頼めばいいのか」という反応につながります。エンジニアが悪意なく正直に言っているだけでも、相手には「壁」として受け取られます。
対立にならないためには、「できない理由」と「できることの提示」をセットにする必要があります。
代替案の基本形
代替案は以下の形式で整理します。
「○○は今の条件では難しいです。理由は○○。ただし、△△という方法であれば対応できます。その場合、○○という影響があります」
この形式の要素は3つです：
- 難しい理由（技術的制約・工数・リスクを具体的に）
- 代替案（何なら対応できるか）
- 代替案の影響（品質・納期・コストのうち何が変わるか）
「難しい」だけで終わらず、「でも△△なら」という言葉をセットにすることで、会話が前に進みます。
品質・納期・コストの3軸で選択肢を作る
代替案は「品質・納期・コスト」の3軸のうちどれかを動かすことで作れます。
品質を変える代替案
「全要件を満たすのは難しいが、○○の機能を後回しにすれば今の納期に間に合います」
納期を変える代替案
「現在の品質基準を維持する場合、○週間の延長が必要です。当初納期に合わせる場合、テスト期間を○日に短縮する必要があります」
コストを変える代替案
「現在の体制では対応が難しいですが、○○人を追加すれば当初納期で対応できます」
この3軸を意識すると、「何か1つ動かせれば対応できる」という提案として伝えられます。3軸全部を相手に選ばせる必要はありません。エンジニア側で「この軸が一番影響が少ない」と判断したものを推奨案として提示します。
メール・会議での言い方例
メールでの表現例：
件名：○○機能について代替案のご提案
○○ご担当者様
ご要望いただいた○○機能について確認いたしました。
現在の設計・工数では、○日の納期での実装は難しい状況です。理由は○○です。
ただし、以下の代替案であれば対応可能です： ・案A：△△方式（納期通り対応可能。ただし○○の制約あり） ・案B：□□方式（品質は維持。納期が○週間後ろになります）
PMとして案Aが現実的と考えます。ご確認のほどよろしくお願いします。
会議での切り出し方：
「今日確認したいことがあります。○○機能についてですが、今の状態では○日の対応が難しく、理由をご説明させてください。ただし、代替案を2つ考えてきたので、一緒に確認させてください」
PMに相談するときの準備
エンジニアが「難しい」状況をPMに相談するときも、同じ形式が使えます。
「難しいです」だけ報告するのではなく：
- 難しい理由（技術的に何が問題か）
- 代替案の候補（何なら対応できるか）
- 各案の影響（品質/納期/コストのどれが変わるか）
- エンジニアとしての推奨案
この4点をセットにして持っていくと、PMが顧客との交渉材料を持てるようになります。「何とかして」という話になりにくくなります。
エンジニアのビジネススキルを高める
代替案提示・顧客折衝スキルは以下で学べます。
代替案の「質」を高める三つの条件
エンジニアが代替案を提示する際、単に「別の方法もあります」では不十分です。良い代替案には「ビジネス目標への到達性」「技術的な実現可能性」「コストとスケジュールへの影響」という三つの条件が揃っている必要があります。
この三つを整理した代替案が、意思決定者の判断を助け、エンジニアの提案が採用される確率を高めます。代替案を提示する前に、この三つの条件を自分で検証することが、提案の質を保証します。
「断る」ではなく「代替案を提示する」という姿勢
要件や期限に対して「できません」と答えることは、エンジニアとPMの関係を悪化させる場合があります。「この要件は現在のアーキテクチャでは実現が難しいですが、○○というアプローチであれば同じビジネス価値を提供できます」という代替案の提示が、建設的な協力関係を生みます。
「断る」という最終結論に至る前に、「どうすれば実現に近づけるか」という発想を持つことが、エンジニアとしての価値を高めます。
代替案を「選択肢の表」として整理する
複数の代替案がある場合、口頭で説明するより「選択肢の比較表」として整理することで、意思決定者が判断しやすくなります。「Option A: 工数3日、リスク低、機能は限定」「Option B: 工数10日、リスク中、フル機能」という表形式が、選択肢の違いを一目で把握させます。
比較表を用意する手間が、意思決定の速度と質を高める投資として機能します。
代替案を提示した後の「選択肢の尊重」
代替案を提示した後、最終的に意思決定者が元の要件を選択した場合でも、その決定を尊重することが重要です。「代替案を提示したのに採用されなかった」という不満を持たず、「決定に最善を尽くす」という姿勢が、長期的な信頼関係を築きます。
代替案の提示は「自分の意見を通すため」ではなく「最善の選択肢を一緒に見つけるため」という目的で行うことが、エンジニアとしての誠実さを示します。
「代替案力」をエンジニアのキャリア資産にする
代替案を提示するスキルは、エンジニアとしての技術力に加え「ビジネス視点での思考力」と「コミュニケーション力」の組み合わせです。このスキルを持つエンジニアは、純粋な技術者としての評価を超え、プロジェクトやビジネスに貢献できる存在として認められます。
代替案を考える習慣が「なぜこの要件なのか」「どんな目的を達成したいのか」という上流の思考を促し、エンジニアとしての視野を技術実装から事業価値へと広げます。この視野の拡大が、PMやプロダクトマネージャーへのキャリア転換の基盤にもなります。
まとめ：代替案の提示がエンジニアの価値を高める
代替案を提示するスキルは、エンジニアとしての技術力に加え、ビジネス視点とコミュニケーション力を組み合わせた複合スキルです。このスキルを持つエンジニアは、PMやステークホルダーから「一緒に考えてくれる頼れる存在」として認識されます。代替案の提示を習慣にすることで、エンジニアとしての価値と影響力が着実に高まります。
代替案を考える習慣が、エンジニアとしての思考の幅を技術から事業へと広げます。この習慣を持つエンジニアが、PM・プロダクトマネージャーへのキャリア転換の選択肢も手に入れます。
代替案を提示できるエンジニアが、チームとプロジェクトにもたらす価値は、コードを書く能力だけのエンジニアの何倍にもなります。この価値を組織に示し続けることが、キャリアの選択肢を広げます。
代替案を提示する習慣を日常的に実践することで、この力がエンジニアとしての「当たり前のスキル」へと進化します。当たり前のスキルが、キャリアの選択肢を大きく広げます。