教える技術 | 新人を受け入れる技術

教えるのが上手い人は、説明が上手いわけではありません。相手の頭の中に今どれだけ余裕があるかを見て、渡す情報の量と粒度を変えているだけです。

この章では、その調整の中身を分解します。教え方のセンスではなく、判断の手順として扱います。

新人は同時に4つを処理している

新人が1つのタスクに向かっている時、頭の中では別々の負荷が同時にかかっています。

負荷の種類	具体例	性質
ドメイン知識	業務用語が何を指すか、なぜその仕様なのか	調べても出てこない
コードベースの構造	どこに何があるか、どこを直せば影響するか	読めば分かるが時間がかかる
ツールの使い方	Git、Docker、IDE、デプロイ手順	一般知識だが手が動くまで遅い
チームの慣習	PR の粒度、命名、レビュー依頼の出し方	誰も明文化していない

熟練者はこの4つを1つも意識していません。だからタスクが小さく見えます。 見えているのは自分の頭の中の負荷であって、相手の負荷ではありません。

「簡単なタスク」が簡単でない理由

たとえば「この画面の文言を1つ直して」というタスクを渡したとします。新人がここで実際に開けている未知は、次のようなものです。

どのリポジトリか、どのブランチから切るか
ローカルで起動する手順（そして途中で落ちる）
該当箇所をどう検索するか
文言が直書きなのか、別ファイルで管理されているのか
コミットメッセージの書き方、PR テンプレートの埋め方
レビューを誰に依頼するか、CI が落ちた時にどこを見るか

1行の修正のために、未知を10個同時に開けています。 「1行なのに1日かかった」は、能力の話ではなく、開いた未知の数の話です。

負荷を下げる3つの操作

同時に処理できる量には上限があります。上限を上げることはできないので、渡す側が量を減らします。

1. 対象を1つに絞る

今日教えたいものが「コードベースの歩き方」なら、Git の話はしません。ブランチを切るコマンドはコピペで渡してしまってよいです。 Git は別の日に、それだけを扱います。

2. 未知を既知に置き換える

雛形、テンプレート、参考にする既存コードの指定。「似た実装がここにあるので、それに合わせて」と1つ示すだけで、設計判断という負荷が丸ごと消えます。

3. 同時ではなく直列にする

「環境構築とドメイン理解とタスク着手」を初日に並べると、どれも中途半端になります。順番を決めて、1つずつ閉じてから次を開けます。

「ついでにこれも」が一番効く毒

質問に答えるついでに、関連する知識を3つ足したくなります。親切のつもりです。

しかし、その瞬間に相手の処理量は4倍になり、 元の質問の答えすら残りません。 話したくなったことはメモしておいて、別の日に渡してください。

足場かけ: 型を与えて、外す

足場かけ（スキャフォールディング）は、最初は型や枠組みを与え、慣れたら外していく渡し方です。重要なのは後半で、足場は外す前提で組みます。 外さない足場は、そのまま依存になります。

粒度の階段

タスクの渡し方は、次のように段階を上げていきます。

段	渡す粒度	言い方の例	本人が決めること
1	行レベル	「この関数の28行目を〇〇に変えて、PR を出して」	ほぼなし（手順の練習）
2	ファイル・関数レベル	「このファイルに〇〇する関数を足して。既存の△△が参考になる」	実装の細部
3	機能レベル	「この機能を追加して。仕様はこのチケットに書いてある」	設計、どこを触るか
4	課題レベル	「この課題を解決したい。方針から考えて提案して」	問題の切り方、優先度

1段目の目的は、コードを書くことではありません。 ブランチを切って PR を出してマージされるまでの1周を、成功体験として通すことです。だから内容は自明なほどよいです。

段を上げる時は、上げたことを言葉にします。「今回はチケットだけ渡すね。どこを直すかは自分で決めていい」と宣言すると、本人は「今日から自分で決める範囲が増えた」と認識できます。

よくある2つの失敗

段を飛ばす

1段目の次にいきなり4段目を渡すケースです。「そろそろ任せてみよう」という善意で起きます。本人は方針を決められず、しかし「任された」と言われているので聞きにくい。これが2週間続くと、あとから見て何も進んでいません。

いつまでも外さない

3ヶ月経っても1段目・2段目しか渡していないと、「指示がないと動けない人」ができあがります。 指示待ちを作っているのは、渡し方の側であることが少なくありません。

足場を外す合図

次のどれかが観測できたら、1段上げてよい合図です。

同じ種類のタスクを2〜3回、大きな手戻りなくやり切った
質問の内容が「どうやるか」から「どちらが良いか」に変わった
レビューでの指摘が、設計の問題ではなく細かい好みの範囲に収まってきた

外す時は予告する

足場を黙って外すと、本人からは「放置された」と区別がつきません。

「次から設計は任せる。ただし着手前に方針だけ5分見せて」のように、 外す範囲と、残す安全網を同時に伝えてください。 安全網があるほど、人は大きく踏み出せます。

答えを教えるべき時と、教えるべきでない時

「答えを教えてはいけない」は、教える側の格言としてよく聞きます。これを絶対視すると、単に時間を溶かすだけになります。

自分で考えさせることが機能するのは、考えれば辿り着ける時だけです。辿り着けない問題を放置するのは、教育ではありません。

判断の基準

状況	判断	理由
社内固有の知識（なぜこの設計になっているかの経緯）	教える	調べても出てこない。詰まっても学びが発生しない
環境依存の罠（この手順は特定のマシンで落ちる）	教える	時間だけが溶ける。再発見に価値がない
探索コストが極端に高い（ログの置き場所、権限の申請先）	教える	時間対効果が悪い。知っていれば10秒
検索すれば出る（エラーメッセージ、言語仕様）	教えない	検索して切り分ける経験そのものが目的
次も同じ状況に出会う（デバッグの進め方）	教えない	一度自力で抜けると定着する
調べ方自体を身につけてほしい（公式ドキュメントの読み方）	教えない	答えを渡すと調べ方が育たない

境目は「調べれば出るかどうか」です。 社内にしか存在しない情報を、自力で発見させることはできません。

迷ったら、答えと経路を両方渡す

判断に迷う場面は必ず出ます。その時のデフォルトはこれです。

「答えは〇〇。ちなみに自分は、まず起動時のログを上から見て、そこに出ていた△△という単語で検索した。次に似たことがあったら同じ順で見てみて」

答えを渡しても、どう辿り着いたかを一緒に渡せば、探索の経路は残ります。 これは「答えを教えない」の上位互換で、時間も短くて済みます。

「自分で調べてみて」は時間を区切らないと放置になる

この一言だけで返すと、相手は「いつまで調べればいいのか」が分かりません。そして聞きに来るタイミングを失います。

必ず上限をつけてください。「30分調べて出なかったら、途中経過ごと持ってきて」まで言って、はじめて指示として成立します。

説明が伝わらない時にすること

同じ説明を2回して伝わらなかったら、説明の仕方の問題ではありません。 前提が揃っていないと考えてください。

そして、揃っていない前提の大半は用語です。デプロイ、ステージング、マイグレーション、冪等、リポジトリとリモート。こちらが説明の材料として使っている単語が、相手にとっては未知の単語です。

効く聞き方

聞き方によって、返ってくる情報がまったく変わります。

聞き方	返ってくるもの
分かった？	「はい」しか返らない
どこが分からない？	分からないことが分からない段階では答えられない
今の説明で分からなかった単語はどれ？	指させる。ほぼ必ず1つ以上出てくる

3つ目が強いのは、答えの単位が単語まで小さくなっているからです。理解度という曖昧なものを申告させるのではなく、指差しに変えています。

補助として、次も使えます。

「今の話、自分の言葉で言うとどうなる？」と説明し返してもらう
抽象度を1段下げる。概念の説明をやめて、実物の画面やコードを開く
例を増やさず、例を1つに絞る。例が3つあると、共通点を探す負荷が増える

比喩は理解の確認にはならない

比喩は入口としては有効ですが、比喩が通じたことは、実物が分かったことを意味しません。

「なるほど、郵便局みたいなものですね」で終わると、実際のコードを前にした時に何も起きません。比喩で入ったら、必ず実物に戻って確かめてください。

ペアプロ・モブプロの使いどころ

一緒に画面を見て作業するのは、負荷の高い場面を通過させる手段として非常に強力です。ただし、常時やるものではありません。

効く場面

環境構築や初回セットアップ。罠が多く、1人だと半日溶ける
コードベースの歩き方を見せる。検索の仕方、定義への飛び方、ログの追い方
初めての種類のタスクの1回目だけ
詰まりが長期化している時の救出

やりすぎた時の害

1人で詰まって抜け出す経験が奪われる。 自走はその経験からしか育たない
新人が操作係になる。手は動いているが、考えているのは横の人
メンターの時間が溶ける。1日中は続かず、続けると他の業務が崩れる
見られている緊張で、試行錯誤や寄り道ができなくなる

目安は、1回30〜60分、目的を1つ決めて実施することです。「今日はログの追い方を見せる回」と宣言してから始めます。

見せる価値があるのは、うまくいく所ではない

ペアプロで最も学びが大きいのは、あなたが詰まって、そこから復帰する場面です。

想定外のエラーが出た時に、どこを見て、何で検索し、どう切り分けるか。段取りよく進む所より、素の姿の方が教材になります。きれいに進めようとしなくて構いません。

教える側が陥る3つの罠

1. 自分のやり方を唯一の正解として押しつける

「まず全体のコードを読んでから着手すべき」「自分は写経で覚えた」。どれも本人にとっては本当ですが、再現できる条件が違います。 当時と今では、コードベースの規模も、使える時間も、本人の背景も違います。

対処は単純で、好みと必須を言い分けることです。

「これは自分の好みのやり方で、理由は〇〇だから。別のやり方でも構わないけど、△△だけはチームの決まりなので合わせて」—— このように言えば、押しつけずに、守ってほしい線だけを伝えられます。

2. 知識の呪い

自分にとって自明になったことは、説明の中で無意識に飛ばされます。そして、飛ばされた所が、そのまま新人の詰まる所になります。

自分で検出する方法があります。説明の中でこう言った箇所です。

「まあ普通に〇〇して」
「あとは適当に」
「いつもの感じで」

ここが飛んでいます。手順を1つずつ書き出すか、新人に手順を復唱してもらうと穴が見えます。

3. 「なんで分からないの」と言ってしまう

これを言った時点で、相手は次から質問できなくなります。第1章で扱った悪循環が、この一言から始まります。

つい言ってしまう言葉	言い換え
なんで分からないの	どこまでは分かってる？
さっき言ったよね	もう一度説明するね。前の説明が分かりにくかったかも
普通こうするでしょ	このチームではこうしてる。理由は〇〇だから
それくらい自分で考えて	15分考えて出なかったら一緒に見よう

苛立ちの正体を切り分ける

同じ説明を3回した時に湧く苛立ちは、たいてい 自分の時間が削られていることへの反応であって、相手の能力への評価ではありません。

この2つを混ぜたまま口を開くと、評価の言葉として相手に届きます。苛立ちを感じたら、まず「今、自分の時間が足りていない」という事実の方をチームに共有してください。それは第7部で扱う、受け入れ体制の問題です。

新人が2時間、ローカル環境で DB に接続できないエラーで詰まっています。原因は「このプロジェクトでは特定の環境変数を設定しないと接続が落ちる」という社内固有の事情で、README には書かれていません。あなたはどうしますか？

判断の順番として整理する

この章で扱ったことを、実際の場面での順番に並べると次のようになります。

今、相手が同時に開けている未知はいくつあるか見積もる
多すぎるなら、教える対象を1つに絞り、残りは既知（コピペ・雛形）に変える
渡すタスクの粒度を、今の段に合わせる。上げる時は宣言する
質問が来たら、それが調べて出る情報かどうかで教える／教えないを決める
迷ったら答えを言う。ただし自分がどう調べたかも一緒に言う
伝わらない時は、説明を言い換える前に、分からなかった単語を聞く

ここまでは、すべて「聞きに来た時にどう答えるか」の話でした。しかし実際の現場では、聞きに来ないことの方が問題になります。 詰まりを本人の勇気に頼らず検知する仕組みは、次の章で扱います。

この章のまとめ

新人はドメイン知識・コード構造・ツール・チーム慣習を同時に処理している。上限を超えたら、渡す側が量を減らす
「ついでにこれも」は親切ではなく、元の答えまで消す
足場かけは、行レベル → ファイルレベル → 機能レベル → 課題レベルと粒度を上げる階段。外す前提で組み、外す時は予告する
答えを教えるかは、調べても出てこない情報かどうかで決める。社内固有・環境依存・探索コスト過大なら教える
迷ったら、答えと「自分ならどう調べたか」をセットで渡す
伝わらない時は前提の不一致を疑い、分からなかった単語を指してもらう
ペアプロは目的を決めて短時間。常時やると、1人で詰まって抜ける経験を奪う
教える側の罠は、自分のやり方の押しつけ・知識の呪い・「なんで分からないの」の3つ