PMに評価される報告は、詳しい説明ではない
「ちゃんと説明しているのに伝わらない」という経験があるとすれば、問題は説明の量ではなく、構造にある。
PMが報告に求めているのは、意思決定できる材料だ。何が起きて、何に影響して、どんな選択肢があって、何を決めてほしいのか。技術的な背景や実装の詳細は、それを聞かれてから話せばいい。
報告の前に整理する4つの項目
1. 結論（何が起きているか）
最初に状態を一言で言う。「現在、Aモジュールでエラーが増加しています」「本日中のリリースは難しい見込みです」。
ここで技術的な原因説明に入るのは待つ。PMは先に「何が起きているか」を知ってから、背景を聞くかどうか判断する。
2. 事実（確認できている情報）
確認済みのことだけを話す。ログ、件数、再現条件など、現時点で確かめられた情報に絞る。推測が混じるなら「未確認ですが」と明示する。
事実と推測が混ざった報告は、PMの判断ではなく確認作業を増やす。
3. 影響（何がどう動かなくなるか）
エンジニアが見落としがちなのがここだ。「DBのクエリが遅い」ではなく、「注文確認画面の表示が5秒以上かかるため、顧客体験とコンバージョン率に影響します」。
PMが気にするのは技術的な事象ではなく、それが何にどう波及するかだ。
4. 選択肢と相談事項（何を決めてほしいか）
「対応策AとBがあります。Aは本日中に対応可能ですが、Bは3日かかります。どちらを優先するか判断をお願いしたい」という形で渡す。
選択肢を整理せず「どうしましょうか」と聞くのは、判断材料を渡さないまま丸投げしている状態だ。
悪い報告と良い報告を比べる
悪い例：
DBのスロークエリが発生しています。インデックスが張られていないテーブルへの結合が原因で、クエリの実行計画を確認したところN+1が起きていました。対応策を検討中です。
良い例：
注文確認画面でページ表示が5秒以上かかっている状態です（昨日から）。原因はDBのスロークエリで、ユーザー体験と問い合わせ増加に影響します。インデックス追加で今日中に改善できます。チケット変更の優先度上げについて承認をお願いしたい。
同じ事象を報告しているが、後者はPMが次の行動を取れる。
この構成が身に付くと変わること
この4項目で報告できるようになると、PMから「あの件はどうなってる？」と聞かれる前に動けるようになる。それが「頼りになるエンジニア」の実態の多くを占めている。
技術的な問題解決能力と、組織の中で動ける報告力は別のスキルだ。後者は練習すれば身に付く。