報告の基本フレームワーク

ストーリー

「今日のスタンドアップでの報告、ちょっと長かったな」

渡辺マネージャーが穏やかに指摘した。

「えっ、詳しく説明した方がいいかと思って......」

「報告で大切なのは『詳しさ』じゃない。 相手が知りたいことを、短い時間で伝えることだ。 エンジニアは技術的な詳細に入りがちだが、 マネージャーが聞きたいのは『進んでいるか、問題はあるか』だ。 報告のフレームワークを覚えよう」

結論ファーストの原則

報告の最も重要な原則は「結論を先に言う」ことです。

悪い例と良い例

悪い例（経緯ファースト）:
  「昨日からログイン機能のバグを調査していて、
   最初はフロントエンドのCookie処理を疑ったんですが違って、
   次にAPIのセッション管理を調べたら、
   Redis のTTL設定に問題があることがわかりました。
   修正自体は30分で終わりそうです」

  → 聞き手は最後まで聞かないと結論がわからない
  → マネージャーの心の声: 「で、結局どうなの？」

良い例（結論ファースト）:
  「ログインバグの原因が特定できました。
   Redis のTTL設定の問題で、今日中に修正完了の見込みです。
   詳細を説明しましょうか？」

  → 3秒で状況がわかる
  → 相手が詳細を聞きたければ聞ける

PREP法

報告や説明の基本フレームワークです。

PREPの構造

PREP法の適用例

進捗報告

P: ユーザー検索機能の実装は80%完了です。
R: バックエンドAPIは完成し、フロントエンドの検索結果表示が残っています。
E: 全文検索、フィルタリング、ページネーションのAPIは全てテスト済みです。
P: 明日中にフロントエンドを完了させ、水曜にPRを出す予定です。

問題報告

P: デプロイが2時間遅延する見込みです。
R: ステージング環境のテストで、決済処理のタイムアウトが発生しています。
E: 外部決済APIの応答が通常の3倍遅く、タイムアウト閾値を超えています。
P: 閾値の調整で対応し、14時にはデプロイ完了の見込みです。

技術提案

P: DBのコネクションプールの設定変更を提案します。
R: 現在のピーク時にコネクション枯渇が発生しているためです。
E: 先週の障害ログで、同時接続数がmaxの100を超えた記録が3回あります。
P: maxを200に増やすことで対応したいのですが、承認いただけますか？

報告の3つの型

状況に応じて使い分ける3つの報告パターンです。

1. 状況報告（Status Update）

テンプレート:
  「[タスク名]の進捗報告です。
   現在の状況: [完了率/ステータス]
   今日やったこと: [具体的な成果]
   明日の予定: [次のアクション]
   問題・リスク: [あれば記載]」

例:
  「プロフィール編集機能の進捗です。
   現在60%完了。
   今日はバックエンドAPIの実装を完了しました。
   明日はフロントエンドUIに着手します。
   問題はありません」

2. 問題報告（Issue Report）

テンプレート:
  「[問題の概要] が発生しています。
   影響: [誰が/何が影響を受けるか]
   原因: [わかっている範囲で]
   対応案: [A案/B案]
   必要な判断: [誰に何を決めてほしいか]」

例:
  「ステージング環境でメモリリークが発生しています。
   影響: 明日のリリースが遅延する可能性があります。
   原因: 画像アップロード処理でストリームが閉じられていない模様です。
   対応案: A)修正してからリリース（+1日） B)該当機能を除外してリリース
   判断をお願いしたいです」

3. 完了報告（Completion Report）

テンプレート:
  「[タスク名]が完了しました。
   成果物: [PR番号、ドキュメント等]
   テスト結果: [テスト状況]
   次のアクション: [レビュー待ち、デプロイ待ち等]」

例:
  「CSVエクスポート機能が完了しました。
   PR #234 を作成済みです。
   テスト: ユニットテスト12件パス、動作確認済み。
   田中さんのレビューをお待ちしています」

報告のタイミング

いつ報告すべきか

報告が遅れるとどうなるか

月曜: バグ発見。「すぐ直せそう」→ 報告しない
火曜: 想定より複雑。「もう少し......」→ まだ報告しない
水曜: 全然終わらない。「報告しづらい」→ さらに報告しない
木曜: マネージャーが気づく。「なぜ月曜に言わなかったんだ」
金曜: 緊急対応でチーム全体が巻き込まれる

→ 月曜に「想定より複雑かもしれません」と報告していれば
  火曜に応援を呼んで水曜に完了していた

報告のルール: 「悪いニュースほど早く」

問題が小さいうちに報告すれば、対応策も多い。問題が大きくなってから報告すると、選択肢が限られます。

相手に合わせた報告レベル

報告先別の情報量

エレベーターピッチ（30秒報告）

どんな報告も30秒で伝えられるように準備しておきます。

「[プロジェクト名]は[予定通り/遅延気味]です。
 今週の成果は[具体的な成果]で、
 課題は[主な課題]です。
 [判断が必要/順調に進行中]です」

例:
「検索機能リニューアルは予定通りです。
 今週はバックエンドAPIが完成しました。
 来週のフロントエンド実装で完了見込みです。
 特に判断が必要な事項はありません」

まとめ

チェックリスト

• 結論ファーストで報告する習慣を理解した
• PREP法の4要素を使って報告を構成できる
• 3つの報告型を使い分けられる
• 報告のタイミングの判断基準を持っている

次のステップへ

次のセクションでは、毎日の報告の場である「デイリースタンドアップ」の効果的な進め方を学びます。短い時間で最大限の情報共有をするテクニックを身につけましょう。

推定読了時間: 30分