ITエンジニアの履歴書、経験年数別「書き分け戦略」完全ガイド：3年目・5年目・10年目で変えるべき6つのポイント
「丁寧に書いたのに通らない」——その原因は”経験年数無視”の書き方にある
転職活動を始めたとき、多くのITエンジニアが最初にやること。それは「以前使った履歴書を引っ張り出して、日付と志望動機だけ書き換える」ことです。あるいは、ネットで拾ったテンプレートにそのまま情報を流し込む。
気持ちはよくわかります。職務経歴書の作り込みに集中したい。履歴書は「決まった枠を埋めるだけの書類」だと思っている。でも実態は違います。
採用担当者が履歴書を見るとき、無意識に「この人は今どのフェーズにいるエンジニアなのか」を判断しています。経験3年目と10年目では、アピールすべき内容もフォーマットの使い方も根本的に異なる。にもかかわらず、同じ「テンプレート埋め込み」をしているエンジニアが非常に多い。
この記事では、既存の「書き方ガイド」では触れない「経験年数ごとの書き分け戦略」に焦点を当てます。3年目・5年目・10年目という3つのフェーズ別に、採用担当者やエージェントが実際に何を見ているかを解説しながら、そのまま使えるビフォー/アフターの書き換え例とチェックリストをお届けします。
採用担当者が履歴書で”本当に”見ていること——doda調査が示す衝撃の事実
「職歴欄」が選考の命運を握っている
doda調査によると、採用担当者が履歴書で最も重視する項目として、48.6%の担当者が「職歴欄」を挙げています。また、一人あたりの書類を見る時間は「5分以上10分未満」が最も多い回答でした。
つまり、5分以内で「会ってみたい」か「見送り」かを判断されることが珍しくない。この事実を踏まえると、「丁寧に書いた」「文字が綺麗」は最低条件であり、職歴欄でいかに短時間で印象を残すかが勝負になるわけです。
IT系採用担当が「年収×年齢」の組み合わせを見る理由
ここはあまり語られない裏側の話ですが、特にIT業界では独特の読み解き方が存在します。システム開発系企業の採用担当者は、「年収×年齢」の組み合わせを確認し、担当した工程の広さからスキルレベルや前職での評価を推測するアプローチを取っている、と語っています。
要は、「30歳でこの年収ということは、担当工程はこの範囲だろう」という逆算をされているのです。だからこそ、職歴欄には単なる「在籍していた会社名」だけでなく、担当していた工程の幅まで書く必要があります。
PC作成が前提——手書きはむしろ逆効果になりうる
IT業界やWeb・IT系の職種では、パソコン作成がおすすめです。パソコン業務が中心の職種では、手書きの履歴書を提出すると、パソコン操作に不安があるのではと見られるケースもあります。
「手書きは熱意が伝わる」という通説は、IT転職においては必ずしも正しくありません。採用担当者が見ているのは熱意よりも「この人はITプロフェッショナルか」という確認です。書くなら迷わずPC作成を選びましょう。
【経験3年目エンジニア】「伸びしろ」を証明する履歴書の書き方
よくある失敗：「こなしてきた技術の羅列」で終わっている
経験3年目は、社会人としての基礎はあるものの、実績で語れる材料がまだ少ない時期。この層に多い失敗が、履歴書の職歴欄を「在籍した会社＋使った言語」の箇条書きで終わらせてしまうことです。
【失敗例】
- ○○株式会社（20XX年4月〜現在）：PHP、MySQL、JavaScriptを使用したWeb開発に従事
採用担当者の頭には「で、あなたはそこで何ができるようになったの？」という疑問符が浮かびます。「従事」は仕事の存在を示すだけで、あなたの成長や貢献を何も語りません。
「成長の軌跡」を30文字で伝える職歴欄の作り方
3年目エンジニアが履歴書で輝くキーワードは「変化」と「自走力」です。採用担当者は「3年でどう変わったか」を見ています。以下のビフォー/アフターを参考にしてください。
【ビフォー】
○○株式会社（20XX年4月〜現在）：PHP、MySQL、JavaScriptを使用したWeb開発に従事
【アフター】
○○株式会社（20XX年4月〜現在）：ECサイト開発（PHP/MySQL）。入社1年目はコーディング補助、2年目からフロント実装をひとりで担当。3年目にリファクタリングを主導し、ページ表示速度を改善。
ポイントは3つです。
- 「入社から今までの役割の変化」を時系列で書く：補助→独立→主導という変化が「成長」を証明する
- 担当フェーズを明示する：「開発」だけでなく「フロント実装」「リファクタリング」など具体的な工程名を入れる
- 技術的な成果を1行添える：「何をしたか」より「何が変わったか」を添えるだけで説得力が跳ね上がる
資格欄の戦略：多く書けばいいわけではない
資格は多く書くほど評価が上がるわけではなく、応募職種と関連性の低い資格を並べるより、関連性の高い資格を厳選する方が効果的です。
3年目エンジニアが陥りがちなのは、「勉強した証拠を見せたい」心理から、関係性の薄い資格まで列挙してしまうこと。ITパスポートと普通自動車免許と簿記3級が並ぶ履歴書は、「軸のない人」という印象を与えます。応募するポジションに関連する資格を2〜3個、取得年月とともに明記するのが正解です。
【経験5年目エンジニア】「再現性」を見せる書き方——ここで差がつく
5年目の壁：「できること」は伝わっても「どこでも活躍できる人」に見えない
経験5年目になると、技術力はある程度証明できます。しかし採用担当者の判断基準がシフトしてきます。「この人のスキルは、うちで再現できるか？」という視点です。
特定の会社のシステムやツールに最適化されたエンジニアではなく、環境が変わっても同じアウトカムを出せる人材かどうか。これが5年目エンジニアの書類選考の核心です。
「再現性」を伝えるための書き方：前提条件と行動を分けて書く
再現性を見せるには、「何をしたか」ではなく「どんな状況で・何を判断して・どう動いたか」というパターンで書くことが重要です。
【ビフォー】
○○株式会社にて、Javaを使用した業務系システムの設計・開発を担当
【アフター】
○○株式会社にて、レガシーシステム（Struts2）のSpring Boot移行プロジェクトに参画。既存コードの仕様が文書化されていない状況で、コードリーディングと業務部門へのヒアリングを主導し、要件定義書を自分で作成してから開発を推進。マイクロサービス化の設計も担当。
「レガシー・ドキュメントなし・自走」というキーワードが連なることで、採用担当者は「うちの現場でも自分で動ける人だ」とイメージできます。これが再現性の見せ方です。
エージェントが内部で使う「5年目のスクリーニング基準」
転職エージェントが5年目エンジニアの書類をチェックするとき、実は職歴欄よりも先に「担当工程の幅」を見ています。要件定義・基本設計・詳細設計・実装・テスト・保守のうち、どこまで経験しているかの確認です。
工程が「実装とテストのみ」の5年目と、「要件定義から保守まで」の5年目では、紹介できる求人の質が変わります。履歴書の職歴欄には、担当した工程を必ず明記してください。「開発」「システム構築」という曖昧な表現は、エージェントに「詳細不明」と判断され、より詳しく確認が必要な案件として後回しにされることもあります。
【経験10年目以上のエンジニア】「影響範囲」で語れなければ負ける
シニアエンジニアの最大の失敗：「個人の技術力」だけで勝負している
10年以上のキャリアを持つエンジニアが書類選考で落ちるとき、共通するパターンがあります。「私はこれができます」という個人のスキル列挙に終始し、「チーム・プロジェクト・組織にどんな影響を与えたか」が一切書かれていないのです。
採用担当者の視点で言えば、「10年エンジニアをやってきて、あなたがいた場所は何が変わりましたか？」という問いに答えてほしいのです。個人の技術者としての優秀さより、周囲を動かす力・組織に変化をもたらす力を見ています。
「影響範囲」で書く職歴欄の作り方
【ビフォー】
○○株式会社にてチームリーダーとしてプロジェクト管理を担当。Java/Spring、AWSを活用したシステム開発を推進
【アフター】
○○株式会社（開発チームリーダー）：5名チームの技術方針を決定し、コードレビュー体制を整備。属人化していた障害対応手順を文書化し、自分がいなくてもチームが動ける体制を構築。新卒・中途計3名のオンボーディングを主導。技術選定（Java→Go移行）の提案から経営層への説明まで担当。
「チームの何が変わったか」「組織で自分の役割は何だったか」を具体的に書くことで、採用担当者はリーダーとしての実力をイメージできます。複数のプロジェクトに関わっている場合、直近かつ成果の大きいプロジェクトは詳しく記載し、その他は簡潔にまとめるなど、メリハリをつけることが採用担当者に読ませるコツです。10年目以上であれば、最近3年分を詳述し、それ以前は会社名と担当工程の概要のみで十分です。
志望動機欄の「書き分け」——10年目が犯しやすいミス
シニアエンジニアの志望動機でよく見るのが「さらなる成長のために」「新しい技術に挑戦したい」という表現です。これは10年のキャリアがある人が書くと、かえって逆効果になります。
採用担当者の本音は「10年あれば現職でもできたはず。なぜ転職なの？」です。採用担当者は何十枚、何百枚という書類を見ており、志望動機や自己PRがしっかり書かれている応募者は「本気度が高い」と評価されやすく、逆に一言だけの記載では「とりあえず応募しただけ」と思われてしまいます。
10年目以上のエンジニアが志望動機に書くべきは「現職でできなかったこと」より「あなたの会社のこの課題に、自分のこの経験が直接刺さる」という構造です。企業研究で拾えるプレスリリース、技術ブログ、採用ページの「開発課題」の言葉を引用しながら、「それは自分が○○プロジェクトで解決してきたことと同じ構造です」と繋げましょう。
採用担当者が「落とす理由」にする3大チェックポイント
①転職回数の見られ方——「多い＝NG」は誤解
転職回数が複数回ある場合は、業種に一貫性があるか、応募者がこれまでどんな分野・役割で仕事をしてきたか、即戦力になるのか、自社に定着してくれる人材なのかを見ています。
転職回数が多い場合、履歴書の職歴欄に「在籍期間が短い会社」が並ぶことへの不安を先手で消す必要があります。具体的には各社の職歴欄に「在籍が短かった理由を匂わせるコンテキスト」を1行添えることが有効です。
- 「プロジェクト完了に伴い契約終了」→ 業務委託だったことが伝わる
- 「会社の事業撤退により部署解散」→ 本人起因でないことが伝わる
- 「〇〇の領域に専門性を集中させるため転職」→ 意図的なキャリア設計が伝わる
②「志望動機の使い回し」はすぐバレる
特にエージェント経由での応募が多い場合、採用担当者は同じ求人に似たような志望動機が並ぶことを知っています。志望動機では企業の技術ブログや開発文化に触れ、「その企業だからこそ応募した」という説得力を持たせることが重要です。
ひとつの志望動機を7社に使い回す「コピペ応募」は、採用担当者の目にはすぐ映ります。少なくとも「企業名が違う部分」だけでなく、その企業のプロダクト・技術スタックの固有名詞を1つ入れるだけで、通過率が大きく変わります。
③「新卒テンプレート」をそのまま使っている
転職用には職歴欄が広いテンプレートを選ぶ方が実務的です。志望動機は簡潔に要点をまとめる方が採用担当者には読みやすく好印象です。
職歴欄が1〜2行しか書けない新卒向けテンプレートを使い続けることで、書くべき情報が物理的に入りきらず、重要なことが削られてしまうエンジニアは非常に多いです。転職用のテンプレートを選ぶ際は、職歴欄が最低でも半ページ分取れるものを選ぶことが必須条件です。
今の転職市場が求める「新しい軸」を履歴書に反映させる
AI活用・クラウド・セキュリティ——市場の変化を「資格・スキル欄」に反映する
現在は、AIを用いた業務効率化やデータ活用、セキュリティ強化など、より高度な運用・改善が求められるフェーズに移行しており、こうした分野に対応できるエンジニアのニーズは引き続き高い状況です。
この流れを受けて、履歴書の「資格・免許欄」や「特記事項欄」には、AIツールの業務活用経験・クラウド資格（AWS/GCP/Azure）・セキュリティ関連の知識を積極的に記載することで、市場のニーズとの適合性を示すことができます。ただしあくまで実務経験や実際の取得実績に基づいて記載してください。ハッタリは面接でバレます。
GitHubやポートフォリオのURLを履歴書に入れる戦略
履歴書の「本人希望欄」や「特記事項欄」は、多くのエンジニアが「特になし」で埋めてしまう”もったいない欄”です。ここにGitHubのURLやポートフォリオサイトのリンクを記載することで、採用担当者が興味を持ったときの「次の一手」を用意できます。
記載する際のポイントはURLを貼るだけでなく、1行コメントを添えることです。
- 【そのままURL貼り付け】https://github.com/username
- 【コメントあり】GitHub（https://github.com/username）：Go言語によるAPIサーバー実装・CI/CD構築の実務ベース実装例を公開中
後者の方が「見てみよう」という気にさせます。採用担当者の5分という限られた時間の中で、自分への興味を引き出す設計が重要です。
まとめ：今日からできるアクション
この記事で伝えてきたことを、すぐに動けるアクションに落とし込みます。今日中に最低1つ取り組んでください。
- 【アクション1】履歴書の職歴欄を「工程・役割・変化」の3点セットで書き直す
「何をしたか」だけでなく、担当した工程名・自分の役割（リーダー/メンバー/推進者）・在籍中の変化（成長・改善・構築したもの）を書き足す。5分あれば今すぐできます。 - 【アクション2】経験年数に合ったテンプレートに切り替える
今使っている履歴書テンプレートの職歴欄を確認してください。3〜4行しか書けないなら、職歴欄が広い転職者向けテンプレートに変更する。これだけで情報量が格段に変わります。 - 【アクション3】志望動機の1社目だけ「企業固有名詞入り」で書き直す
応募予定の企業1社の技術ブログか採用ページを10分読み、そこに書かれている開発課題や技術スタックの言葉を1つ引用して志望動機に組み込む。その1社の通過率がどう変わるか、実験してみてください。