採用してから「こんなはずじゃなかった」と気づく場面は、意外と多い。それは候補者側だけでなく、受け入れるチームの側でも起きています。

エンジニアが入社3ヶ月で辞める、本当の理由

「思っていた環境と違った」という離職理由は、採用広報の失敗として片付けられがちです。しかし実際に退職した人の話を聞くと、多くが「誰に聞けばいいかわからなかった」「何を期待されているのかが最後までつかめなかった」と語ります。

厚生労働省のデータでは、入社後1年以内の離職率は全職種で10〜15%。エンジニア職ではこの数字がさらに高くなる傾向があり、採用コスト（1人あたり50〜150万円ともいわれる）が入社3ヶ月で無駄になるケースは珍しくありません。しかし、その原因の多くは「ミスマッチ」ではなく「オンボーディング設計の欠落」にあります。

定着しないチームが省いている3つの設計

受け入れ側が整えていない共通点は、次の3つです。

1. 技術的な初速設計

コードベースの全体像を説明しないまま「このバグを直して」から始まる職場があります。初日から迷子にした状態で「自走してほしい」と言っても、人は動けません。入社2週間以内に「小さなPRをマージする体験」を意図的に設計することが、自信と帰属感の出発点になります。

2. 心理的な接続設計

「困ったら誰に聞いてもいい」は、裏を返せば「誰に聞けばいいかわからない」と同義です。質問先の人物・チャンネル・タイミングを明示した「接続マップ」を入社1週間以内に渡すだけで、不安なスタートが大きく変わります。

3. 期待値の可視化

30日・60日・90日後にどんな状態になっていてほしいかを、最初の1週間に言葉にして渡す。これがないまま進むと、メンバーも受け入れ側も「うまくいっているかどうか」を判断できないまま3ヶ月が終わります。

最初の90日を3つのフェーズで設計する

フェーズ期間リーダーがやること
足場を整えるDay 1〜14コードの地図を渡す、最初のPRをペアで進める
文脈につなぐDay 15〜30意思決定の場に同席させる、プロダクトの背景を共有する
自走の回路をつくるDay 31〜90少し背伸びのある仕事を任せる、振り返りの場を定期設計する

「放り込んで育てる」を美徳とする現場もありますが、設計なき放置は定着率を下げるだけです。新メンバーが「この組織で貢献できる」と感じる最初の体験を、意図的に作ることがリーダーの仕事です。

さいごに

あなたのチームに新メンバーが入ったとき、入社1週間後に「質問できる人の名前を3人言える状態」になっているでしょうか。オンボーディングは採用の延長です。入社後の90日を設計するかしないかで、定着率だけでなく、そのメンバーがその後チームに与える影響まで変わります。

チームビルディングや採用設計について相談したい方は、採用問い合わせからお気軽にご連絡ください。