---
title: 【非IT学部卒未経験学生のエンジニア就職応援】IT研修講師ハンドブック_202604280652
tags: 
author: [smile_yukiko_it](https://image.docswell.com/user/smile_yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/PJXQQVV57X.jpg?width=480
description: 【非IT学部卒未経験学生のエンジニア就職応援】IT研修講師ハンドブック_202604280652 by smile_yukiko_it
published: April 28, 26
canonical: https://image.docswell.com/s/smile_yukiko_it/ZJW9DN-2026-04-28-065110
---
# Page. 1

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

FOR
I T
T RAI NING
INST RUCT ORS
/
I T 研修講師向け
IT研修講師ハンドブック
指導法 × カリキュラム × 対話ガイド
未経験講師でも実装できる、観察 → 誘導 → 並走 → 対話 の完全パッケージ。
PART A
PART B
PART C
指導法
5日間カリキュラム
問題行動 対話ガイド
受講生をどう観察し、どう動くか
受講生に渡す中身。3つの実践スキル
問題が起きた時の実践マニュアル
・WHY 否定しないとは何か
・WHAT 10典型行動
・HOW 5ステップ × 5型
・ACTION 5W1H + 3週間並走
・Day 1 基本マナー
・Day 2 報連相 (事実×仮説)
・Day 3 仮説思考 (PDCAのA)
・Day 4 質問力 (15分ルール)
・Day 5 エンジニア固有
・WHAT 対話の3ステップ
・HOW 5W3H で対話設計
・HOW 4ステップ進行 + フレーズ集
・HOW 講師の自己チェック
・NG 避けるべき5パターン
対象：未経験〜初級IT講師 / メンター候補 / OJT担当
Instructor Handbook v1.0


# Page. 2

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

02 / 28
OVE R VIE W
ハンドブックの使い方
Part A=動き方、Part B=教える中身、Part C=問題対応。それぞれ独立して使える。
PART
A
PART
B
PART
C
指導法 — 講師の動き方
5日間カリキュラム — 受講生に渡す中身
対話ガイド — 問題行動が起きた時
使うシーン
使うシーン
使うシーン
・受講生の行動が気になり始めた時
・「指摘していいか」迷った時
・週次の1on1の準備
・3週間の並走計画を立てる時
・新人受け入れ初週の研修
・OJT前の知識整え
・現場デビュー準備の総点検
・受講生のセルフチェック
・遅刻・未提出など問題行動が出た時
・1on1で深く話す必要がある時
・指摘の前に自分を点検したい時
・「何と言うか」迷った時
収録内容
収録内容
収録内容
WHY 否定しない / WHAT 10典型行動 / HOW 5ステップ
+ 5型 / ACTION 5W1H + 3週間並走
Day 1 基本マナー / Day 2 報連相 / Day 3 仮説思考 /
Day 4 質問力 / Day 5 エンジニア固有 + 卒業チェック
対話3ステップ / 5W3H / 4ステップ進行 / 質問フレーズ集
/ 講師の自己チェック / NG対話5パターン
講師は Part A で動き方を、受講生に Part B を渡し、問題行動が出たら Part C を開く、という三段使いを推奨。


# Page. 3

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

03 / 28
P A R T
A
指導法 — 講師の動き方
受講生を観察し、否定せず、習慣を一緒に作る。
講師の仕事はジャッジではなく「並走」。
指導の鋭さは保ち、人格を傷つける言葉だけを取り除く。
WHY 否定しない
WHAT 10典型行動
HOW 5ステップ
HOW 5型言い換え
ACTION 5W1H
ACTION 3週間並走


# Page. 4

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

PA RT A
WHY
04 / 28
なぜ「習慣」を指導す るのか
「否定しない」=「指摘しない」ではない
人格と行為を分けて、行為についてだけ事実を伝える。これが定義。
✕ 人格を否定する言い方
○ 行為について事実を伝える
「やる気あるの？」
「進捗報告で「もうちょっと」が3日続いていますね」
「向いてないんじゃない？」
「この書き方は、現場で問題が起きやすいパターンです」
「こんなコード書いて…」
「データ件数が増えるとメモリで詰まる書き方になっています」
「なんでできないの？」
「情報がもう少しあれば一発で答えられそうです」


# Page. 5

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

PA RT A
WHAT
05 / 28
評価を下げる10の典型行動
「観察すべき10の行動」一望表
★印は初級講師がまず3週間集中して観察すべき優先3行動。
1
★
質問が「動きません」だ
け
6
Slack/MTGの応答が遅
い
2
★
進捗報告に具体性がない
7
同じミスを繰り返す/メ
モなし
3
締切前日まで遅延を共有
しない
8
朝会で詰まりを報告しな
い
※ 優先3行動（★）= 質問の質 / 進捗の具体性 / フィードバック受容。10個全部を同時に追わない。
4
5
レビュー指摘が表面的で
再発
9
★
FBに「でも」「だって」
が出る
仕様書を読まずに実装開
始
10
自己評価が過大または過
小


# Page. 6

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

PA RT A
WHAT
06 / 28
評価を下げる10の典型行動
★優先3行動 — 観察ポイントと現場影響
未経験講師は、まずこの3つだけを毎日観察する。それ以外は無視してよい。
質問が「動きません」だけ
1
観察
・自分で何を試したかが書かれていない
・エラー全文が添付されていない
・仮説がない
進捗報告に具体性がない
2
観察
・「昨日と同じところやってます」が続く
・「あと少し」が3日続く
・%や完了基準で言えない
フィードバックに「でも」「だって」
9
観察
・指摘に対して防衛が先に出る
・「環境のせい」「仕様のせい」が口癖
・表情が固くなる
現場影響
シニアの時間を奪う。質問の質はエンジニアの実力と直結すると評価される
。
現場影響
PMがリスクを察知できない。隠したつもりが、結果として手遅れに。
現場影響
シニアが「言っても無駄」と判断しFBが止まる。これが最も怖い結末。


# Page. 7

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

PA RT A
HOW
07 / 28
カイゼン誘導の伝え方
カイゼン誘導の5ステップ
順序を守る。飛ばすと改善は空回りする。
S TE P
1
S TE P
2
S TE P
3
S TE P
4
S TE P
5
状態観察
要件把握
論点把握
カイゼン誘導
並走
1〜2週間。一過性か習慣化
された問題か見極める。
「何ができていればOKか
」を双方で言葉にする。
改善インパクト最大の1つ
に絞る。3つ言うと「全部
ダメ」と受け取られる。
「直して」と言わず、今日
からできる具体行動を示す
。
改善が習慣化するまで一緒
に走る。指摘して放置は
NG。
目安：2週間
目安：30分対話
目安：1論点
目安：具体1個
目安：3週間
ポイント：3週間並走する覚悟がないなら、その指摘はしない方がよい。


# Page. 8

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

PA RT A
HOW
08 / 28
カイゼン誘導の伝え方
否定しない伝え方 — 5つの言い換え型
迷ったらこの5型に当てはめる。鋭さは保ち、人格を傷つける言葉だけ取り除く。
型
✕ NG
○ 言い換え
詰問→確認
「なんでこうしたの？」
「これ、何をしようとしたか教えて」
断罪→観察
「質問が雑」
「質問にこの情報があると一発で答えられる」
比較→自分史
「同期はもうできてる」
「1ヶ月前の自分と比べてどう？」
指示→質問
「こうしろ」
「どう進めるのが良さそう？」
脅し→道筋
「現場で潰される」
「現場ではこのレベル。あと3ヶ月でここまで届こう」
言いにくいことは「事実 → 認識 → 行動」の3点セット
①「進捗報告で『もうちょっと』が3日続いていますね」(事実) → ②「サポートしたくてもできない状態です」(認識) → ③「明日から進捗を%で言えるようにしませんか
」(行動)


# Page. 9

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

PA RT A
ACTION
09 / 28
未経験講師の具体行動
5W1H — 未経験講師が明日からできる具体行動
講師未経験でも、この6項目を埋めれば動ける。
WHEN
WHERE
WHO
いつ
どこで
誰が
毎朝会(15分) / 毎日終業前メモ / 週1の1on1(30分
)。
指摘は「気づいた瞬間」ではなく「2週間観察した
後」。
朝会＝チーム全員 / 個別指摘＝1on1専用Slackチャ
ンネル＋DM。
公開で晒さず、必ずDMでフォロー。
観察＝初級講師 / 判定＝上級講師 / 並走＝両方。
判断に迷ったら必ず上級講師にエスカレ。
WHAT
WHY
HOW
何を
なぜ
どう
「優先3行動（質問の質・進捗具体性・FB受容）」
だけを観察。
10個全部を同時に追わない。1論点に絞る。
受講生の評価を下げているのは「能力」ではなく「
習慣」。
習慣は「指摘」ではなく「並走」でしか変わらない
。
事実→認識→行動の3点セットで伝える。
「直して」ではなく「今日からこうしよう」と具体
行動を渡す。
迷ったら上級講師にエスカレ。「自分で判断しない」ことが、未経験期の最大の安全策。


# Page. 10

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

PA RT A
ACTION
10 / 28
未経験講師の具体行動
3週間並走の設計図
改善は1回の指摘では終わらない。最低3週間並走する覚悟で。
1〜3日
4〜10日
11〜21日
22日〜
1
2
3
4
認識共有
行動変容
習慣化
定着確認
何を改善したいか、双方で言葉にす
る。本人が「直すべき1つ」を自分で
言えるまで対話。
新しい行動を試す。良い変化が見え
たら即フィードバック。1日1回は短
く声かけ。
戻り気味な場合のリカバリー設計。
責めずに「もう一度試そう」と言え
る距離感を保つ。
別の改善ポイントに移る。並列で2つ
を同時には絶対にやらない。
並走中の上級講師セルフチェック（毎週金曜）
□ 改善ポイントは本人と認識が合っているか
を拾えているか
□ 良い変化が見えたとき即承認したか
□ 別の改善ポイントを並行で持ち出していないか
□ 1on1で「うまくいかなさ」


# Page. 11

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

11 / 28
P A R T
B
5日間カリキュラム
受講生に渡す中身。3つの実践スキルで「現場デビュー準備」を完成させる。
Day 1で型を、Day 2-4で核となる3スキルを、Day 5で統合する設計。
このPart B は、受講生に直接渡してもよい完成された教材です。
講師は Part A を片手に、この教材を「一緒に並走する」イメージで使ってください
。
①報連相 事実と仮説
②仮説思考 PDCAのA
③質問力 15分ルール


# Page. 12

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

PA RT B
12 / 28
5日間カリキュラム全体 マップ
5日間カリキュラム 全体マップ
Day 1で型を、Day 2-4で核となる3スキルを、Day 5で統合する設計。
D1
D2
D3
D4
D5
Day 1
Day 2
Day 3
Day 4
Day 5
IT現場の基本マナー
①報連相
②仮説思考
③質問力
エンジニア固有マナー
& 統合
型を作る
挨拶/服装/時間/応答
名乗り/メール署名
事実 vs 仮説
報告テンプレ
NG/OK実例
演習
PDCAのA
PDCAサイクル
IF-THEN形式
Aの最小手順
15分ルール
自己解決vs質問
質問テンプレ
誰に聞くか
現場デビュー
PR/レビュー作法
コミット作法
卒業チェック
毎日の終わりに「今日の3行ふりかえり：事実1つ・気づき1つ・明日試す1つ」を提出。これがDay 3で学ぶPDCAのAそのもの。


# Page. 13

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

13 / 28
D A Y
01
IT現場の基本マナー
K E Y
M E S S A G E
「即返信」が信頼を作る
✕ 既読スルー / 半日後返信
○ 30分以内に「見ました」
先輩は「届いたか」「見たか」が分からず、別の人に振
り直すか自分でやることに。
「見ました。今のタスクを17時に区切って取り掛かりま
す」だけで、先輩は安心して次の仕事に進める。
即返信ルール 3か条
① 30分以内に「見ました」だけでも返す
② 「いつ返せるか」を添える(例:17時頃)
③ 返せない時は理由を1行(例:今障害対応中)
Day 1 / 5


# Page. 14

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

14 / 28
D A Y
02
Day 2 / 5
① 報連相
K E Y
M E S S A G E
「事実」と「仮説」を分けて伝える
事実 (Fact)
仮説 (Hypothesis)
誰が見ても同じになるもの。
・エラーメッセージ全文
・コマンドの出力
・実行手順
・観測した数値
自分の解釈・推測。
・「○○のせいだと思う」
・「たぶんこれが原因」
・「○○すれば直りそう」
→ 必ず仮説とラベル付け


# Page. 15

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

PA RT B
Day 2
15 / 28
①報連相 — 事実と仮説を分ける
Day 2 詳細：報告テンプレと NG/OK実例
テンプレを毎回使う。最初は遅くてもよい。3週間で習慣化する。
✕ NG報告
○ OK報告
「APIが死んでます。
たぶんサーバーの問題です。
直してもらえますか？」
「/api/users にPOSTを3回送信、
すべて HTTP 500 が返ります(事実)。
サーバー側の問題と推測しています(仮説)。
ログ確認まで自分でやれます。
権限の付与をお願いできますか？」
報告テンプレート
1
事実
観測されたこと(全文)
2
仮説
自分の推測(ラベル付け)
何がダメか
何が良いか
・「死んでる」は事実か仮説か不明
・「サーバーの問題」と断言してる
・自分は何を試したか不明
→ 先輩は最初から状況を再調査する必要
・「事実」「仮説」がラベル付き
・自分でできる範囲を明示
・依頼内容が具体的
→ 先輩は10秒で次の判断ができる
3
やったこと
自分が試した手順
4
依頼/相談
次に何が欲しいか
Day 2の演習：今日の作業の中で「事実3つ・仮説3つ」を書き分けて先輩に報告する。


# Page. 16

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

16 / 28
D A Y
03
② 仮説思考
K E Y
M E S S A G E
解決するのはPDCAの「A」だけ
P
D
C
A
Plan
Do
Check
Action / Adjust
仮説を立てる
実行する
結果を見る
学習する ★
★ 多くの人が P・D・C で止まる。Aを書く人だけが、3ヶ月後に伸びる。
Day 3 / 5


# Page. 17

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

PA RT B
Day 3
17 / 28
②仮説思考 — PDCA のAで「学習」を作る
Day 3 詳細：IF-THEN形式とAの最小フォーマット
仮説は「もし○○なら△△が起きるはず」の形で書く。これだけで思考が整理される。
実例：APIエラーへの仮説思考
仮説の形式：IF-THEN
「もし [原因] が正しければ、[結果] が起きるはず」
例：もしDB接続が原因なら、DBサーバーを再起動するとエラーは消えるはず。
P 仮説
→ 検証して結果を見れば、原因か違うか1回で分かる。
→ 結果が予想と違ったら、それが「学習」になる。
D 実行
Aの最小フォーマット (毎タスク末)
① 予想と違ったこと ＿＿＿＿＿＿＿＿
② 次回試すこと
＿＿＿＿＿＿＿＿
③ 覚えておくこと
＿＿＿＿＿＿＿＿
C 結果
A 学習
もしDB接続文字列が間違っているなら、DB再起動しても500の
ままのはず。
DBサーバーを再起動。
500エラーは消えなかった。仮説は外れた。
①予想と違ったこと=DB再起動で直らなかった →接続文字列が
原因確定。
②次回試す=接続文字列を確認。
③覚える=エラー時はまずsettingsを見る。
Day 3の宿題：終業前に「Aの3項目」を1日3回(朝/昼/夕)書く習慣を始める。


# Page. 18

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

PA RT B
Day 4
18 / 28
③質問力 — 選択して先輩に聞ける
Day 4 ③質問力 — 「選択して」聞ける
「聞くか・自分でやるか」を毎回判断する。これが「選択して聞ける」の意味。
15分ルール
質問の判断フロー
1
2
15分自分で考えて解けないものは聞く。ただし「何を15分やったか」は必ずメモして質問に添える。
質問テンプレート (5項目)
エラー全文で検索したか？
① やりたいこと
→ Yes 次へ / No まず検索
② やったこと(手順)
公式ドキュメントを開いたか？
→ Yes 次へ / No まず読む
③ 出たエラー(全文)
④ 自分で調べたこと
⑤ 自分の仮説
3
15分以上詰まっているか？
→ Yes 質問する / No もう少し試す
誰に聞くか — 階段を1段ずつ
4
「自分の仮説」を1つ持てているか？
→ Yes 質問する / No 仮説を作ってから
直属の先輩 → チームSlackチャンネル → 全社の質問チャンネル
身近な人に聞いてダメな時だけ広げる。
Day 4の演習：今日の質問を1つ選んで、5項目テンプレで書き直す。


# Page. 19

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

PA RT B
Day 5
19 / 28
エンジニア固有マナー & 統合
Day 5 コードでのコミュニケーション3点
コミットメッセージ・PR本文・レビュー受けは、すべて「文章での報連相」。
コミット作法
PR(プルリク)作法
レビューの受け方
✕ NG
fix
✕ NG
色々直したPRです
お願いします
✕ NG
「直しました」だけ
再提出 → 同じ指摘
→ 学習速度が遅い評価
○ OK
fix: ユーザー登録時のメール検証エラーを修正
○ OK
## 目的
ユーザー登録の不具合修正
○ OK
「ありがとうございます。
なぜこの書き方が良いのか
教えてください」
→ 理由を聞く → 次から自分で気づける
空文字を許容していたバリデーションを
is_valid_email() で厳密化。
#1234
1コミット1意図。Whyを必ず書く。後で自分が読
み返す。
## 確認ポイント
・空文字メールが弾かれるか
・既存テストが通るか
目的・確認ポイントを書く。レビュアーの時間を短
縮する。
指摘は人格否定ではない。「Thanks → Why?」
のセットで返す。


# Page. 20

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

PA RT B
20 / 28
5日間 卒業チェックリスト
5日間 卒業チェックリスト
全項目が□になったら、現場デビュー準備完了。1on1で先輩と一緒に確認する。
Day 1 - 基本マナー
Day 2 - 報連相
Day 3 - 仮説思考
Day 4 - 質問力
Day 5 - エンジニア固有
始業10分前にログインして
いる
報告に「事実」「仮説」の
ラベルを付けている
仮説をIF-THEN形式で書け
る
15分ルールを使い分けてい
る
コミットメッセージにWhy
を書いている
Slackメンションに30分以
内に1行返している
テンプレ4項目(事実/仮説/
やったこと/依頼)で書ける
毎タスク末にAの3項目を書
いている
質問テンプレ5項目で書け
る
PR本文に目的と確認ポイン
トを書いている
「いつ返せるか」を添えて
返している
エラーメッセージは全文で
報告している
予想と違った時を「失敗」
ではなく「学習」と捉えて
いる
「自分の仮説」を添えて質
問している
レビュー指摘に「Thanks
→ Why?」で返している
各項目「□ できる」と「□ 教えられる」の2段階で評価。教えられる=自分の言葉で後輩に説明できる状態。


# Page. 21

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

21 / 28
P A R T
C
問題行動 対話ガイド
講師経験ゼロでも大丈夫 — このガイドの通りに進めれば必ずできる。
責めるのではなく「一緒に原因を探る」対話。
本人が「直す1つ」を自分の口で言えるまで導く。
5W3H・4ステップ進行・質問フレーズ集を使えば、未経験でも対話を組み立てられ
る。
WHAT 対話3ステップ
HOW 5W3H 設計
HOW 4ステップ進行
HOW フレーズ集
HOW 自己チェック
NG 5パターン


# Page. 22

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

PA RT C
WHAT
22 / 28
対話で何をするのか
問題行動への対話 — 3ステップ
「責める」のではなく「原因を一緒に探る」。3ステップなら未経験でも迷わない。
11
STEP 1
データ収集
22
STEP 2
原因のヒアリング
33
STEP 3
改善の言語化
事実を集める
本人の視点・背景を聞く
本人が「直す1つ」を言う
いつ・何が・どこで起きたか。観察できる事実
だけを集める。
本人の解釈や自分の推測はまだ入れない。
「そのときどう思っていましたか？」
本人の認識・状況を、こちらの判断を挟まず先
に全部聞く。
答えを与えず、本人の口で「変えたいこと1つ
」を言わせる。
出るまで待つ。これが対話のゴール。
例：今月の遅刻3回 / 報告メール未送信2件
例：体調 / 家庭事情 / 業務量 / 指示理解のズレ
例：「明日から朝のSlack投稿を必ずします」
仮説を事実のように話すと、本人の信頼を一瞬で失う。「やる気がない」ではなく「やる気がないかもしれない」と言う。


# Page. 23

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

PA RT C
HOW
23 / 28
対話を設計する
5W3H で対話を設計する
「何を・いつ・どう聞くか」を事前に準備する。まずは Who・What・Why の3つだけで十分。
Who
★
What
★
When
Where
誰が
何を
いつ
どこで
問題行動を起こしているのは誰か
何をしたか（事実ベースで）
いつ起きたか（頻度・パターン）
どの場面・状況で起きたか
How
How much
How many
なぜ
どう
どの程度
どれくらい
なぜそうなったか（本人の認識）
どんな方法で対話を進めるか
改善度合いをどう測るか
何回・どの期間で確認するか
Why
★
★印 = まずこの3つだけ意識する。慣れたら他の5つも入れていく。全部一度に使う必要はない。


# Page. 24

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

PA RT C
HOW
24 / 28
対話の進め方
対話の進め方 — 4ステップ
この順番通りに進めれば、誰でも迷わない。STEP 4 が出るまで待つのが講師の仕事。
S TE P
1
S TE P
2
S TE P
3
S TE P
4
事実を伝える
本人の話を聞く
一緒に改善策を考える
「直す1つ」を本人の口か
ら
Whatから始める
Whyを引き出す
Howへ
ゴール
「○○の場面で、○○がありまし
た」と事実だけ話す。
感情・判断・自分の解釈は一切入
れない。
「そのときどう思っていましたか
？」
本人の背景・視点を、口を挟まず
先に全部聞く。
「次はどうしたいですか？」
答えを与えず、本人に考えさせる
。沈黙を恐れない。
「一番変えたいことを1つ言葉にし
てみてください」
出るまで待つ。本人の言葉になっ
て初めて改善が始まる。
→
→
→
STEP 4 で本人が自分の言葉で言えたとき、はじめて本当の改善が始まる。焦らず待つ。


# Page. 25

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

PA RT C
HOW
25 / 28
そのまま使える質問フ レーズ集
そのまま使える 質問フレーズ集
迷ったらこの言葉をそのまま使ってOK。「短く・優しく・具体的に」が最強。
事実を確認するとき
本人の気持ちを引き出すとき
「あの場面、具体的に何がありましたか？」
「そのとき、自分ではどう感じていましたか？」
「それは何回くらいありましたか？」
「なぜそうしようと思ったか、教えてもらえますか？」
改善を考えさせるとき
1つに絞らせるとき
「次に同じ場面になったら、どうしたいですか？」
「今日の話で、1つだけ言葉にするとしたら？」
「今一番変えてみたいと思うことは何ですか？」
「まず最初にやってみることを1つ決めましょう」
難しい言葉は要らない。短く・優しく・具体的に。これだけで対話は前に進む。


# Page. 26

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

PA RT C
HOW
26 / 28
本人を指摘する前に
まず自分をチェックする
本人を指摘する前に、講師側の改善余地を必ず確認する。これが公正な対話の出発点。
本人への指摘の前に「自分はどうだったか？」を必ず問いかける。
指示・期待値は明確に伝えていたか？
→ 曖昧な指示が原因のミスは、講師の責任
声がけ・フォローの頻度は十分だったか？
→ 孤立させると問題行動が見えにくくなる
本人が相談しやすい雰囲気をつくれていたか？
→ 話しかけにくい環境が隠蔽を生む
フィードバックは都度できていたか？
→ 溜めてまとめて言うのは逆効果
4つ全部チェックできてから、はじめて本人への対話に進む。


# Page. 27

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

PA RT C
NG
27 / 28
避けるべき対話パター ン
やってはいけない NG対話 5パターン
これだけ避ければ、対話は確実に前に進む。完璧を目指さなくてよい。
✕ NG 1
✕ NG 2
✕ NG 3
✕ NG 4
✕ NG 5
仮説を事実として話す
複数の改善点を一度に渡
す
答えを先に言ってしまう
感情的になって話す
確認しないまま終わる
「やる気がない」などの決めつけ
は反発を生む。
「あれもこれも」では本人が混乱
し、何も変わらない。
「〜すべき」と正解を与えると、
本人の気づきが育たない。
怒りや失望を前面に出すと、本人
は委縮し本音を話せなくなる。
「言いっぱなし」で終わると変化
が起きない。
→ 仮説には必ず「〜かもしれ
ない」をつける
→ 必ず「1つ」に絞る
→ 待つことが大切
→ 1日置いてから話す
NGを1つ減らすだけで、対話の質は大きく上がる。完璧を目指さなくていい。
→ 次回のフォロー日を必ず決
める


# Page. 28

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

28 / 28
C L O S I N G
講師の仕事は、ジャッジではなく
「習慣を一緒に作る」こと。
PA RT A 講師 の3 ルー ル
PA RT B 受講 生の 3 アク ショ ン
PA RT C 対話 の3 原則
① 本人を否定せず、行為について事実を伝える
① 事実と仮説を分けて報告する
① 事実→Why→改善案→「直す1つ」の順で進む
② 観察→要件→論点→誘導→並走の順序を守る
② 毎タスク末に「Aの3項目」を書く
② 指摘の前に自分を4点チェックする
③ 最低3週間の並走を覚悟する
③ 15分ルールで「選択して」聞く
③ 「正解を与える」より「気づきを支える」
習慣にしてしまえば、毎日の負担はゼロ。講師も受講生も、自然と伸びる。