---
title: 【エンジニア転職応援】エンジニア技術コミュニケーション_受講生用
tags:  #転職 #エンジニア転職 #コミュニケーション  
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/47MYMD827W.jpg?width=480
description: 【エンジニア転職応援】エンジニア技術コミュニケーション_受講生用 by Yukiko
published: October 13, 26
canonical: https://image.docswell.com/s/yukiko_it/59NY1W-2026-10-13-054052
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/47MYMD827W.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/P7R9V455E9.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PJXQZ2KX7X.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/3JK98M59JD.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LE3W2YK9E5.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/8EDKZ5387G.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/V7PKDG4WJ8.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/2JVV16X9JQ.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/5EGL2NV4JL.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4JQYPQ6R7P.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/K74WYN4QE1.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/LJ1Y654LEG.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/GJWGW5XQ72.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4EZL5N6373.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/Y76W982Z7V.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/G75MN92974.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/9J295245ER.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/DEY4KYM6JM.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/VJNYRP3178.jpg)

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