エンジニアが「伝える力」を鍛えたら、技術の評価が変わった話

「自分が見つけたバグの説明をしたのに、なぜかレビュアーに伝わらなかった」

「設計の意図を説明したのに、会議では別の方向に話が進んでしまった」

「上司への進捗報告のたびに、なぜかすれ違いが起きる」

技術力は十分にあるはずなのに、コミュニケーションのたびに手ごたえがない。こういったもどかしさを抱えているエンジニアは、決して少なくありません。私自身も、キャリアの初期にまったく同じ壁にぶつかりました。

転機になったのは、「伝える力」を意識的に鍛え始めてからです。コードを書く技術とは別の軸で、「相手に情報を届ける力」を磨いたことで、コードレビューの通り方、会議での発言の受け取られ方、上司との関係性が変わりました。

この記事では、エンジニアが「伝える力」を鍛えることで何が変わるのかを、具体的な場面・方法・おすすめの本とともに解説します。

この記事で分かること：

• エンジニアが「伝えにくさ」を感じやすい3つの場面
• 「知識の呪い」と「論理優先の思考」が伝わらない原因になるメカニズム
• 「1分で話せる力」の正体と実践法
• 今日から始められる「伝える力」の日常トレーニング
• Audibleで聴けるおすすめ本5冊

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

エンジニアが「伝えにくさ」を感じる3つの場面

エンジニアとして働いていて「うまく伝わらない」と感じる場面には、いくつかの共通パターンがあります。まず代表的な3つを整理します。

コードレビューで指摘した内容が受け入れられない

コードレビューで技術的に正しい指摘をしたつもりでも、「なぜそうしなければならないのか」が相手に伝わらず、議論が噛み合わなかった経験はないでしょうか。

こういった状況が起きる原因の多くは、コメントの書き方に問題があります。「この実装はパフォーマンス上の問題があります」という指摘は技術的には正確でも、「なぜそれが今のプロダクトで問題になるのか」「どう直せばよいのか」という文脈が抜けていると、受け取る側は判断がしにくくなります。

技術的な正確さと、相手にとっての分かりやすさは別物です。この違いを認識するだけで、コードレビューのコメントの書き方が変わります。

非エンジニアや上司への技術説明が毎回難航する

プロダクトマネージャーや経営層に技術的な制約や工数を説明しようとすると、話が噛み合わないことがあります。「なぜそれに2週間もかかるのか」「もっと簡単にできないのか」といった質問を受けるたびに、どこから説明すればいいか迷ってしまう。こういった経験を持つエンジニアは多いはずです。

この場面での課題は「どれだけ詳しく説明するか」ではなく、「相手の関心事に合わせて何を選んで伝えるか」です。非エンジニアが知りたいのは技術の詳細ではなく、「それによって何ができるか・できないか」という事業への影響です。

もう一つ代表的なのは、1on1や進捗報告での「伝えたいことが言えなかった」という体験です。頭の中に言いたいことはあるのに、言葉にしようとするとうまくまとまらない。その結果、「なんとなくOK」で会議が終わってしまい、本当に相談したかったことが積み残しになる。

「伝わらない」の根本原因を理解する

伝わらない原因は、「話し方が下手」「説明が長い」といった表面的なものではありません。より根本的な認知のメカニズムを理解することが、改善への近道です。

「知識の呪い」が引き起こす一方通行の説明

「知識の呪い（Curse of Knowledge）」とは、認知心理学の概念で、「ある知識を持っている人が、その知識を持っていない人の視点に立って考えることが難しくなる」という認知バイアスのことです。

エンジニアは技術的な知識が深いがゆえに、この呪いにかかりやすいです。「スタックトレースを見ればわかる」「Nプラスワン問題だから遅いのは当然」といった説明は、同じ知識を持つエンジニア同士では通じても、そうでない相手には暗号になります。

実際に試してみて気づいたのは、「自分が当然だと思っていることを疑う」という習慣を持てるかどうかが、伝わる人と伝わらない人の分かれ目だということです。説明の前に「相手はどこまで知っているか」を確認するだけで、伝わり方が変わります。

エンジニアに多い「論理優先・結論後回し」の思考パターン

エンジニアはプロセスの積み上げで答えを導く思考が得意です。「まず現状を整理して、問題を特定して、原因を分析して、解決策を提示する」という流れは、技術的な問題解決には最適です。しかし、コミュニケーションでこれをやると、相手は「で、結論は何？」と思いながら聴き続けることになります。

ビジネスのコミュニケーションでは、結論を最初に言ってから理由・背景を補足する「結論ファースト」が原則です。エンジニアが意識的にこの順序を逆転させることが、最初の大きな改善ポイントになります。

「Aという問題があります。原因はBで、Cという対応をします。工数はDです。」この4行で伝えられる内容を、背景の説明から始めると10分の会議になります。

「1分で話せる力」の正体と、エンジニアへの応用

伊藤羊一氏の著書「1分で話せ」は、エンジニアが「伝える力」を鍛えるうえで最も実用的な一冊の一つです。書名の「1分」は時間の話ではなく、「聞き手の集中が続く範囲で、最も重要なことを伝え切る」という思想を指しています。

結論ファーストのピラミッド構造を身につける

「1分で話せ」が提唱する構造は、ピラミッド型の3段構成です。

• 頂点（結論）：「何を伝えたいか」を1文で言う。例：「このリリースは1週間延期が必要です」
• 中段（理由・根拠）：結論を支える理由を2〜3点挙げる。例：「テストで致命的なバグが見つかった、修正に3日必要、QA再確認に2日かかる」
• 底辺（事実・データ）：必要に応じて詳細を補足する。例：「具体的には〇〇の機能でX件のバグが発見されており、影響範囲はY箇所です」

このピラミッド構造を意識するだけで、コードレビューのコメント・Slackのメッセージ・会議での発言が変わります。結論から始まるので、相手は最初の1文を聞いた時点で「この話が自分に関係あるかどうか」を判断できます。

「相手が何を決めたいか」から逆算する習慣

「1分で話せ」でもう一つ重要な考え方が、「聞き手は何かを判断・決定するために聴いている」という前提です。上司への報告も、チームへの技術説明も、相手は最終的に「何かを判断する」ために聴いています。

この前提を持つと、伝えるべき内容の選び方が変わります。「自分が言いたいことを言う」から「相手が判断するために必要な情報を届ける」へと、思考の起点が変わります。エンジニアが設計の意図を説明するとき、技術的な詳細より「この選択によってプロダクトにどんな影響があるか」を先に伝える方が、意思決定者には刺さります。

実際にこの視点を持ち始めてから、スプリントレビューでの自分の説明時間が半分以下になり、かつ「わかりやすかった」というフィードバックが増えました。伝える量を増やすより、相手が必要としているものを絞り込む方が、コミュニケーションの質は上がります。

今日から始められる「伝える力」の日常トレーニング

「伝える力」はセンスではなく、訓練で高められるスキルです。エンジニアの日常業務の中に組み込める具体的なトレーニングを4つ紹介します。

コードレビューのコメントを「WHY」から書く練習

コードレビューのコメントに「なぜそうすべきか」を毎回1文添える習慣をつけます。

• 修正前：「この変数名はわかりにくいです」
• 修正後：「この変数名はわかりにくいです。機能の目的が名前から読み取れないと、3ヶ月後に自分も含めて誰も意図を思い出せなくなるためです」

WHYを添えることで、指摘の意図が伝わりやすくなります。また、WHYを言語化しようとすると、自分の指摘が本当に正当かどうかを自分でも検証できます。根拠を書けない指摘は、言わない方がいいことも多いです。

「今日の作業を15秒で説明する」デイリー練習

毎朝か毎晩、「今日やること（やったこと）を15秒で説明する」という練習をします。書いてみる、声に出す、どちらでも構いません。ポイントは「15秒に絞る」という制約です。

制約を設けることで、「本当に重要なことは何か」を選ぶ力が鍛えられます。スタンドアップミーティングやSlackの朝のひとこと投稿をこの練習の場として使うのも有効です。

また、ゼロ秒思考のメモ習慣（A4に1分書き殴る）を使い、「上司に今日の進捗をどう伝えるか」をテーマにメモを書いてから報告する、という組み合わせも効果があります。書いて整理してから話すと、格段に伝わりやすくなります。

Slackの長文メッセージを書いた後に「半分に削る」習慣

Slackやドキュメントで長文を書いた後、送信前に「半分の文字数に削れないか」と自問します。余分な前置き、説明のための説明、謝罪の言葉など、削っても意味が変わらない部分は意外と多いです。

この習慣は最初は難しく感じますが、「何が本質か」を見極める力を着実に鍛えます。アウトプット大全（樺沢紫苑）でも、「書くことはアウトプットの訓練であり、それ自体が思考を明確にする」と述べられています。書いて削る行為は、思考と表現の両方を同時に鍛える最良の練習です。

週1回の「技術の非エンジニア向け説明」練習

週に一度、自分が取り組んでいる技術的なテーマを「エンジニアではない友人や家族に説明するとしたら」という設定で言語化します。ブログに書く、口頭で説明してみる、社内向けの勉強会で発表する、どれでも構いません。

「人に説明できるかどうか」は、自分がその概念を本当に理解しているかを測る最良のテストです。うまく説明できないとき、それは説明力ではなく理解の浅さが原因であることが多いです。説明を試みることで、自分の理解の深さも可視化できます。

エンジニアにおすすめの「伝える力」関連本5選

「伝える力」を深く学びたい方に向けて、Audibleで聴けるおすすめ本を5冊紹介します。

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

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

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

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

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

よくある質問（FAQ）

まとめ：技術力と伝える力は、どちらも磨ける

エンジニアが「伝える力」を鍛えることで変わることを、振り返ります。

• 「知識の呪い」と「論理優先・結論後回し」が「伝わらない」の根本原因
• 結論ファーストのピラミッド構造を使うだけで、話の伝わり方が変わる
• 「相手が何を判断したいか」から逆算すると、伝えるべき情報が自然と絞られる
• コードレビューコメントへのWHY添付、15秒要約の練習、Slackの半分削りが日常トレーニングになる
• 「1分で話せ」「アウトプット大全」「イシューからはじめよ」など、Audibleで聴ける良書が揃っている

伝える力はセンスではなく、反復で身につくスキルです。今日のコードレビューのコメント1件に「なぜそうすべきか」を1文添えることから始めてください。小さな変化が、1ヶ月後のコミュニケーションの質を大きく変えます。

「伝える力」に関する本をAudibleで通勤中や作業の隙間に聴くことで、日々のインプットを加速できます。今なら30日間無料で試せます。

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