なぜ最初の90日が重要なのか
4月。新しいIDカードを首からぶら下げ、見慣れないオフィスに足を踏み入れる。
その瞬間から、あなたのエンジニアとしてのキャリアは動き始めている。
「最初の90日」という数字には根拠がある。
ハーバード・ビジネス・スクールのマイケル・ワトキンス教授が著書『The First 90 Days』で提唱した概念で、新任リーダーが組織に適応し成果を出すまでの臨界期間を指す。
エンジニアにとっても同じだ。
最初の3ヶ月で得た評価は、その後1年以上にわたってあなたに貼り付く。
「あの新人、キャッチアップが早い」と思われるか、「まだ慣れてないみたいだね」と言われるか。
その分岐点は、才能ではなく戦略にある。
新卒エンジニアと中途採用の違い
新卒で入社する場合、技術力よりも「組織への溶け込み方」が問われる。
すでにコードを書ける人は山ほどいる。差がつくのは、チームのコンテキストを理解するスピードだ。
一方、中途採用の場合は「前職のやり方」を一度リセットできるかが鍵になる。
前の会社では正解だったアプローチが、新しい環境ではアンチパターンかもしれない。
90日をフェーズに分ける理由
90日を漫然と過ごすのと、30日ごとのフェーズに分けて意識するのとでは結果がまるで違う。
本記事では以下の3フェーズで整理する。
- 第1フェーズ（1〜30日）: 環境の把握と信頼の土台づくり
- 第2フェーズ（31〜60日）: 小さな成果の積み上げ
- 第3フェーズ（61〜90日）: 信頼の確立と自走態勢
順番に見ていこう。
第1フェーズ（1〜30日）——環境を把握する
最初の30日で最も大切なことは、「早く成果を出すこと」ではない。
聞くこと、観ること、記録することだ。
開発環境のセットアップを甘く見ない
入社初日、多くの企業では開発環境のセットアップドキュメントが渡される。
ここでの振る舞いが、最初の印象を決める。
ドキュメント通りに進めて詰まったら、すぐに質問する前に15分だけ自力で調べてみる。
それでもダメなら、「ドキュメントのこの手順でこのエラーが出ました。こういう仮説で調べたのですが解決できず」と具体的に聞く。
「質問の質」は、エンジニアとしての評価を最も早く決定するファクターのひとつだ。
何を聞くかではなく、どう聞くかが見られている。
セットアップで気づいた不備は、必ずメモしておく。
後でドキュメントの修正PRを出せば、それだけで「この人、ちゃんと見てるな」という印象になる。
1on1を自分から設計する
多くのチームでは、メンターや上長との1on1が週1回設定されている。
問題は、この時間を「報告の場」にしてしまうことだ。
1on1は、自分のためにデザインする場所だと認識を変えよう。
おすすめの構成はこうだ。
| 時間配分 | 内容 | ポイント |
|---|---|---|
| 最初の5分 | 今週やったこと（事実のみ） | 長々と説明しない |
| 10分 | 困っていること・判断に迷ったこと | 具体的な選択肢を示して相談 |
| 5分 | 来週チャレンジしたいこと | 小さくても「主体性」を見せる |
ポイントは「教えてください」ではなく「AとBで迷っています。自分はAだと思うのですが、どう思いますか」と仮説ベースで聞くこと。
これだけで対話の質が変わる。
コードベースの地図を頭に入れる
いきなり全体を理解する必要はない。
まずはディレクトリ構造を眺めて、以下の3点を把握する。
- エントリーポイントはどこか（APIルート、ページコンポーネント等）
- ビジネスロジックの中心はどのレイヤーにあるか
- テストはどこに、どの粒度で書かれているか
全部読む必要はない。
「この機能はこのあたりにある」というインデックスを頭に作ることが目的だ。
第2フェーズ（31〜60日）——小さな成果を出す
30日が経ち、チームの雰囲気やコードベースの全体像がぼんやり見えてきた頃。
ここから「アウトプット」のフェーズに入る。
最初のPRは「小さく、確実に」
初めてのPull Requestで壮大な機能を実装しようとする人がいる。
気持ちはわかるが、逆効果になることが多い。
最初のPRは小さいほどいい。
typoの修正、不要なimportの整理、テストケースの追加。
レビューする側の負担が小さいから、すぐにマージされる。
「この人、もうコードに手を入れ始めてるんだ」という事実が重要なのだ。
コードレビューの受け方で差がつく
レビューコメントへの対応は、技術力よりも「姿勢」が見られる瞬間だ。
やるべきことはシンプル。
- 指摘を受けたら、まず「ありがとうございます」から入る（形式的でも構わない）
- 修正理由を1行コメントで添える。「ここはXXXの理由でこう修正しました」
- わからない指摘は「この部分、もう少し詳しく教えていただけますか」と率直に聞く
- 意見が異なる場合は「自分はこう考えたのですが、こちらのアプローチのほうが良い理由を教えていただけますか」と対話にする
絶対にやってはいけないのは、黙ってコメントを無視すること。
そして、全部素直に言うことを聞きすぎるのも考えもの。
「なぜそうすべきなのか」を理解した上で修正する習慣が、成長速度を加速させる。
他の人のPRを読む習慣
自分がレビューを受ける側だけでなく、先輩エンジニアのPRを読む時間を週に1時間だけ確保しよう。
コードの書き方、コミットメッセージの粒度、設計判断の根拠。
教科書には載っていない「このチームの文法」が、PRの中に詰まっている。
気になった設計判断があれば、SlackやPRコメントで質問してみるのもいい。
「この実装の判断理由を教えてください」は、先輩にとって嬉しい質問だ。
自分のコードに興味を持ってもらえている、と感じるからだ。
第3フェーズ（61〜90日）——信頼を確立する
60日を過ぎると、チーム内での自分の「役割」がうっすら見えてくる。
この時期にやるべきは、その役割を意識的に言語化し、少しずつ広げていくことだ。
「得意領域」を一つ持つ
90日後に「XXXならあの人に聞こう」と思ってもらえる領域を一つ作る。
それは大きなものでなくていい。
CIパイプラインの設定に詳しくなる。特定のAPIの仕様を一番理解している。
テストの書き方について社内ドキュメントをまとめた。
どれでもいい。「この領域は自分」と周囲に認知されることがゴールだ。
社内ネットワークを広げる
エンジニアは自分のチームに閉じがちだ。
しかし、他チームとの接点が、長期的なキャリアを左右することは少なくない。
具体的なアクションとしては、以下が有効だ。
- 社内勉強会やLT会に参加する（発表しなくても、顔を出すだけでいい）
- 隣のチームのエンジニアとランチに行く
- Slackの他チームのチャンネルをウォッチして、興味のある話題にリアクションする
技術力だけでは見えない景色が、ネットワークの中にある。
とくに組織が大きいほど、「誰が何を知っているか」を把握している人が重宝される。
フィードバックを自分から取りに行く
90日が近づいたら、メンターや上長に対して自分からフィードバックを求めよう。
「入社してから3ヶ月が経ちましたが、自分のパフォーマンスについて率直なフィードバックをいただけませんか。
改善すべき点があれば、具体的に教えていただけると助かります。」
この一言を言えるかどうかで、その後の成長曲線が変わる。
フィードバックを恐れる人は多いが、聞かなかった場合のリスクのほうがはるかに大きい。
自分では気づけない死角を、90日目のタイミングで潰しておく。
やりがちな失敗パターン
ここまで「やるべきこと」を書いてきた。
逆に、多くの新人エンジニアが陥る失敗パターンも押さえておこう。
完璧主義に陥る
「もっと良いコードを書けるはず」と思って、PRを出すタイミングが遅れる。
結果、レビューも遅れ、学びの機会も減り、チームからの可視性が下がる。
最初の3ヶ月は、60点でいいから出す勇気が大切だ。
完璧なコードは、レビューを経て磨けばいい。
質問を溜め込む
「こんなことも知らないのかと思われたくない」という恐怖。
この感情は自然だが、放置すると致命的だ。
入社1ヶ月目の質問は「当然の質問」として受け止められる。
3ヶ月目に同じ質問をすると「まだわかってないの?」になる。
質問には鮮度がある。早ければ早いほど、周囲の反応は寛容だ。
自チームだけで世界を完結させる
チーム内で居場所を確保することは大事だが、そこに閉じてしまうと視野が狭まる。
前述のとおり、社内ネットワークの構築は意図的にやらないと起きない。
とくにリモートワーク環境では、意識しなければ「隣の人が何をしているか」すら見えなくなる。
週1回、チーム外の誰かと5分話す。それだけでも違う。
技術書だけに頼る
技術書を読むことは重要だが、それだけでは「現場の文脈」は身につかない。
実際のPRを読む、障害対応のポストモーテムを読む、設計ドキュメントを読む。
チーム固有の暗黙知に触れる時間を確保しよう。
| 失敗パターン | 根本原因 | 対処法 |
|---|---|---|
| PRを出すのが遅い | 完璧主義 | 60点で出す。レビューで磨く |
| 質問できない | 恐怖心 | 1ヶ月目は質問ボーナス期間と割り切る |
| チーム外と接点がない | 受動的な姿勢 | 週1回、他チームの誰かと話す |
| 独学に偏る | インプット過多 | PRを読む時間を週1時間確保 |
90日後のあなたへ——問いかけ
90日という期間は、長いようで短い。
振り返ったとき、「あの3ヶ月は密度が濃かった」と思えるかどうか。
それは偶然ではなく、設計によって決まる。
チェックリスト: 90日後の自分を確認する
90日が過ぎたら、以下の項目を自分に問いかけてみてほしい。
- チームのコードベースで、迷わずに修正できる範囲が3つ以上あるか
- 「XXXならあの人」と言われる得意領域があるか
- チーム外に、名前で呼び合える同僚が5人以上いるか
- 1on1で、自分から議題を設定できているか
- コードレビューで、指摘するだけでなく「良い部分」を伝えた経験があるか
全部にYesと答えられなくても問題はない。
大事なのは、90日後にこの問いを振り返る習慣を持つことだ。
「同期と差がつく」の本当の意味
タイトルに「同期と差がつく」と書いた。
だが正直に言うと、同期との比較にはあまり意味がない。
本当に差がつくのは、「3ヶ月前の自分」との比較だ。
入社初日に書けなかったコードが書けるようになっている。
知らなかったドメイン知識が身についている。
名前すら知らなかった人と、今は普通に議論できている。
その変化を自分で認識できるかどうか。
認識できる人は、次の90日も走り続けられる。
あなたの最初の90日が、その先の数年間を形作る。
この記事が、そのための地図のひとつになれば幸いだ。
