TL;DR

技術選定の答えは、技術の中にはない。 事業フェーズとリソース制約の中にある。「どっちのライブラリが優れているか」をいくら比較しても、決め手は出てこない。
エンジニアの説明が通らないのは技術力不足ではなく、「翻訳」の問題。エンジニア語は「技術の状態」を語るが、意思決定者は「お金・時間・リスクの変化」で判断する。
持ち帰ってほしい型は4点セット。選択肢 → 判断軸 → 捨てるもの → 切り替え条件。
「何が得られるか」だけの提案は通らない。「何を捨てるか」を宣言して初めて、相手は判断できる。

はじめに

「なんでこの構成にしたの？」

上司や事業側からこう聞かれたとき、どう答えていますか？　技術的な正しさを丁寧に説明したのに「で、結局どうなるの？」という顔をされた経験、心当たりはありませんか？

正直に言うと、自分は長いことこれを「説明力の問題」だと思っていました。もっと分かりやすく、もっと正確に技術を説明すれば伝わるはずだと。でも違いました。**相手が聞きたいのは技術の説明ではなく、「何が得られて、何を失って、それはいつ効いてくるのか」**でした。

この記事では、自分の過去のやらかしと実際の判断を素材に、コードを書く前の思考プロセスと、それをステークホルダーに伝わる言葉へ翻訳する型をまとめます。対象読者は、実装はできるようになってきたけれど「上の人との会話」で消耗しているエンジニアです。

「正しいHow」を積み上げても、決められなかった

きっかけは性能テストでのやらかしでした。詳細は別記事『シナリオ設計編: 初めての性能テストをうまく進めるには？ ― JMeterを開く前にやるべきだったこと』に書きましたが、かいつまむと、

在庫系業務システムの性能テストを、短納期・前任者不在の条件で引き取った
JMeterの使い方から入り、何時間格闘しても1％も進まなかった
そもそも「短納期かつ前任者不在で性能テスト結果を出す」というゴール自体が、引き受けた時点で破綻していた

当時の自分が磨こうとしていたのはHowでした。スレッドグループの切り方、サンプラーの書き方。でもこの案件で本当に決めるべきだったのは「期限内に何を捨てるか」で、その答えはJMeterのドキュメントのどこにも書いてありません。納期・人・ドメイン知識という制約の中にしか答えがなかったんです。

仕切り直しでやったことは、技術的にはとても地味です。最初の1日で「できること / できないこと / 誰かに決めてもらうこと」の3つに仕分けして合意を取る。つまり、結果を出す約束を、実現可能な範囲を決める約束に置き換える。 このときようやくビジネス側との会話が前に進みました。約束の対象を「成果」から「範囲」に変えただけで、見えない破綻が見える計画に変わった。

これが、トレードオフをビジネスの言葉にした最初の経験でした。以降の判断を一般化したのが、次の型です。

型: 選択肢 → 判断軸 → 捨てるもの → 切り替え条件

技術選定やタスクの進め方を説明するとき、自分はこの4点セットで考えるようにしています。

1. 選択肢      : 最低2つ。「やらない / 現状維持」も選択肢に数える
2. 判断軸      : いまの事業フェーズ・制約のうち、動かせないものは何か
3. 捨てるもの  : 選んだ案で「諦めるもの」を明示する
4. 切り替え条件: 何が起きたら、この判断を見直すか

1文に圧縮するとこうなります。

「選択肢はXとYがあった。いまは◯◯というフェーズ／制約なので、△△を捨ててXにした。Yに切り替える条件は□□」

ポイントは後半の2つです。前半（選択肢と判断軸）は比較表を作れば誰でも書けます。提案が通るかどうかを分けるのは後半です。

「捨てるもの」が言えない提案は、何も約束していない。
「品質もスピードも両立します」「がんばって間に合わせます」は、聞き手からすると情報量がほぼゼロです。何かを捨てると宣言して初めて、相手は「その捨て方でいいか」を判断できます。判断材料を渡すところまでが提案です。

「切り替え条件」は、捨てる判断の賞味期限。
捨てる判断は、いまのフェーズ・制約に対する最適化なので、前提が変われば腐ります。条件を先に言語化しておくと、半年後の再交渉が「以前から気になっていたんですが……」という弱い切り出しではなく、「合意していた条件を踏んだので、見直します」という強い形になります。

「やらない」を選択肢に入れるのを忘れがちです。現状維持にもコスト（確認する人の時間、事故ったときの損失）があります。それを言語化して初めて、「やる」案の価値が比較可能になります。

エンジニア語 → ビジネス語の翻訳

型ができても、語彙がエンジニア語のままだと伝わりません。翻訳のコツは2つ。主語を「技術の状態」から「お金・時間・リスクの変化」に変えること。そして**「いつ効いてくるか」の時間軸を入れる**ことです。

エンジニア語	ビジネス語への翻訳例
技術的負債が溜まっている	このまま3ヶ月進むと、同じ規模の修正にかかる時間が今より増えていきます
リファクタリングしたい	この画面の修正を「他を壊さないか怯えながら」ではなく、安全にできる状態にします
性能テストをやるべきです	本番で業務が止まる事故に対して、いまは無保険の状態です
この設計だと拡張性がありません	来期予定の機能を載せるとき、作り直しに時間を取られる見込みです
仕様が決まっていないので作れません	決め方の選択肢を持ってきました。どれで進めるか選んでください

表の数字や期間はあくまで形の例です。実際に使うときは自分のプロジェクトの実情に置き換えてください。盛った数字は一度バレると、以降すべての翻訳の信用を失います。

最後の行が一番大事だと思っています。「決まっていません」「できません」で止めるのは、トレードオフを語る権利を自分から手放す行為です。選択肢と捨てるものをセットで持っていけば、同じ「決まっていない」状況でも会話が前に進みます。

実例で型をなぞる

ここからは、自分が実際にやった判断を4点セットに当てはめ直してみます。

例1: Copilotトライアル ― 「全員導入の即効性」を捨てて、76ドルの実験にする

別記事『【開発作業効率化】GitHub Copilot Business をエンジニア4名でトライアルしてみた』の判断を分解するとこうなります。

型	中身
選択肢	A: 全エンジニアに一斉導入 / B: 4名×1ヶ月のトライアル
判断軸	社内にAIツールの導入実績がなく、判断材料がない。他社事例をそのまま持ってきても自社では客観性がない
捨てたもの	全員導入の即効性
切り替え条件	終了時の判定基準（利用継続率・提案の受け入れ率・コーディング以外への波及・セキュリティ懸念）を先に決め、「何が起きたら見送るか」まで言語化

これを承認者向けのビジネス語に翻訳すると、**「月19ドル×4名＝76ドル・1ヶ月で、全社導入のGo/No-Goを判断する材料が手に入ります」**になります。実際、この構造の経費申請が承認されました。承認する側から見ると、リスクの上限が76ドルと明確で、終了時に判断材料が残る設計になっている。ここに技術の話はほとんど出てきません。稟議を通すのも、仕組みを動かすためのエンジニアリングの一部です。

例2: GAS内製 ― 「メンテフリー」を捨てて、今日から動かす

別記事『GASとCrowdLog APIで、チームの勤怠入力を自動チェックしてSlackに爆速通知する』では、勤怠入力チェックの自動化でこう判断しました。

型	中身
選択肢	① 手動リマインドを続ける / ② 有料の勤怠連携ツールを導入する / ③ GASで内製する
判断軸	追加費用ゼロ・既存のGoogle / Slackアカウントで完結・欲しい機能は「入力チェックと通知」だけ
捨てたもの	メンテフリー。属人化リスク・GASの実行制限・メンテ責任を自分で背負った
切り替え条件	チェック対象が全社規模に広がる、または締め処理まで自動化したくなったら②へ乗り換え

翻訳すると「稟議も予算も不要で今日から始められます。引き換えにメンテはこちら持ち。全社規模になったら有料ツールへの乗り換えを提案します」。「GASが面白いから」ではなく、「いまの規模・要件なら③一択。ただし乗り換え条件はこれ」という構造で語れる状態にしておくのが肝です。

ちなみに、捨てたものへの手当ても忘れずに。属人化リスクには「設定の一点集約」と「仕組みの文書化」で緩和策を打ちました。捨てたものは消えてなくなるわけではないので、せめて被害を小さくする手は打っておきます。

例3: AI効果測定 ― 「盛れる数値」を捨てる

捨てる対象は機能やスピードだけではありません。数値の精度も捨てる対象です。

別記事『その分析、ノイズ混じりじゃない？AI導入効果を正しく測るためのデータクレンジング術』で、AI導入前後のPRサイクルタイムを分析したとき、除外条件を足すたびに改善幅は57.7％から4.9％まで縮みました。どちらを報告に使うか。判断軸は「誰に報告するための数値か」です。経営層のROI判断に載せるなら、盛れる57.7％ではなく、除外理由をすべて説明できる4.9％の方でした。

これも翻訳の仕事です。「統計的に有意でした」で終わらせず、「この数値は誰の・どの作業を測ったもので、どの精度を捨てているか」までセットで渡す。数値だけが一人歩きしたあとで前提を突かれて崩れるより、最初から控えめで崩れない数値の方が、長期的には信頼につながります。

同じ「捨てる」でも、フェーズが変われば正解が変わる

最後にもう一段だけ。4点セットの判断軸にわざわざ「事業フェーズ」と書いているのには理由があります。同じトレードオフでも、フェーズによって名判断にも事故にもなるからです。

一般論として、

検証期（PoC・デモ前）に網羅テストや汎用化を捨てるのは、たいてい正しい判断です。学習速度がすべてに優先するフェーズだからです
安定運用期にデータの整合性や「後から検証できること」を捨てるのは、たいてい事故です。画面やロジックは作り直せますが、壊れたデータと「測っていなかった期間」は遡れません

だからこそ、技術の議論より先に「いまこのプロダクトはどのフェーズだと認識していますか？」をステークホルダーと揃える価値があります。エンジニアが「そろそろ品質に投資すべき時期」と思い、事業側が「まだ速度優先」と思っていたら、個々のトレードオフの議論は全部すれ違います。

そして、フェーズは必ず移ります。移った瞬間、過去の「捨てる判断」は前提を失う。これが、型に「切り替え条件」を組み込んでいる理由です。

まとめ

技術選定の答えは技術の中にはなく、事業フェーズと制約の中にある
説明が通らないのは技術力不足ではなく翻訳の問題。「お金・時間・リスクの変化」と「いつ効くか」で語り直す
型は4点セット: 選択肢 → 判断軸 → 捨てるもの → 切り替え条件
捨てるものを宣言して初めて約束になる。切り替え条件を先に合意しておくと、将来の再交渉が強くなる

「何を捨てたか」を言えるエンジニアは、たとえ選んだ技術が地味でも信頼されます。逆に、捨てたものを言えないまま「全部やります」と言ううちは、どれだけ綺麗なコードを書いても、意思決定の場には呼ばれません。

次の技術選定やタスク着手の前に、サクッと5分、4点セットをメモに書いてみてください。書けない欄があったら、それは「まだ着手すべきタイミングではない」と教えてくれる、一番安いアラートです。