「で、結論は？」と言わせない。新人エンジニアが身につけるべき「伝わる」思考法

✅ 📋 1分で読めるこの記事の概要

エンジニアとして働き始めたばかりの頃、先輩への報告や相談で「話が長い」「結局どうしたいの？」と言われてしまった経験はありませんか？一生懸命に状況を伝えようとするほど、起きた出来事を時系列で話してしまい、肝心の「結論」が埋もれてしまいがちです。私自身、今でも「事実」と「感想」が混ざってしまうことがあり、日々反省の連続です。この記事では、伝え方の基本フレームワーク「PREP法」を軸に、情報のプロであるエンジニアが意識すべき「最短距離で意図を伝える」ための思考法を共有します。

✅ なぜ一生懸命話すほど、伝わらなくなるのか

障害が起きたときや、実装で行き詰まったとき。私たちはつい、自分が辿ったプロセスをそのまま話してしまいます。「まずここを直して、次にこのコマンドを叩いたら、こんなエラーが出て……」これは「作業ログ」であって「報告」ではありません。聞き手である先輩は、「今、助けが必要なのか」「作業は継続できているのか」という結論をまず知りたがっています。背景を丁寧に説明しようとするあまり、肝心の結論が最後になってしまう。これが「で、結論は？」を生んでしまう正体です。

✅ 最強の型「PREP法」をエンジニアの日常に落とし込む

このズレを解消するために、私が改めて意識しているのが「PREP法」です。

• P（Point）：結論（まず、今の状態を一言で）
• R（Reason）：理由（なぜそうなったのか）
• E（Example）：具体例（起きた事実、エラーログ、ソースコード）
• P（Point）：結論（だから、次はこうします／こうしてほしいです）

例えば「APIの疎通確認が取れません（P）」から始めれば、相手は「ネットワークか、認証の問題だな」と予測を立てた状態で話を聞くことができます。

✅ 「事実」と「感想」を分ける――トラブル時こそ冷静に

私がよく陥ってしまう失敗に、「事実」と「感想」が混ざってしまうことがあります。「サーバーの反応が遅い気がします（感想）」ではなく、「レスポンスタイムが普段の3倍の600msになっています（事実）」と伝える。感情や主観を乗せて話すと、相手は「それは君の思い込みじゃないか？」と確認の手間を増やしてしまいます。まずは客観的な「事実」を淡々と。その上で「なので、私は〇〇ではないかと推測しています」と意見を添える。この切り分けが、あなたの信頼性を高める近道です。

✅ 上司や先輩の時間を奪わない3つのテクニック

1. チャットでは「箇条書き」を徹底する … 文章をダラダラ書かず、PREPの要素を箇条書きにするだけで、視認性は劇的に向上します。
2. 「なるべく早く」を「数字」に変える … 「急ぎです」ではなく「14時からの打ち合わせで使いたいので、13時半までに確認してほしいです」と期限を明確にします。
3. 冒頭で「相談・報告・連絡」のどれかを宣言する … 「相談です」と言われれば、相手はアドバイスをするモードで聞いてくれます。

✅ 📌 まとめ：伝える技術は、技術スキルと同じくらい裏切らない

「伝える」という行為は、センスではなく技術です。結論から話し、事実と感情を分ける。これができるようになると、チームのスピード感は劇的に変わりますし、何よりあなた自身が仕事をしやすくなります。私自身、まだまだ自己反省の毎日ですが、この「型」を意識し続けることで、よりスムーズなチーム開発を目指していきたいと考えています。