エンジニアが「伝わらない」と思ってしまう理由
持っている知識に大きな差がある
エンジニアと非エンジニアの間には、前提知識の量に大きなギャップがあります。エンジニアにとって当然の概念でも、非エンジニアにとっては初めて聞く言葉であることが少なくありません。特に開発部署以外の人と会話するときは、相手は自分と同じ知識を持っていない場合がほとんどです。
「デプロイ」「技術負債」「レビュー」といった用語は、エンジニア間では日常的に使われます。しかし、非エンジニアがこれらの言葉を聞いても、具体的なイメージを持てないのが実情。このギャップを埋めずに説明を続けると、相手は話の内容を追えなくなり、結果として「なんとかなるでしょ」という判断につながりやすくなります。
また、知識の差を意識せずに伝えてしまうと、情報の欠落が起きる可能性もあります。専門用語や技術的背景だけでなく、伝えたい事象に至った背景、判断に至った経緯も知識と同じように大切です。お互いが持つあらゆる情報の差を埋めてはじめて”同じ知識を持った状態”と言えるでしょう。
伝える目的に対して情報量が多い
相手が知りたいのは「結局どうすればいいのか」という結論であることがほとんどですが、その結論に至るまでの情報量が多くなる傾向にあります。
相手の立場次第では、状況を100％伝える必要がありません。必要以上の情報量は、相手の理解を助けるどころか混乱を招きます。打ち合わせの場で技術的な詳細を長々と説明しても、営業担当者やプロジェクトマネージャーにとっては判断に不要な情報が多すぎると感じる場合があります。
伝えるべき情報を相手の目的に絞り込む意識が、エンジニアの伝え方には欠かせません。
物事の背景から伝えている
エンジニアはロジカルに物事を考えるため、話の順序として「背景→経緯→原因→結論」という流れをとりがちです。しかし、この順序では相手が結論を聞くまでに長い時間がかかり、途中で話の主旨を見失ってしまいます。
話す相手は伝える事案の全体像を知りません。全体像を知らないのに、背景から詳細を伝えられても相手は何を話しているのか分からなくなります。
たとえば「先月のリリース後に発生した問題の原因を調べたところ、データベースへのアクセス処理に非効率な部分があり、これを改善するために追加で3日間の工数が必要になります」という説明では、重要なポイントがどこか把握できません。
こうなると話の着地点が分からなくなり、相手に不安を抱かせたままコミュニケーションが進んでしまいます。
伝え方を変えることで得られるメリット
生産性が上がる
伝え方を改善すると、1回の説明で相手に理解してもらえる確率が高まります。何度も同じ内容を説明し直したり、誤解を解くための追加ミーティングを設けたりする手間が減ります。
たとえば、開発中のプロジェクトの仕様説明に30分かかると仮定しましょう。1回の説明で十分に内容を伝えられず、最終的に同じような説明を3回したとしたら、説明だけで90分費やしていることになります。90分あればコードレビューやテストを1件程度こなせたはずです。
会議や説明に費やす時間が短縮されることで、開発や設計に十分な時間を充てられるようになります。思考に費やす時間が増え、自分自身だけでなくチーム全体の生産性向上にもつながります。最終的に残業時間が減って、プライベートを犠牲にすることなく働ける環境が整うでしょう。
手戻りが減る
要件定義など上流工程で認識のズレが生じると、後になって大きな修正作業が発生します。最初の説明で正確に伝えられていれば、仕様の勘違いによる手戻りを大幅に減らせます。
要件定義があいまいなまま開発が進んでテスト段階で大幅な仕様変更が発生したり、発注者とPMとの間で前提条件にずれがあって実装前に大幅な修正が発生したり……。伝え方一つでプロジェクトの炎上につながるので、早めに認識合わせをすることが大変重要です。
伝え方を磨くことで自分の開発時間を守り、心理的負担も軽減できます。
リモートワークでも快適に働ける
テキストコミュニケーションが中心のリモートワーク環境では、言葉のニュアンスが伝わりにくく、誤解が生じやすくなります。正確で簡潔な伝え方を身につけると、チャットやドキュメントだけでも円滑なコミュニケーションが実現できます。
SlackやTeamsといったチャットコミュニケーションでは、表情や声のトーンといった非言語情報がなくなります。ちょっとしたトーンの差で伝えていたニュアンスが出せないので、ただやってほしいことだけを伝えても相手にストレスを与えてしまう可能性があります。
「冷たい印象を与えてしまっているかもしれない」という不安を抱えているエンジニアも多いですが、構造的な伝え方を習得することで、テキストのやり取りでも温かみのある説明ができるようになります。
エンジニアの本音を伝えやすくする言語化テクニック
本当に必要なことだけ伝える
伝えるべき情報を絞り込むことが、分かりやすい説明の第一歩です。相手に何を判断してほしいのかを明確にしたうえで、その判断に必要な情報だけを選んで伝えましょう。
たとえば、追加工数を承認してほしい場面では、「何日追加でかかるか」「その理由は何か」「承認しないとどうなるか」の3点だけ伝えれば十分です。技術的な詳細は相手から質問があったときに補足する形で対応できます。
相手が絶対に欲しい情報を事前に厳選して話し、それ以外の情報は質問があったら伝えるようにするだけでお互いのストレスが大きく減るでしょう。
全体像が伝わる結論を最初に話す
結論から話す習慣を持つことは上手な話し方のベースであり、相手に伝わる説明の基本。エンジニアに限らず、どの職種でも”結論ファースト”が重要視されるのには理由があります。
結論ファーストで話すと、相手に物事の全体像を端的に伝えられます。話の構造をつかみ切れていない人に対して、結局どうなったかを伝えると、話の方向性が分かった状態で話を聞けます。全体像が分かるようにするだけで情報がかなり伝わりやすくなるので、ぜひ取り入れましょう。
結論ファーストを実行するために使えるフレームワークがPREP法です。
PREP法はPoint（結論）・Reason（理由）・Example（具体例）・Point（結論）の頭文字から来ており、最初に結論を話してその背景を肉付けする伝え方です。先ほど紹介した追加工数を承認してほしい場面でPREP法を使うと、このような形になります。
この型を使うと、聞き手は最初から話の着地点が分かるため、説明の途中で迷子になりません。ロジカルに話を進められるので、非エンジニアに限らずエンジニア間のコミュニケーションもスムーズに進むでしょう。
関連記事
抽象的な話から具体的な話へ移行する
結論ファーストではうまく伝えにくい内容の場合、最初に全体像や方針を伝えるのも有効です。
ここまで例示してきた追加工程の承認の話だと、このような流れになります。
話の全体にかかわる抽象的な内容から話していき、結果を予想してもらいながら具体的な内容へと順を追って説明します。すると、聞き手がどのような文脈の話なのか最初に把握できるため、細かい内容が頭に入りやすくなります。
相手のレベルに合わせる
言語化能力が高い人の特徴の一つは、相手の知識レベルを素早く把握し、それに合わせた言葉を選べることです。同じ内容でも、エンジニアに話すときと営業担当者に話すときでは、使う言葉や説明の深さを変える必要があります。作業者として手伝ってほしいのか、状況を把握してほしいのかによっても伝え方が変わるので注意が必要です。
特に若手エンジニアや非エンジニアと会話する際は説明の途中で理解度の確認を挟みつつ、相手の反応を見ながら説明の粒度も変えていきましょう。
技術的な内容は"例え話"を活用する
抽象的な概念や技術的な仕組みを相手に伝えるには、日常的な場面に置き換えた例え話が効果的です。たとえばサーバーの処理能力の話をするとき、「レストランで言えば厨房のキャパシティのようなもので、注文が増えすぎると料理の提供が遅くなります」と説明すると、非エンジニアでもイメージしやすくなります。
バグのように非エンジニアでもよく使われるようになった言葉でも、認識がずれている可能性があります。できるだけ相手がすっと理解できるような言葉を使いながら、認識のずれを起こさない例え話を挟んでいきましょう。
どうしても口頭で伝えないとダメか考える
重要な内容や複雑な情報は、口頭よりもテキストで伝えるほうが正確に伝わる場合があります。テキストであれば相手は自分のペースで読み返せますし、確認の記録としても残ります。必要に応じてビジネスチャットや図説入りのドキュメントなどを準備しましょう。特に同じ内容を複数人に伝える必要がある場合は、自身が伝える労力を減らすためにも文章化が有効です。
このときも口頭での伝え方同様、相手に伝わりやすい言葉や図示方法を選ぶことをお忘れなく。
言語化能力をより高めるためにできること
読書
言語化能力が高い人に共通する特徴として、読書量の多さが挙げられます。読書は語彙力を高めるだけでなく、物事を構造的に理解する力や言語化能力を養います。
ビジネス書やエッセイ、小説など自身の専門性と関係ないジャンルでも問題ありません。大切なのは読書を通じて自分で気づかなかった視点に気づくこと。「この意見には同意できるな」「この考えは違うかも」など、読書を通じて色々な考え方を身に付けられます。
1日15分でも読書の時間を設けることで、継続的に言語化の引き出しを増やせるでしょう。
0秒思考
0秒思考とは、A4の紙に1つのテーマについて思いついたことをひたすら書き出す思考整理法です。毎日1分以内を目安に、頭に浮かんだことをそのままメモする習慣をつけることで、思考をすばやく言葉に変換する力が鍛えられます。
瞬時に言語化できる人がうまくいく理由の一つは、思考を言葉にするまでの時間を日々の訓練で短縮しているから。その練習にうってつけです。
「今日の打ち合わせで伝えたかったことは何か」「コードレビューでどう伝えればよかったか」といったテーマを設定して書き出すと、自分の伝え方の課題を客観的に把握する練習になります。はじめはひたすら考えてアウトプットするのは難しく感じるでしょうが、何度も繰り返すと脳内を整理できてスッキリするようになるでしょう。
文章によるアウトプットを行う
0秒思考のようなアウトプットもよいですが、Qiita や Zenn などの技術情報共有サービスへの記事投稿や社内 Wiki にナレッジをまとめる習慣も有効です。文章を書くことで、自分の理解があいまいな部分が明確になり、より正確な言葉を選ぶ力が育ちます。
読者に伝えることを意識した文章は、口頭での説明よりも論理の矛盾や説明の欠落に気づきやすくなります。週に1回、業務で学んだことや気づきをまとめる習慣をつけるだけでも、言語化の精度は着実に上がるでしょう。
まとめ
エンジニアにとって伝え方の工夫は単なるマナーではなく、自分の技術力と時間を守るための重要なスキルです。相手の知識レベルに合わせて情報を構造化し、専門用語をビジネス上のメリットやリスクに置き換えるようにしましょう。PREP法などの型を活用して結論から話す習慣を身につけると合意形成がスムーズになります。
同時に読書や0秒思考などで言語化能力を高めると、より論理的かつ精度の高い伝え方ができるようになるでしょう。
コミュニケーションを「仕様」として捉え、改善を繰り返すことで、後輩からも頼られ、無理な要求も論理的に回避できるエンジニアを目指しましょう。
