はじめまして。
株式会社PRUMでエンジニアをしている人見です。
日々、プログラミング学習や実務の中で
つまずきやすいポイントを整理して発信しています。
PRUMについて気になった方は、
コーポレートサイトもご覧ください。
▶ コーポレートサイト
「で、"結局"今どんな状況なの？」と言われたとき、あなたの報告はまだ“報告”になっていない【前編】
―― 新人エンジニアの報告が噛み合わない本当の理由
はじめに
「で、結局今どんな状況なの？」
そう聞かれて、言葉に詰まった経験はないでしょうか？
新人エンジニアとして現場に入ったとき、
多くの人が一度は経験するやり取りです。
新人 >> 「ログイン機能の実装が終わりました」
リーダー >> 「で、"結局"今どんな状況なの？」
「終わった」と報告したのに、伝わっていない。
このとき、多くの新人はこう感じます。
「ちゃんと報告したのに、なぜ伝わらないのか」
しかし、ここで本当に起きているのは
「報告が下手」という問題ではありません。
もっと根本的な問題があります。
それは、
新人とリーダーが、「報告」という言葉に対して、
まったく異なる役割を期待している
ということです。
新人は「作業の完了」を伝えたつもりであり、
リーダーは「プロジェクトの状態」を知ろうとしています。
つまり、
同じ「報告」という言葉を使いながら、
見ている対象が異なっているのです。
このズレは偶然ではなく、
報告という行為の「目的」の違いから生まれています。
まず、「報告の本当の目的」から説明します。
報告の本当の目的
報告の目的は、報告することではありません。
報告の目的は、
相手が判断できる状態を作ること
です。
リーダーは報告をもとに、次のことを判断します。
・このまま任せてよいか
・問題が発生しているか
・優先順位を変える必要があるか
・スケジュールに影響があるか
つまり、報告とは
意思決定のための情報共有
です。
注1：Situation Awareness（Endsley, 1995）
認知心理学者 Mica Endsley は、意思決定の質は
「Situation Awareness（状況認識）」に依存すると定義しました。
Situation Awareness は次の3段階で構成されます：
・Perception（知覚）：何が起きているかを知る
・Comprehension（理解）：それが何を意味するか理解する
・Projection（予測）：今後どうなるかを予測する
意思決定は、この3段階の情報処理に基づいて行われます。
報告は、この Situation Awareness を形成するための
最も重要な入力なのです。
なぜ「完了報告」では足りないのか
ここで、最初の報告をもう一度見てみます。
「ログイン機能の実装が終わりました」
この報告からは、次のことが分かりません。
・問題は発生していないのか
・動作確認は完了しているのか
・予定通り進んでいるのか
・今後の作業に影響はないのか
つまり、
意思決定に必要な情報が不足しています。
そのため、リーダーはこう聞き返します。
「で、結局今どんな状況なの？」
これは単なる確認ではなく、
意思決定に必要な情報を取得するための質問
なのです。
なぜ新人は「完了報告」をしてしまうのか
これは新人の能力の問題ではありません。
人間は、「スキーマ」と呼ばれる認知構造を使って行動します。
スキーマとは、
過去の経験から形成される「行動パターン」
です。
例えば、レストランに入ったとき、私たちは自然に
・席に座り
・メニューを見て
・注文する
という行動を取ります。
これは、その場で毎回考えているのではなく、
過去の経験から形成されたスキーマを適用しているためです。
注2：スキーマ理論（Bartlett, 1932）
心理学者 Frederic Bartlett は、人間の記憶と行動は
「スキーマ」と呼ばれる認知構造に基づいていると提唱しました。
人は新しい状況に直面したとき、
既存のスキーマを適用して行動します。
これは認知負荷を減らし、迅速な行動を可能にするための
合理的な仕組みです。
問題は、「環境が変わっている」こと
新人はこれまで、
・学校
・アルバイト
・課題
といった環境で、
報告 ＝ 完了 を伝えるもの
というスキーマを形成してきました。
なぜなら、これらの環境では、
完了を伝えれば十分だった
からです。
しかし、エンジニアの環境ではそうはいきません。
この違いは、「課題の性質」の違いから生まれます。
課題の性質が異なれば、
必要とされる報告の内容も変わります。
課題には2種類ある
認知科学では、問題は次の2種類に分類されます。
Closed Task（閉じた課題）
例：
・皿洗い
・宿題
・決められた作業
特徴：
・目標が明確
・解決方法が決まっている
という特徴があります。
重要なのは、
完了したかどうか
です。
そのため、
「終わりました」
という報告で十分です。
Open Task（開いた課題）
ソフトウェア開発は Open Task です。
特徴：
・解決方法が複数存在する
・途中で問題が発生する
・状況が変化する
このような課題では、
完了だけでは、状況を説明できません。
注3：Ill-defined problem（Simon, 1973 / Jonassen, 1997）
認知科学者 Herbert Simon は、現実世界の問題を
「Ill-defined problem」と分類しました。
Jonassen は、ソフトウェア開発のような問題は
Ill-defined problem の典型例であると指摘しています。
これらの問題では、
解決方法も、目標も、途中で変化します。
報告が噛み合わない本当の原因：3層構造
ここまでで分かるのは、
新人とリーダーは、
異なる認知構造・異なる目的・異なる視点
を持っているということです。
この違いは、次の3層構造として現れます。
第1層：認知構造の違い（スキーマ）
- 新人：完了を報告するスキーマ
- リーダー：状況を把握するスキーマ
第2層：目的の違い（意思決定）
- 新人：作業完了を伝える
- リーダー：意思決定のために状況を知る
第3層：視点の違い（局所 vs 全体）
- 新人：自分のタスクを見る
- リーダー：プロジェクト全体を見る
ログイン機能の小さな遅延も、
→ 認証機能のテスト遅延
→ 統合テストの遅延
→ リリース遅延
という連鎖を引き起こします。
リーダーにとって重要なのは
完了したかどうか
ではなく
現在どの状態にあるか
なのです。
「報告」とは何か
エンジニアにとって報告とは
完了を伝える行為ではありません。
報告とは
意思決定を可能にするための状況共有
です。
例：
ログイン機能の実装は完了しました。
動作確認も終わっています。
ただ、エラー処理に1件問題があり現在修正中です。
本日中に完了見込みです。
この報告により、リーダーは判断できます。
これが、本当の報告です。
補足 2025/2/20記載
「ログイン機能の実装は完了しました。」との報告は
現場によっては勘違いされてしまう恐れがあります。
開発の現場では、
・基本機能の実装は完了している
・他機能から利用可能な状態である
・しかし一部の例外処理に修正が必要
といった、「完了している部分」と「未完了の部分」が
混在する状態がよくあります。
基本実装や疎通が完了し、他の作業に進める状態であれば「実装完了」と表現する場合もありますし、
一部に修正が残っている以上「まだ作業中」と捉える場合もあります。
重要なのは、「完了」か「作業中」かという言葉そのものではなく、
・どこまで終わっているのか
・何が利用可能なのか
・何が未対応なのか
といった状況を正確に伝えることです。
前編まとめ
報告が噛み合わない原因は、能力ではありません。
原因は、
・認知構造の違い
・目的の違い
・視点の違い
という構造的な問題です。
そして、報告の本質は
意思決定のための状況共有
です。
後編予告
後編では、
・新人でもすぐ使える報告テンプレ
・評価される報告の共通点
・なぜその報告は伝わるのか
を解説します。
PRUMのエンジニアの95%以上は、未経験からの採用です。
よければ、コーポレートサイトもご覧ください。