最初の1週間を設計する

最初の1週間は、その後の数ヶ月の空気を決めます。 ここで「聞いていい人だ」「手を動かしていい場所だ」と伝わるかどうかで、 2週目以降に本人が出してくるアウトプットの量が変わります。

この章では、初日のタイムテーブルから最初の PR までを具体的に設計します。

初日のゴールは1つだけにする

初日に詰め込みたくなる気持ちは分かりますが、ゴールは1つに絞ってください。

初日のゴールは、コードを1行変えて、それが動いたのを本人の目で確認することです。

画面の文言を変える、ログを1行足す、何でも構いません。 重要なのは、自分の変更がこのプロダクトに反映されるという体験を初日に済ませること です。 これができていると、2日目以降の質問の質が変わります。 「どこを直せばいいですか」ではなく「ここを直すとここが動くはずなんですが」に変わります。

逆に、初日が説明を聞くだけで終わると、本人の頭に残るのは 「たくさん聞いたけど何も分からなかった」という感触だけになります。

初日のタイムテーブル例

10時始業として、1日をこう組みます。

時間	内容	担当	ねらい
10:00–10:20	挨拶・その日の流れの共有	メンター	今日のゴールを先に伝える
10:20–11:00	チーム紹介・担当の地図を渡す	メンター	誰に何を聞けるかを先に固定する
11:00–12:00	アカウント・権限の疎通確認	本人	事前発行分が本当に使えるか確認
12:00–13:00	昼食（誰かと一緒に）	チーム	雑談の入口を作る
13:00–15:00	環境構築（詰まったら30分で声かけ）	本人＋メンター	ローカルで起動できる状態
15:00–15:30	コードを1行変えて動かす	本人	初日のゴール
15:30–16:30	明日以降のタスクの説明	メンター	手持ち無沙汰を作らない
16:30–17:00	1日の振り返り（15分でよい）	2人	詰まりの初期検知
17:00	終了。残業させない	—	初日に無理をさせない

ポイントは3つです。

• 午前は設定作業、午後は手を動かす に分ける。集中力の高い午前を待ち時間で潰さない
• 環境構築は本人にやらせるが、30分詰まったら声をかける約束 を最初にしておく
• 最後の振り返りを必ず入れる。初日の不安は、その日のうちに拾うと軽い

何を教えて、何を教えないか

初週にアーキテクチャ全体を語り尽くすのは、親切に見えて逆効果です。 文脈のない情報は記憶に定着せず、「難しそうな場所だ」という印象だけが残ります。

判断基準はシンプルです。今週触る範囲に必要かどうか で切ります。

領域	初週に教える	初週は教えない
コード	今週触るディレクトリ1つの構造	全サービスの依存関係図
環境	ローカルでの起動とテスト実行	本番デプロイ手順、インフラ構成
プロセス	ブランチ → PR → レビュー → マージ	リリース計画、障害対応フロー
ドメイン	触る画面1つが何をするものか	用語集の全部、事業指標
人	まず聞く相手3人	全社の組織図

「教えない」は「隠す」ではありません。必要になった時に渡す ということです。 資料の場所だけ伝えて、「今は読まなくていいです」と明言してください。 これを言わないと、真面目な人ほど全部読もうとして、初週が読書で終わります。

到達点を3段階で決める

「立ち上がった」の基準が曖昧だと、本人も受け入れ側も現在地が分かりません。 1週目・2週目・1ヶ月で、判定できる形の到達点を決めます。

時期	到達点	判定方法
1週目	環境が動き、小さい PR が1本マージされている	PR のマージ履歴
2週目	小さい修正を、指示なしで最後まで進められる	レビューでの手戻り回数
1ヶ月	仕様が曖昧なタスクを、質問で詰めながら進められる	本人からの質問の内容

書き方のコツは、態度ではなく事実で書くこと です。

• 悪い例: 「チームに馴染む」「主体的に動く」——判定できません
• 良い例: 「PR が1本マージされている」「デイリーで自分から詰まりを言える」

とくに1ヶ月の到達点は、コード量ではなく質問の中身に出ます。 「どうすればいいですか」から 「A と B で迷っています。A だとこの点が心配です」に変わっていれば、 その人は自分で設計を考え始めています。これは強いシグナルです。

最初の PR を1週間以内に出す

初週で最も効くのが、これです。

目的は成果物の大きさではありません。 ブランチを切る → 実装する → PR を出す → レビューを受ける → 直す → マージする という一連の流れを、早く1周させることです。

1周すると、本人の中に次のものが残ります。

• このチームのレビューはどれくらいの粒度で指摘が来るのか
• どこまで自分で判断してよく、どこから相談すべきか
• CI で何が走り、何が落ちると止まるのか
• マージした後、それはいつ本番に出るのか

これらは説明で伝えても頭に入りません。1回通した人だけが体で覚えます。

最初の PR に向くタスク

向く	向かない
エラーメッセージの文言修正	既存機能の仕様変更
ログを1行追加する	複数サービスにまたがる修正
テストケースを1本足す	パフォーマンス改善
手順書の誤りを直し、関連コードも1行直す	「まだ誰も手を付けていない部分」

注意点として、ドキュメント修正だけの PR にしない でください。 コードに1行でも触れていないと、CI もレビューもデプロイも通らず、 「1周させる」という目的が達成できません。

歓迎を設計する

歓迎は気持ちの問題ではなく、設計項目です。次の3つを用意します。

1. 自己紹介の場

チャンネルに投稿するだけで終わらせず、話す場を作ります。 本人が話す時間は3分で十分ですが、チーム側も同じ形式で自己紹介する のが効きます。 「担当領域・最近やっていること・気軽に聞いていいこと」の3点で揃えると、 本人はその後、誰に何を聞けばいいか判断できます。

2. 担当の地図

組織図ではなく、「困った時に誰に行くか」の地図です。 初日に紙1枚（もしくはドキュメント1ページ）で渡します。

困りごと	まず聞く人	不在時
環境が動かない	メンター	チームの誰でも
コードの意図が分からない	その領域の担当者	メンター
仕様・受け入れ条件	プロダクト担当	メンター
労務・PC・権限	コーポレート窓口	—

「不在時」の列が重要です。メンターが休んだ日に止まらない ようにしておきます。

3. 雑談の場

雑談は業務外の贅沢ではなく、質問のハードルを下げる仕組みです。 初週は、意図的に雑談の機会を作ります。昼食、15分の雑談枠、何でも構いません。

リモートの場合

リモートは、放っておくと歓迎がゼロになります。意識的に補います。

• 初日は同期の時間を多めに取る。ずっと画面共有をつないでおく時間を数時間作る
• テキストだけで済ませない。声で話す機会を1日1回 は入れる
• 「困ったら言ってください」ではなく、こちらから定時に声をかける。初週は朝と夕方の2回
• 常時接続の音声チャンネルは、強制しない。監視されている感覚になる人もいる
• カメラの ON/OFF はチームのルールを先に伝える。判断を本人に丸投げしない

1つだけ選ぶなら、初週の毎朝15分、雑談込みの通話を固定する ことです。 議題がなくてもやります。議題がない日があること自体が情報で、 「今日は特にないです」と言えない人は、たいてい何かに詰まっています。

初週にやりがちな失敗

どれも善意から起きます。だから気づきにくいものです。

失敗	何が起きるか	代わりにやること
放置する	3日詰まっても誰も気づかない	朝夕2回、定時に声をかける
横に張り付きすぎる	考える前に答えが来る。試行錯誤が育たない	詰まったら30分で呼ぶ約束にして離れる
資料を大量に渡す	何が重要か分からず、読書で1週間が終わる	今週必要な3つだけ渡す。残りは場所だけ伝える
本番相当のタスクを渡す	前提知識が足りず、進捗ゼロで自信を失う	1行の変更から始めて段階的に上げる

放置と張り付きは正反対に見えますが、原因は同じです。 どこまで自分でやり、どこから聞くかの線引きを、本人に丸投げしている ことです。 線引きはこちらが決めて、言葉にして渡します。

具体的には、初日にこう伝えます。

「30分やって進まなかったら、調べ続けずに声をかけてください。 それは怠けではなく、こちらが手順書を直すべきサインです。 逆に30分以内は、まず自分で試してみてください。」

この一言があるだけで、放置と過干渉の両方が減ります。

ケーススタディ: 「順調」に見えた1週間

初日から真面目に取り組み、質問も少なく、渡した資料を全部読んだインターン生がいました。 金曜の時点で、チームの評価は「順調」でした。

2週目に入って分かったのは次のことです。

• 環境は動いていたが、自分で起動したことは一度もなかった（初日にメンターが動かした）
• 資料は読んだが、コードとの対応がつかず、用語だけ覚えていた
• 質問が少なかったのは理解していたからではなく、何が分からないか分からなかった から
• PR は1本も出していなかった。「まだ理解できていないので」と本人は言っていた

「順調」の根拠が、本人の態度 しかなかったのが問題でした。 態度は測りやすく、そして当てになりません。

この章のまとめ

• 初日のゴールは1つ。コードを1行変えて、動いたのを本人が確認する こと
• 午前は設定、午後は手を動かす。最後に15分の振り返りを必ず入れる
• 教える範囲は「今週触る範囲」に絞る。全体アーキテクチャは2〜3週目に回す
• 到達点は1週目・2週目・1ヶ月で分け、態度ではなく事実で判定する
• 最初の PR は1週間以内。目的は大きさではなく、マージまでを1周させること
• 歓迎は設計項目。自己紹介・担当の地図・雑談を用意し、リモートでは同期の時間を明示的に取る
• 放置と過干渉は同じ原因。どこから聞くかの線引きは、こちらが言葉にして渡す