新しい職場で最初の3ヶ月間、最もストレスになるのは「仕事の進め方がわからない」「誰に何を聞けばいいかわからない」という状況です。多くのエンジニアがこの"手探り期間"に消耗し、静かに辞めていきます。

最初の3ヶ月に、早期離職は起きている

中途採用エンジニアの離職データを見ると、退職の意思が固まるのは入社後30〜90日が最も多いとされています。スキルのミスマッチではなく、「この組織でどう動けばいいかわからなかった」「質問できる雰囲気がなかった」という理由が目立ちます。

問題は本人の適応力ではありません。組織が"着地の設計"をしていないことにあります。即戦力を期待するほど、受け入れ設計は後回しになりがちです。

「任せれば育つ」が機能しない構造的な理由

開発現場で根強いのが「仕事は現場で覚えるもの」という考え方です。ある程度は正しい。しかし、前提となる関係性や文脈の共有なしに「あとはよろしく」とタスクを渡しても、新人エンジニアが学べるのは技術ではなく「ストレス耐性」だけです。

もう一つの構造的な問題は、既存メンバーへの遠慮です。教える側も本業を抱えており、「なんとなく放置」が続くうちに、新人側の心理的距離が静かに広がっていきます。

3ヶ月で自走を生む、オンボーディングの3設計

1. 最初の2週間は「なじみタスク」から始める

難易度より"理解範囲が広がるタスク"を優先します。バグ修正でも機能追加でも、コードベース全体を読む必然性があるものを選ぶ。「わかった」という感覚が早期の自信を作ります。

2. 「教える人」より「壁打ち相手」を置く

技術的な正解を与えるより、「今どこで詰まっているか」を一緒に整理してくれる存在のほうが機能します。週1回30分、詰まり場所を声に出すだけで、停滞速度は明らかに変わります。

3. 30日・60日・90日の短期チェックポイントを設ける

「3ヶ月で一人前」は抽象的すぎます。30日で「コードベースを説明できる」、60日で「小機能を独立して設計できる」、90日で「レビューを出して議論できる」——3段階で目線を揃えると、本人も組織も進捗が見えやすくなります。

さいごに

オンボーディングの設計は、採用コストの回収にも、チームの生産性にも直結します。「入社後の3ヶ月に何が起きているか」を言語化できている組織は、まだ少ないのが現実です。

開発チームのカルチャーや育成の仕組みに関心がある方は、ぜひ気軽に話しかけてみてください。