職務経歴書の書き方ガイド

エンジニアの職務経歴書の書き方ガイド採用側の視点と、セクション別のNG/GOOD例文つき

職務経歴書は、転職活動で最初に評価される「あなたの仕事のポートフォリオ」です。このガイドでは、ITエンジニアが書類選考を通過するための書き方を、採用側の視点と具体例つきで解説します。

読みながらそのまま作成ツールで書き進められる構成になっています。

30秒
一次スクリーニングで書類が読まれる時間
2〜3枚
職務経歴書のちょうどいい分量
5部構成
要約・スキル・経歴・資格・自己PR

職務経歴書と履歴書の違い

ポイント

履歴書は「事実の確認」、職務経歴書は「能力のプレゼン」。エンジニア採用の合否は職務経歴書でほぼ決まります。

デスクで職務経歴書を書いているエンジニアのイラスト

履歴書が「学歴・職歴の事実を時系列で示す公的フォーマット」であるのに対し、職務経歴書は「何ができる人か」を自由形式でプレゼンする書類です。エンジニア採用では履歴書はほぼ形式的な確認にしか使われず、書類選考の合否は職務経歴書(またはスキルシート)で決まります。

自由形式だからこそ差がつきます。「事実の羅列」で終わっている書類と、「読み手が知りたい順に、根拠つきで能力を示した」書類では、同じ経歴でも通過率が大きく変わります。

履歴書そのものの書き方(学歴は大学卒業からでよい・写真は指定がない限り不要など)は履歴書の書き方ガイドにまとめています。

採用担当者はここを見ている

ポイント

最初の30秒で見られるのは4箇所だけ。「冒頭の要約」と「直近案件」に全力を注ぐのがセオリーです。

採用担当者が職務経歴書を読み込んでいるイラスト

職務要約

冒頭200〜400字で「経験年数 × 領域 × 直近の役割」が読み取れるか

直近1〜2案件の内容

募集ポジションと重なる経験があるか。古い案件はほぼ読まれない

技術スタックと習熟度

求人要件の必須スキルを満たしているかを機械的にチェックされる

定量的な成果

「改善した」ではなく「何をどれだけ改善したか」の数字

基本構成と各セクションの書き方

ポイント

標準は5部構成。赤いブロック(職務要約・職務経歴)から先に磨くのが効率的です。

セクションごとに整理された書類とペンのイラスト
職務経歴書
1職務要約
2保有スキル
3職務経歴
4保有資格
5自己PR
1
職務要約200〜400字。最初に読まれる最重要パート
2
保有スキルカテゴリ別に「年数×習熟度」で一覧化
3
職務経歴案件単位で逆時系列。直近を厚く書く
4
保有資格関連する資格だけを新しい順に
5
自己PR強み×エピソード×再現性のセットで

※ 赤いブロック(職務要約・職務経歴)が評価の8割を決めます

職務要約 — 「誰か」が3行でわかるように

最初に読まれる最重要パートです。「経験年数」「領域」「直近の役割」「強み」を1段落に凝縮します。

× NG真面目にコツコツと開発に取り組んできました。様々な言語を経験しており、チームワークを大切にしています。
◎ GOODWebアプリケーションエンジニアとして約7年の実務経験。SIerで金融系業務システムの開発に従事した後、 自社ECサイトおよびSaaSプロダクトの開発・運用を担当。要件定義から運用保守まで一貫した経験を持ち、 直近2年はフロントエンドリードとして5〜8名のチームマネジメントも担当。

保有スキル — 「年数 × 習熟度」で盛らずに書く

言語・フレームワーク・DB・インフラ・ツールのカテゴリに分け、それぞれ経験年数と習熟度を添えます。重要なのは習熟度の基準を明記することです(例: ★★★=独力で実装可、★★★★=設計・技術指導可)。

基準のない自己評価は読み手が信用できず、面接で厳しく検証される原因になります。

職務経歴 — 案件ごとに「規模・役割・技術・成果」

案件単位で、①期間、②業界・案件概要、③チーム規模と自分の役割、④使用技術、⑤担当業務、⑥成果を書きます。新しい案件から書く「逆時系列」が現在の主流です。

成果は必ず数字で語ります

× NGパフォーマンス改善を担当し、サイトの高速化に貢献した。
◎ GOODCore Web Vitals改善を主導(LCP 4.2s → 1.8s、CLS 0.25 → 0.02)。改善後のCVRが+12%となり、 事業指標への貢献を定量的に確認した。

保有資格 — 関連するものだけを新しい順に

IT系資格(基本情報・応用情報・AWS認定など)と、ポジションに関連する資格のみで十分です。資格がなくても、実務経験が具体的であれば大きなマイナスにはなりません。

自己PR — 強みを「エピソード+再現性」で

「強みの宣言→裏付けエピソード→入社後どう活かすか」の3点セットを、強み2〜3個ぶん書きます。職務経歴に書いた事実と紐づいていることが重要で、経歴と無関係な抽象的な長所(明るい・努力家など)は不要です。

エンジニアならではのポイント

担当工程を明示する

「要件定義〜運用保守」のどこを担当したかで評価が変わる。SIer系・受託系の選考ではとくに重視される

技術スタックは構成まで

「React」より「Next.js 14(App Router)/ React 18 / TypeScript」。具体的なほど実在の経験として伝わる

GitHub・記事のリンク

公開できるアウトプットは必ず載せる。Web系企業では書類の信頼性を大きく補強する

提出形式はPDFが基本

レイアウト崩れを防ぐためPDF提出が基本。エージェント経由ではWord/Excel形式を求められることも

よくあるNG例

全案件が同じ粒度で5枚超

直近・関連案件を厚く、古い案件は2〜3行に。全体で2〜3枚が目安

「担当業務」しか書かれていない

やったこと(作業)だけでなく、工夫と成果(結果)を書く

習熟度の自己評価が過大

面接は書類の検証の場。1つでも「盛り」が見つかると全体の信頼が崩れる

専門用語・社内用語の説明なし

一次スクリーニングは非エンジニアが行う場合もある

応募先ごとのカスタマイズなし

少なくとも職務要約と自己PRは募集ポジションに合わせて調整を

よくある質問

Q.何枚にまとめるべき?

2〜3枚が目安です。経験が長い場合も、直近案件を厚くして古い案件を圧縮すれば収まります。1枚のサマリー版を別途用意しておくと、カジュアル面談やスカウト返信で重宝します。

Q.経験が浅い(1社・少数案件)場合は?

案件数の少なさは工夫の深掘りでカバーします。1案件の中でのフェーズごとの役割変化、改善提案、学習したことを分解して書けば、十分な情報量になります。個人開発や学習アウトプットも「ポートフォリオ」として堂々と載せてOKです。

Q.転職するか未定でも書く意味はある?

あります。職務経歴書は「キャリアの棚卸し」そのものなので、書くことで自分の市場価値と足りない経験が可視化されます。半年に1回の更新をおすすめします。

読みながら、そのまま作ってみましょう

このサイトの作成ツールは、本ガイドの構成(職務要約・スキル・案件・資格・自己PR)に沿った ステップ入力で、テンプレート10種からPDF出力まで無料で使えます。データはブラウザ内にのみ保存されます。

おすすめ記事

記事の一覧へ →