複数人を同時に受け入れる

4月に3人、夏に2人。新人がまとまって入ってくる時期は、どのチームにもあります。 その時、多くのチームは「1人の受け入れを人数分やる」つもりで準備します。

しかし、人数が増えると必要な設計そのものが変わります。 この章では、複数人を同時に受け入れる時に何が別物になるのかと、 同期がいることを不利ではなく資産として使う方法を扱います。

3人の受け入れは、1人の受け入れ×3ではない

まず、増えないものを確認します。メンターの時間は人数に比例して増えません。 3人受け入れても、メンターの1週間は40時間のままです。

第7部で見たとおり、新人1人の受け入れはメンターの週8〜12時間を消費します。 これをそのまま3倍すると、週24〜36時間。もう本業が残りません。

だから、複数人の受け入れでは「1人分の運用を人数分やる」以外の設計が必要になります。 とはいえ、負荷は本当に3倍になるわけでもありません。項目によって伸び方が違うからです。

この表が、この章の設計方針をほぼ決めています。

• 増えない行は、まとめてやる（共通研修として切り出す）
• 人数倍になる行は、担当を分散させる（メンター1人に集めない）

「気合で3人見ます」は、人数倍の行を1人で抱えるという意味です。 第7部で書いたとおり、その時に削られるのはメンター自身の作業時間ではなく、 新人への応答速度です。 3人いれば、3人ぶん遅くなります。

同期がいることは、それ自体が資産

複数人の受け入れには、1人では絶対に手に入らない利点があります。 同期がいることです。 これは我慢すべき副作用ではなく、設計に使える資源です。

新人同士の方が質問しやすい

最大の利点はこれです。新人が新人に聞くとき、質問のコストが劇的に下がります。

第3部で扱ったとおり、新人が聞きに来ないのは 「時間を奪う」「低く見られる」という2つのコストが消えないからでした。 同期相手なら、この2つがほぼ消えます。

最後の行も重要です。1週間前に同じ場所で詰まった人は、 どこが分からないのかを説明しなくても分かってくれます。 メンターに聞くと「そもそも何が分かっていないのか」から説明する必要があります。

もちろん答えの正確さは落ちます。間違った理解が共有されることもあります。 それでも、黙って3時間詰まるよりは、同期に聞いて30分で半分進む方がましです。 正確さはレビューで直せますが、失われた3時間は戻りません。

設計で同期を使う

「仲良くなってくれるといいですね」で終わらせないでください。 放っておくと、席が近い2人だけが話すようになり、残りが孤立します。 次の3つは、初日から仕込めます。

1. 新人だけのチャンネルを作る

メンターや他のメンバーが入らないチャンネルを1つ作ります。 初日にこう伝えます。

ここは皆さんだけの場所です。私たちは見ません。 「これどうやりました？」「まだ環境構築終わってない」みたいな話に使ってください。

見ないと言ったら本当に見ないでください。1度でも覗くと、その場所は死にます。 第7部で「質問は公開チャンネルへ」と書いたのと矛盾するようですが、役割が違います。 公開チャンネルは記録と分散のため、新人チャンネルは言い出す前の段階を吐き出すためです。

2. 朝10分の相互共有

新人だけで、毎朝10分。メンターは同席しません。話す内容は3つだけです。

• 昨日どこまで進んだか
• 今日やること
• 今詰まっていること

メンターがいないので、「詰まっています」が言いやすくなります。 そして高い確率で、別の誰かが同じ場所で詰まっています。 「自分だけが遅れている」という誤解が、ここで潰れます。

3. 週1回の持ち回り共有（15分）

週に1回、新人の誰か1人が、その週に学んだことを他の新人に説明します。 15分で構いません。持ち回りなので、3人なら3週に1回です。

効果は2つあります。人に説明すると理解の穴が見つかること。 そして説明する経験を、失敗しても安全な場所で積めることです。

「同期に聞いた」を歓迎していると態度で示す

3つの仕組みを用意しても、新人が「同期に聞くのは手抜きでは」と考えていれば使われません。 だから、こちらから明示的に肯定してください。

• 「それ、誰かに聞いた？」を口に出す
• 「〇〇さんも先週そこ通ってたから聞いてみて」と、聞く先を指し示す
• 同期に聞いて解決した報告に「それでいいです」と一言返す

逆効果になるのが「それは私に聞いてくれれば早いのに」です。 善意で言っても、同期間の相談を止める効果しかありません。

共通で済むものと、個別に必要なもの

複数人の受け入れ設計の中心は、この切り分けです。 共通化できるものを個別にやると時間が足りず、個別に必要なものを共通化すると質が落ちます。

境界の見分け方は単純です。 「内容が人によって変わらない」ものは共通、「その人の状態に依存する」ものは個別です。

共通化の落とし穴

共通化は効率が良いので、やりすぎが起きます。典型的なのが座学の詰め込みです。

3人まとめて集められるからと、初週に説明会を並べたくなります。 しかし第2部で扱ったとおり、初週の敵は情報の不足ではなく情報の過多です。 人数が増えても、1人が1日に吸収できる量は変わりません。

• 共通研修は1日2時間まで。残りは手を動かす時間にする
• 説明した内容は、必ずその日のうちに使う機会を作る（聞いただけの知識は残らない）
• 質問が出ない共通研修は、届いていないと考える（3人いて質問ゼロは異常）

もう1つの落とし穴が、全員同席の時間を増やしすぎることです。 全員が集まる会議は、人数分の時間を一度に消費します。 3人×1時間は3人時間であって、1時間ではありません。 「全員に関係あるかもしれない」程度の話で全員を集めないでください。

一方で、共通研修には副産物があります。作った資料は次の受け入れでそのまま使えます。 1人の受け入れでは「この人のために資料を作る」の元が取れませんが、3人なら初回から取れます。 複数人の受け入れは、資料を整備する絶好の機会です。 第7部で書いたとおり、資料が正確になるのは新人がいる時期だけなので、 この機会を逃すと次の受け入れまで手つかずのまま残ります。

同じタスクを渡すか、別々に渡すか

複数人を受け入れる時、必ず判断が必要になる分岐です。どちらにも明確な利点と欠点があります。

結論から言うと、最初の1本は同じ、2本目以降は別々が扱いやすい形です。

最初の1本を揃える理由は、質問対応と相談の効率です。 環境構築や最初の小さな修正は、同じ場所で詰まるので、 1回の説明が全員に効き、同期同士の相談も成立します。

2本目から分ける理由は、当事者意識と成果です。 同じタスクを続けると「自分がやらなくても誰かが解く」が発生します。 そして何より、進度の差がそのまま全員の目に晒され続けます。

そして、同じタスクを渡す時に絶対にやってはいけないのが、速さの比較です。 「誰が一番早くできるかな」は、その場は盛り上がりますが、 遅い人が質問できなくなるという代償を払います。 競争中に助けを求めるのは、負けを認めることだからです。

同じタスクを渡すなら、最初に明示的にこう言ってください。

早さは見ていません。詰まったところを共有してくれる方が価値があります。

進度の差は必ず出る。それ自体は問題ではない

同じ日に入った3人が、1ヶ月後に同じ場所にいることはありません。 経験も、得意分野も、詰まり方も違うからです。差が出るのは正常です。

問題になるのは、差ではなく、差が引き起こす二次被害の方です。

最も避けるべきは3行目です。理由は単純です。 遅れは取り戻せますが、質問が止まった状態は検知できません。

遅れている人ほど質問が必要なのに、遅れているという自覚が質問を止めます。 「これ以上迷惑をかけられない」「今さらこんな初歩的なことは聞けない」—— 第3部で扱った質問のコストが、同期がいることで倍増します。

比較は、口に出した瞬間に壊れる

受け入れ側の一言が引き金になります。最悪なのがこれです。

〇〇さんはもう終わってるよ。

言った側には「発破をかけた」つもりがあります。 受け取った側に届くのは、「あなたは遅れている」という評価だけです。 そして次の瞬間から、その人は自分の状況を正直に報告しなくなります。

似た形は他にもあります。全部同じ害があります。

比較するなら、過去の本人と比べる

進度を見る基準は1つだけにしてください。本人と、過去の本人です。

• 悪い: 「〇〇さんはもう PR を3本出してる」
• 良い: 「先週は環境構築で止まってたけど、今週は自分でエラーを読めてますね」

過去の本人との比較には、他人との比較にない性質が2つあります。 必ず前進が見つかることと、本人が反論できないことです。 1週間前より何もできていない人は、まずいません。見つけて言葉にするのが受け入れ側の仕事です。

メンターをどう割り当てるか

複数人になると、メンターの割り当て方に選択肢が出ます。人数によって向き不向きが変わります。

実務では、組み合わせが現実的です。

• 技術的な質問の一次受け → 日替わり当番（チーム全体で回す）
• 1on1・進度の把握・評価 → 1対1の固定担当

第7部で扱った「技術メンターと相談相手を分ける」の延長です。 毎日の割り込みは分散させ、継続的な把握だけは固定の1人が持ちます。

1対1で分けるなら、メンター間の同期を取る

担当を分けると、必ず基準がずれます。 片方は細かくレビューし、もう片方はほぼ通す。片方は毎日30分見て、もう片方は週1回。

このずれは、新人側から丸見えです。 「自分のメンターは放置ぎみだ」は必ず伝わります。

対策は、メンター側の定例です。週15分で足ります。

• 各自の担当が今どこにいるか、一言ずつ
• 詰まりが3日を超えている人はいるか
• 渡しているタスクの難易度が揃っているか
• 明らかに手が足りていない担当はいないか

この場で「自分の担当が一番遅れている」と言えることが重要です。 メンター同士も比較を恐れます。新人の進度でメンターを評価しないと明言してください。

レビューが詰まる

複数人の受け入れで、最初に目に見えて壊れるのがコードレビューです。 理由は単純で、N 人分の PR が、同じ1人のレビュアーに集まるからです。

新人の PR は、通常の PR よりレビューに時間がかかります。 指摘が多く、往復が増え、説明を添える必要があるからです。 1本あたり30〜60分として、3人が週2本ずつ出せば、週6本。週3〜6時間がレビューだけで消えます。

そして、レビューが遅れた時の害は人数分に増えます。

レビュー担当をチームに分散させる

やることは1つです。メンター以外の人をレビュアーに入れてください。

• 新人の PR のレビュアーを、曜日か人でチーム内に割り振る（メンターに固定しない）
• 「新人の PR は24時間以内に一次返信」をチームのルールとして掲げる
• レビュアーが1人しか付いていない PR が翌日残っていたら、誰かが拾う

分散の利点は負荷だけではありません。

1. 複数の人のコードを見る目に触れる（1人のレビュアーの癖だけを学ばない）
2. チームの複数人が、新人のコードの傾向を知る
3. メンターが休んでも、PR が止まらない

ただし、分散には前提が1つあります。指摘の書き方が揃っていることです。 第5部で扱った「人ではなくコードを指摘する」「nit を明示する」が チームで共有されていないまま人を増やすと、 新人から見てレビュアーごとに厳しさが違うという不安が生まれます。 分散する前に、指摘のトーンだけはチームで揃えておいてください。

1人だけ遅れている時、集団と個別を分ける

Quiz で扱った状況は、複数人の受け入れで最も頻繁に起きます。 原則は1つです。集団の運用は変えず、個別の支援は個別の場でやります。

集団の運用を変えると、変更の理由が全員に伝わります。 「〇〇さんが遅れているから、進捗確認が厳しくなった」と読まれた時点で、 遅れている本人にとって最悪の状況になります。

遅れの中身を切り分ける

「遅れている」は症状であって、原因ではありません。 第6部で扱った切り分けを、ここでも使います。

• 詰まりが検知されていないだけ → 質問できていない。検知手段の問題
• タスクが本人に対して重すぎる → 割り当ての問題。難易度を下げる
• 前提知識が足りない → 学習の問題。共通研修で飛ばした部分がある
• 体調・生活・環境の問題 → 技術の話ではない。無理に技術の話にしない

複数人の受け入れで特有なのは、3つ目です。 共通研修は「全員が同じ前提を持っている」ことを暗黙に仮定します。 実際にはばらつきがあり、共通研修から零れた1人が、後から遅れとして表面化します。

だから、共通研修の直後に「分からなかったところ」を個別に確認してください。 全員の前で「分からない人？」と聞いても手は挙がりません。 1on1 で「今週の説明で、消化しきれてないところある？」と聞くと出てきます。

1on1 でも、他の人を引き合いに出さない

個別の場だから比較してよい、ということはありません。 1on1 で「みんなできてるよ」と言われるのは、全員の前で言われるのと同じか、それ以上に効きます。 逃げ場がないからです。

伝えるべきなのは、他人との差ではなく、こちらの期待値です。

• 悪い: 「みんなもう自分でエラーを読めてるよ」
• 良い: 「この規模の修正を2日で出せる状態を、1ヶ月後の目安にしています。今どのへんだと思いますか」

基準を人ではなく、期待値に置いてください。 人に置いた瞬間、それは順位になります。

運用チェックリスト

複数人を受け入れる前に、次の質問に答えられるか確かめてください。

1. 共通で済ませるものと個別に必要なものを、書き出して分けましたか
2. 共通研修は1日2時間以内に収まっていますか
3. 新人だけの場（チャンネル・朝の共有）はありますか。そこにあなたは入っていませんか
4. 新人 N 人の PR は、N 人以上のレビュアーに分散していますか
5. 「その人が今どこにいるか」を継続的に知っている人が、1人ずつに決まっていますか
6. 直近1週間で、あなたは新人同士を比較する発言をしませんでしたか
7. 一番質問が少ない人は誰ですか。その人の状況を説明できますか

7 に即答できない場合、その人がこの受け入れで最も危険な状態にあります。 質問が少ない人は、順調な人ではなく、見えていない人です。

最後に

この本は、新人を迎える側が何をするかをひととおり書いてきました。 準備、教え方、質問しやすさ、タスク、レビュー、1on1、うまくいかない時、チーム、そして制度。

書いてきたことは多いですが、根っこにあるのは一貫して同じ考え方です。

新人が伸びるかどうかを、本人の資質や気合の問題にしない。 質問しやすさは仕組みで作れる。詰まりは検知できる。レビューの遅さは分散で直せる。 進度の差は比較しないことで悪化を防げる。どれも受け入れ側が設計できる範囲にあります。

そして、全部を一度にやる必要はありません。 第7部で書いたとおり、うまくやろうとする前に、明らかな失敗を潰す。 それだけで、受け入れの問題の大半は消えます。

最後に1つだけ付け加えます。

あなたが今つくっている受け入れの仕組みは、目の前の新人のためだけのものではありません。 その新人は数年後、今度は迎える側に立ちます。 その時に真似されるのは、あなたが書いたドキュメントではなく、 あなたが質問に答えた時の態度です。

良い受け入れを経験した人が、良い受け入れをします。 それが、この本が最終的に狙っている唯一のことです。

この章のまとめ

• 3人の受け入れは1人の受け入れ×3ではない。メンターの時間は人数に比例して増えない
• 負荷が限界を超えると、劣化は平均ではなく最も声が小さい人に出る
• 同期がいることは資産。新人同士の方が質問しやすい（時間を奪う罪悪感が小さく、前提知識が近い）
• 同期を設計で使う。新人だけのチャンネル・朝10分の相互共有・週1の持ち回り共有。放っておくと比較の対象になる
• 共通（環境構築・チーム紹介・開発フロー）と個別（タスク割り当て・レビュー・1on1）を分ける。共通研修は1日2時間まで
• タスクは最初の1本は同じ、2本目以降は別々。同じタスクを競争にしない
• 進度の差は正常。問題は差ではなく、遅い側が質問しなくなること
• 「〇〇さんはもう終わってるよ」は最悪の一言。進度は本人と過去の本人で比べる
• メンター割り当ては、一次受けは日替わり当番、継続的な把握は1対1の固定担当という組み合わせが現実的
• N 人分の PR が1人に集まるとレビューが詰まる。レビュアーをチームに分散させる
• 1人だけ遅れている時は、集団の運用は変えず、個別の支援を個別の場でやる
• 良い受け入れを経験した人が、良い受け入れをします

参考資料