1〜3年目での転職は、とても微妙なステージです。
入社したての頃に先輩から言われた言葉が、今振り返ると本当に的を射ています。「1〜3年目の人材を採用するとき、面接官が買っているのは経験じゃなくて成長性だ。転職しようとしているのに、履歴書が新卒の頃と変わらないなら、誰が2年分の給与を余分に払うんだ？」
少し厳しい言い方ですが、ロジックは正しい。1〜3年目は「リアルな仕事の環境で問題を解決できること」を証明するステージであって、「何を学んだか」を証明するステージではないのです。
以下、このステージで最もよく見られる問題をいくつか解体していきます。
問題1：履歴書が依然として「タスク消化」の書き方
これは1〜3年目の履歴書で最も普遍的な問題です。書き方はだいたいこんな感じ：
プロダクト要件に基づいてバックエンド API の開発を完了。
コードレビューに参加し、オンラインのバグを修正。
技術文書を作成。
この3行は、本質的に開発者の職務記述書であって、あなた個人の履歴書ではありません。別の同僚が書いても、プロジェクト名以外はまったく同じ内容になり得ます。
1〜3年目にもなると、面接官はあなたに基本的な開発能力があることをデフォルトで前提としています。「コードが書けること」の証明はもう不要で、見たいのは：
- 独立して問題を解決できるか？ 毎回誰かに指示されないと動けないのか。
- 「割り当てられたタスク」を超えて行動する意識があるか？ 自ら問題を発見したことがあるか？何かのプロセスを改善したことがあるか？
- 自分が作っているものに対して全体像を理解しているか？ それとも自分の担当範囲しか知らないのか？
どう直すか：
バックエンド API 開発を独力で完遂。注文作成、決済コールバック、返金処理の3つのコアフローをカバーし、累計20以上の RESTful API を開発。
コードレビューを主導する中で、3つの潜在的な並行処理の安全問題を発見・修正。これらの API に起因するリリース後の P0 事故はゼロ。
API ドキュメントを作成し、Swagger 導入を推進。フロントエンドとの結合テスト工数を約30%削減。
同じ開発業務の記述でも、「独力」「主導」「P0ゼロ」「30%削減」が加わることで、伝わるシグナルがまったく変わります。
問題2：プロジェクト記述に個人のポジショニングがない
1〜3年目だと関わったプロジェクトは少なくありません。でも多くの人の書き方は、1つのプロジェクトに5〜6行、すべて「やったこと」を列挙するだけで、読み終わってもこの人がプロジェクトでどんな役割を果たしたのかがわかりません。
プロジェクトA：要件議論に参加、バックエンドコードを書いた、単体テストを書いた、デプロイした、ドキュメントを書いた、バグをいくつか修正した。
プロジェクトB：同上。
面接官が読んだ後の困惑：で、あなたはフルスタックなの？それともバックエンド寄り？それとも雑用係？
解決策： 各プロジェクトにあなたの役割を明確に書く。
プロジェクト：XX プラットフォーム注文システム再構築（2025.03 - 2025.08）
ポジション：バックエンドコア開発、注文リンクの設計と実装を担当。フロントエンド、QA、プロダクトの計6名と協業
- 注文ステートマシンを独力で設計し、8つの注文状態と15の状態遷移シナリオをカバー
- 並行処理下での冪等性処理と在庫引当を実装し、オンラインでの金銭的損失ゼロ
- QA と協力して全リンク負荷テストを実施。コア API の TPS が 2000以上に到達
各プロジェクトの冒頭に1〜2行でチューニングを：どんなプロジェクトか、何人か、自分は何の役割か。 面接官は読み終えた時点で頭の中に人物像を描けます。
問題3：技術しか見ず、ビジネスを見ていない
この点は1〜3年目の人にとっては不公平に感じるかもしれません——「まだ2年しか働いてないのに、ビジネス理解なんて自分の担当じゃないでしょ？」
でも現実はこうです：同じ技術レベルの2人がいて、一人はビジネス背景を語れ、もう一人は技術実装だけを語る——後者はジュニアに見えます。
例として、同じプロジェクトを2人が書いたとします：
書き方 A（技術だけ）：
Redis キャッシュでホットデータをキャッシュし、データベース負荷を低減。メッセージキューを導入して注文タイムアウトを非同期処理。
書き方 B（技術＋ビジネス理解）：
ライブコマースのフラッシュセールシーンで、注文の瞬間同時実行数が QPS 5000以上に達し、データベース接続プールが枯渇して注文タイムアウトが発生。
対策設計：Redis による商品在庫キャッシュ + ブルームフィルターで無効リクエストを遮断 + RocketMQ で注文タイムアウトキャンセルを非同期処理。
最適化後、注文 API の応答時間が 2秒から 300ms に改善し、1回のライブ配信で10万以上のユーザー注文を支えた。
両者の技術的な対策はまったく同じかもしれません。でも書き方 B は重要なシグナルを発信しています：この人はコードが書けるだけでなく、コンテキストを理解し、「なぜ」そうするのかがわかっている。
1〜3年目で転職するとき、面接官が求めているのはまさにこの「コンテキストを理解できる」人です。
問題4：プロジェクトが多すぎて重点がない
1〜3年目で関わるプロジェクト数は通常3〜6個。でも履歴書に載せるのは 最も能力を示せる2〜3個だけ に絞るべきです。
プロジェクトを選ぶ基準：
- 最も新しいものを優先（直近1〜2年）
- 役割が最もコアなものを優先（あなたが主導または深く関与したプロジェクト）
- 最も難易度が高いものを優先（単なる「使い走り」だったプロジェクトではない）
1〜2ヶ月しか関わっていない、関与度が低い、または時間が経ちすぎている（インターンシップなど）プロジェクトは、すべて削除。
面接官が履歴書で探している5つのシグナル
上記の調整をした後、自分の履歴書がこれらのシグナルを発信しているかチェックしてみてください：
- 10秒以内にあなたの方向性とレベルが判断できる → 最初の画面に明確なポジショニングがある
- 独立した問題解決能力が見える → 「主導」「独力で完遂」「0から1へ」の事例がある
- 「タスク消化」の枠を超えた主体性が見える → 最適化、改善、自発的な推進の事例がある
- 関わったプロジェクトのコンテキストが理解できる → 技術対策＋ビジネス背景の両方がある
- 技術の方向性と成長可能性が判断できる → プロジェクト選択に方向性があり、雑多ではない
最後に
1〜3年目で転職するときの履歴書で最も怖いのは、「書き方が下手」なことではなく、入社半年の新人のような書き方になっていることです——全部がタスク記述で、個人の判断がなく、成果の数値化もない。
自分の履歴書がどのレベルにあるか不安なら、DeepResume にアップロードして診断を受けてみてください。成果の数値化、キーワードカバレッジ、ATS 対応度の各軸で具体的なスコアと修正アドバイスを出し、「応募できる」状態まであとどれくらいかを見える化します。