エンジニアの職務経歴書の書き方｜採用担当者目線の実践ガイド

この記事では、エンジニア職への転職で必要になる職務経歴書の書き方を、採用担当者が実際に審査する視点から解説します。技術スタックの正しい見せ方、定量的な成果の書き方、NG例と良い例文の対比まで、実践的な内容をまとめました。

エンジニアの職務経歴書が書類選考を通らない根本的な理由

「担当しました」の羅列が落選を招く

書類選考で落とされているエンジニアの職務経歴書には、共通のパターンがあります。「〇〇を担当しました」「△△の開発を行いました」「PythonとAWSを使用しました」——こうした記述が並んでいる書類です。

採用担当者が見たいのは、何をやったかではなく、何を成し遂げたかです。「担当した」という言葉は、関与の深さも成果も伝えません。プロジェクトの端の方にいただけなのか、チームを引っ張ったのかが、同じ言葉では区別できないのです。

「技術スタックを並べておけば伝わるはず」という思い込みも通過率を下げる原因のひとつです。採用担当者はエンジニアのプロフェッショナルではないケースが多く、技術名の羅列からスキルレベルを読み取ることはできません。

採用担当者が30秒で判断する3つのポイント

書類選考では、1通の職務経歴書に長時間をかけることはできません。最初の30秒で、次の3点を確認しています。

この3点が30秒で読み取れない職務経歴書は、続きを読んでもらえません。フォーマットの見栄えや文章の完成度より、この3点が伝わるかどうかが最初の関門です。

職務要約の書き方

「自分の一言プロフィール」を決めてから書く

職務要約は、職務経歴書の冒頭に置く200〜300文字の自己紹介欄です。多くの人がここで詰まる理由は、「何年間で何を経験した」という情報の羅列から書こうとするからです。

正しい手順は逆です。まず「自分のエンジニアとしての強みを一言で表すと何か」を決めてください。「〇〇に強いエンジニア」という核心を決めてから、それを裏付ける経歴を添えるというのが職務要約の設計順序です。核心が決まっていない職務要約は、読んでも何も残らない文章になります。

採用担当者を引き込む職務要約の型

職務要約は次の3要素で組み立てると、情報の密度と読みやすさが両立します。

• ①経歴の概要：「Webアプリケーション開発を中心に5年間の経験があります」
• ②強みの核心：「特にバックエンド（Python/Django）と要件定義〜リリースまでの一気通貫が得意領域です」
• ③今後の方向性：「今後はサービス企画や技術的意思決定に関わる立場を目指しています」

職務要約の良い例とNG例

職務経歴（プロジェクト経歴）の書き方

記載する順番と絞り込みの基準

職務経歴は原則として新しいもの（直近）から順に記載します。採用担当者は「今のあなた」に最も興味を持っているため、古い経歴から読んでもらう必要はありません。

経験が多い場合、すべてのプロジェクトを書こうとすると書類が長くなりすぎます。A4用紙2〜3枚が目安で、それ以上になる場合は絞り込みが必要です。

• 直近3〜5年のプロジェクトを優先する
• 応募先の求人に関連する技術・役割のプロジェクトを優先する
• 成果や役割が明確に書けないプロジェクトは省略する

「規模・役割・技術・成果」の4点セットで書く

各プロジェクトの記述は、次の4点を揃えることで採用担当者が比較・評価しやすくなります。

項目	書くべき内容	記述例
規模	チーム人数、プロジェクト期間	開発チーム5名・6ヶ月
役割	担当ポジション、リーダー経験	バックエンドリード担当
技術	使用言語・フレームワーク・インフラ	Python/FastAPI、PostgreSQL、AWS（EC2, S3）
成果	定量・定性の実績	API応答速度を40%改善、月次障害件数をゼロに削減

定量的な成果の書き方｜数字がないときの対処法

「自分の仕事は数値で表せない」と感じるエンジニアは少なくありません。しかし、数字がないのではなく、数字を探す視点が不足しているケースがほとんどです。次の問いを自分に向けてみてください。

• 処理速度・レスポンスタイムは改善したか？（〇%改善、〇秒から〇秒へ）
• バグ件数・障害発生率は変化したか？（月〇件から〇件へ削減）
• コードレビューやドキュメント整備で何人の工数を削減したか？
• 新機能の実装によって問い合わせ件数や作業時間に変化はあったか？

数値が出てこない場合は、「なぜその技術選定をしたか」「チームにどんな変化をもたらしたか」を言語化することで、定性的な成果として記載できます。「成果がない」のではなく、「成果の言語化ができていない」だけです。

職務経歴の良い例とNG例

スキル・技術スタック欄の書き方

採用担当者が技術スタックを見て判断すること

技術スタック欄でよく見られる書き方は「Java（5年）、Python（3年）、JavaScript（2年）、AWS、Docker、Kubernetes…」のように、使ったことのあるものをすべて並べるスタイルです。

この書き方の問題は、採用担当者が「実際にどのレベルで使えるか」を判断できない点にあります。5年の経験でも、業務の中心として使ったのか補助的に触れただけなのかでは、実力に大きな差があります。

経験年数より「実務でどう使ったか」を書く

技術スタック欄は、単純な羅列より「実務でどう使ったか」を添えるだけで評価が変わります。習熟度をレベル分けして記載する形式が、採用担当者には最も読みやすいです。

「基礎知識レベル」を正直に書くことで、面接での「実際に使ったことはありますか？」という問いに備えられます。採用担当者は正直に書ける人を信頼します。背伸びして書いた技術を面接で深掘りされると、一気に評価が下がります。

自己PRの書き方｜エンジニアが差をつける3要素

技術力だけでは差がつかない理由

エンジニアの自己PRで最も多いパターンは「〇〇という技術が得意です」「品質の高いコードを書くことができます」という技術力のアピールです。

技術力は選考の前提条件であって、差別化要因にはなりません。採用担当者は「この人がチームに入ったとき、どんな変化をもたらすか」を見ています。技術力を伝えることと、チームへの貢献を伝えることは、別の話です。

採用担当者に刺さるエンジニアの自己PRの3要素

採用担当者が自己PRに求めているのは、次の3要素のいずれか（または組み合わせ）です。

要素	内容	記述例
技術的リーダーシップ	チームの技術課題を解決したエピソード	コードレビュー文化の定着、技術的負債の解消を主導
事業理解と技術の橋渡し	ビジネス要件を技術に落とし込んだエピソード	営業要件を整理し、実装工数を30%削減できる設計を提案
チームの生産性向上	チーム全体のパフォーマンスを上げた行動	テンプレート整備で後輩のキャッチアップ時間を半減させた

GitHubやポートフォリオの記載方法

GitHubやポートフォリオサイトへのリンクを記載することは、エンジニアの職務経歴書において有効な差別化手段のひとつです。ただし、リンクを貼るだけでは評価につながりません。

採用担当者に「ここを見てほしい」という案内を添えることが必須です。リンク先のどのリポジトリが職務経歴書の記述と対応しているかを明示するか、代表的なコントリビューションを要約して記載してください。

GitHubのコミット頻度が著しく低い場合や、リポジトリが整備されていない場合は逆効果になることもあります。記載する前に、少なくとも代表的なリポジトリのREADMEが読める状態になっているかを確認してください。

職種・状況別の書き方のポイント

若手エンジニア（1〜3年目）の場合

経験が浅い段階では、職務経歴の「量」で勝負することはできません。代わりに、成長速度と自主的な行動を前面に出すことが有効です。

• 業務外でのアウトプット（個人開発、技術ブログ、OSSコントリビューション）があれば必ず記載する
• 「与えられた業務だけ」でなく「自分から動いた経験」を具体的に書く
• 取得資格・社内勉強会への参加や主催など、学習継続の姿勢を記載する

経験が少ないこと自体は減点要因ではありません。「この人は入社後に伸びる」と感じさせる記述が、若手の書類選考では最も効きます。

中堅エンジニア（4〜10年目）の場合

4年以上の経験がある場合、採用担当者は「技術が使えること」より「何をリードしてきたか」を見ています。実装力の証明より、リードの証明が優先されます。

• チームリード・技術選定・設計の主導経験を重点的に記載する
• 後輩育成やOJT経験がある場合は「何人に、どんな方法で」を具体的に書く
• 複数プロジェクトにわたって共通する「自分の戦略・スタイル」を自己PRで言語化する

フリーランス・副業経験がある場合

フリーランスや副業の経験は、クライアントとの直接折衝・要件定義・品質管理を自分で担った証拠として強みになります。機密保持の関係でクライアント名を明かせない場合は、「詳細は面接時にお伝えします」と注記した上で、業種・規模・技術スタック・成果を記載してください。

まとめ

• 職務経歴書で重要なのは「やったこと」ではなく「成し遂げたこと」を書くこと
• 採用担当者は30秒で「規模・役割・技術・成果」の4点を確認する
• 技術スタックは羅列するより「実務でどう使ったか」を添える形式が効果的
• 自己PRは技術力より「チームにどんな変化をもたらしたか」を伝える
• GitHubは「見てほしい箇所」を明示して初めて有効な差別化手段になる

職務経歴書は提出して終わりではありません。各応募先の求人要件に合わせて「規模・役割・技術・成果」の4点の強調ポイントを調整することで、通過率は大きく変わります。

職務経歴書に関するよくある質問

職務経歴書に決まったフォーマットはありますか？

決まった形式はなく、自由に作成できます。一般的にはWordやExcelで作成することが多いですが、PDF形式での提出を求める企業が増えています。エンジニア向けには、Googleドキュメントで作成し共有リンクで提出するケースも増えています。どの形式であっても、規模・役割・技術・成果の4点が読み取りやすいレイアウトにすることが最優先です。

プロジェクト経験が多い場合、何年分書けばいいですか？

原則として直近3〜5年を重点的に記載します。それ以前のプロジェクトは、応募先の求人に関連するものがあれば1〜2行の簡略記述で補足する程度にとどめてください。書類全体のボリュームはA4用紙2〜3枚が目安で、それ以上になると読み飛ばされるリスクが高まります。

成果が数値で表せない場合、どう書けばいいですか？

数値が出ない場合は「なぜその技術選定をしたか」「チームにどんな変化をもたらしたか」を定性的な成果として記載できます。例えば「コードレビュー文化を定着させ、リリース品質が安定した」「ドキュメント整備により、新メンバーのキャッチアップ期間が2週間から1週間に短縮された」という書き方です。自分の行動がチームや製品に与えた変化を振り返ると、必ず何かが見つかります。

エンジニアの職務経歴書は何枚が適切ですか？

A4用紙2〜3枚が一般的な目安です。経験が浅い場合でも1枚では情報量が不足することが多く、逆に5枚以上になると読んでもらえないリスクが高まります。情報量と読みやすさのバランスを保つためにも、記載するプロジェクトを絞り込み、2〜3枚にまとめることを目指してください。