【エンジニア転職応援】エンジニア技術コミュニケーション_受講生用

Udemy講座｜受講生用資料 60分・実務経験者向け エンジニアのための 伝わる技術コミュニケーション 結論・理由・締めの型で、報告・説明・レビューが変わる 認知科学の知見に基づく「型」を、 60分で身につける うさうさ研修工房

Section 1｜導入 この60分で身につくこと 1 2 3 4 型で組み立てる 理由を説明できる 30〜45秒で話せる 曖昧さを整理できる 結論→理由→締めで、報告・説明・ レビューコメントを組み立てられる なぜ型が伝わるのかを、認知科学 の根拠つきで人に説明できる 障害報告・進捗報告・非エンジニア への説明を端的に話せる 事実と見立てを分け、曖昧語を置き 換えて伝えられる 対象：実務経験2〜5年のエンジニア／リーダー候補／非エンジニアへ説明する機会の多い SE・PG エンジニアのための伝わる技術コミュニケーション 前提：報告やレビューの経験（なくても可） 02

Section 1｜導入 60分の進み方｜知識 → 実践 → テスト 導入 3分 知識編（インプット） 25分 確認 3分 実践ワーク 20分 修了テスト 7分 まとめ 2分 楽しい 楽しい → 理解 小さな達成 ちょっと苦しい 苦しい→達成感 達成感 気持ちの流れ 前半は「聞く」だけ 新しい概念は前半に集約。実践は混ぜない（負荷を分けるため） 後半は「思い出して使う」 答えを見る前に自分で考える。思い出す作業そのものが定着を助ける ヒントは3段階 詰まったらH1→H2→H3の順に。いきなり答えを見ない エンジニアのための伝わる技術コミュニケーション 03

Lecture 1｜知識編 Murdock (1962) なぜ「結論から」話すと伝わるのか 何が起きているか リストを聞いて思い出す課題では、最初の方の項目ほど思い出されやすい（初 頭効果）。最後の項目も残りやすい（親近効果）が、報告では最後まで集中して 聞いてもらえるとは限らない。 エンジニアの場面では 障害報告・進捗報告は、経緯を時系列で話しがち。結論（いま何が起きていて、 どうなっているか）を最初の一文に置く。 ※系列位置効果の一般的傾向を示すイメージ図（原論文の実測値の再現ではない） ここまでのポイント：結論は最初の一文 エンジニアのための伝わる技術コミュニケーション 04

Lecture 2｜知識編 Sweller (1988)／Cowan (2001) 聞き手の頭に載せられる量には限りがある 何が起きているか 全部話す（情報が散らばっている） 経緯 ログ 設定値 作業記憶の処理容量には限りがあり（Sweller, 1988）、一度に保持できるまとまり（チャン ク）は平均4つ前後とされる（Cowan, 2001）。話の構造を追うこと自体に容量を使わせる と、内容の理解に回せなくなる。 試した手順 影響範囲 原因候補 時刻 担当者 今後の案 エンジニアの場面では ▼ 3つのまとまりに絞る 結論 知っていることを全部話したくなるが、聞き手に必要なのは判断材料。話す内容を「結論・ 理由・締め」の3つに絞り、残りは質問されたときに出す。 理由 締め ※概念図。Cowan (2001)の知見に基づく一般化であり、厳密な再現図ではない ここまでのポイント：話す内容は 3つのまとまりに絞る エンジニアのための伝わる技術コミュニケーション 05

Lecture 3｜知識編 型：結論 → 理由をつなぐ → 締め ① ② ③ 結論 理由をつなぐ 締め Point Reason Close いま何が起きていて、どうなっているか／提案は 何か 「決済APIで障害が発生し、現在は復旧済みです」 ▶ 根拠は一つに絞る。原因・背景のうち最も重要 なもの 「原因は環境変数の設定ミスです」 ▶ 再発防止・依頼・次の報告時刻で終える 「再発防止のチェックリストを追加し、詳細は本日 中に共有します」 ここまでのポイント：結論 → 理由は一つ → 締めで次の行動 エンジニアのための伝わる技術コミュニケーション 06

Lecture 3｜知識編 場面別・型フレーズ（エンジニア版） 場面 結論 理由をつなぐ 締め 障害報告 〇〇で障害が発生し、現在△△です。 原因は〜です。影響は〜のみです。 再発防止として〜します。次の報告は〇時です。 進捗報告 進捗は〇%、〇日遅延しています。 要因は〜です。 〇〇までに挽回します。 非エンジニアへの説明 結論は〜です。／〜を提案します。 例えると〜という状態です。 ご判断いただきたいのは〜です。 レビュー指摘 〜の可能性があります。 〜のケースで〜となるためです。 〜案はいかがでしょうか。 仕様確認 確認させてください。〇〇はAですか、Bですか。 〜と理解していますが、〜のためです。 〇〇までにご回答いただけますか。 〇〇・△△・〜の部分に、自分の現場の言葉を入れて使う。 エンジニアのための伝わる技術コミュニケーション 07

Lecture 4｜知識編 Lorch (1989) 構造を先に見せる／曖昧語を整える 構造を示す一言（シグナル） 曖昧語の置き換え 「結論から言うと」 一応／とりあえず 削除する（必要なら理由を添える） 色々／結構 数・固有名詞に置き換える たぶん 「現時点の見立てでは」＋確認予定 〜と思います 事実は「〜です」、見立ては「見立てでは〜」 「理由は2点あります」 「確認したいのは1点です」 「次に、対応方針です」 見出し・要約・予告のような「構造の合図」がある文章は、理解と記憶が良くなる傾向が 複数の研究で示されている（ Lorch, 1989のレビュー）。話し言葉でも同様に、先に構造を 予告しておく。 ここまでのポイント：構造を予告し、事実と見立てを分ける エンジニアのための伝わる技術コミュニケーション 08

Section 3｜中間チェック ここまでの確認（一問一答） Q1 初頭効果をふまえると、報告で最も記憶に残りやすいのはどれ？ A. 最初の一文に置いた結論 B. 途中で話した経緯 C. 最後に付け足した補足 Q2 聞き手の負荷を下げるために有効なのはどれ？ A. 知っていることを時系列で全部話す B. 決まった順序（結論→理由→締め）で話す C. 専門用語を多めに使う 答え： Q1＝A Q2＝B（動画を止めて考えてから進む） エンジニアのための伝わる技術コミュニケーション 09

Section 4｜実践ワーク ワークの進め方｜ Q → H1 → H2 → H3 → A Q H1 H2 H3 A 問題を読む ヒント 1 ヒント 2 ヒント 3 答え合わせ 状況を読み、 3文で書く（話す） 結論の作り方 理由の絞り方 締めの作り方 自分の答えと比べる 動画を一時停止して、まず自分で書く。詰まった時だけ、ヒントを順番に見る。想定時間：Q1＝7分／Q2＝7分／Q3＝6分 エンジニアのための伝わる技術コミュニケーション 10

Section 4｜実践ワーク Q1 障害報告（上長へ） 状況 課題 本番の決済APIで15:20からエラーが発生 上長に、30〜45秒で口頭報告する内容を、結論 →理由→締めの3 文で書いてください。時系列では話さない。 原因：デプロイ時の環境変数の設定ミス 15:45にロールバックして復旧済み 影響：15:20〜15:45の新規決済のみ 対応：デプロイ前チェックリストを追加予定 H1 H2 H3 最初の一文は「何が起きて、いまどうなっているか」。 状況と現在のステータスを一文に。 理由（原因）は一つだけ。影響範囲は一言で添える。 締めは再発防止と、次の報告のタイミング。 エンジニアのための伝わる技術コミュニケーション 11

Section 4｜実践ワーク Q2 非エンジニアへの技術説明 状況 課題 一覧画面の表示に平均5秒かかっている 営業部門長に、承認をもらうための説明を、専門用語を使わずに 原因：画面を開くたびに全データをDBへ問い合わせている 結論→理由→締めの3文で書いてください。 改善案：よく使う結果を一時保存する（キャッシュ） 効果：待ち時間を大きく短縮できる見込み／工数は3日 相手：専門用語を知らない営業部門長 H1 H2 H3 結論は「提案＋効果」から。技術の仕組みは後回し。 理由は例え話を一つだけ使う（例：毎回倉庫まで取り に行っている）。 締めは、ご判断いただきたいこと（承認）と工数・着手 時期。 エンジニアのための伝わる技術コミュニケーション 12

Section 4｜実践ワーク Q3 コードレビューの指摘 状況 課題 先輩のプルリクエストをレビュー中 レビューコメントとして、懸念 →理由→提案の3文で書いてください。 「〜かもしれないですが …」のような逃げを使わない。 関数に null が渡されると例外で落ちる 注文が空のケースで呼ばれる箇所が2か所ある 修正案：関数の冒頭でnull チェックを入れる 相手：経験の長い先輩（失礼なく、でも曖昧にしない） H1 H2 H3 結論は懸念の内容を言い切る（「〜の可能性がありま す」）。 理由は具体的なケース一つ。件数など数字を入れ る。 締めは修正案を示し、相手に返す（「〜はいかがで しょうか」）。 エンジニアのための伝わる技術コミュニケーション 13

Section 4｜実践ワーク 解答例（自分の答えと比べる） Q1 障害報告 15時20分から決済 APIで障害が発生していましたが、 15時45分にロールバックして復旧済みです。原因はデプロイ時の環境変数の設定ミスで、影 響は15時20分〜45分の新規決済のみです。再発防止としてデプロイ前チェックリストを追加し、詳細は本日中に共有します。 Q2 技術説明 一覧画面の表示を、いまの 5秒から大きく短縮する改善を提案します。いまは画面を開くたびに、倉庫まで全部取りに行っているような状態で、よ く使う分を手元に置けば待ち時間が減ります。作業は 3日ですので、ご承認いただければ今週中に着手します。 Q3 レビュー ここは null が渡されると例外で落ちる可能性があります。注文が空のケースで呼ばれる箇所が 2か所あるためです。関数の冒頭で null チェックを 入れる案はいかがでしょうか。 文言は違ってよい。見るのは「結論が先頭か／理由が一つか／締めがあるか」の 3点。 エンジニアのための伝わる技術コミュニケーション 14

Section 5｜修了テスト 問1・問2（想起テスト／ 7分・合格 70点） 問1 並べ替え（ 30点） 問2 穴埋め（ 30点・各 10点） 次の3文を「結論→理由→締め」の順に並べ替えなさい。 話す順番は（ ① ）→（ ② ）→締め。人は（ ③ ）に聞いた情報ほど 記憶に残りやすい（初頭効果）ため、①を最初に置く。 ア ご確認のうえ、承認をお願いします。 イ 現行の方式だと、検索に毎回5秒かかっているためです。 ウ 検索処理の改善を提案します。 ※見返さずに、思い出して書く。 エンジニアのための伝わる技術コミュニケーション 15

Section 5｜修了テスト 問3 実技（40点）｜自分の現場の 1件を型で話す 課題 最近の仕事の出来事を一つ選び（報告・提案・相談のどれでも可）、結論 →理由 採点基準（ 40点満点） 結論が冒頭の一文にある 15点 理由が一つに絞られている 10点 締め（依頼・次の行動）で終えている 10点 30〜45秒に収まっている 5点 →締めの3文で、30〜45秒で声に出して話す。 録音して聞き返し、右の基準で自己採点する。 合格ライン：問 1〜問3の合計 70点以上 エンジニアのための伝わる技術コミュニケーション 16

Section 5｜修了テスト 答え合わせと復習マップ 問1 正解（30点） 問2 正解（各10点） ウ→イ→ア ① 結論 ② 理由 ③ 最初 （結論：改善提案／理由：現状の遅さ／締め：承認依頼） つまずいた所に戻る（復習マップ） 問1で失点 ▶ Lecture 3（型） 問2で失点 ▶ Lecture 1（初頭効果）・Lecture 3 問3で失点 ▶ Lecture 2（絞る）・Lecture 4（構造と曖昧語） エンジニアのための伝わる技術コミュニケーション 17

まとめ・次の一歩 ✓ 結論は最初の一文（初頭効果） ✓ 話す内容は3つのまとまりに絞る（認知負荷・チャンク） ✓ 型は 結論 → 理由は一つ → 締め ✓ 構造を予告し、事実と見立てを分ける 明日からの一歩 明日の報告・チャットを、最初の一文だけ「結論」から書く 週に1回、自分の報告を録音して聞き返す レビューコメントの逃げ言葉（かもしれない）を一つ減らす エンジニアのための伝わる技術コミュニケーション 18

References 参考文献 Murdock, B. B. (1962). The serial position effect of free recall. 1 Journal of Experimental Psychology, 64(5), 482–488. https://doi.org/10.1037/h0045106 Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. 2 Cognitive Science, 12(2), 257–285. https://doi.org/10.1207/s15516709cog1202_4 Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. 3 Behavioral and Brain Sciences, 24(1), 87–114. https://doi.org/10.1017/S0140525X01003922 Lorch, R. F., Jr. (1989). Text-signaling devices and their effects on reading and memory processes. 4 Educational Psychology Review, 1(3), 209–234. https://doi.org/10.1007/BF01320135 Roediger, H. L., & Karpicke, J. D. (2006). Test-enhanced learning: Taking memory tests improves long-term retention. 5 Psychological Science, 17(3), 249–255. https://doi.org/10.1111/j.1467-9280.2006.01693.x エンジニアのための伝わる技術コミュニケーション 19

• https://doi.org/10.1037/h0045106
• https://doi.org/10.1207/s15516709cog1202_4
• https://doi.org/10.1017/S0140525X01003922
• https://doi.org/10.1007/BF01320135
• https://doi.org/10.1111/j.1467-9280.2006.01693.x