「技術的に正しい」だけでは伝わらない。エンジニアが話す構造を変えてから気づいたこと

設計レビューの場で、10分かけて丁寧に説明したのに「で、結局どうしたいの？」と返ってきたことがある。

技術的には正しい判断だと自分では確信していた。背景も、選択肢の比較も、リスクの考慮も、すべて盛り込んだはずだった。なのに相手には届かなかった。

このとき初めて気づいたのは、「技術的に正しい」ことと「伝わる」ことは、まったく別のスキルだということです。

結論から言うと、エンジニアの説明が伝わらない原因のほとんどは、情報の量ではなく「話す順番と構造」にあります。何を話すかより、どの順番でどう組み立てるかが、聴き手の理解と納得を左右します。この記事では、エンジニアが「話す構造」を変えることで、技術の説明・提案・レビューコメントが変わった気づきと実践方法を整理します。

※ 30日間の無料体験。いつでも解約可能。

「技術的に正しい」のに伝わらない理由

「正確さ」と「伝わりやすさ」は別のスキル

エンジニアはコードを書くうえで「正確さ」を最優先にするよう訓練されています。曖昧な変数名はバグを生み、不正確な仕様は手戻りを生む。正確さへのこだわりは技術者として本質的な美徳です。

しかしこの習慣が、説明の場では逆効果になることがあります。正確に伝えようとするあまり、前提の説明に時間をかけすぎる。例外ケースを丁寧に列挙しすぎる。結論に至るまでの経緯を省略できない。

聴き手は多くの場合、完全な正確さより「要点が何か」を先に知りたがっています。特に非エンジニアのステークホルダーや忙しいマネージャーは、詳細な背景より「で、結論は何か・自分は何をすればいいか」を最初に求めています。正確さと伝わりやすさを両立するには、構造の設計が必要です。

聴き手の「知識レベルと関心」を出発点にしていない

伝わらない説明のもう一つの共通点は、「自分が話したい順番」で話していることです。技術者として理解している流れ（背景→調査→比較→選定→結論）を、そのまま相手に押しつけてしまう。

しかし聴き手によって、関心のある情報は異なります。エンジニア同士のコードレビューなら技術的な詳細を深く聞きたい。プロダクトマネージャーへの技術提案なら「なぜこの選択がビジネスに良いか」が最優先の関心事。経営層へのリスク報告なら「影響範囲と対処コスト」が核心。

伝わる説明は、聴き手の関心事から逆算して設計されています。自分の話したい内容を整理するのではなく、相手が知りたいことを先に定義し、そこに向かって組み立てる。この順番の逆転が、「伝わらない」を解消する起点になります。

伝わる話し方の「構造」とは何か

結論から先に話すPREP法

ビジネスコミュニケーションで最も汎用性が高い話の構造が、PREP法です。Point（結論）、Reason（理由）、Example（具体例）、Point（結論の再提示）の順で話す構造です。

エンジニアが設計提案をする場合の例を挙げます。

• Point（結論）：「今回はマイクロサービス分割ではなくモノリスのまま進めることを提案します」
• Reason（理由）：「現チームの規模とデプロイ頻度では、分散システムの運用コストがメリットを上回るためです」
• Example（具体例）：「〇〇社のケースでも、チームが10名以下の段階でマイクロサービスに移行した後、運用負荷が3倍になった報告があります」
• Point（結論の再提示）：「そのため、まずモノリスの設計を整え、スケールフェーズで再検討することを推奨します」

伊藤羊一氏は「1分で話せ」の中で、「人は最初に結論が来ないと聴く気をなくす」と指摘しています。聴き手はまず「この話を聴く価値があるか」を判断しようとするため、結論が最初に来ることで注意を引きつけることができます。

ピラミッド構造で情報を階層化する

より複雑な説明が必要な場合に有効なのが、ピラミッド構造です。頂点に「主張（結論）」を置き、その下に「根拠」、さらに下に「データ・具体例」を積み上げる構造です。

技術設計の提案書・ドキュメントに適用する場合：「このアーキテクチャを採用すべき（主張）」→「スケーラビリティ・保守性・コストの3点で優位（根拠）」→「各根拠のデータと比較表（データ）」という流れです。

この構造の利点は、「どこまで深く聴くか」を聴き手が選べることです。忙しいステークホルダーは頂点の主張だけ聞けば意思決定できる。詳細が必要なレビュアーは根拠とデータまで読む。階層構造が聴き手の時間コストを下げ、説明の汎用性を上げます。

エンジニアが特に使えるシーンと実践方法

技術提案をPREPで組み立てる

「次のスプリントでリファクタリングを入れたい」「ライブラリをアップデートすべき」「新しいキャッシュ戦略を試したい」。エンジニアが技術的な提案をする場面は多い。しかしこうした提案が通らない場合の多くは、技術の正しさより「なぜ今やるのか・やらないとどうなるのか」の説明が弱いケースです。

PREP法を使うと、技術提案がシャープになります。「結論（何をしたいか）→理由（なぜ今必要か）→例（やらないと何が起きるか・やった事例）→結論再提示（決断してほしいこと）」。このフォーマットで準備することで、会議の場で「説明が長い」と言われる状況が減ります。

実際に試してみて気づいたのは、PREPで組み立てると、自分の提案の根拠が甘い部分に気づくことです。「理由」を一文で書こうとすると、「なぜそれが必要か」を自分で明確に言語化できていないことが浮き彫りになります。話す構造を整えることは、思考の整理でもあります。

非エンジニアへの技術説明を変える

エンジニアが最も苦労するのが、技術的な内容を非エンジニアのマネージャーや他部署のメンバーに説明する場面です。「APIの応答速度が劣化している」「データベースのインデックス設計を見直す必要がある」といった内容を、技術の詳細なしに伝えなければならない。

このときに有効なのが「ビジネスへの影響に翻訳する」アプローチです。技術の問題を直接説明するのではなく、「それが放置されると何が起きるか（リスク）」「対処するとどうなるか（メリット）」「対処にかかるコスト（工数・期間）」の3点に絞る。

「APIの応答が劣化している」ではなく「現状では一部の操作に3秒以上かかっており、離脱率の上昇リスクがあります。1週間の修正で改善できます」という伝え方です。聴き手の関心事（ビジネスへの影響）から逆算した翻訳が、技術説明を「伝わる説明」に変えます。

コードレビューのコメントを「伝わる」形に変える

コードレビューのコメントもまた、話す構造が問われる場面です。「ここは良くない」「修正が必要」というコメントが多いと、レビュイーは「何が問題で、どう直せばいいか」が理解しにくく、レビューの往復が増えます。

伝わるレビューコメントの構造は「問題の指摘（What）→なぜ問題か（Why）→改善案（How）」の3点セットです。「この箇所はN+1クエリが発生する（What）。ループ内でDBアクセスが繰り返されるためパフォーマンスへの影響が大きい（Why）。eager loadingを使ってクエリを1回にまとめることを検討してください（How）」という形です。

この構造を守ることで、レビュイーが意図を理解しやすくなり、修正の品質も上がります。また、Why を書くことで自分自身の指摘の根拠も明確になり、議論の場でも説得力が増します。

話す前の「準備」を変える

1分で話せるかを自分でテストする

会議の前日、または朝の準備時間に「今日伝えたいことを1分で言えるか」を自分にテストすることを習慣にしました。タイマーを1分セットして、声に出して話す。1分で結論・理由・お願いが言い切れない場合は、整理が足りていないサインです。

伊藤羊一氏が「1分で話せ」で強調しているのは、「1分は制限ではなく訓練」だということです。1分に収めようとすることで、「本当に伝えたいことの核心は何か」を考える力が磨かれます。最初は難しくても、繰り返すことで要点の抽出スキルが身につきます。

1分でまとめられない話は、聴き手の10分を奪う可能性があります。この感覚を持てるようになると、会議での発言が変わります。

メモで「話す設計図」を先につくる

説明する前に、A4用紙か手元のメモに「結論・理由・例・お願い」を箇条書きで書き出す習慣を取り入れました。これは赤羽雄二氏が「ゼロ秒思考」で推奨するメモ手法の応用で、頭の中を一度外に出すことで思考が整理されます。

書き出してみると、「理由が1つしかない」「例が弱い」「結論が2つに分かれている」という問題が見えやすくなります。書く前には気づかなかった設計の甘さが、文字にすることで可視化されます。

この事前準備を取り入れてから、会議中に「あ、言い忘れた」と焦るケースが大幅に減りました。話す内容がメモとして頭の外に出ているため、話しながら別のことを考える認知的余裕が生まれます。

相手の「知りたいこと」を先に定義する

説明を準備するとき、「自分が伝えたいこと」から考えるのではなく、「相手が知りたいこと」から逆算するようにしました。安宅和人氏が「イシューからはじめよ」で示すイシューの定義と同じアプローチです。

相手が知りたいことは「この技術判断はビジネスにどう影響するか」「このリスクはどの程度深刻か」「自分がすべきアクションは何か」といったことです。これを先に定義してから説明の構造を組むことで、「必要な情報だけが並ぶ」説明になります。

エッセンシャル思考（グレッグ・マキューン著）の「本当に重要なことだけに絞る」という原則は、説明の設計にも当てはまります。詰め込みすぎた説明より、核心だけを届ける説明の方が聴き手の記憶に残ります。

話す構造を変えるきっかけになった本4冊

エンジニアとして「伝える力の構造」を学ぶうえで、視点を根本から変えてくれた4冊を紹介します。いずれもAudible（オーディブル）で配信されており、通勤中や隙間時間に音声で聴くことができます。

1分で話せ

著者：伊藤羊一（ソフトバンクアカデミア第1期生・Yahoo! Academiaを設立したリーダーシップ教育の専門家）

「人は話の最初の15秒で聴くかどうかを決める」という前提から始まり、結論から話す構造・ピラミッド型の思考整理・相手を動かすプレゼンの組み立てを、具体的なフォーマットで解説した実践書です。エンジニアが設計提案や技術説明を行う場面に直結する内容が多く、読んだ翌日から試せる手法が詰まっています。

Audibleで聴くなら：通勤中に1章ずつ聴き、その日の会議やSlackでのやりとりで「1分で言えるか」を試す。インプットとアウトプットのサイクルが最も回しやすい一冊です。

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

イシューからはじめよ

著者：安宅和人（ヤフー株式会社CSO・慶應義塾大学環境情報学部教授）

「解くべき問題（イシュー）を正しく定義する」ことがすべての仕事の質を決めるという核心を説いた思考法の本。説明の場面では「相手が本当に知りたいことは何か」というイシュー定義が出発点になります。この問いを持てるようになると、説明の設計が根本から変わります。

Audibleで聴くなら：1章ずつ聴きながら「今担当しているプロジェクトのイシューは何か」を考えながら聴くと理解が深まります。説明力と問題解決力を同時に磨ける一冊です。

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

ゼロ秒思考

著者：赤羽雄二（マッキンゼー出身・エンジニア起業家支援・ビジネス書著者）

「頭の中にある考えをA4メモで即座に言語化する」というシンプルな手法で、思考の整理と言語化のスピードを上げる実践書。説明の前に「言いたいことをメモに書き出す」習慣の土台として機能します。話す内容が頭の外に出ることで、会議中の余裕が生まれます。

Audibleで聴くなら：移動中に聴いて、到着後すぐにメモを試す。「1分で聴いて1分で書く」というサイクルが習慣化しやすい本です。

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

エッセンシャル思考

著者：グレッグ・マキューン（世界的なコンサルタント・講演家）

「最重要なことに集中し、それ以外を捨てる」という思想を徹底的に掘り下げた思考法の本。説明においては「伝えたいことを詰め込みすぎない」という選択の重要性を教えてくれます。「少ないほど伝わる」という逆説を体得したいエンジニアに刺さる一冊です。

Audibleで聴くなら：各章が短くコンパクトにまとまっているため、隙間時間に1〜2章ずつ聴くスタイルが合います。「この説明、本当にこれだけの情報が必要か？」という問いを持つ習慣が身につきます。

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

よくある質問

まとめ

「技術的に正しい」説明が伝わらない理由は、情報の量ではなく、話す構造の設計にあります。

• 正確さと伝わりやすさは別のスキル。構造で両立できる
• PREP法（結論・理由・例・結論）で話す順番を変えるだけで説明が変わる
• ピラミッド構造で情報を階層化し、聴き手が深さを選べるようにする
• 非エンジニアへの説明は「ビジネスへの影響に翻訳する」
• コードレビューのコメントも「What・Why・How」の3点セットで伝わりやすくなる
• 1分で話せるかを事前にテストする習慣が、説明力を磨く最速の練習になる

話す構造を変えると、技術の評価が変わります。同じ内容でも、結論から話し、理由が明確で、相手の関心に合った説明をするだけで、会議での発言の重みが変わります。

「1分で話せ」を移動中にAudibleで聴きながら、その日の会議で実践する。このサイクルを繰り返すことで、「伝え方がうまいエンジニア」という評価は、才能ではなく練習の積み上げで手に入ります。

※ 30日間の無料体験。いつでも解約可能。