説明しているつもりなのに伝わらない

この瞬間の、頭が真っ白になる感じ。覚えがある方も多いのではないでしょうか。

自分では順を追って丁寧に説明しているつもりなのに、相手はキョトンとした顔。挙げ句、横にいた同僚が30秒で要約した説明のほうがスッと伝わる—— みたいな気まずい時間。

技術力と同じくらい(ときにはそれ以上に)エンジニアの評価を左右するのが「説明」です。

この記事では、「なぜ伝わらないのか」をメカニズムから分解し、明日から使える処方箋をまとめました。

想定読者

「説明が分かりにくい」「で、結論は?」と言われたことがある人
質問するたびに、相手を逆に混乱させてしまう人
後輩や他チームへの説明がうまく伝わらず悩んでいる人

結論

説明が伝わらない最大の原因は、「自分の頭の中」を基準に話していて、「相手の頭の中」を無視していることです。

伝わらない説明は、ほぼ次の4パターンに分類できます。

#	パターン	症状	聞き手の心の声
①	時系列トーク	結論が最後に来る	「この話、どこに向かってるの?」
②	知識の呪い	前提の説明を飛ばす	「その用語、なに?」
③	抽象語オンリー	具体例がない	「で、何をすればいいの?」
④	詰め込みすぎ	一度に大量の情報を流す	「待って、処理が追いつかない」

以下、順番にメカニズムと処方箋を見ていきます。

前提: 説明とは「相手の頭の中に絵を描く」作業である

各論に入る前に、1つだけ前提を共有させてください。

説明とは、自分の知っていることを口に出す作業ではありません。自分の頭の中にある「絵」を、言葉を経由して、相手の頭の中に再現してもらう作業です。

ポイントは、聞き手は受け取った言葉を自分の持っている知識を使って再構築する、という点です。だから、

相手が持っていない前提知識に依存した情報はイメージできない
順序がバラバラに届いた情報は、組み立てられない
一度に大量に情報は、理解できないため

「伝えた」と「伝わった」は、まったくの別物です。この前提に立つと、4つのパターンの正体がよく見えてきます。

パターン①: 時系列トーク〜結論が最後に来る〜

なぜやってしまうのか

人間にとって一番ラクな話し方は、自分が体験した順番に話すことです。思い出す順番=話す順番にできるので、頭を使わずに済みます。その結果、こうなります。

聞き手にとって一番重要な情報が最後に来るため、それまでのすべての情報を「どう受け取ればいいか分からないまま」になります。

処方箋: 結論ファースト(PREP法)

型としては PREP法 が鉄板です。

Point: 結論(障害は発生したが復旧済み)
Reason: 理由(環境変数の設定ミス)
Example: 具体例・詳細(どのキーが、どの環境で)
Point: 結論・次のアクション(CIにチェック追加)

ここでいう「結論」とは「自分が一番言いたいこと」ではなく、「相手が一番知りたいこと」です。

障害報告で上司が一番知りたいのは「ユーザー影響が今あるのか」。自分の苦労話ではなく、そこから話します。

パターン②: 知識の呪い〜前提を飛ばす〜

正答率2.5%の実験

1990年、スタンフォード大学で行われた有名な実験があります。

被験者を「叩き手」と「聞き手」に分けます。叩き手は「ハッピーバースデー」のような誰もが知っている曲を選び、机をタップしてリズムだけで表現します。聞き手はそれを聞いて曲名を当てる、というシンプルな実験です。

実験の前、叩き手たちは「50%くらいは当ててもらえるだろう」と予想しました。

実際の正答率は2.5%。120曲中、たったの3曲でした。

なぜここまで外れたのか。叩き手の頭の中ではメロディが鳴っているからです。自分には「タン、タン、タタン♪」が完璧に曲に聞こえる。しかし聞き手に届いているのは、ただの不規則な打撃音です。

このように、一度知ってしまった人間は、「それを知らない状態」を想像できなくなる。これが「知識の呪い」と呼ばれる認知バイアスです。

エンジニアの現場は知識の呪いだらけ

先輩の頭の中には「環境構築の全体像」というメロディが流れています。しかし新人に届いているのは断片的なタップ音だけ。先輩はサボっているわけでも意地悪をしているわけでもなく、「分からなかった頃の自分」を思い出せないのです。

専門用語、社内用語、「例の件」「いつものやつ」……すべて認知バイアスから発生します。

処方箋: 説明の前に3つの自問

説明を始める前に、3秒だけ自問してください。

相手はこの話の背景・経緯を知っているか?
相手はこの専門用語・社内用語を知っているか?
聞き終わった相手は、次に何をすべきか分かるか?

1つでも怪しければ、冒頭で確認してしまうのが最速です。

「この障害の件、経緯はどこまでご存知ですか?」
「Terraformって触ったことありますか? なければそこから説明しますね」

前提の確認は失礼ではありません。前提がズレたまま10分話し続けるほうが、よほど相手の時間を奪います。

パターン③: 抽象語オンリー〜具体例がない〜

症状

コードレビューでよく見る光景です。

「このコード、保守性が低いので、もっと疎結合になるようにリファクタしてください」

言っていることは正解ですが、言われた側はイメージできず手が動きません。「保守性」「疎結合」という抽象語は解釈の幅が広すぎて、レビュアーと実装者の頭の中に別々の絵が描かれてしまうからです。

処方箋: 「たとえば」を口癖にする

抽象的な言葉を使ったら、必ず「具体的には」「たとえば」で一段降りる。

「このコード、保守性の面で1点気になります。
具体的には、UserService がメール送信クラスを直接 new している部分です。
この構造だと、たとえば将来メール基盤をSendGridから別サービスに乗り換えるとき、
UserService 側まで修正が必要になります。
インターフェースを切ってDIする形にしませんか?」

逆に、細かい話が続いたときは「要するに〜ということです」と要約する。この抽象と具体の往復を自在にできる人の説明は、圧倒的に伝わります。

話し方	聞き手の反応
抽象だけ(「保守性が低い」)	「……で、何をすれば?」
具体だけ(「この行と、この行と……」)	「……で、結局何が問題?」
抽象⇔具体(「保守性が低い。たとえばこの行は〜」)	「なるほど、直します」

パターン④: 詰め込みすぎ〜ワーキングメモリ溢れ〜

症状

「このAPIが遅いのはたぶんN+1が原因で、ただキャッシュが効いてない箇所もあって、
あとそもそもインデックスが張られてないテーブルがあって、それとは別に
フロントのリクエスト回数も多くて、どれから手をつけるかなんですが、
予算的にはインフラ増強という手もあって……」

一つひとつの内容は正しくても、聞き手の処理が追いつきません。

認知心理学では、人間が一度に頭の中に保持できる情報のかたまり(チャンク)はおおよそ4±1個と言われています。それを超えて流し込まれた情報は、右から左へこぼれ落ちます。

処方箋: 個数の宣言 + 1文1メッセージ

「APIが遅い原因は3つあります。
1つ目がN+1クエリ、2つ目がキャッシュ未使用、3つ目がインデックス不足です。
影響が大きい順に、まず1つ目から説明します」

冒頭で「3つあります」と宣言すると、聞き手は頭の中に3つの空き箱を先に用意できます。情報の置き場所が先に確保されるので、こぼれません。

あわせて、「〜で、」「〜なんですけど、」で文をつなげるのをやめて、文を短く切る。これだけでも体感はかなり変わります。

冒頭は話す個数(論点)を宣言し、１文１メッセージで短く切って話す

実践: 4つ全部入りの「質問」Before → After

総仕上げとして、エンジニアの日常で一番頻度が高い「質問」のシーンで見てみます。

Before：状況把握コストを100%相手に押し付ける質問

「すみません、なんかエラーが出て動かないんですけど、どうしたらいいですか?」

①結論(相手にしてほしいこと)が不明
②前提(何をしていたか)の共有なし
③具体性(どんなエラーか)なし

このような場合、聞かれた側は状況を知るため、ゼロから尋問のように状況を聞き出すことになります。

After：仮説の検証だけお願いする質問

パターン	処方箋
「ログイン機能の実装で詰まっていて、15分ほどお時間いただけますか?	①結論(依頼)
JWTの署名検証でエラーが出ています	②前提の共有
エラーメッセージは『invalid signature』です	③具体
確認済みのことが2つあります。	④個数の宣言
署名アルゴリズムの指定ミスを疑っているのですが、他に確認すべき箇所のアタリをいただけないでしょうか」	⑤相手への期待値

回答する側の立場で想像してみてください。どちらに気持ちよく答えたくなるかは明らかですよね。質問力とは、相手の頭の中のセットアップを代行してあげる力なのです。

まとめ: 説明は才能ではなく、技術

パターン	処方箋
① 時系列トーク	結論ファースト(PREP法)。「相手が一番知りたいこと」から話す
② 知識の呪い	話す前に「相手はどこまで知っているか」を確認する
③ 抽象語オンリー	「たとえば」「具体的には」を口癖にする
④ 詰め込みすぎ	最初に個数を宣言し、1文を短く切る

4つの共通は、たった1つ。主語を「自分」から「相手」に切り替えることです。
「自分が何を話すか」ではなく、「相手の頭の中に、いま、どんな絵が描かれているか」。

説明がうまい人は、生まれつき話がうまいわけではありません。話しながら相手の頭の中を想像する、という地味な技術を毎回実行しているだけです。そして技術である以上、練習すれば誰でも上達します。

まずは明日、結論から話す。そこから始めてみませんか?

……ところで、お気づきになったでしょうか。

この記事自体、「冒頭に結論」「パターンは4つと最初に宣言」「抽象論のあとに必ず会話例」という、本文で紹介した技術だけで構成されています。

最後まで読めてしまったのなら、それがこの記事の主張のささやかな証明です。

役に立ったと思っていただけたら、いいね・ストックをいただけると今後の励みになります 🙏