エンジニアの職務経歴書は、採用担当者が読む順番に合わせて書くと、経験が伝わりやすくなります。読み手は、冒頭で応募要件に合うかを見て、プロジェクトで役割と成果を確かめ、技術スタックで即戦力かを判断します。
この順に「何を」「どの形で」書くかを、構成、プロジェクト欄、技術スタックの順に、書き換え例つきで説明します。
採用担当者は、職務経歴書の何を見ているのか
まず、読み手が何を重く見ているかを、数字で確かめます。dodaが2025年9月に、2024・2025年度に中途採用を行った企業の採用担当者2,000人へ行った調査です。
職務経歴書で最も重視する項目は、「職務経歴・職務内容」が43.4%でした。技術系（IT・通信）に絞ると、「職務経歴・職務内容」が45.0%、「活かせる知識・スキル」が22.3%です。
エンジニアの書類で見られているのは、自己PRの文章よりも、職歴とスキルの中身です。
1人の応募書類にかける時間は、最も多いのが「5分以上10分未満」で、職務経歴書では32.2%でした。「1分未満」は2.6%です。
数分は読まれますが、その数分で、面接に呼ぶかどうかが決まります。冒頭の欄ほど、読み手の判断に使われやすくなります。
マイナスの印象につながる項目は、「ミスや誤字・脱字が多い」が47.2%、「応募要件に合致しない」が45.1%でした（複数回答）。
担当者は、経験やスキルが自社の職務や課題に役立つかを見ています。職務経歴書では、経験・実績のマッチングが主な確認点で、志望動機との整合性も見られます。
読まれる順番に並べる：6つの欄の構成
職務経歴書の欄は、読み手が判断する順に並べます。リクルートエージェントのWebエンジニア向けの書き方と、ギークリーの解説を踏まえ、運営会社の採用支援の現場での読み方を重ねた構成が、次の表です。
| 順番 | 欄 | 読み手が判断すること | 書き方の目安 |
|---|---|---|---|
| 1 | 職務要約 | 応募要件に合う経歴か | 100文字程度。経験年数、分野、強みを1〜2文で |
| 2 | 活かせる経験・知識・技術 | 入社後に何ができるか | 応募先の求人に合わせて、箇条書きで3〜5項目 |
| 3 | テクニカルスキル | どの技術を、どの深さで使えるか | 言語・FW・DB・クラウドに分け、期間とレベルを表に |
| 4 | 職務経歴（会社・プロジェクト） | 役割と成果、再現できる強さ | 直近と注目案件を厚く。古い案件は短く |
| 5 | 自己PR | 仕事の進め方と、貢献の方向 | 箇条書きなら3つほど、文章なら5行以内 |
| 6 | 資格・業務外の取り組み | 学び続けているか | 業務に関係するものだけ |
職務経歴の書き方には、時系列で書く方法と、プロジェクトごとに書く方法があります。Web系のサービスエンジニアには、両者を組み合わせたハイブリッド型が一般的だと、ギークリーの解説は書いています。
ハイブリッド型は、会社ごとに概要を書いたあとに、見てほしいプロジェクトを2〜3件、時系列でまとめる形です。
どの案件も同じ厚さで書かないことが、読みやすさの要になります。
枚数に決まりはありません。編集部では、A4で2〜3枚に収まる量が、読み手の負担になりにくいと考えています。
プロジェクト欄の書き方：6項目で書く
職務経歴書の中心は、プロジェクトの欄です。リクルートエージェントは、担当したシステム、関わった工程、プロジェクト内での役割の3点は書くよう勧めています。
これに、規模と、課題・取り組み・成果を足した6項目で書きます。
- 概要：何のためのシステムか（誰が、何に使うか）
- 期間と規模：期間、チームの人数、自分の担当範囲
- 役割と工程：設計、実装、レビュー、運用のどこを担ったか
- 環境：言語、フレームワーク、DB、クラウド（バージョンつき）
- 課題・取り組み・成果：起点、判断の理由、数字で見た変化
最後の項目は、転職ドラフトの記事が、評価される職務経歴書の条件として挙げている点と重なります。何をしたかに加え、どう解決したかまで書き、課題・取り組み・成果に筋を通すことです。
次は、バックエンドの案件の書き換え例です。想定した例で、実在の案件ではありません。
悪い書き方です。
2022年4月〜2024年3月 ECサイトの開発。Java、Spring Bootを使用。バックエンドを担当しました。
何を作り、どこを担い、何が変わったかが読み取れません。
良い書き方です。
【概要】自社ECサイトの注文・決済機能の刷新（2022年4月〜2024年3月） 【規模・役割】開発メンバー8名（バックエンド4名）。注文APIの設計と実装を担当し、後半は新メンバー2名のコードレビューも担当 【環境】Java 17、Spring Boot 3、PostgreSQL 15、AWS（ECS、RDS）、GitHub Actions 【課題】決済の途中離脱で、在庫の引き当てだけが残る不整合が月10件前後発生し、カスタマーサポートが手作業で戻していた 【取り組み】引き当てを決済完了後に移す案と、期限つきで自動解放する案を比べ、決済事業者の仕様変更に強い後者を採用した。境界値のテストを追加し、レビューの観点にも加えた 【成果】不整合の発生を月10件前後から月1件未満に減らした。サポートの手作業は、導入前3か月と導入後3か月の記録を比べて確認した
良い書き方は、案件の目的、担当範囲、判断の理由、数字の測り方まで書いています。読み手は、そこから面接で聞く質問を作れます。
インフラの案件は、規模を数で書きます。リクルートダイレクトスカウトのサーバーエンジニア向けの解説は、チームの人数、予算、サーバー台数が、プロジェクトの大きさを伝えると書いています。
【概要】基幹システムのオンプレミスからAWSへの移行（2023年1月〜2024年6月） 【規模・役割】メンバー6名、サーバー約40台。移行の設計とネットワーク構成、切り替え手順書の作成を担当 【環境】Linux（RHEL 8）、Terraform、AWS（EC2、VPC、RDS）、Zabbix 【成果】切り替え作業時間を計画比で3割短縮し、移行当日の障害はなし
役割と担当を書かないと、強みが伝わりません。リクルートダイレクトスカウトの解説も、役割と担当業務の欠落を、よくある失敗に挙げています。
技術スタックは、表で「期間・レベル・業務かどうか」を分ける
技術の欄は、読み手が応募要件と照らして見る場所です。ギークリーの解説は、OS、言語、データベース、フレームワークに分けて、表か箇条書きでまとめることを勧めています。
書く項目は、ツール名、使えるようになってからの期間、どの程度扱えるかの3つです。
リクルートエージェントの解説は、レベルを「業務で即戦力になれる」「一人でアプリケーション開発ができる」のように、できることで表す例を示しています。
業務での経験と、業務外の経験は、分けて書きます。次が表の例です。
| 区分 | 技術 | 経験 | できること | 業務／個人 |
|---|---|---|---|---|
| 言語 | Java 17 | 4年 | 設計から実装まで1人で担当できる | 業務 |
| 言語 | TypeScript | 1年 | 既存コードの改修ができる | 個人開発・一部業務 |
| FW | Spring Boot 3 | 2年 | API設計と、テストの整備ができる | 業務 |
| DB | PostgreSQL 15 | 4年 | インデックス設計と、実行計画の確認ができる | 業務 |
| クラウド | AWS（ECS、RDS、S3） | 2年 | 構築と運用を担当できる | 業務 |
書き方で見られるのは、深さを自分で測れているかです。全部に「できる」と書くと、面接で深く聞かれたときに崩れます。
並び順は、応募先の求人票で求められている技術を上に置きます。バージョンまで書くと経験が伝わりやすくなり、固有名詞は公式サイトの正式な表記に合わせます。
AIコーディングツールの経験は、同じ表に加えることができます。ツール名だけでなく、課題・運用の決め事・数字・確認の4点で書く方法は、職務経歴書にClaude Codeをどう書く？に分けて書いています。
書類が面接の質問票になる：採用する側の読み方
運営会社の採用支援の現場では、職務経歴書は書類選考を通す資料であると同時に、面接官が質問を作る資料でもあります。
面接官は、書かれた1行ごとに「この数字は何と何を比べたのか」「この判断を、ほかの選択肢と比べてどう決めたのか」を考えながら読みます。
だから、説明できないことは書かないのが基本です。説明できない行は、深掘りされたときに、書類全体の信頼を下げます。
面接で聞かれやすい点は、次の4つです。
- その案件で、あなたが決めたことと、チームが決めたこと
- 数字の測り方（何と何を、いつ比べたか）
- うまくいかなかった点と、そのときの対応
- 同じ案件を、いまやるなら変えること
書類を書く段階で、各案件についてこの4つに答えられるか、声に出して確かめます。答えに詰まった行が、直す場所です。
減点される書き方6つと、直し方
これまでの調査や解説で、減点の原因として挙がっている書き方を、直し方とあわせて並べます。
| 減点される書き方 | 読み手が受け取ること | 直し方 |
|---|---|---|
| 誤字、年月、固有名詞の誤り | 確認の丁寧さに不安が残る（誤字は担当者の47.2%がマイナスと回答） | 提出前に、年月・金額・技術名の表記を公式の表記と突き合わせる |
| 応募要件との重なりが読み取れない | 要件に合致しない（担当者の45.1%がマイナスと回答） | 求人票の必須項目を、職務要約と技術の欄に入れる |
| 役割と担当が曖昧 | 強みが分からない | 「チームで開発」ではなく、自分が担った範囲を書く |
| 技術名の長い羅列 | 強みが埋もれる | 応募先に関係の深い技術を上にして、深さを添える |
| 感想の成果（「効率が向上した」） | 検証できない | 期間、件数、比べた相手をつけた数字にする |
| 他の書類との食い違い | 注意力と整合性に不安が残る | 履歴書と、年月、会社名、職位を突き合わせる |
役割の欠落と長い羅列は、リクルートダイレクトスカウトの解説が挙げている失敗です。他の書類との食い違いは、リクルートエージェントが提出前のチェック項目に挙げています。
感想の成果は、AIの普及で、さらに見られるようになりました。SHIFT AIが2026年5月に採用担当者503名へ行った調査では、AI書類と判断する理由として、中途採用担当の57.8%が「表現は洗練されているのに、具体的なエピソードや数字が伴っていない」を挙げています（複数回答）。
社名やサービス名を出せないときの書き方
守秘義務があり、社名やサービス名を書けない案件は多くあります。ギークリーの解説は、企業名や取り扱いサービス名は、秘密保持への配慮から具体名を避けるよう注意しています。
名称を伏せても、経験は伝わります。次の4つで置き換えます。
- 業界とシステムの種類（例：中堅メーカーの受発注システム）
- 利用者と規模（例：社内ユーザー約500名）
- 期間とチームの人数
- 自分の担当と、判断した範囲
数字も、勤務先の売上など公表されていないものは、割合や相対的な表現に置き換えます。「売上が伸びた」ではなく、「注文処理の時間が約3割減った」のように、自分の担当範囲で測れる数字を選びます。
案件が多い人は絞り、応募先ごとに出し分ける
案件が多い人は、全部を同じ厚さで書かず、見せる案件を絞ります。転職ドラフトの記事は、直近の経歴やアピールしたい経歴は詳しく書き、3年以上前や材料が弱いものは簡潔に書くよう助言しています。
同じ記事は、開発体制と使用技術の記載形式を、経歴書全体で揃えることも勧めています。形式が揃うと、読み手が案件を比べやすくなります。
編集部では、全案件を書いた「マスター」を1つ作り、応募ごとに見せる案件と並び順を入れ替える方法を勧めます。
マスターには、各案件の6項目（概要、期間と規模、役割、環境、課題・取り組み・成果）を、全部書いておきます。応募先の求人票を見て、要件に近い2〜3件を選び、職務要約の1〜2文を応募先に合わせて書き直します。
転職ドラフトの記事のデータでは、1案件あたりの平均記載文字数が平均以上のグループの指名数が、平均未満のグループの約2倍でした。東京勤務を希望するユーザーの、2023年1月以降の職務経歴を2026年8月26日時点で集計したもので、相関を示す数字であり、内定を保証するものではありません。
AI時代の職務経歴書で変わったこと
AI技術やツールの活用経験を、候補者の評価で重視する企業は増えています。ファインディが2025年7月に、同社のサービスを使う企業220社へ行った調査では、57.0%が重視していて、2月の前回調査の18.1%から増えました。
一方で、AIで整えた書類への目も厳しくなっています。SHIFT AIの同じ調査では、中途採用担当の52.0%が、AIで書いたと判断した書類で選考を落とした経験がありました。
Anthropicの応募者向け案内は、最初の下書きは自分で書き、推敲にAIを使うよう求めています。実際にはない経験をAIに作らせることは、禁じています。
AIは、文章を整える道具として使い、数字・固有名詞・役割は自分の記録で確かめるのが、安全な使い方です。AIが整えた文章は、面接で自分の言葉で説明できる範囲にとどめます。
全体の転職の進め方と、書類を出す時期の目安は、エンジニアの転職の流れと期間にまとめました。書類を整えたあとの転職先探しには、転職エージェントの面談も使えます。
提出前のチェックリストと、今日からの手順
提出の前に、次の6点を確かめます。リクルートエージェントの最終チェック項目をもとにしています。
- 誤字脱字、年月、金額、技術名の表記に誤りがない
- 職務要約が、応募先の要件に合う経験を、冒頭に書いている
- 各案件に、役割・規模・環境・成果がそろっている
- 数字に、期間と比べた相手が添えてある
- 履歴書と、年月・会社名・職位が一致している
- 書いた内容を、すべて自分の言葉で説明できる
今日30分でできることは、次の3つです。
- 直近の案件を1つ選び、6項目の記入欄を作って埋める
- 技術スタックを、区分・経験・できること・業務か個人かの表にする
- 作ったプロジェクト欄を声に出して読み、答えに詰まった行に印をつける
