明日から使える「報告ができない」人のためのチャットテンプレート

Transcript

1. 2026.10.05 品川会 明日から使える 「報告ができない」 人のための チャットテンプレート 株式会社エクサウィザーズ 小島啓明
2. 自己紹介 小島 啓明 もともとは画像の機械学習エンジニア クラウド推進組織を立ち上げから組織運営 3年間でインターン生7人ぐらい見てます 2025/2026 Japan All AWS Certifications Engineers 2026 Japan AWS Top Engineers 趣味：北海道が好きです 好きなAWSサービス：AWS Neuron
3. 今日の対象者・対象外 こんな方に向けた話です 学生・新卒を指導していて、 「困ったら言ってね」が機能せず、 つきっきりの状態から抜け出せない 口頭では報告できるが、チャットでの報告が苦手 「自走力」というふわっとした言葉で丸め込まれている 今回は対象外 自力でチャット報告できる人、自走できるエンジニアの育成、 チーム全体の報告フォーマット標準化
4. こういう経験ありませんか？ 朝 指導者「今日やることはこれ」 新人「わかりました」 午後 指導者（あれ、報告がないな…） 指導者「そういえば、どう？」 新人「なんかここが動かなくて。 ☓☓の問題だと思います」 →実は作業の最初で止まっていた その後 「どういう状況で起きたの？」 「エラーやスクショはある？」 チャットで数ターン、結局通話で 解決。 なぜこれがよくないのか 「つきっきりで面倒を見れば解決で きる」が固定化。 マイクロマネジメントの常態化。 長めのタスクを任せきれず、 成果が頭打ちになる。 できる人のマネジメントコストを 払い続け、 組織的にスケールしない。
5. 無意識にできている報告、 誰でもできるわけではない 悪い例 なんかAWSでうまくいかないです。権限が足りないのだと思います。 良い例 ◦◦処理のLambdaを実行すると、次のエラーが出ました。 … is not authorized to perform: s3:GetObject … IAMロールの権限が原因かもしれません。 ※※までは動いていましたが、□□から動かなくなりました。 現在の実行ロールのポリシーはこちらです［設定・スクショを添付］。 何をしたか・実際のエラー・どこまで動いたか・今の設定がそろえば、チャットだけで状況が伝わる。 この力は、メールや（AWSなどの）サポート問い合わせでも絶対に必要。
6. AIで一周回って重要になったもの 技術的な問題（How）は、 AIに聞けばほとんど解決できるようになった。 「エンジニアとしてのOS」は、AIだけでは身につかず、 むしろ重要に 報連相のスキル ロジカルシンキング・ファクトベース思考 クリティカルシンキング・メタ認知
7. AI以前のバグは ロジカルシンキングの優秀な教師だった 仮説検証が自然に身につく 教師としてのよさ ログなどの証拠を整理する 「エラーが消えれば解決」という 考えられる仮説を列挙する 分かりやすいDefinition of Done 確かめる実験を設計する 24時間365日、いつでも取り組める 誰も悪くない。機械相手だけの話 AIでバグ解消はシームレスになったが、 教師としての役割が失われてしまった。 参考：Shen & Tamkin (2026), How AI Impacts Skill Formation 新しい非同期ライブラリを学ぶ実験。学習への影響はAIの使い方によって異なる。
8. 活字離れが原因？ 1か月に読んだ本が0冊 読書量が減った理由 2025年5月の調査 0冊の割合 小学生（4〜6年） 9.6% 中学生 24.2% 43.6% 「情報機器に時間を取られる」 読書量が減ったと答えた人のうち。 文化庁・令和5年度調査、2つまで回答。 高校生 55.7% 読書習慣の変化は背景として考えられるが、それだけでは説明できない。 本を読む量と、チャットで状況を説明する力は別の指標。 出典：全国SLA 第70回学校読書調査 ／ 文化庁 令和5年度「国語に関する世論調査」
9. 「困ったら言ってね」は自由作文 報告できない側の本音 チャットでどう書けばいいのかわからない。 忙しそうで、いつ聞いていいかわからない。 「困ったら言ってね」は、 「◦◦について論じなさい」という自由作文。 自由作文は慣れている人向きのコミュニケーション。 慣れない人にいきなり書かせるのはハードルが高い。
10. 難しいなら、問題を分割してしまう 分割の例 報告なら 数学：いきなり証明でなく誘導問題 自由作文を LLM：大きな依頼をタスク分解する テンプレート埋めに置き換える。 誰もが使うべき標準化仕様ではない。 あくまで、自由作文（報告）が苦手な人の補助用。 自由作文で報告できる人に、無理やり使わせるものではない。 想定利用者：学生（インターン生）〜エントリーレベルの新卒。自走できるエンジニアはスコープ外。
11. 夕方の報告テンプレート 今日やったこと： 今詰まっていること： 事実・ログ（詰まっている場合）： 自分の推測： 明日やること／確認してほしいこと： 各項目1文程度。長文を書かせず、報告の敷居を下げる。 これとは別に、朝は「今日やること」を箇条書きで共有する。
12. 権限問題やエラーで詰まったとき 何をやろうとしたか： 何が起きたか： ログ・証拠： 試したこと： 自分の推測： 何を聞きたいか： 説明は各1文程度。エラー原文やスクリーンショットを添える。
13. 大事なのは型より「事実・推測・確認事項」の分離 事実 Lambdaのテスト実行で AccessDenied が出た。 推測 実行ロールの権限が足りないかもしれない。 確認事項 ロールとポリシーの対応を一緒に確認してほしい。 類似例：医療のSBAR（エスバー） Situation（状況）／Background（背景）／Assessment（評価）／Recommendation（提案） 報告の型が先行しがちだが、重要なのは分けて書く思想。 この分離さえできれば、今日のテンプレートでなくてもよい。 参考：AHRQ TeamSTEPPS: SBAR。エラー表記は説明用の短縮例。
14. 背景と適用効果 導入前 インターン生と1日2回の個別MTG。長期的にはコスト高。 → 1日1回のMTGで自走できる状態を目指す。 最初の1週間 いきなり1日1回にせず、夕方のMTGを 一緒にテンプレートを埋める伴走支援に使う（足場かけ）。 1週間後〜 徐々に自分でテンプレートを埋めて報告できるように。 2〜3週間後 1日1回で十分回るように。マネジメントコストが約半分に。 最終的には、執行役員からのレイヤー高めの技術的な質問にもチャットで回答可能に。 足場かけ（スキャフォールディング）：最初は支え、できるようになったら支援を外す。参考：Wood, Bruner & Ross (1976), The Role of Tutoring in Problem Solving
15. AI時代ならではの副次的効果 活字離れ？ AIのチャットログをひたすら読めば、 大量の活字に接する機会はむしろ多い。 ネット掲示板を大量に読んでいた時代よりはマシでは？ 自走ループへ 事実・推測・確認事項の言語化は、AIと相性がよい。 ここができれば、そのままプロンプトに入れて自走ループ に入れる。 Skill化 この報告自体も、コーディングエージェントの コンテクストから生成できるのでは？ → Skillにできる。
16. AIに能動的に問い合わせるための言語化 以前：バグ退治 今：AIへの問い合わせ 存在自体がブロッカー。 問い合わせれば教えてくれるが、 受動的でもOKだった。 勝手には教えない・解決しない。 向き合ううちに 能動的な言語化が必要。 仮説検証が身についた。 24時間365日、誰にも迷惑をかけずに使える練習相手が、 「バグ退治による仮説検証」から「問い合わせ可能なAI」へシフトした。 AIに能動的に問い合わせるための言語化、 その仕組み化がこのテンプレートの本質。
17. まとめ 自由作文が苦手な人に、 答えられる問いを渡す。 最初は一緒に埋めて、少しずつ支援を減らす。 事実・推測・確認事項を分ける考え方を身につける。 人にもAIにも、自分から相談できる力につなげる。