チームとして受け入れる

ここまでの章は、ほとんどが「メンターが何をするか」の話でした。 最後の章は、その前提そのものを疑います。

受け入れがメンター1人の善意と体力で回っているうちは、 どれだけやり方がうまくても、次の受け入れは楽になりません。 この章では、受け入れをチームの仕組みに移し、次回に引き継ぐところまでを扱います。

メンターの工数は「余剰」ではない

受け入れが失敗する原因で最も多いのは、教え方でも人選でもありません。 メンターに元の仕事がそのまま残っていることです。

新人1人の受け入れにかかる時間は、最初の1ヶ月で概ねこのくらいです。

内容	週あたりの目安
質問への割り込み対応	3〜5時間
コードレビュー（往復が増える）	2〜3時間
1on1・デイリーの確認	1〜2時間
ドキュメント修正・タスクの仕込み	1〜2時間
合計	週8〜12時間

週40時間で働いているなら、工数の2〜3割です。 2ヶ月目以降は減っていきますが、最初の1ヶ月はこの水準を見込んでください。

問題は、この2〜3割がどこからも引かれていないことです。 スプリントの担当ポイントは前と同じ、オンコール当番も入ったまま、 その上に受け入れが乗ります。

唯一の現実的な解は、事前に減らすこと

やることは1つです。メンターの担当タスクを、受け入れが始まる前に減らす。

• スプリントの担当ポイントを、1ヶ月間は7割にする
• オンコール・障害対応の当番から、最初の2週間は外す
• 期日が動かせない案件のオーナーにしない
• 「減らした分は誰が持つか」をチームで決めてから受け入れを始める

これはメンターへの配慮ではなく、見積もりの修正です。 週8〜12時間を消費する作業が新しく発生するのだから、その分の枠を空けるのは当たり前です。 空けずに始めるのは、新しい案件を人員ゼロで着手するのと同じことをしています。

メンターを1人にしない

もう1つの構造的な問題は、受け入れが1人に集中していることです。 メンターが休んだ日に新人が止まるなら、その体制はすでに壊れています。

役割を2つに分ける

「メンター」という言葉が指す仕事は、実は性質の違う2つが混ざっています。

役割	見る対象	向いている人
技術メンター	コード、設計、レビュー、詰まりの解消	同じ領域を触っている人
相談相手（バディ）	働き方、人間関係、不安、評価への疑問	別チームでもよい／年次が近い人

分ける理由は、同じ人に両方は言いにくいからです。 「このタスク、正直きついです」を、自分のコードをレビューする人に言うのは難しい。 評価に響くのではないかと考えるからです。

年次が1〜2年上の人がバディに入ると効きます。 詰まった記憶がまだ新しく、「それ、自分も分からなかったです」が言えるからです。

日替わり当番にする

技術的な質問先は、1人に固定せず当番制にします。

• 月〜金で担当を割り当て、その日の一次受けを決める
• 当番の日は「割り込まれる日」として、深い作業を入れない
• 答えられない質問は、当番が適任者につなぐ（新人に探させない）

効果は3つあります。1人あたりの負荷が5分の1になること、 新人が複数の人と話す機会を持てること、 そしてチームの複数人がコードベースの穴を知ることです。

質問先を公開チャンネルにする

質問を個人 DM で受けるのをやめて、公開チャンネルに移してください。 これは今日から実行できて、効果が最も大きい変更です。

	個人 DM	公開チャンネル
答えられる人	その1人だけ	手が空いている人全員
メンター不在時	止まる	誰かが拾う
記録	本人しか見られない	残る
次の新人	同じ質問を最初からする	検索して自己解決できる

新人が DM を選ぶのは、「全員の前で聞くのが怖い」からです。 だから、置き場所を用意するだけでは移りません。次の2つがセットで要ります。

1. 受け入れ初日に「質問はこのチャンネルに書いてください」と場所を明示する
2. 最初の数回、メンターが公開チャンネルで丁寧に答える（DM で来たら「ここに書き直してもらえますか」ではなく、自分でチャンネルに転記して答える）

「こんな初歩的なことを公開の場で聞いていいのか」への答えは、 説明ではなく、実際に初歩的な質問に丁寧な回答がついている履歴です。

なお、「メンターが休んだら新人が止まる」は、 「その人が抜けたらチームが止まる」の小さい版です。 受け入れの分散は新人のためだけの施策ではなく、 チームの属人化を測るリトマス試験紙でもあります。 受け入れを1人に任せきりにしているチームは、たいてい他の領域でも同じことをしています。

質問はドキュメントの穴の報告である

新人が質問してくるということは、その情報がどこにも書かれていないということです。 これは新人の準備不足ではなく、ドキュメントの不足の報告です。

ここで回すべきループは1つだけです。

質問に答えたら、その内容をドキュメントに書く

答えて終わりにすると、同じ質問が次の人からも来ます。 第1章で書いた「入社のたびに再発する固定費」は、ここで作られます。

やり方は重くしないでください。完璧な文書は要りません。

• 既存のドキュメントに2〜3行追記するだけでよい
• 置き場所が無ければ、チャンネルの回答に見出しをつけて残すだけでもよい
• 「後でまとめて書く」はまとめて書かれません。答えた直後にやる

書くのは新人自身が最も効率が良い

追記の作業は、メンターではなく新人本人に振ってください。

理由は工数の分散ではありません。視点が違うからです。

	メンターが書く	新人が書く
前提知識	無意識に省略する	省略できない（自分が知らなかったので）
何が分かりにくいか	もう思い出せない	まさに今つまずいた場所
工数	メンターの時間を使う	新人の学習として成立する

初見の視点は、その人につき一度しか手に入りません。 入って3ヶ月経った人には、もう「どこが分からなかったか」は書けません。 だから、分からなかった直後に書いてもらうのが唯一のタイミングです。

新人にとっても悪い話ではありません。 入って数日で「チームのドキュメントを改善した」という貢献が形になり、 最初の PR の題材にもなります。

リモートでの受け入れ

リモート前提のチームでは、これまでの話に加えて1つ前提が変わります。 偶然の会話が起きません。

オフィスでは、隣の席の様子から「詰まっていそうだ」が伝わり、 昼食や休憩でチームの雑談に混ざれました。 リモートでは、この経路が全部消えます。 消えたものは、意図的に作り直すしかありません。

起きなくなるものと、その代替

消えるもの	代替として置くもの
隣の席の様子で詰まりに気づく	デイリーで「今どこ？」を毎日聞く／分報
雑談で人となりを知る	週2回15分の雑談枠（議題なしと明示する）
画面をのぞいて助ける	週1回60分の画面共有／モブの時間を固定で確保
会議の後の立ち話	会議終了後5分、退出しない時間を作る

重要なのはカレンダーに入れることです。 「困ったらいつでも声をかけて」と同じで、枠がないものは発生しません。 特に画面共有の時間は、テキストの質問だけでは絶対に見つからない詰まり （そもそも手順を1つ飛ばしていた、エラーを読んでいなかった等）が一度で見つかります。

テキストは温度が伝わらない

もう1つの問題は、リモートのやり取りがほぼテキストになることです。

対面なら口調と表情で緩和されていた指摘が、テキストだと素のまま届きます。

• 「これ、なんでこうしたんですか？」 → 詰問に読める
• 「ここ直してください」 → 突き放しに読める
• 既読がついて無反応 → 怒っていると解釈される

対策は、テキスト側で明示的に補うことです。

1. 意図を書く。「理由を知りたいので聞きます」「これは nit なので直さなくても通します」
2. 絵文字・リアクションを使う。軽い肯定が伝わる手段が他にありません
3. 読んだことを示す。すぐ答えられない時ほど「見ました、夕方に返します」と1行返す
4. 往復が3回を超えたら通話にする。テキストで解けない話をテキストで続けない

受け入れが終わったら、次の準備をする

受け入れが一段落した時点（目安は1〜2ヶ月後）で、必ず本人に振り返りを聞いてください。 30分で足ります。

何を聞くか

• どこで一番詰まりましたか（時間を溶かした場所の特定）
• 何があれば早く進めましたか（不足していた資産の特定）
• 最初の1週間で、要らなかったと思うものはありますか（過剰な情報の特定）
• 聞きにくかったことはありますか。あるとしたら、それはなぜですか

最後の質問は答えにくいので、「ある前提」で聞くのがコツです。 「聞きにくいことはなかった？」ではなく「どういう時に聞きにくかったですか」と聞きます。

数字で比較する

第1章で挙げた指標を、受け入れのたびに記録してください。

指標	記録するもの
初日に手を動かせるまでの時間	環境構築完了〜1行変更が動くまで
最初の PR までの日数	入社日〜最初の PR 作成
最初の PR のマージまでの日数	レビュー体制の健康度が出る
レビューの初回返信までの時間	24時間を超えているかどうか
3日以上詰まった回数	検知の仕組みが働いているか

数字が要るのは、報告のためではありません。 前回と比べるためです。

「今回は初日のセットアップが6時間かかった。前回は2日だったので改善した」 「最初の PR までが12日。前回より延びた。原因はタスクの粒度が大きすぎたことだった」

このくらいの粒度で構いません。測っていないものは、改善したかどうかが分かりません。 そして分からないものは、次も同じやり方で繰り返されます。

明らかな失敗だけは避ける

最後に、この本全体の立場をもう一度書いておきます。

受け入れに唯一の正解はありません。 答えを教えるべきか、どこまで任せるべきか、どのくらいの頻度で声をかけるべきか—— これらは相手にもチームにも状況にも依存します。 この本に書いたことも、あなたのチームでそのまま当てはまるとは限りません。

一方で、状況によらず失敗と言えるものはあります。

• 3日詰まっているのに、誰も気づかない
• レビューが1週間返らない
• 最初のタスクが、2週間ドキュメント修正だけ
• 質問先がメンター1人しかなく、その人が休むと止まる
• メンターの担当タスクが受け入れ前と同じまま

これらはどれも、難しい判断を必要としません。 気づいて、決めて、やめるだけです。

そして、これらを潰した時点で、受け入れの問題の大半は消えます。 残るのは「もっと良くできたかもしれない」という改善の余地であって、 「なぜあの人は伸びなかったのか」という取り返しのつかない話ではありません。

うまくやろうとする前に、明らかな失敗を潰してください。 順序はいつもこちらが先です。

この本を読み終えた後、全部を一度にやろうとしないでください。1つで構いません。 次の受け入れまでに1つだけ変えるなら、 質問先を公開チャンネルにするか、 メンターの担当タスクを2割減らすのどちらかをおすすめします。 どちらも今日決められて、効果が最も大きい部類です。

この章のまとめ

• 受け入れはメンターの工数を週8〜12時間（2〜3割） 消費する。気合で両立させず、担当タスクを事前に減らす
• 本人は「大丈夫です」と言う。マネージャー側が先に減らすのが正しい順序
• メンターを1人にしない。技術メンターと相談相手を分け、質問の一次受けは当番制にする
• 質問先は個人 DM ではなく公開チャンネルに置く。他の人が答えられ、記録が残り、次の新人が検索できる
• 新人の質問はドキュメントの穴の報告。答えたら書く。書くのは新人自身が最も効率が良い
• リモートでは偶然の会話が起きない。雑談枠・画面共有・意図の明示をカレンダーと運用で作り直す
• 受け入れ後に本人へ振り返りを聞き、指標を記録して前回と比較する
• 資料が正確になるのは、新人がいる時期だけ
• うまくやろうとする前に、明らかな失敗を潰す。この本が一貫して言っているのはそれだけです