はじめに——最初の90日が、その後の3年を決める
新卒でエンジニアとしてテック企業に入社する。 期待と不安が入り混じるその瞬間から、見えない時計が動き始めている。
最初の90日間。 この期間に築いた習慣と信頼が、その後のキャリアの土台になる。 逆に言えば、この90日で躓くと、リカバリーには想像以上の時間がかかる。
これは精神論ではない。 組織心理学の研究でも、入社後90日間のオンボーディング体験が、その後の離職率とパフォーマンスに強い相関を持つことが示されている。 Glassdoorの調査によれば、充実したオンボーディングを経験した新入社員は、そうでない場合に比べて3年以内の離職率が82%低下する。
ただし、「充実したオンボーディング」を提供してくれる企業ばかりとは限らない。 メンターがいない。ドキュメントが古い。誰に何を聞けばいいかわからない。 そんな環境でも、自分の力で最初の90日を乗り切るための戦略がある。
第1フェーズ（1〜30日）: 観察と理解の30日間
入社直後の30日間で最も大切なのは、「いきなり成果を出そうとしない」ことだ。 意外に聞こえるかもしれない。 だが、ここで焦って的外れな提案やコードを書くと、「状況を読めない人」という印象を初日から植えつけてしまう。
最初の30日間は「観察期」と位置づける。 やるべきことは明確だ。
- コードベースを読む: 自分が配属されたチームのリポジトリを、まずはひたすら読む。動いているコードが最高のドキュメントだ。アーキテクチャ、命名規則、テストの書き方。チームの「お作法」を体で覚える
- 会議を観察する: スプリントプランニング、レトロスペクティブ、デザインレビュー。発言は最小限でいい。誰がどんな役割を担い、意思決定がどう行われているかを観察する
- 社内ドキュメントを掘る: Confluenceでも Notionでも Google Docsでも、チームのドキュメント置き場を探して読み込む。古い設計判断の経緯がわかることも多い
- 人間関係のマップを描く: 誰が技術的な意思決定者か。誰がドメイン知識を持っているか。困ったとき誰に聞けばいいか。この地図は、後で何度も自分を助けてくれる
この期間に意識してほしいのは、「無知は武器になる」ということだ。 新人だからこそ聞ける質問がある。 「なぜこの設計になっているのですか」「このレガシーコードの背景は何ですか」。 ベテランには聞きづらいことも、新人なら自然に聞ける。 その特権を使い切ってほしい。
「質問の技術」を最初に磨く
新卒エンジニアの生死を分けるスキルの一つが、「質問の仕方」だ。 よく言われる「5分調べて3分まとめて聞く」というルールには合理性がある。
悪い質問の例を見てみよう。
「このエラー、よくわからないんですけど、どうすればいいですか？」
これでは相手が一から状況を把握しなければならない。 良い質問はこうなる。
「○○のAPIを叩いたときに403エラーが返ります。ドキュメントを確認したところ認証トークンの有効期限が原因かと思いましたが、トークンの再発行を試しても解消しません。環境変数の設定を疑っていますが、この方向性で合っていますか？」
違いは明白だ。 後者は「何を試したか」「どこまで理解しているか」「何が知りたいか」が明確になっている。 相手は的確なヒントを返すだけで済む。
質問力は、技術力と同じくらいキャリアを左右する。 最初の30日間で、この筋肉を徹底的に鍛えてほしい。
第2フェーズ（31〜60日）: 小さな貢献を積み重ねる
30日間の観察期を終えたら、次の30日間は「貢献期」に移行する。 ここからは、実際に手を動かしてチームに価値を提供していく。
ただし、いきなり大きな機能を任されることは少ない。 最初の貢献は、小さなものでいい。
- Good First Issue: 多くのチームが、新人向けのタスクを用意している。バグ修正、テスト追加、ドキュメント更新。地味だが、コードベースに触れる最良の入口だ
- テストを書く: テストカバレッジが低いコードにテストを追加する。プロダクションコードの理解が深まるうえ、チームから感謝される。一石二鳥だ
- ドキュメントの穴を埋める: 新人の目で見て「ここがわからなかった」という部分は、そのままドキュメントの改善点になる。READMEの更新やセットアップガイドの追記は、地味だが高い評価につながる
コードレビューの受け方——防衛反応を抑える
この時期に避けて通れないのが、コードレビューだ。 自分の書いたコードに赤い指摘がびっしりつく。 新人にとって、これは想像以上にキツい体験だ。
まず理解してほしいのは、コードレビューのコメントは「あなた自身」への批判ではないということだ。 レビュアーが指摘しているのは「コード」であって、「あなたの能力」や「あなたの人格」ではない。 ここを混同すると、防衛反応が生まれる。
防衛反応のパターンはいくつかある。
- 「前のプロジェクトではこうやっていました」と言い訳する
- 指摘に対して長文で反論する
- 修正リクエストに渋々従い、不満を態度で示す
- レビュー自体を避けるため、PRを小出しにしなくなる
どれも自然な反応だが、どれもキャリアにとってマイナスに働く。
代わりに実践してほしいのは、「感謝してから質問する」パターンだ。
「指摘ありがとうございます。この部分、○○という理由でこう書いたのですが、△△のアプローチのほうがこのコードベースでは一般的ということでしょうか？」
感謝で始めることで、対話のトーンが建設的になる。 そのうえで、自分の意図を説明しつつ、相手の提案を理解しようとする姿勢を見せる。 この一連の流れが、レビュアーとの信頼関係を築く。
もう一つ、コードレビューで意識してほしいことがある。 「指摘の内容をメモして、同じ指摘を二度受けないようにする」ことだ。 一度目の指摘は学習。二度目の指摘は注意不足。三度目になると、信頼を損なう。 Notionやメモアプリに「レビュー指摘ログ」を作り、チェックリストとして活用するのが効果的だ。
第3フェーズ（61〜90日）: 信頼貯金を積み上げる
入社から2ヶ月が経過すると、周囲の目は変わり始める。 「新人」から「チームメンバー」への移行期だ。 この時期の目標は、「信頼貯金」を着実に積み上げることにある。
信頼貯金とは何か。 簡単に言えば、「あの人に任せれば大丈夫」と思われる度合いのことだ。 これは一発の大きな成果ではなく、日常の小さな行動の積み重ねで増える。
- 約束を守る: 「金曜までにPR出します」と言ったら、金曜までに出す。間に合わないなら、早めに伝える。納期を守れる人だという評判は、技術力以上に重要だ
- 報告を怠らない: 進捗が遅れているとき、問題にぶつかったとき。悪いニュースほど早く共有する。隠したり先延ばしにしたりすると、問題が大きくなったときに信頼を一気に失う
- 他人のコードレビューに参加する: まだ新人でも、レビューに参加してコメントすることは可能だ。「ここの処理、自分の理解だと○○ですが合ってますか？」程度でいい。レビューは最高の学習機会であり、チームへの貢献でもある
- 1on1を戦略的に使う: マネージャーとの1on1を「報告の場」ではなく「フィードバックを求める場」として使う。「いまの自分に足りていないのは何ですか」「改善すべき点は何ですか」。この質問ができる新人は、成長速度が段違いだ
1on1で聞くべき3つの質問
1on1の時間は限られている。 だからこそ、準備して臨みたい。 新人エンジニアが必ず聞くべき質問を3つ挙げる。
一つ目は「自分の現在地」に関する質問だ。 「いまの自分のパフォーマンスは、この時期の新卒として期待されるレベルに対してどのあたりですか」。 抽象的な「がんばってるね」ではなく、具体的な位置づけを求める。
二つ目は「優先順位」に関する質問。 「次の1ヶ月で、自分が最も注力すべき技術領域やタスクは何ですか」。 チームのニーズと自分の成長を重ねるポイントを見つけるための質問だ。
三つ目は「キャリア」に関する質問。 「このチームで2年目を迎えるとき、どんなスキルセットを持っていることが期待されますか」。 中期的なゴールが見えると、日々の学習にも方向性が生まれる。
よくある失敗パターン——先輩たちの屍を越えてゆけ
ここまで「やるべきこと」を書いてきた。 ここからは、逆に「やりがちだが避けるべきこと」を紹介する。 先輩エンジニアたちが踏んできた地雷を、あらかじめ知っておくだけで回避率は格段に上がる。
失敗パターン1: 完璧を目指して何も出さない
新人にありがちな罠だ。 「もっとキレイに書いてから出したい」「もう少しテストを追加してから」。 完璧を追求するあまり、PRを出すのが遅くなる。
現実のソフトウェア開発では、70%の完成度で早く出すほうが、100%を目指して遅く出すよりも評価される。 理由は単純で、早く出せばフィードバックも早く得られるからだ。 方向性が間違っていた場合、早期に修正できる。 「Draft PRを先に出して、方向性を確認してから磨き上げる」が正解だ。
失敗パターン2: 質問しない（できない）
「こんなことも知らないのかと思われたくない」。 この恐怖から質問を避け、一人で抱え込む。 結果、2時間で解決できた問題に2日かけてしまう。
先に述べた「5分調べて3分まとめて聞く」を徹底すれば、この問題は大幅に軽減される。 そして、質問しないことで失われる時間のほうが、質問することで受ける（想像上の）評価の低下よりも、はるかにコストが高い。
失敗パターン3: 技術にだけフォーカスする
エンジニアだから、コードが書ければいい。 この考え方は、短期的には正しいが、長期的には限界がある。 ソフトウェア開発はチームスポーツだ。 コミュニケーション、ドメイン知識、ビジネス理解。 技術以外の筋肉も同時に鍛えることが、3年目以降の伸びを決める。
失敗パターン4: 比較に溺れる
同期のAさんはもうfeatureブランチを任されている。 Bさんは入社1ヶ月でチームに表彰された。 SNSを開けば、同世代のエンジニアが副業で月50万円稼いでいる。
比較は成長の大敵だ。 スタート地点も、配属されたチームも、担当するプロダクトの複雑さも、すべて違う。 意味があるのは「昨日の自分」との比較だけだ。
90日後の自分に向けて——成長のスイッチは自分で入れる
最初の90日が終わったとき、あなたは何を手にしているだろうか。
コードベースの理解。 質問の技術。 コードレビューの経験。 チーム内の信頼関係。 そして、「自分はこの環境でやっていける」という静かな自信。
どれも、入社前にはなかったものだ。 それを90日で手に入れたのなら、十分に健闘したと言っていい。
一方で、90日はあくまでスタートラインだ。 エンジニアとしてのキャリアは長い。 技術は変わる。組織も変わる。自分の興味も変わる。 最初の90日で身につけた「学び方」そのものが、その先の武器になる。
最後に一つだけ。 成長のスイッチは、会社が入れてくれるものではない。 自分で入れるものだ。 待っていても、誰も押しに来てはくれない。
いま、あなたの90日間のうち何日目にいるだろうか。 そして明日、何を一つだけ変えてみるだろうか。
