はじめまして。
株式会社PRUMでエンジニアをしている人見です。
日々、プログラミング学習や実務の中で
つまずきやすいポイントを整理して発信しています。
PRUMについて気になった方は、
コーポレートサイトもご覧ください。
▶ コーポレートサイト
「で、"結局"今どんな状況なの？」と言われたとき、あなたの報告はまだ“報告”になっていない【後編】
――「判断できる報告」とは何か
報告とは「事実の共有」ではなく、「判断材料の提示」である
はじめに
前編では、こんな会話を扱いました。
新人「ログイン機能の実装が終わりました」
リーダー「で、結局いまどんな状況なの？」
新人は「作業の完了」を伝えたつもりなのに、伝わらない。
この噛み合わなさの原因は、報告の上手い下手ではなく、
- 新人とリーダーが「報告」という言葉に期待している役割が違う
- Closed Task（閉じた課題）と Open Task（開いた課題）で、必要な報告が変わる
- 認知構造（スキーマ）・目的（意思決定）・視点（局所/全体）の“3層”でズレが起きる
という「構造の違い」でした。
後編では、その続きとして、
では、リーダーが“判断できる”報告は、どんな情報でできているのか
を分解し、明日から使える形に落とします。
1. 上司は「何のために」報告を聞いているのか
上司は「事実」を集めているのではなく、「判断材料」を集めている
まず前提として、
上司が報告を聞く目的は「事実確認」ではありません。
上司が本当に知りたいのは、次の3つです。
- いま介入すべきか？
- リスクはあるか？
- このまま任せてよいか？
つまり、報告とは
判断材料になる情報を上司に伝えること
なのです。
2. 伝わらない報告は何が足りないのか
不足した情報を補完しようとすると、思考コストが増える
例：
「ログイン機能の実装が終わりました」
この報告には“事実”しかありません。
しかし上司の頭の中では、同時に次の処理が走っています。
- 動作確認は済んでいるのか？
- 例外ケースは？
- 不具合は？
- 次は何をする？
- 予定通りか？
つまり上司は、いきなり判断に入れず、まず
不足情報を集めるための思考・質問
が必要になります。
この“追加処理”が、後述する 認知負荷 の正体です。
3. 認知負荷とは何か
「認知負荷（Cognitive Load Theory）」は、教育心理学者
John Sweller（ジョン・スウェラー）によって提唱された理論です。
人のワーキングメモリには処理できる情報量に限界があり、
- 不足した情報を推測する負荷
- 不要な情報を選別する負荷
が増えると、理解や判断の質が低下するとされています。
人のワーキングメモリは同時に多くの情報を処理できません。
情報が整理されていないと、
- 推測
- 補完
- 再質問
といった追加処理が発生します。
これが認知負荷を増やします。
整理された報告は、
- 推測を不要にし
- 補完を不要にし
- 再質問を不要にする
ことで、判断までの距離を短くします。
4. では、どう構造化すればよいのか
構造化された情報は、判断までの距離を短縮する
判断に必要な材料は次の4つです。
① 現在位置（どこまで進んでいるか）
② 確認済みの範囲（どこまで検証したか）
③ 問題・リスクの有無
④ 次の一手（どう進めるつもりか）
この4つが揃うと、上司は
- 介入するか
- 任せるか
- 方針を修正するか
を即座に判断できます。
5. 悪い共有の例（上司が判断できない）
ログイン機能は一応できました。
でもまだちょっと怪しいところがあって、
さっきエラーも出たんですが直るかもしれません。
仕様もたぶん合っていると思います。
この報告は、一見「情報量」は増えています。
しかし上司が欲しいのは、情報量ではなく判断材料です。
上司の頭の中ではこうなります。
- 何が確定情報？（「一応」「たぶん」が多い）
- どこまで確認できてる？
- いま一番のリスクはどれ？
- 次にどうする？いつまで？
上司の返答例（＝不足情報の回収）
「“一応”っていうのは、どこまで確認できた？」
「エラーは再現する？再現条件は？」
「次に何をどこまでやる予定？」
つまり、判断に入る前に情報収集フェーズが発生しています。
6. 改善例（上司がすぐ判断できる）
ログイン機能の実装は完了しました。
正常ログインは確認済みです。
パスワード誤入力時のエラー表示に不具合があり、現在修正中です。
本日中に修正予定ですが、仕様認識に不安があるため方向性だけ確認させてください。
この報告では、
- 現在位置
- 確認済み範囲
- 問題・リスク
- 次の一手
が揃っていて、上司はすぐ判断に入れます。
上司の頭の中：
- OK、正常系は確認済み
- リスクはエラー表示（対象が明確）
- 今日中に対応予定
- いま必要なのは「方向性の確認」だけ
上司の返答例：
「方向性はそれでOK。今日中に進めてください。」
ここでは追加の情報収集がほぼ不要なので、思考負荷（認知負荷）が下がります。
7. 情報は多ければよいわけではない
ここで重要なのは、
情報を増やせば伝わるわけではない
という点です。
報告が伝わらないからといって、
- 作業ログをすべて説明する
- 思考過程を最初から最後まで話す
など“情報の過剰投入”をすると、今度は
重要な判断材料が埋もれる
という問題が起きます。
人のワーキングメモリには限界があるため、
- 何が重要かを選別する負荷
- どこがリスクかを探す負荷
が増大します。
つまり、少なすぎても多すぎてもダメ。
重要なのは、
相手の判断に必要な情報だけを、構造化して渡すこと
です。
8. 結論
報告とは、完了通知ではありません。
判断可能な状態をつくる行為
です。
評価される報告とは、
- 正確な状況共有に加え
- 次の一手を提示し
- 相手の思考を前に進める
報告です。
前編で扱った構造のズレは、
能力ではなく“何を出せばよいか知らない”ことから生まれます。
その答えはシンプルです。
相手が判断するために必要な材料を、先回りして出すこと。
これが、伝わる報告の構造です。
PRUMのエンジニアの95%以上は、未経験からの採用です。
よければ、コーポレートサイトもご覧ください。