技術説明が長くなる理由
「技術説明が長い」と言われるとき、多くの場合は説明の量が問題ではなく、聞き手が求めている情報と話している情報がずれている。
エンジニアが説明しようとするのは「どうなっているか」の詳細だが、上司やPMが知りたいのは「それで何をどう判断すればよいか」だ。このズレが、説明が長くなる構造的な原因になっている。
相手が知りたいのは判断材料
会議室での技術説明も、チャットでの課題共有も、聞き手は自分の仕事の判断に使える材料が欲しくて聞いている。
「なぜそのバグが起きているのか」を完全に理解したいわけではない。「このバグを今日中に直せるか、スケジュールを変える必要があるか」を知りたい。
ここを捉えて説明を組み立てると、自然に短くなる。
要約の型：4つで組み立てる
結論（1文で）
何が起きているか、または何を伝えたいかを最初に言う。「今日中のリリースが難しくなりました」「Aの機能でエラーが出ています」。
接続詞や経緯から入ると、最初の数十秒で聞き手は「で、何が言いたいの？」という状態になる。
影響（何に波及するか）
技術的な事象が、業務・スケジュール・顧客対応のどこに影響するかを言う。「このままだと本番DBに影響します」ではなく「注文処理が止まる可能性があります」。
聞き手の知っている言葉で影響を言う。
選択肢（何ができるか）
「できません」ではなく「AかBかCができます」。選択肢が一つしかなくても「この対応方法があります」の形で提示する。
補足（聞かれたら答える）
詳細な原因、実装の背景、調査過程は、聞かれたときに話す。最初から出す必要はない。
悪い説明と良い説明の比較
悪い例：
昨日のリリースでAモジュールに変更が入りまして、そのときにBテーブルへのクエリが変わったんですが、インデックスの設定が古いままで、スロークエリが発生するようになっていて、ログを確認したらN+1も出ていて、だいたい1件あたり3秒くらいかかっています。対応を考えているところです。
良い例：
注文確認画面の表示に3秒以上かかっています（昨日のリリース後から）。今のまま続くとユーザーの離脱が増える可能性があります。インデックス修正で本日中に直せます。作業優先度の変更について判断をお願いします。
伝えている内容は同じだが、後者は聞いた側がすぐ動ける。
日常でできる要約練習
次の課題報告や進捗共有の前に、1分だけ「結論・影響・選択肢」を書き出してから話す。
最初は少し止まるが、続けると話す前に自然に整理できるようになる。会話の場だけでなく、メールやチャットでも同じ構成で書くと、返信が返ってくる速度が変わる。