受け入れ前にそろえるもの | 新人を受け入れる技術

受け入れの成否は、初日より前にほぼ決まっています。初日に新人が手を動かせるかどうかは、その前の週に誰が何を準備したかの結果でしかありません。

この章では、新人が来る前の1週間でやることを、具体的な作業に落として書きます。

初日のゴールから逆算する

何を準備すべきかは、初日のゴールを決めれば自動的に決まります。おすすめは1つだけです。

コードを1行変更して、自分の手元で動いているのを見る

このゴールが効くのは、前週にそろえるものをここから逆算できるからです。

初日のゴール	そのために前週に必要なもの
コードを1行変更して動かす	リポジトリへのアクセス、環境構築手順、動く開発環境、変更していい場所
チームの全体像を理解する	（測れないので、準備の指針にならない）

「全体像を理解してもらう」のようなゴールは、達成したかどうかを誰も判定できません。判定できないゴールからは、準備の抜け漏れも検出できません。

この章で扱うのは、上の表の右側——前週までにそろえるものです。初日をどう進めるか、本人にどう伝えるかは、次章で扱います。

環境構築ドキュメントはなぜ腐るのか

環境構築の手順書は、ほぼ確実に腐ります。これは誰かがサボったからではなく、構造的にそうなるからです。

腐る4つの経路

1. 書いた人しか実行しない

手順書を書いた人は、すでに環境が動いています。その後その人が手順を最初から実行することは、まずありません。つまり手順書は、書かれた瞬間から誰にも検証されなくなります。

2. 差分を口頭で伝えて終わる

依存パッケージのバージョンが上がった時、チーム内は Slack の一言で足ります。

「あ、それ今週から Node 22 じゃないと動かないです」

その場では最速で、実際に解決します。ただし、解決したのはその人の環境だけです。手順書は古いままです。第1章で見たとおり、これが次の人に繰り越されます。

3. 各自の環境に「気づかない差分」が溜まる

手順書に書かれていないのに動いてしまう理由は、たいてい既存メンバーの環境にあります。

前のプロジェクトで入れたツールがたまたま入っている
昔手で作ったディレクトリや設定ファイルが残っている
環境変数がシェルの設定ファイルに書き込まれたまま忘れられている

これらは新品のマシンには存在しません。だから新人だけが失敗します。

4. 失敗しても手順書を直す動線がない

新人が詰まって聞きに来た時、直すべきは手順書です。しかし急いでいるので口頭で解決し、その場は終わります。 手順書を直す責任者が決まっていない限り、これは必ず繰り返されます。

対策は1つだけ

対策はいろいろ考えられますが、実際に効くのは1つです。

受け入れの直前に、受け入れる側が新品のマシンで手順書を最後まで通す

「新品のマシン」がここでの核心です。自分の慣れた環境で読み返しても、上の 3 の差分は絶対に見つかりません。読み返しは検証ではありません。

新品のマシンが用意できない場合は、次のいずれかで代用します。

手段	やり方	検出できるもの
新しいユーザーアカウント	OS に新規ユーザーを作ってログインし直す	シェル設定・環境変数・ホーム配下の残骸
コンテナ	まっさらなベースイメージから手順どおり実行	インストール済みツールへの依存
クラウド VM	数時間だけ立てて捨てる	上記ほぼすべて
新人の実機	初日に本人と一緒に通す	すべて（ただし初日が溶ける）

最後の行が、準備しなかった場合に起きていることです。

通す時のルール

通す作業には、守ると効果が変わるルールがあります。

手順書に書いてあることしかやらない。詰まっても、勘で補完しない
補完したくなった瞬間が手順書の欠落です。その場でメモする
所要時間を計る。「3時間かかる」と分かれば、初日の組み方が変わります
詰まった箇所はその日のうちに手順書へ反映する。翌日には理由を忘れます
コピペで実行できる形にする。「適宜読み替えてください」は新人には読み替えられません

「動くはず」で渡さない

手順書を書いた本人は、自分の手順書を過大評価します。これは能力の問題ではなく、自分の環境で動いている以上、動かない理由が想像できないためです。

「たぶん動くはず」で渡された手順書が最後まで動いたケースは、まず出てきません。通すのに半日かかったとしても、新人の初日1日とあなたの割り込み数時間より安く済みます。

なお、この作業は「定期的に見直す」ではなく、 受け入れが決まったら必ず通すというイベント駆動にしてください。手順書の鮮度は日単位で落ちるので、3ヶ月前に検証した手順書はまた腐っています。そして定期的なタスクは、忙しい時期に真っ先に飛びます。

アカウントと権限を先に発行する

初日が溶ける原因の第1位は、環境構築ではなくアカウントと権限です。環境構築は自力で進められますが、権限は待つことしかできないからです。

何日前に申請するか

社内の承認フローの長さは組織によって違いますが、考え方は共通です。

申請するもの	目安	理由
貸与 PC・入館証	2週間前	物理的な調達・郵送が絡むと最も遅い
メール・チャット・カレンダー	1週間前	他のサービスの招待先になるので最初に要る
ソースコード管理・チケット管理	1週間前	組織への招待は承認者が別部署のことがある
クラウド環境・ステージング	1週間前	権限設計のレビューが挟まると数日かかる
本番環境の閲覧権限	必要になった時	初日には不要。むしろ渡さない方がよい

日付そのものより、承認者が誰で、その人が不在の時に誰が代われるかを確認しておくことが重要です。申請が止まる原因は、たいてい承認者の休暇です。

「発行済み」を信じない

権限まわりで一番多い失敗は、発行したつもりで足りていないことです。

リポジトリは見えるが、ブランチを push する権限がない
チャットには入れるが、開発チャンネルに招待されていない
クラウドにログインはできるが、必要なプロジェクトが見えない
アカウントは作られているが、初回ログインの案内メールが本人に届いていない

これらは、発行した側の画面では「発行済み」に見えます。確認する方法は1つで、実際にその権限で操作してみることです。

初日の朝に確認しない

「初日の朝に全部そろっているか確認しよう」は、確認としては遅すぎます。足りないと分かっても、その日のうちに申請が通るとは限りません。

確認は初日の2〜3営業日前に済ませてください。不足が見つかっても、まだ埋められる余地があります。

メンターを指名する

「みんなで見る」は、誰も見ないことと同じです。新人から見ると、質問先が決まっていない状態は「全員に遠慮する」状態になります。

1人に集中させない

一方で、メンターを1人にするのも失敗します。理由は3つあります。

その人が休んだ日、新人は何も進められない
質問がすべて1人に集まり、その人の作業が細切れになる
新人が「この人に嫌われたら終わり」という状態になり、聞きにくくなる

現実的な形は、次のような役割分担です。

役割	担当	やること
メインメンター	1人	日々の質問対応、最初のタスクの設計、レビュー
バックアップ	1人	メインが不在・会議中の時の質問先
1on1 担当	1人（上長でもよい）	週1の振り返り、評価・キャリアの話

小さいチームなら、バックアップと 1on1 担当が同じ人でも構いません。重要なのは新人に「誰に聞けばいいか」が2人以上見えていることです。

メンターの工数を先に確保する

指名と同じくらい重要なのが、メンターの工数です。これを確保しないと、指名は「善意で頑張れ」という指示になります。

最初の2週間は、メンターの稼働の2〜3割を受け入れに割り当てる前提で計画してください。 1日8時間なら、1.5〜2時間分です。

チームのスプリント計画で、メンターの担当分を先に減らす
「新人対応」を作業項目としてチケット化する（見えないと減らされます）
メンターの当番・オンコールを、その2週間だけ外す

工数を減らさずに指名した場合に起きること

メンターは自分のタスクを守ろうとするので、質問への返信が後回しになります。新人は待ちます。待ちきれずに遠慮して、聞くのをやめます。

その結果として「新人がなかなか質問してこない」という現象が観測され、 本人の積極性の問題として記録されます。原因は工数配分です。

最初のタスクを事前に仕込む

初日から3日目までにやってもらうタスクは、来る前に決めておきます。「来てから様子を見て決める」と、最初の数日が確実に手持ち無沙汰になります。

タスクの選び方そのものは第4部で詳しく扱いますが、前週の準備としては次の3点を満たしておけば十分です。

1. 実物として存在している

チケットが起票され、URL があり、受け入れ条件が書かれている状態にします。「何かあったはず」という記憶の中のタスクは、渡す時に必ず整備し直すことになります。

2. 前提知識が要らない

ドメイン知識や設計の経緯を知らないと着手できないタスクは、最初には向きません。第1章のケーススタディで2週間溶けた原因がこれです。

3. あなたが答えを知っている

最初のタスクは、新人の実力を測る場ではなく、開発サイクルを1周させる場です。変更 → 動作確認 → PR → レビュー → マージまでを一度通すのが目的です。だからメンター側が正解を持っているタスクの方が、詰まった時に短時間で復帰できます。

予備を1つ用意しておく

最初のタスクが想定より早く終わることは、しばしばあります。そこで次のタスクが無いと、新人は「終わりました」と言った後、何をしていいか分からない時間を過ごします。

軽いものを1つ予備に置いておくと、この空白を防げます。

来週から新人が来ます。準備に使えるのは半日だけです。最も優先度が高いのはどれですか？

前週チェックリスト

まとめとして、いつ・何を・誰がやるかを表にします。自分のチームの承認フローに合わせて日数は調整してください。

いつ	何を	誰が
2週間前	貸与 PC・入館証を申請する	受け入れ担当・総務
2週間前	メインメンターとバックアップを決める	チームリード
1週間前	各種アカウントを申請する（承認者と代理も確認）	受け入れ担当
1週間前	メンターの稼働を2〜3割空ける（スプリント計画に反映）	チームリード
1週間前	最初のタスクを起票し、受け入れ条件を書く	メインメンター
3日前	まっさらな環境で環境構築手順を最後まで通す	メインメンター
3日前	詰まった箇所を手順書に反映し、所要時間を記録する	メインメンター
2日前	発行済み権限を実際に操作して確認する	受け入れ担当
2日前	初日のスケジュールを組み、関係者の予定を押さえる	メインメンター
前日	質問先（チャンネル・人）を新人に伝える準備をする	メインメンター
前日	予備のタスクを1つ用意する	メインメンター

この表をそのままチケットにする

チェックリストは、文書のままだと実行されません。受け入れが決まった時点で、上の行をそのままチケット化して担当と期限を入れてください。

次回以降はチケットを複製するだけになり、準備そのものが資産になります。

この章のまとめ

初日のゴールはコードを1行変更して動かすに絞る。判定できるゴールだけが準備の指針になる
環境構築ドキュメントは、書いた人しか実行せず、差分が口頭で流れ、既存環境の残骸に隠されるため、構造的に腐る
対策は受け入れの直前に、受け入れる側がまっさらな環境で最後まで通すこと。読み返しは検証ではない
アカウントと権限は待つしかないので先に申請する。発行済みの表示ではなく、実際に操作して確認する
メンターは1人に集中させず、バックアップを決め、稼働の2〜3割を先に空ける
最初のタスクは前週に起票しておく。予備を1つ持っておくと空白時間を防げる