---
title: ②【実践編】Mentor_Phrase_Guide
tags: 
author: [smile_yukiko_it](https://docswell.com/user/smile_yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GJ5MMLPGJ4.jpg?width=480
description: ②【実践編】Mentor_Phrase_Guide by smile_yukiko_it
published: May 06, 26
canonical: https://docswell.com/s/smile_yukiko_it/KX2W27-2026-05-06-084847
---
# Page. 1

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

メンター口頭
フレーズ集
「なぜするのか分かる」伝え方
— もし〇〇しないと〇〇になる —
対象：IT研修メンター・OJT担当エンジニア


# Page. 2

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

なぜ「フレーズの型」がメンターに必要か
伝え方を変えるだけで、研修生の行動が変わる
よくある失敗：Why が抜けた指示
「このコードはこう書いて」「とりあえず動けばいい」
「先輩がそうしてたから」
→ 研修生は理由を知らないまま真似するだけ。
PhBL型：もし〇〇しないと〇〇になる
状況（If）→ 結果（Then）→ だから行動（Action）の順で伝える。
研修生が「自分事」として理解し、次に応用できる。
効果（Frontiers in Education 2024）
現象起点の説明は批判的思考・問題解決力を向上させる。
「なぜ」を先に渡すと記憶定着率が大幅に上がる。


# Page. 3

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

NG vs OK ── 同じ内容でも伝え方でこんなに違う
「もし〇〇しないと〇〇」の型を使うだけで劇的に変わる
NG — Why なし
OK — もし〇〇しないと〇〇
「もし変数名が曖昧だと、3ヶ月後に自分でも読めなくなるよ。
「変数名はちゃんと付けて」
コード
だからdataじゃなくuserListにしよう。」
「もし1コミットに全部入れると、バグの原因を探すとき
「コミットは細かくして」
Git
地獄になるよ。だから機能単位で区切ろう。」
「もし手順を書かないと、次に誰かがやるとき同じ時間がかかる。
「ドキュメント書いといて」
ドキュ
だからこのフォーマットで残しておこう。」
「もしログがないと、障害が起きたとき何も手がかりなくなるよ。
「エラーはちゃんとログに出して」
ログ
だからこの行にログを追加しよう。」


# Page. 4

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

技術指導フレーズ集 ── コード・設計・ツール
「もし〇〇しないと〇〇になる。だから〇〇しよう。」の型で
テスト
「もしテストなかったら、リファクタのたびに
全部手で確認するはめになるよ。
だからこのケースにユニットテストを書こう。」
手間→ 自分のコストに置き換えると刺さる
プルリクエスト
「もしPRを大きくしすぎると、レビューが1週間
止まることもある。だから300行を目安に分割しよう。」
チームの実例を使うとリアリティが出る
エラーハンドリング
「もし例外を握りつぶすと、本番で何も出なくて
原因不明のまま数時間溶けるよ。
だからここはきちんとthrowしよう。」
障害シナリオは記憶に強く残る


# Page. 5

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

習慣・姿勢フレーズ集 ── コミュニケーション・ドキュメント
技術以外の「なぜ」こそ、明示的に伝えないと伝わらない
相談のタイミング
「もし30分悩んで動かなかったら聞いてくれていいよ。
もし言わないでいると、午後丸ごと溶けることがある。
だから早めに声をかけよう。」
時間のコストを数字で見せると動きやすい
進捗報告
「もし詰まってるのが見えないと、
チームが次の工程に動けなくて全体が遅れるよ。
だから詰まったら先にひとこと言ってほしい。」
自分ではなくチームへの影響を伝える
手順ドキュメント
「もし手順を残さないと、次に同じ作業するとき
また1時間かかる。だからこのフォーマットで書いておこう。
未来の自分へのプレゼントだと思って。」
「未来の自分へ」は自発性を引き出す言葉


# Page. 6

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

障害・レビュー指摘フレーズ集 ── 失敗から学ばせる伝え方
叱責にならず、次の行動を引き出すフレーズ
バグ発生時
「もしここに入力チェックないと、変な値が入って
下流が全部狂うんだよね、実際今回そうなった。
だからバリデーションをここに追加しよう。」
「今回そうなった」と現象を使うと説得力UP
レビュー指摘時
「もしここをこのままにすると、半年後に
誰もここを触れなくなる可能性がある。
だから今のうちに整理しておこう。」
未来のリスクを見せる。責めない形にする
同じミスが続くとき
「もしチェックリストなかったら、
同じところでまた引っかかる可能性が高いよ。
だから自分でリストを作って持つといい。」
解決策をセットで渡す。依存させない


# Page. 7

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

キャリア・成長フレーズ集 ── 自律・判断・目標
「なぜ成長が必要か」をメンターが言語化してあげる
自律的に動いてほしいとき
「もし毎回指示待ちにしてると、
自分で仮説を立てる筋肉が育たないんだよね。
だからまず自分で考えてから聞いてほしい。」
「筋肉」などの比喩は腑に落ちやすい
スキルアップの動機づけ
「もしDockerを知らないままだと、
今後のチームでは環境構築の度に人に頼むことになる。
だから今のうちに触っておこう。」
具体的な将来困るシーンを見せる
本質を考えてほしいとき
「もし動いたからOKで終わると、
次に似た問題が来たとき同じ時間かかるよ。
だから、なぜこれで動いたかを説明してみて。」
アウトプットさせると定着が深まる（PhBL手法）


# Page. 8

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

メンター5原則
すべてのフレーズはこの5原則に基づいている
01
「もし〇〇しないと → 〇〇になる → だから〇〇しよう」の型を使う
02
Why（理由）を先に渡す。How（方法）は後。順番が定着を決める
03
現象（実際の障害・失敗・チームの困り事）を例に使う
04
責めない。リスクを一緒に見る。解決策はセットで渡す
05
最後に「なぜそうなったか説明してみて」とアウトプットさせる