新卒エンジニアが最初の90日で差をつける技術習得ロードマップ

4月、新しいチームに配属されたエンジニアにとって、最初の90日間は特別な意味を持つ。

大学や専門学校で学んだプログラミングの知識は、実務のほんの入り口にすぎない。 現場で求められるのは、コードを書く力だけではない。 チームで開発するための「作法」と「仕組み」を理解し、自走できる状態をつくることだ。

本記事では、新卒エンジニアが入社後90日間で身につけるべきスキルを、時系列のロードマップとして整理した。 各フェーズで何を優先すべきか、どんなツールを使えばいいのか、具体的に見ていこう。

全体像：90日ロードマップの3フェーズ

90日間を大きく3つのフェーズに分ける。 闇雲に勉強するのではなく、段階的に実務能力を積み上げるのがポイントだ。

フェーズ	期間	テーマ	ゴール
Phase 1	1〜30日	開発環境と基本動作	一人でタスクを完了できる
Phase 2	31〜60日	品質とプロセス	チームの品質基準を理解し実践できる
Phase 3	61〜90日	自走と貢献	自ら課題を見つけて改善提案できる

重要なのは、Phase 1でつまずいたままPhase 2に進まないことだ。 各フェーズの「ゴール」を達成してから次に進もう。 焦る必要はない。着実に積み上げることが、90日後の差になる。

Phase 1（1〜30日）：開発環境とGitの基本を固める

最初の1ヶ月で最優先すべきは、開発環境の構築とバージョン管理の習得だ。 コードを書く前の「土台」がここにある。

開発環境のセットアップ

配属初日、多くの新卒エンジニアが直面するのが環境構築の壁だ。 READMEを読んでも動かない、依存関係が解決できない、そもそもどのバージョンのランタイムを使えばいいかわからない。

まずは以下を確実にセットアップしよう。

• エディタ：VS Code（拡張機能はチームの推奨リストに従う）
• ランタイム管理：asdf、mise、またはnvm/rbenvなどの言語別バージョンマネージャ
• パッケージマネージャ：npm/pnpm/yarn（プロジェクトの指定に従う）
• Docker：ローカルでDBやミドルウェアを動かすために必須
• ターミナル：iTerm2やWindows Terminalをカスタマイズして効率化

「環境構築でつまずいた点」をメモしておくと、後輩のオンボーディング資料として役立つ。 困ったことこそ、チームへの最初の貢献になる。

Gitの基本操作を体に覚えさせる

Gitは現代のソフトウェア開発における共通言語だ。 最低限、以下のコマンドを「考えずに打てる」レベルにしておきたい。

操作	コマンド	使う場面
ブランチ作成	git switch -c feature/xxx	新しいタスクを始めるとき
変更の確認	git diff	コミット前に差分を確認
ステージング	git add -p	変更を部分的に選んでコミット
コミット	git commit -m "..."	意味のある単位でコミット
リベース	git rebase main	mainの最新を取り込む
コンフリクト解消	手動修正 → git add → git rebase --continue	リベース中の衝突時

おすすめリソース：「Learn Git Branching」はブラウザ上でGitの分岐・マージを視覚的に学べる無料ツール。まずここで30分遊んでみてほしい。

特にgit add -p（パッチモード）は、多くの新卒が知らないまま過ごしがちだが、プロのエンジニアは日常的に使っている。 変更を「意味のある単位」に分割してコミットする習慣は、この時期に身につけておきたい。

ブランチ戦略とプルリクエスト

Git-flowやGitHub Flowなど、チームごとにブランチ戦略は異なる。 配属されたら真っ先に確認すべきは、以下の3点だ。

1. ブランチの命名規則（feature/、fix/、chore/など）
2. プルリクエスト（PR）のテンプレート（何を書くべきか）
3. マージの方法（squash merge、rebase merge、merge commitのどれか）

プルリクエストは単なるコードの提出ではない。 「自分がなぜこの実装を選んだか」をチームに伝えるコミュニケーションの場だ。 PRの説明文に背景と意図を書く習慣をつけよう。

Phase 1 後半：コードリーディングとチームの文化を吸収する

環境構築とGitの基本ができたら、次は「チームのコードを読む」ことに時間を使おう。 自分でコードを書くよりも先に、既存のコードベースを理解することが大切だ。

• 過去のPRを30件読む：どんなレビューコメントがついているか、どんなコードが承認されているかのパターンを掴む
• ディレクトリ構成を把握する：どこに何があるかの全体マップを頭に入れる
• コーディング規約を確認する：ESLint/Prettier等のルールファイルを読む
• テストコードを読む：テストは「期待される動作の仕様書」として読める

「コードを書く力」よりも「コードを読む力」のほうが、最初の1ヶ月では価値が高い。先輩のコードを読み込むことで、チームの「暗黙の設計思想」が見えてくる。

わからないコードがあったら、まず自分で調べる。 それでもわからなければ、「ここまで理解できたが、この部分がわからない」と具体的に質問する。 この「調べてから聞く」の順序が信頼を積み上げる。

Phase 2（31〜60日）：テストとコードレビューの実践

2ヶ月目に入ったら、コードの「品質」に意識を向けるフェーズだ。 自分が書いたコードに責任を持てる状態を目指す。

テストを書く習慣をつける

テストコードは「未来の自分への保険」だ。 リファクタリングや機能追加のとき、テストがあるかないかで心理的安全性がまるで違う。

テストの種類	対象	代表的なツール	優先度
ユニットテスト	関数・メソッド単位	Jest、Vitest、pytest	最優先
統合テスト	複数モジュールの連携	Testing Library、Supertest	Phase 2後半
E2Eテスト	ユーザー操作の再現	Playwright、Cypress	Phase 3

まずはユニットテストから始めよう。 「この関数にこの入力を渡したら、この出力が返るべき」というシンプルなテストを書くことから慣れていく。

テストを書くときの心構えとして覚えておきたいのが、「テストは仕様を表現するもの」ということだ。 テストケースのネーミングを見るだけで、その関数が何をするかわかる——そんなテストが理想的だ。

コードレビューの受け方・やり方

コードレビューは、新卒エンジニアにとって最大の学習機会だ。 レビューを受ける側にも、する側にもコツがある。

レビューを受けるとき：

1. PRは小さく保つ（300行以下が目安）
2. セルフレビューを必ず先にやる（自分のPRを一度読み直す）
3. 「なぜこう書いたか」をPR説明文に書く
4. 指摘されたら防御的にならず、まず理解しようとする
5. 同じ指摘を2度受けないようにメモしておく

レビューをするとき：

1. まずPRの目的と背景を理解してからコードを読む
2. 「なぜダメか」ではなく「こうするとより良い」という提案型で書く
3. 些末な指摘と重要な指摘を区別する（nit: プレフィックスの活用）
4. 良いコードには「ここいいですね」とポジティブなコメントも残す

新卒でもレビューに参加していい。むしろ「初心者の目」で読むからこそ気づける可読性の問題がある。遠慮せずにコメントしよう。

CI/CDパイプラインを理解する

CI/CD（継続的インテグレーション / 継続的デリバリー）は、チーム開発の生命線だ。 コードをpushしたら自動でテストが走り、問題がなければデプロイされる。 この仕組みを「使う」だけでなく「理解する」ことが2ヶ月目の目標になる。

• GitHub Actions：最も普及しているCI/CDプラットフォーム。YAMLで定義する
• CircleCI / GitLab CI：企業によってはこちらを使っている場合も
• Vercel / Netlify：フロントエンドのプレビューデプロイに使われることが多い

自分のPRを出したとき、CIが落ちたら慌てずにログを読もう。 エラーメッセージの読み方に慣れることも、この時期に鍛えたいスキルだ。

CI/CDで確認される項目	目的
Lint	コーディング規約への準拠
型チェック	TypeScript等の型安全性
ユニットテスト	ロジックの正しさ
ビルド	本番環境で動作するか
セキュリティスキャン	脆弱性のある依存パッケージの検出

Phase 3（61〜90日）：ドキュメンテーションと自走力

3ヶ月目のテーマは「チームに貢献する」だ。 ここまでで基礎力を身につけたら、次はチーム全体の生産性を上げるアクションに目を向けよう。

ドキュメンテーションの技術

「コードは書けるけどドキュメントが書けないエンジニア」は、実務では評価されにくい。 なぜなら、ドキュメントは「未来のチームメンバーへのギフト」だからだ。

新卒エンジニアが書くべきドキュメントは、大きく4種類ある。

1. ADR（Architecture Decision Record）：設計判断とその理由を記録する。「なぜMySQLではなくPostgreSQLを選んだか」「なぜこのAPIの認証方式を選んだか」など
2. README / セットアップガイド：新メンバーが迷わず環境構築できるように
3. API仕様書：エンドポイントの入出力、エラーケースを明文化
4. 障害対応の振り返りメモ：何が起きて、どう対処して、何を学んだか

ドキュメントの質は「6ヶ月後の自分が読んで理解できるか」で判断する。書いた直後は当たり前に思えることでも、時間が経つと文脈を忘れる。

ツールとしてはNotion、Confluence、GitHub Wiki、あるいはコードベース内のMarkdownファイルなど、チームの方針に合わせる。 大切なのはツールの選択ではなく、「書く」という行動を習慣化することだ。

自走力を高める3つの習慣

90日を過ぎたとき、周囲に「あの新卒は自走できる」と思ってもらえるかどうか。 その評価を左右するのは、以下の3つの習慣だ。

1. 15分ルール：15分調べてわからなければ聞く。30分以上悩み続けない。ただし「何を調べたか」「どこまでわかったか」をセットで伝える
2. タスク分解：大きなタスクを受けたら、まず30分〜2時間で終わる粒度に分解する。分解した結果をチームに共有してから着手する
3. 振り返りの記録：週に1回、「今週学んだこと」「つまずいたこと」「来週やりたいこと」を3行で書く。これが3ヶ月後に振り返ったとき、成長の軌跡になる

習慣	なぜ重要か	実践のコツ
15分ルール	時間の無駄を防ぎつつ自力で考える力も養う	タイマーを実際にセットする
タスク分解	見積もりの精度が上がり、進捗が可視化される	付箋やGitHub Issueで管理
振り返り記録	成長を実感でき、1on1の材料にもなる	金曜の退勤前に5分で書く

90日間で使いこなしたいツール一覧

最後に、90日間で触れておきたいツール・サービスを一覧でまとめた。 すべてを深く使いこなす必要はないが、「存在を知っている」だけで行動の選択肢が広がる。

カテゴリ	ツール名	用途
バージョン管理	Git / GitHub / GitLab	コードの共同作業
エディタ	VS Code / Cursor / JetBrains系	コードの記述・デバッグ
CI/CD	GitHub Actions / CircleCI	テスト・デプロイの自動化
コンテナ	Docker / Docker Compose	環境の再現性確保
テスト	Jest / Vitest / Playwright	品質の自動検証
コミュニケーション	Slack / Discord / Notion	チームの情報共有
タスク管理	Jira / Linear / GitHub Projects	作業の可視化・優先順位づけ
モニタリング	Datadog / Sentry / Grafana	本番環境の監視
AIアシスタント	Claude Code / GitHub Copilot	コーディング支援

AIコーディングツールについて1点補足しておきたい。 GitHub CopilotやClaude Codeは強力な味方だが、「なぜそのコードが正しいのか」を理解せずにコピペするのは危険だ。 AIが提案するコードを「レビューする力」こそ、新卒エンジニアが身につけるべきスキルだ。

90日後の自分に問いかけてほしいこと

ここまで、新卒エンジニアが最初の90日間で身につけるべきスキルをロードマップ形式で整理してきた。

Phase 1でGitと開発環境の基礎を固め、Phase 2でテストとコードレビューの文化を吸収し、Phase 3でドキュメンテーションと自走力を身につける。 この流れを意識するだけで、90日後の立ち位置は大きく変わるはずだ。

ただ、技術スキルの習得以上に大切なことがある。 それは「わからないことを、わからないと言える姿勢」だ。

経験豊富なエンジニアほど、「知らない」と正直に言う。 なぜなら、知ったかぶりをするほうが、チームにとってはるかにリスクが高いからだ。

90日後、あなたは自分にこう問いかけてみてほしい。

• 入社初日の自分には書けなかったコードを、今日は書けているか
• チームの誰かに「ありがとう」と言われた経験があるか
• 自分が学んだことを、次の新卒に説明できる自信があるか

もしひとつでもYesなら、あなたの90日間は成功だ。 そしてこのロードマップは、あくまで出発点にすぎない。 90日を超えた先にある「自分だけの学び方」を見つけることが、エンジニアとしての本当のスタートラインになる。

あなたの最初の90日間で、最も力を入れたいフェーズはどこだろうか。