正論では動かない：提案を「翻訳」で通す技術【第8回】

この記事を読み終えると、相手の評価指標に翻訳した提案を組み立てられ、現状維持のコストを数字で示し、小さく試して合意を積み上げる進め方を設計できるようになります。ジュニアエンジニア向け 成果の出し方シリーズ（全12回）の第8回です。

🎯 テーマの主役：「翻訳」

今回の主役は翻訳です。一言で言えば、提案とは「自分の言葉を、相手の言葉に翻訳して渡す行為」です。正しさを主張する行為ではありません。翻訳です。

日常の例えで言うなら、通訳です。あなたは技術の言葉で考えています。「テストカバレッジが低い」「結合度が高い」「N+1クエリが出ている」。これらは正確な言葉です。しかし意思決定をする人は、別の言葉で考えています。「来期の問い合わせ対応に何人必要か」「この機能が止まると何円の機会損失か」「法規制への対応が間に合うか」。同じ出来事を、別の言語で表現しているだけです。だから通訳が必要になります。

そして通訳に必要なのは、語学力ではなく、相手の言語を知っていることです。相手が何を指標に評価されているかを知らなければ、正しい翻訳はできません。「正論なのに通らない」の正体は、たいてい翻訳されていないことです。

この記事の仮説はこうです。提案の成否は「内容の正しさ」ではなく「相手の意思決定の形式に合っているか」で決まる。したがって提案の技術とは、内容を磨く技術ではなく、翻訳と形式を設計する技術である。もしこれが正しければ、あなたが身につけるべきは説得の熱意ではなく、相手の評価指標を調べる習慣になります。

なお第1回から第7回で扱った調査・設計・報告・質問は、すべて提案の中身になります。提案は、これまでの技術の集大成です。そして第4回（理不尽シリーズ）で扱った「利害の地図」は、この記事の土台です。まだの方は、そちらも併せて読んでください。

動機：「正しいのに、なぜ通らないのか」

ジュニアエンジニアが最初にぶつかる理不尽の1つが、これです。明らかに直すべき問題を、明らかに正しい方法で提案したのに、通らない。

たとえばこうです。テストがなく、修正のたびに壊れる。設計が密結合で、1か所直すと3か所が壊れる。監視がなく、障害に気づくのが利用者からの連絡より遅い。どれも正しい指摘です。そしてどれも通らない。

このとき、人は2つの誤った結論を出します。「上は分かっていない」か、「自分には影響力がない」です。しかし多くの場合、本当の理由は別にあります。その提案が、相手の意思決定の形式に合っていないのです。相手は「正しいか」ではなく「損か得か」「いつやるか」「誰がやるか」を判断しています。そしてあなたの提案には、その材料が入っていない。

この記事のゴールは、正しい提案を、通る形にすることです。

🔍 検証①：決定は「正しさ」ではなく「損得」で行われる

まず、意思決定の構造を理解します。人が何かを決めるとき、判断の軸は「正しいか」ではありません。「いま、それをやるべきか」です。これは正しさとは別の問いです。

たとえば「テストを書くべきか」という問いを考えます。正しさの答えは「書くべき」です。しかし意思決定の問いは「いま、この機能を止めて、テストを書く時間を確保すべきか」です。そこには他の選択肢との比較が入ります。「新機能の開発」「問い合わせ対応」「採用面接」。すべて正しい仕事です。限られた時間をどれに割くかが、決定の本質です。

だから提案は、他の選択肢と比較されるという前提で作ります。「これをやるべき」だけでは足りません。「これをやるために、あれを止める」まで書く必要があります。資源の有限性は、第4回（理不尽シリーズ）で扱った政治の3理由の1つ目です。同じ構造です。

4行目の「まず〜だけ試します」が、実務で最も通りやすい形です。大きな決断を小さな決断に分解する。第5回で扱った可逆性の設計が、そのまま提案の技術として効きます。「戻せる形で小さく試す」なら、相手は安心して承認できます。

🔍 検証②：相手の評価指標に翻訳する——4つの通貨

次に、翻訳の具体技術です。技術の言葉を、相手が使っている4つの通貨に変換します。

①時間：何時間・何人日・何待ち時間。技術用語を使わずに、人の時間で語ります。「テストがない」→「修正のたびに、確認作業に2時間かかっています。月8回で16時間」。

②金額：コスト・損失・機会損失。「監視がない」→「検知が平均40分遅れています。この間、影響を受ける利用者は約500人、機会損失は試算で月〇〇円」。

③リスク：起きる確率と、起きたときの大きさ。「セキュリティ対策が必要」→「発生確率は年1回程度、発生時の対応コストは数百万円規模。規制への対応義務もあります」。

④評価：相手自身が評価される指標。ここが最も強力で、最も見落とされます。「サービス品質」→「経営会議で報告している可用性の指標が、目標を下回る月が出ています」。

④評価が最も強い理由は、相手が自分事として判断するようになるからです。人は自分の評価に関わる問題には、驚くほど速く動きます。だから「相手が何を報告しているか」を知ると、提案が通ります。これは聞き出せる情報です。「いま一番気にしている指標は何ですか」と聞くだけで、多くの場合は教えてもらえます。

🔍 検証③：現状維持のコストを数字で示す

次に、最も説得力を持つ論法を扱います。「現状維持のコスト」です。

人は変化のコストを過大評価し、現状のコストを過小評価します。心理学では、同じ金額の損失は、利益より強く感じられることが知られています（損失回避）。つまり「やれば得られる」より「やらないと失う」のほうが動きます。これは人間の性質であり、良い悪いの話ではありません。提案の技術として使いこなすものです。

では現状維持のコストをどう出しますか。4つの発生源を数えると出せます。

①手作業の時間：毎回人がやっていること。頻度 × 1回の時間で計算します。
②待ち時間：止まっている時間。「誰かの回答を待つ」「ビルドを待つ」「権限を待つ」。
③手戻りの時間：やり直し。「修正のたびに壊れる」はここに入ります。
④回避行動の時間：「触らないようにしている」こと。最も見落とされます。壊れるのが怖いから誰も触らない。すると改善できず、状態は悪化し続けます。

回避行動が最も強い論法です。「この機能は誰も触りません。触ると壊れるからです。そのため、3年前から改善されていません」。これは技術の言葉より、はるかに強い。損失が進行していることが伝わるからです。

数字を作るときの注意があります。精密に見せすぎないことです。「月16.3時間」より「月16時間程度」のほうが信じられます。根拠も併記します。「1回約2時間、月8回、実測は先月の作業記録から」。推定であることを明示し、幅を持たせます。「16〜20時間」。過剰な精度は、逆に疑われます。これはファクトチェックの原則と同じです（blog-writer エージェントの職種定義でも扱っています）。

🔍 検証④：提案は6点セットで作る

次に、提案の構造です。形式が整っていると、相手の判断コストが下がります。承認の速度は、判断コストに反比例します。

①現状：いま何が起きているか。事実のみ。感情や評価を入れません。
②問題：何が困るのか。誰が困るかを明示します。
③放置した場合：これが最重要。いつ、何が起きるか。時間軸と金額で示します。
④選択肢：最低3つ。「何もしない」も必ず入れます。
⑤推奨：どれをなぜ勧めるか。判断の材料を減らすのが目的です。
⑥必要なもの：人・時間・権限・予算。具体的な数字で。

④選択肢に「何もしない」を必ず入れるのは、心理的に重要です。選択肢が1つしかない提案は、脅しのように受け取られます。「何もしない」を並べることで、「選ぶ」という構図になります。そして「何もしない」の欠点を③で書いてあるので、自然に推奨へ誘導されます。誘導ではなく、比較になっているのがポイントです。

🔍 検証⑤：小さく試す——1回で全部を通そうとしない

次に、通す進め方です。大きな提案は、1回で通りません。そして1回で通そうとすると、議論が大きくなりすぎて止まります。

代わりに分割して提案します。3段階の進め方が有効です。

段階1：調査の提案（最も通りやすい）。「本番での影響を調べるために、3日だけ使わせてください」。工数が小さく、可逆で、判断が簡単です。そして調査結果が、次の提案の材料になります。調査は提案の燃料です。

段階2：小さな試行の提案。「1機能だけ、テストを追加して効果を測ります」。範囲が限定され、戻せます。第5回の可逆性の設計が、ここで効きます。

段階3：全体への展開。段階1と2の実績を持って提案します。この時点で、あなたは「実績のある人」になっています。

「調べるだけ」の提案が最も通りやすいという事実は、覚えておく価値があります。「3日ください」は、ほとんど誰も断りません。そしてその3日が、あなたの提案の質を決めます。第1回で扱った「成果の時間差」を思い出してください。調査は短期的には成果に見えませんが、提案という形で回収されます。

🔍 検証⑥：反対意見の先回りと、根回し

次に、通すための事前準備です。提案は、会議で初めて出すものではありません。

先回りとは、想定される反対意見を、提案書に先に書いておくことです。「工数が足りないのでは？」→「初年度は月4時間で、既存の保守枠から捻出できます」。「他チームへの影響は？」→「影響は2画面のみで、事前に確認済みです」。「効果は本当に出るのか？」→「同種の取り組みで、社内に前例があります。実測値は〇〇」。反対意見を先に潰しておくと、会議は「承認」の場になります。

根回しとは、会議の前に、キーとなる人に1対1で話しておくことです。第4回（理不尽シリーズ）で扱った5役割（決定者・影響者・情報保持者・実行者・影響を受ける人）を思い出してください。特に「影響を受ける人」を忘れないこと。会議で初めて知った人は、反対します。理由は内容ではなく、知らされていなかったことです。事前に5分話しておくだけで、態度が変わります。

タイミングも重要な変数です。予算の時期、評価の時期、障害の直後、体制変更の直後。関心が高いときは、提案が通りやすい。逆に関心が低いときに正論を出しても、届きません。「いつ出すか」は「何を出すか」と同じくらい重要です。

結果：提案書のテンプレートと、却下されたときの扱い

提案書のテンプレートです。

【提案】〈一行で、何をどうするか〉
　例：リリース前の自動チェックを導入し、手戻りを月16時間削減する

■ 現状（事実）
　・直近3か月で、リリース後の修正が月8件発生
　・1件あたりの確認・再リリースに約2時間（作業記録より）
　・月16時間、担当2名の時間が消えている

■ 問題（誰が困るか）
　・担当者の時間が奪われ、新機能の開発が遅れる
　・利用者には、修正が届くまで最大2日かかる

■ 放置した場合（いつ・何が・いくら）
　・利用者数の増加に比例して、手戻りは増える見込み
　・来期は月12件（約24時間／月）と試算
　・年換算で約〇〇万円相当の工数

■ 選択肢
　① 何もしない → 手戻りは増加し続ける（推奨しない）
　② 自動チェックを導入（推奨）
　③ 手動チェックリストを増やす → 時間は増えるが効果は限定的

■ 推奨と理由
　②を推奨。導入は1機能から始められ、問題があれば元に戻せる（可逆）
　第5回の手順に従い、フラグで切り替え可能な形にする

■ 必要なもの
　・工数：初月12時間、以降は月2時間（保守）
　・権限：CI設定の変更権限
　・期限：来期の開発計画に間に合わせるなら今月中の着手

■ 想定質問
　Q. 工数が足りないのでは → A. 既存の保守枠から捻出可能（内訳は別紙）
　Q. 別チームへの影響は → A. 影響は2画面のみ。事前確認済み
　Q. 効果は確実か → A. 社内の類似事例では手戻りが約4割減（実測）

却下されたときの扱いも設計します。却下は失敗ではありません。判断の材料が足りなかっただけです。そして最も大切なのは、却下理由を記録することです。「予算の都合」「優先順位」「情報不足」「時期尚早」。理由によって、次の一手が変わります。情報不足なら追加調査、優先順位なら他の課題とセットにする、時期なら次の機会を待つ。「再度提案する条件」を書いておくと、次の提案が通りやすくなります。

考察：提案が通る人は、内容ではなく「形式」を磨いている

ここまでを踏まえて、1つ踏み込んだ話をします。提案が得意な人は、内容が人より優れているわけではありません。形式が整っているだけです。

観察してみてください。通る提案には共通の形があります。一行の結論、数字、選択肢、推奨、必要なもの。逆に通らない提案にも共通の形があります。長い、技術用語が多い、選択肢がない、誰が得するか書いていない。内容の質と、形式の質は別であり、後者は練習で身につきます。

そして、提案は1回で完結しません。却下され、修正され、別の形で再登場します。だから提案の記録を残すことが効きます。決定と理由、却下の理由、当時の前提。数か月後、前提が変わったときに、あなたの記録が提案を復活させます。「半年前に検討したときは、前提がXでした。いまYに変わったので、再提案します」。この記録がある人は、非常に強い。記憶は消えますが、記録は残ります。

もう1つの考察は、提案の究極の形は「提案しなくても進む仕組み」だということです。毎回承認を取るのではなく、基準を先に決めておく。「この指標がこの水準を下回ったら、自動的にこの対応をする」と決めておけば、いちいち提案しなくて済みます。これは第2回で扱ったエラーバジェットや第5回の可逆性と同じ発想です。良い仕組みは、判断の回数を減らします。そしてその仕組みを作る提案こそ、最も価値の高い提案です。

📌 注目ポイント

核心は4点です。第一に、意思決定は正しさではなく損得で行われること。第二に、技術の言葉を4つの通貨（時間・金額・リスク・評価）に翻訳すること。第三に、現状維持のコストを数字で示すこと（とくに回避行動）。第四に、小さく試す3段階（調べる→試す→広げる）で合意を積み上げること。

特に第二点の「評価」への翻訳が最も強い武器です。相手が報告している指標に結びつけると、他人事が自分事になります。これはずるい技術ではなく、相手の関心を理解する技術です。

💡 活用事例：提案の形式が標準化されている世界

提案の形式が公開の標準として整備されている例があります。Rust言語のRFCプロセスとPythonのPEP（Python Enhancement Proposal）です。これらは言語仕様の変更提案の書式を定義しており、世界中の技術者が同じ形式で提案しています。

その構成は、提案書のテンプレートとしてそのまま使えます。①動機（なぜ必要か）、②ガイドレベルの説明（概要）、③詳細設計、④欠点（欠点を隠さない）、⑤代替案、⑥未解決の課題。注目すべきは④欠点と⑤代替案を必須にしていることです。提案者が自分の提案の弱点を書く。これにより、読む人は比較検討できます。

欠点を自分から書くという技術は、心理的に抵抗があります。しかし信頼の面で圧倒的に有利です。「この人は都合の悪いことも書く」という評価が生まれ、その後の提案も読んでもらえるようになります。提案は1回の勝負ではなく、繰り返しのゲームです。1回の勝ちより、100回読まれる信頼のほうが価値があります。

✅ 要点まとめ

• 意思決定は正しさではなく損得で行われる。「すべき」では決まらない
• 技術の言葉を4つの通貨（時間・金額・リスク・評価）に翻訳する
• 評価への翻訳が最も強い。相手が報告している指標に結びつける
• 現状維持のコストを示す。とくに回避行動（触らないことによる損失）が強い
• 提案は6点セット：現状・問題・放置した場合・選択肢・推奨・必要なもの
• 「何もしない」も選択肢に入れる。比較の構図を作る
• 1回で通そうとしない。調べる→試す→広げるの3段階
• 先回り（想定質問）と根回し（1対1）を先にやる
• 却下理由を記録する。再提案の条件を書いておく
• 欠点を自分から書くと、長期的に読まれる提案になる

🚀 取り込み方：明日から使う3段階

今日（5分でできること）：自分が通したい提案を1つ選び、「放置した場合に何が起きるか」を1文で書いてください。これが書けない場合、提案の緊急性が伝わりません。「このままだと、いつ、何が、どれくらい困るか」。1文で書ければ、提案の8割は準備できています。

今週（小さく試す）：「調べるだけ」の提案を1つ出してください。「3日だけ使って、現状を計測させてください」。そして計測結果を、数字と日付でまとめます。たとえば「先月の手戻りは8件、確認作業は合計16時間」。この数字を持って、次の提案をします。数字を持つ人は、提案が通ります。第1回の言葉で言えば、計測は成果の材料を作る仕事です。

今月（業務に組み込む）：提案の記録を作ります。提案した内容、決定、理由、却下の場合はその理由と再提案の条件。これを1つのファイルに貯めます。半年後に前提が変わったとき、この記録があなたの提案を復活させます。そしてチームに「提案のテンプレート」を提案します。提案の形式が揃うと、チーム全体の意思決定が速くなります。これは第1回で扱った「成果」の典型例で、作業は小さく、効果は長期に残ります。

🔥 ハマりポイント：提案が通らない3つの型

その1：「内容が正しければ通る」と思いがちだが、実は相手は損得で判断している

症状は、正論を並べた提案が「検討します」で終わる。原因は相手の判断軸に翻訳されていないことです。対処は、提案を出す前に「相手は何を報告しているか」を調べることです。四半期の目標、経営会議の資料、評価指標。これらは多くの場合、共有されています。そして自分の提案をその指標に結びつけます。「この取り組みは、〇〇の指標を0.5ポイント改善します」。1文の翻訳が、提案の生死を分けます。

その2：「大きな提案を一度に出すほうが効率的」と思いがちだが、実は大きい提案は止まる

症状は、半年分の改善をまとめた提案が、議論の大きさに耐えられず止まる。原因は判断の単位が大きすぎることです。対処は、提案を分割することです。「調べる」「試す」「広げる」の3段階。そして各段階を、独立して承認できる形にします。第5回の可逆性の設計が、そのまま使えます。「1機能だけで試し、問題があれば戻せます」——この一言で、承認のハードルが一段下がります。

その3：「一度却下されたら終わり」と思いがちだが、実は理由が変われば通る

症状は、却下後に同じ提案を繰り返すか、諦める。原因は却下の理由を記録していないことです。対処は、却下理由を4分類して記録することです。①情報不足（追加調査で解決）②優先順位（他の課題とセットにする）③資源不足（時期を待つ）④方針不一致（提案の方向を変える）。分類すると、次にやることが決まります。そして半年後に前提が変わったとき、その記録が提案を復活させます。却下は、延期であって否定ではありません。

🔄 代替アプローチとの比較：提案の通し方

提案の通し方には複数の型があります。組織の文化と、提案の性質で選びます。

巻き込み型が向いているケースは多くあります。影響を受ける人が多い提案では、完成した提案を見せるより、途中から参加してもらうほうが通ります。「自分の意見が入っている」提案は、反対しにくいからです。第4回（理不尽シリーズ）の「影響を受ける人」を思い出してください。最も忘れられる役割であり、最も反対する役割です。最初から巻き込めば、反対者が味方になります。ただし時間はかかります。急ぎの提案には向きません。

📅 今後の展望：提案は「文書化」と「基準化」へ

提案の文化は、この10年で文書化の方向に進みました。口頭で根回しして通すより、書かれた提案を読んで判断する。会議で長い資料を説明するより、事前に読んでから議論する。この流れは非同期の働き方とも噛み合い、リモートワークの普及で加速しました。提案書の質が、そのまま影響力になる環境が増えています。

もう1つの流れは、基準化です。毎回提案しなくても、基準を満たせば進められる仕組み（エラーバジェット、自動承認、権限委譲）が広がっています。これは提案の回数を減らし、その代わり「基準を作る提案」の価値を上げます。基準を作れる人は、最も影響力の大きい提案をしていることになります。

そしてAIの普及で、提案書の下書きは簡単に作れるようになりました。形式は誰でも整えられます。だからこそ差がつくのは「何を翻訳するか」「どの数字を使うか」「どのタイミングで出すか」です。相手の評価指標を知っているかどうかが、これまで以上に重要になります。相手を観察する時間が、提案の質を決めます。

まとめ

この記事では、提案を通す技術を扱いました。意思決定は正しさではなく損得で行われ、技術の言葉は4つの通貨（時間・金額・リスク・評価）に翻訳します。現状維持のコスト、とくに回避行動を示すことで緊急性が伝わります。提案は6点セットで作り、調べる→試す→広げるの3段階で通します。そして却下理由を記録し、欠点を自分から書くことで、長期的に読まれる提案者になります。

これを読んだあなたは、正しい提案を、相手が判断できる形に翻訳して出せるようになりました。次の第9回では、そもそも何を作るべきかを扱います。作れるものと、効くものは違う——それが次のテーマです。第8回が「通し方」なら、第9回は「何を通すか」です。

参考文献

1. Rust RFC テンプレート（rust-lang/rfcs） — 動機・詳細設計・欠点・代替案・未解決の課題という公開提案の書式。 https://github.com/rust-lang/rfcs
2. PEP 1 / PEP 12（Python Enhancement Proposals） — 提案書の標準構成を定義した一次資料。 https://peps.python.org/
3. Malte Ubl「Design Docs at Google」（2020） — 設計提案の文書文化と構成。 https://www.industrialempathy.com/
4. Jeff Bezos「2017 Letter to Shareholders」（Amazon） — 6ページの文章による提案・意思決定の運用。 https://www.aboutamazon.com/
5. Daniel Kahneman & Amos Tversky（1979）「Prospect Theory」 — 損失回避の原典。 https://www.jstor.org/
6. Daniel Kahneman『Thinking, Fast and Slow』（2011） — 損失回避と意思決定の偏り。
7. Robert B. Cialdini『Influence: The Psychology of Persuasion』（1984, 新版2021） — 説得の6原則。
8. Roger Fisher & William Ury『Getting to Yes』（1981） — ポジションとインタレストの区別。
9. John P. Kotter『Leading Change』（1996） — 変革における緊急性の確立。
10. Everett M. Rogers『Diffusion of Innovations』（1962） — 新しい取り組みの採用者分類。
11. Chip Heath & Dan Heath『Made to Stick』（2007）／『Switch』（2010） — 伝わる説明と変革の設計。
12. Ward Cunningham（1992）「The WyCash Portfolio Management System」 — 技術的負債の原義。
13. Michael Nygard「Documenting Architecture Decisions」（2011） — 決定と理由を記録するADRの原典。
14. Google『Site Reliability Engineering』 — エラーバジェットによる、提案を減らす基準設計。 https://sre.google/
15. IPA『iコンピテンシ ディクショナリ』 — 合意形成と提案に関する能力定義。 https://www.ipa.go.jp/
16. 経済産業省『DXレポート』 — 経営層と技術者の対話に関する日本の政策的文脈。 https://www.meti.go.jp/