エンジニアの職務経歴書の書き方【見本・テンプレ付き】
最終更新: 2026年6月 | 書類選考突破率を上げる職務経歴書のコツ
【直答】エンジニアの職務経歴書はどう書けば書類選考を突破できる？
結論: 成果を改善前後の数値で示し、使用技術を規模感とともに書くこと。同じ経歴でもこの2点で通過率は変わります。
- ・構成は職務要約・技術スキル一覧・職務経歴・自己PR・保有資格/OSSの5ブロック。分量はA4で2〜3枚（経験10年以上でも最大4枚）、直近3〜5年を厚く書く。
- ・成果はSTARフレームワークで整理し、改善前後の数値か改善率で示す（例：レスポンスを200ms→50msに改善）。
- ・使用技術は経験年数・習熟度・規模感をセットで記載。1通を全社に使い回さず、職務要約と自己PRは応募先ごとに微調整する。
エンジニア転職では、職務経歴書が最初の関門です。技術力を持っていても、その伝え方を誤ると書類選考で落ちてしまいます。逆に、同じ経歴でも「成果を数値で示す」「使用技術を規模感とともに書く」だけで通過率は変わります。
本記事では、30代・40代エンジニアが書類選考を突破するための職務経歴書の書き方を、職務要約・職務経歴・スキル一覧・自己PRそれぞれのBefore/After例文、STARフレームワーク、成果の数値化フレーズ、避けるべきNG例まで、そのまま使えるテンプレートとして解説します。
データ調査時点: 2026年6月 ｜ 出典: 各IT転職エージェント公開情報、厚生労働省 job tag
求人数・年収などの数値は調査時点の公開情報に基づきます。最新の情報は各サービスの公式サイトをご確認ください。 当サイトの評価基準は記事制作ポリシーをご覧ください。
1. 職務経歴書の全体像と適切な分量
エンジニアの職務経歴書は、次の5ブロックで構成するのが基本です。採用担当は上から順に読むため、最初の「職務要約」で興味を引けるかどうかが通過率を大きく左右します。
職務要約（サマリー）
3〜5行でキャリア全体を要約。得意分野・経験年数・実績のハイライトを凝縮する。採用担当が最初に読む最重要ブロック。
技術スキル一覧
言語・フレームワーク・インフラ・ツールをカテゴリ別に整理。経験年数と習熟度を併記する。
職務経歴（直近から逆時系列）
各社の事業概要、在籍期間、担当プロジェクト、役割、使用技術、課題、成果（数値）を記載。
自己PR
技術的な強み・マネジメント経験・ビジネス貢献を3点程度に絞ってアピール。
保有資格・OSS・GitHub・登壇
関連資格、OSS貢献、個人開発、技術ブログ、登壇のURLを記載。
分量の目安：A4で2〜3枚（経験10年以上でも最大4枚）。直近3〜5年を厚く、それ以前は概要のみに。厚生労働省 job tag によれば「システムエンジニア（受託開発）」の平均年齢は37.1歳（令和7年賃金構造基本統計調査ベース）と、ミドル層が中核を担う職種です。経験が長い分、取捨選択して「読ませる」構成が重要になります。
2. 成果を語るSTARフレームワーク
職務経歴や自己PRで成果を書くときは、STARフレームワークに沿って整理すると説得力が一気に高まります。「何をしたか」だけでなく「どんな状況で・なぜ・どうやって・結果どうなったか」を順に示すことで、再現性のある実力として伝わります。
Situation（状況）
プロジェクトの背景・課題が生まれた状況。「月間100万PVのECで、ピーク時にAPIが頻繁にタイムアウトしていた」
Task（課題）
自分が担うべき具体的な目標。「レスポンス遅延を解消し、ピーク時の離脱を防ぐこと」
Action（行動）
実際に取った技術的アクション。「N+1解消、Redisキャッシュ導入、スロークエリのインデックス再設計を主導」
Result（結果）
数値で示す成果。「平均レスポンスを200ms→50msに改善し、ピーク時のエラー率を1.2%→0.1%に低減」
STARで書いた一文の例：「ピーク時にAPIタイムアウトが多発していた課題に対し（S/T）、N+1解消・Redisキャッシュ導入・インデックス再設計を主導し（A）、平均レスポンスを200ms→50msに改善、エラー率を1.2%→0.1%に低減した（R）。」
3. 職務要約の記入見本（Before/After）
Before（避けたい例）
Web開発の経験があります。JavaScriptやPythonが使えます。チームでの開発経験もあります。コミュニケーション能力が高く、チームワークを大切にしています。新しい技術の習得にも意欲的です。
→ 経験年数・プロジェクト規模・成果が不明。どの企業にも送れる汎用文で、印象に残らない。
After（30代バックエンドエンジニアの例）
Webアプリケーション開発に8年従事。直近5年はTypeScript／Node.jsとGoによるバックエンド開発をリードし、月間100万PVのECサイトのAPI設計・実装を担当。5名チームのテックリードとして技術選定・コードレビュー・育成を担い、リリースサイクルを月次→週次に短縮。AWS上のインフラ設計・運用にも携わり、月額インフラ費用を約30%削減しました。
→ 経験年数・主要技術・規模・役割・具体的な成果が1段落に凝縮されている。
4. 職務経歴の記入見本（Before/After）
各プロジェクトは「期間・プロジェクト・チーム規模・役割・使用技術・課題・成果」の項目で揃えると読みやすくなります。
Before（避けたい例）
ECサイトの開発を担当しました。バックエンドのAPIを作ったり、パフォーマンスの改善をしたりしました。チームで協力して開発を進めました。
→ 規模・役割・成果が曖昧で、本人が何をしたのか判断できない。
After（プロジェクト記載のテンプレート）
5. スキル一覧の記入見本（Before/After）
Before（避けたい例）
Java, Python, JavaScript, TypeScript, Go, Ruby, PHP, SQL, HTML, CSS, AWS, Docker, Kubernetes, Git ……
→ ただの羅列で、どれを実務でどこまで使えるのかが伝わらない。
After（カテゴリ＋習熟度を併記）
→ 「TypeScript（3年／業務メイン／月間100万PVのWebアプリ）」のように規模感まで添えると、さらに実力が伝わります。
6. 自己PRの記入見本（Before/After）
Before（避けたい例）
私は責任感が強く、最後までやり遂げる力があります。チームワークを大切にし、コミュニケーションを重視しています。新しい技術にも積極的に挑戦します。
→ 抽象的な性格描写のみで、エンジニアとしての裏づけが一切ない。
After（STAR＋数値で裏づけ）
強み：技術課題を事業成果に接続する力。前職ではピーク時のAPIタイムアウトが離脱の主因となっていた状況に対し、N+1解消とキャッシュ導入を主導し、レスポンスを200ms→50msに改善。結果としてピーク時のエラー率を1.2%→0.1%に下げ、決済完了率の改善に貢献しました。技術選定では「なぜその技術か」をチームに言語化して共有することを重視しており、5名チームのレビュー文化づくりにも取り組みました。
→ 強みを一言で示し、STARで裏づけ、数値で締める。再現性のある実力として伝わる。
7. 成果の数値化フレーズ集
「改善した」を数値に置き換えるだけで説得力が変わります。下表の左（曖昧表現）を、右（数値化した書き方）に変換しましょう。改善前後の値か改善率を入れるのがコツです。
Before：APIのレスポンスを改善した
After：主要APIの平均レスポンスタイムを200ms→50msに改善（75%削減）。N+1クエリの解消とキャッシュ層の導入が主因。
Before：テストを書いて品質を上げた
After：テストカバレッジを40%→80%に引き上げ、本番障害の月次発生件数を6件→1件に削減。
Before：リリースを速くした
After：CI/CDを整備しデプロイを手動週1回→自動で週3回に高速化。リードタイムを平均5日→1.5日に短縮。
Before：インフラのコストを下げた
After：AWSのリソース最適化とリザーブドインスタンス導入で月額インフラ費用を約30%削減（年間換算で数百万円規模）。
Before：売上に貢献した
After：決済導線のUX改善でCVRを2.1%→2.6%に向上させ、月間売上の約12%増に寄与。
Before：後輩を育成した
After：新メンバー3名のオンボーディングを設計し、立ち上がり期間を平均3ヶ月→1.5ヶ月に短縮。
※ 数値は記載例です。ご自身の実績に置き換えてください。守秘義務に触れる具体的な金額・社名は、概算や比率にぼかして記載しましょう。
8. やってはいけないNG例3つ
NG1：スキルの羅列だけで終わる
言語やツール名を並べるだけでは、習熟度も実務経験も伝わりません。必ず『経験年数・習熟度・使用規模』をセットにします。
NG2：成果がすべて定性表現
『改善した』『貢献した』だけでは比較も評価もできません。改善前後の数値か改善率を入れ、STARで状況と行動も添えます。
NG3：1通を全社に使い回す
応募先の技術スタックや求めるスキルに合わせて、強調するプロジェクトや表現を調整しないと『刺さらない』書類になります。最低でも職務要約と自己PRは応募先ごとに微調整しましょう。
9. 提出前チェックリスト
提出前に次の項目を確認しましょう。1つでも欠けていると、書類選考の通過率が下がる原因になります。書き上げた直後ではなく、一晩おいて読み返すと粗が見つかりやすくなります。
- ✓職務要約の3〜5行だけで、得意分野・経験年数・代表的な成果が伝わる
- ✓すべての主要成果に改善前後の数値か改善率が入っている
- ✓使用技術に経験年数・習熟度・規模感が添えられている
- ✓直近3〜5年が厚く、それ以前は概要に圧縮されている
- ✓自己PRが性格描写ではなく実績の裏づけで構成されている
- ✓応募先の技術スタックに合わせて職務要約・自己PRを微調整した
- ✓誤字脱字・表記ゆれ（半角全角、英大文字小文字）がない
- ✓社名や内部数値など守秘義務に触れる情報を出していない
自分でのチェックに加えて、第三者の目を通すと精度が上がります。IT特化型エージェントの添削は、応募先の評価ポイントを踏まえた指摘が受けられるため、独力で書くより通過率を高めやすいのが利点です。
10. 30代・40代の職務経歴書の勘所
30代：技術の幅とリード経験を両輪で示す
30代は実装力に加えて、技術選定・レビュー・小規模チームのリードを担えることを示すと評価が上がります。直近のプロジェクトでの『意思決定の中身』を具体的に書きましょう。関連: 30代エンジニアの転職。
40代：マネジメントと再現性のある実績を前面に
40代は『チーム・プロダクト・事業にどう貢献したか』が重視されます。プレイヤー実績だけでなく、組織課題をどう解決したかをSTARで整理しましょう。関連: 40代エンジニアの転職、40代転職のリアル。
経歴が長い分、取捨選択が命
10年以上のキャリアを全部詳細に書くと読まれません。直近3〜5年を厚く、それ以前は1〜2行の概要に圧縮。応募先に関係の薄い経験は思い切って削りましょう。
11. よくある質問
Q. 職務経歴書の適切な長さは？▾
Q. 使用技術の書き方にコツはありますか？▾
Q. プロジェクト経験はどのように書くべきですか？▾
Q. 転職回数が多い場合はどう書くべきですか？▾
Q. GitHubやポートフォリオは記載すべきですか？▾
Q. ブランク期間がある場合はどう説明しますか？▾
Q. 職務経歴書の添削はどこで受けられますか？▾
職務経歴書のプロ添削を無料で受けよう
IT特化型エージェントに登録すれば、エンジニアの職務経歴書に精通したアドバイザーが無料で添削してくれます。
おすすめエージェントランキングを見る