新人を受け入れる技術

3ヶ月を過ぎたら

この部の 1 / 4 章 ・ 全体で 19 / 22 章 ・ 読了目安 25 分

この章を読むとできるようになること
  • 停滞のサインに気づける
  • レビューする側に回す設計ができる
  • 「もう自分で判断していい」を明示できる

この本のほとんどは、最初の3ヶ月について書いてきました。 実際、受け入れの設計はそこに集中します。

しかし、その後に空白ができます。

3ヶ月:  歓迎され、丁寧に教わり、毎週 1on1 がある
6ヶ月:  「もう慣れたよね」で、1on1 が隔週になる
1年後:  何を目標にすればいいか分からないまま、日々のタスクをこなしている

離職や伸び悩みが顕在化するのは、たいていこの時期です。 手厚い時期が終わった後にこそ、設計が要ります。

「慣れた」の中身を確認する

3ヶ月経つと、表面上は自走しているように見えます。

□ 環境構築で詰まらない
□ 小さなタスクは自分で終えられる
□ 質問が減った

しかし、質問が減った理由は2つあります。

1. 分かるようになった          ← 望ましい
2. 聞きにくくなった / 諦めた    ← 危険
質問が減ったら、中身を確認する
□ 「最近あまり質問が来ないけど、詰まってない?」
□ 「今、一番分かっていないと感じるのはどこ?」
□ 「調べても分からなかったこと、最近あった?」

「順調です」で終わらせないでください(第3部)。

特に、「聞くと迷惑をかける」と学習してしまった場合、 表面上は静かなまま、内側では停滞が進みます。

この時期に起きること

症状背景
飽き・停滞感同じ難易度のタスクを繰り返している
成長実感が無い伸びているのに、測る基準が無い
役割が曖昧「新人」ではなくなったが、何者かは決まっていない
周囲との比較同期や中途入社の人と自分を比べ始める
キャリアの不安この会社で何になれるのかが見えない

技術的な問題ではなく、ほぼすべて「見通しの問題」です。

任せる範囲を広げる

最初の3ヶ月は「実装」を任せていました。次はその前後を渡します。

3ヶ月まで:  仕様が決まったタスクを実装する
     ↓
次:         仕様の曖昧さを自分で潰す(誰に聞くかを含めて)
     ↓
次:         設計から任せる(レビューは受ける)
     ↓
次:         見積もりと段取りを任せる
     ↓
次:         他の人のレビューをする
     ↓
次:         後輩に教える
「レビューする側」に回すのが効く

自分のコードを書くだけでは見えなかったものが、 他人のコードを読むと見えます。

□ 読みにくいコードが、なぜ読みにくいかを言語化できる
□ 「自分もやっていた」と気づく
□ 説明する力がつく

いきなり承認権を渡す必要はありません。 「レビューは2人で。1人は必ず本人」という形から始められます。

そして受け入れ側にとっても、レビューの分散になります(第7部)。

目標を、本人と一緒に作る

3ヶ月を過ぎたら、与えられる側から、決める側へ少しずつ移します。

□ 半年後にどうなっていたいかを聞く
□ そのために必要な経験を、一緒に洗い出す
□ 実際のタスクに落とす(「次の案件で設計を担当する」など)
「何かやりたいことある?」では出てこない

新人は、選択肢を知りません。

✕ 「今後どうなりたい?」
○ 「うちだと、こういう方向があるよ」と選択肢を並べてから聞く
□ 技術を深める(特定領域の専門性)
□ 幅を広げる(フロント/インフラ/データ)
□ 設計・アーキテクチャに寄る
□ 人やプロジェクトを動かす側に寄る
□ プロダクトや事業に近づく

具体的な人の例を挙げると、さらに伝わります。 「◯◯さんは3年目でこうなった」という実例が、最も想像しやすい情報です。

停滞のサインを見る

□ 同じ種類のタスクばかりを、こちらが渡し続けていないか
□ 難しいタスクを、こちらが巻き取り続けていないか
□ 本人が「これは自分の仕事ではない」と線を引き始めていないか
□ 目に見えて口数が減っていないか
巻き取りすぎに注意

第4部で「手放す判断と巻き取る判断」を扱いました。 この時期に多いのは、巻き取りすぎのほうです。

□ 締め切りが近い → こちらがやったほうが速い
□ 難しい → 失敗させたくない
□ 品質が心配 → 自分で書き直す

すべて善意ですが、成長の機会を奪っています。

失敗してよい範囲(本番影響が小さい・戻せる)を用意して、 そこは最後まで本人にやらせる設計が必要です。

インターンの場合

期間が決まっているぶん、この「3ヶ月後」が終盤にあたることがあります。

□ 残り期間で、何を持ち帰ってほしいかを再確認する
□ 「完結する成果」を1つ作る(第8部)
□ 終わり方と、その後の関係を設計する(第8部)

長期インターンで期間が続く場合は、社員と同じ考え方で構いません。 むしろ「学生だから」で任せる範囲を狭めると、本人の成長も止まります。

受け入れ側の卒業

いつまでもメンターが付いている状態は、健全ではありません。

□ 1on1 の頻度を、本人と相談して調整する(無くすのではなく、目的を変える)
□ 質問先を、メンターからチーム全体へ広げる
□ 「これはもう自分で判断していい」の範囲を明示する
「もう聞かなくていい」を明示する

新人は、いつまで確認すべきかを判断できません。

「この規模の変更は、もう自分の判断で進めていいよ。
 迷ったら聞いて。判断が分かれそうなものだけ相談して」

この一言で、本人の動き方が変わります。 逆に言わないと、いつまでも確認を取り続けるか、 勝手に判断して怒られるかの二択になります。

受け入れを振り返る

その人の受け入れが一段落したら、次の受け入れのために記録を残します (第7部)。

□ 何がうまくいったか
□ 何が足りなかったか(本人に聞くのが最も正確)
□ ドキュメントのどこが不足していたか
□ 最初のタスクは適切だったか
□ 期待値のずれはどこで生まれたか

本人に聞くのが最も価値のある情報です。 そして「あなたの経験が、次の人のために使われる」と伝えると、 本人にとっても貢献の実感になります。

受け入れから3ヶ月が経ちました。環境構築で詰まることもなく、小さなタスクは自分で終えられ、質問もほとんど来なくなりました。この状況をどう読むべきでしょうか?

この章のまとめ

  • 手厚い時期の後に空白ができる。離職や伸び悩みはここで顕在化する
  • 質問が減った理由は2つ。「分かった」のか「聞けなくなった」のかを確認する
  • この時期の問題は技術ではなく、ほぼ見通しの問題
  • 任せる範囲を実装 → 仕様 → 設計 → 見積もり → レビュー → 教えると広げる
  • レビューする側に回すと、書くだけでは見えないものが見える
  • 目標は本人と一緒に作る。ただし選択肢を並べてから聞く
  • この時期に多いのは巻き取りすぎ。失敗してよい範囲を用意する
  • 「もう自分で判断していい」を明示する。言わないと確認を取り続ける
  • 一段落したら本人に振り返りを聞く。次の受け入れが楽になる

参考資料

対象リンク
Google re:Work(マネジメントの実践)https://rework.withgoogle.com/
Google re:Work: 1on1 の進め方https://rework.withgoogle.com/guides/managers-coach-managers/
厚生労働省 キャリア形成支援https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/jinzaikaihatsu/index.html
新人側の教科書「エンジニアとしての立ち振る舞い」https://learning-it-skills.makoto-developer.net/chapters/engineer-conduct/
読み終わったら記録しておくと、目次で進み具合が分かります。