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/ |