エンジニア転職の職務経歴書の書き方【テンプレート・サンプル付き】

「職務経歴書に何を書けばいいかわからない」「サンプルを見ても自分の経歴にどう当てはめればよいか迷う」——エンジニア転職を始めた多くの方が、最初に直面する壁が職務経歴書の作成です。

エンジニアの職務経歴書は、一般的な事務職とは書き方が大きく異なります。扱った技術スタック・プロジェクトでの役割・成果を具体的な数値や事例で示す必要があり、書き方ひとつで書類選考の通過率が大きく変わります。同じ経歴でも、書き方が下手だと通らず、上手だと通る——これがエンジニア転職市場の現実です。

この記事では、エンジニア転職の職務経歴書について、必須6項目の構成・スキルセットの書き方・STAR記法を使ったプロジェクト経歴のサンプル・未経験者と経験者の書き分けまで、書類通過率を上げるための実践的なノウハウをまとめます。最後にチェックリストもあるので、提出前の確認にも使ってください。

エンジニア転職の職務経歴書が重要な理由

エンジニア転職において職務経歴書は、書類選考通過の鍵を握る最重要書類です。履歴書が経歴の事実を伝えるのに対し、職務経歴書は「何を・どうやって・どんな成果を出したか」を伝えるドキュメントです。採用担当者は主に3点を確認します。①扱える技術スタックの広さと深さ、②プロジェクトでの具体的な役割と実績、③キャリアの一貫性。これらが明確に書かれていない職務経歴書は、内容が良くても書類選考で落ちる可能性があります。逆に、これら3点をきちんと言語化できていれば、経験年数が浅くても通過率は大きく上がります。

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

履歴書と職務経歴書は、伝える情報の性質がまったく異なります。履歴書は「いつ・どこに所属したか」という事実を一覧化する書類で、フォーマットも定型です。一方、職務経歴書は「何をして、どんな成果を出したか」という実績を自由に表現する書類で、内容の質がそのまま評価につながります。

エンジニア採用では、履歴書よりも職務経歴書の比重が圧倒的に大きくなります。学歴や所属企業よりも「何を作ってきたか」が判断材料になるためです。年齢や前職の規模に自信がなくても、職務経歴書の書き方しだいで充分にカバーできます。

採用担当者が見ている3つのポイント

採用担当者は短い時間で多数の応募書類に目を通すため、最初の数十秒で「読み込む価値があるか」を判断します。このとき注目されるのが、技術スタックの一覧・プロジェクトの具体性・キャリアの一貫性です。

技術スタックは募集要項とのマッチ度を見られ、プロジェクト経歴は「実務で活躍できるか」を判断する材料になります。キャリアの一貫性は、転職理由や志望動機との整合性を含めて確認されます。この3点が冒頭で伝わる構成にできれば、書類選考の通過率は確実に上がります。

書類通過率に直結する書き方の差

同じ経歴でも、書き方の違いで通過率が2倍以上変わるケースは珍しくありません。差が出るのは「具体性」と「数値」の有無です。「Webアプリ開発に携わった」と書くか「月間100万PVのECサイトのフロントエンド改修を担当し、ページ表示速度を40%改善した」と書くかで、伝わる解像度はまったく違います。

エンジニア採用は応募者の母数が多く、抽象的な記述はそれだけで埋もれます。「自分の貢献」と「定量的な成果」を必ずセットで書く——これが書類通過率を上げる第一歩です。

職務経歴書の必須6項目と構成

エンジニアの職務経歴書には、業界共通の必須6項目があります。順番と構成を整えるだけで読みやすさが大きく変わり、採用担当者が情報を拾いやすくなります。ここでは各項目の役割と書き方のポイントを順に解説します。

1. 職務要約（200〜300字）

職務要約は、職務経歴書の冒頭に置く「自分のキャリアの要約版」です。200〜300字で、これまでのキャリア全体・主な技術領域・現時点での強みを一気に伝えます。

採用担当者はここで「読み進める価値があるか」を判断するため、最重要セクションです。「Webエンジニアとして5年、PHPとLaravelを軸にECサイト・予約システム等の自社開発を3件担当。直近2年はチームリーダーとして4名のメンバーマネジメントも経験」のように、年数・技術・役割・実績を簡潔に詰め込みます。長すぎず、しかし情報密度の高い文章を意識してください。

2. 職務経歴（時系列または逆時系列）

職務経歴は、所属企業ごとに在籍期間・事業内容・従業員規模・自分の所属部門・担当業務を一覧化します。直近の経歴ほど詳しく書くため、逆時系列（最新が上）にする企業が増えています。

各社の情報は、企業名・在籍期間・事業概要・資本金や従業員数・自分の役職を整理して書きます。後続のプロジェクト経歴とリンクしやすくするため、ここでは大枠だけを示し、具体的な技術や成果は次のプロジェクト経歴セクションに譲るのがポイントです。

3. プロジェクト経歴（5〜10件、STAR記法）

プロジェクト経歴は職務経歴書の中心であり、最もページ数を割くセクションです。直近5年程度から代表的なプロジェクトを5〜10件選び、STAR記法（Situation / Task / Action / Result）で記載します。

各プロジェクトには、概要・期間・自分の役割・チーム規模・使用技術・成果を明記します。「何をしたか」だけでなく「自分がチームの中で何を担い、どう貢献したか」が伝わる書き方が重要です。後述のサンプルを参照しながら、自分の経歴を当てはめてください。

4. スキルセット（言語・FW・DB・インフラ・ツール）

スキルセットは、扱える技術を一覧化したセクションです。言語・フレームワーク・データベース・インフラ・開発ツール・開発手法のカテゴリ別に整理します。

各スキルには「経験年数」と「自己評価レベル」を併記すると、採用側が判断しやすくなります。書きすぎ・書き不足のバランスが難しいポイントなので、次の専用セクションで詳しく解説します。

5. 資格・受賞歴・OSSコントリビューション

エンジニア特有の項目として、取得資格に加えて受賞歴やOSSへの貢献を書けます。基本情報技術者・応用情報技術者・AWS認定資格などの保有資格は積極的に記載しましょう。

技術コンテストの受賞、技術ブログの運営、OSSへのPull Request、登壇歴なども、可能なら必ず書いてください。これらは「業務外でも技術に取り組む姿勢」を示す強力な材料となり、特に成長意欲を重視する企業では評価されやすくなります。

6. 自己PR（強みと志望動機を結ぶ）

最後のセクションは自己PRです。これまでの経歴から導かれる強みを1〜2点に絞り、それが応募企業でどう活かせるかを300〜400字でまとめます。

「技術力・チームでの実績・キャリアの方向性」の3要素を盛り込み、志望動機との一貫性を持たせるのがポイントです。職務要約と内容が重複しないよう、要約は「何をしてきたか」、自己PRは「だから何が強みで、どう活かしたいか」と役割を分担させます。

スキルセットの書き方とサンプル

スキルセットはエンジニア職務経歴書の中で、採用担当者が最初に目を走らせる箇所です。募集要項とのマッチ度をここで判断するため、書き方ひとつで書類選考の合否が分かれます。情報の整理方法と表記の工夫が要点です。

スキルレベルの表記方法

スキルレベルは「経験年数」と「自己評価レベル」をセットで書くと、採用側に伝わりやすくなります。経験年数だけでは「触ったことがある」のか「実務で問題なく使える」のか判断できないからです。

自己評価レベルは、以下のような4段階表記が標準的です。

• レベル1（学習中）: 個人学習やチュートリアル経験あり
• レベル2（基本的な実装が可能）: 簡単な機能であれば自力で実装できる
• レベル3（実務レベル）: 一般的なプロジェクトで業務として使用してきた
• レベル4（指導・設計が可能）: 後輩への指導や技術選定・設計判断ができる

「Python 5年・レベル3」のように併記すると、採用側は具体的な期待値を持てます。

カテゴリ分けで整理する

スキルセットは、ジャンルごとに分けて表形式で書くと格段に読みやすくなります。一般的なカテゴリは以下の6つです。

カテゴリ	例
プログラミング言語	Python、TypeScript、Go、PHP、Java
フレームワーク	Django、React、Next.js、Laravel、Spring
データベース	PostgreSQL、MySQL、MongoDB、Redis
インフラ・クラウド	AWS、GCP、Docker、Kubernetes、Terraform
開発ツール	Git、GitHub、Jira、Slack、Notion
開発手法	アジャイル、スクラム、CI/CD、TDD

カテゴリを揃えておくと、募集要項のキーワードと照合しやすくなり、採用担当者の読み取りコストが下がります。

スキルセットのサンプル

実際の記載例は次のような形式です。

カテゴリ	スキル	経験年数	レベル
言語	Python	5年	実務レベル
言語	TypeScript	3年	実務レベル
FW	Django	4年	実務レベル
FW	React	2年	基本的な実装が可能
DB	PostgreSQL	5年	実務レベル
インフラ	AWS（EC2/RDS/S3）	3年	運用経験あり
ツール	Git / GitHub Actions	5年	実務レベル

書きすぎ・書き不足を避けるバランス

スキルセットでよくある失敗は、書きすぎと書き不足の両極端です。「触ったことがある」レベルの技術まで全部書くと、レベル感が信用されなくなります。逆に経験のある技術を絞りすぎると、実力よりも低く見られて損をします。

判断基準は「面接で深掘りされても説明できるか」です。技術名を挙げた以上、面接で「実際にどう使ったか」を聞かれる前提で考えてください。具体的な業務経験を1つでも語れる技術は書く、それ以下は書かない——この基準で取捨選択するのが安全です。

プロジェクト経歴をSTAR記法で書くサンプル

プロジェクト経歴は職務経歴書の中で最も読まれる部分であり、書類選考の通過率を最も左右するセクションです。エンジニア採用では「何をしてきたか」を具体的に伝える必要があり、ここで使えるフォーマットがSTAR記法です。

STAR記法とは

STAR記法は、以下の4要素でエピソードを構造化する手法です。

• S（Situation）: プロジェクトの背景・状況
• T（Task）: そのプロジェクトで自分が解決すべき課題
• A（Action）: 自分が実際に取った行動・技術選定
• R（Result）: その結果として得られた具体的成果

STAR記法に従って書くと、自然に「自分の役割」と「定量的成果」が浮かび上がるため、抽象的な記載を防げます。エンジニアの職務経歴書に最適なフォーマットです。

良い書き方の例

良いプロジェクト経歴の特徴は、以下の3点が明確であることです。

1. 自分の役割が明示されている（チームの成果と自分の成果が区別されている） 2. 技術選定の理由が説明されている 3. 成果が数値で語られている

例えば「APIのレスポンス改善を担当」だけでは弱く、「N+1問題が発生していたAPIに対し、Eager LoadingとRedisキャッシュを導入し、平均応答時間を800msから120msへ改善（85%短縮）」と書くと、読み手は実力を具体的にイメージできます。

悪い書き方の例

避けるべき書き方は、次のような特徴を持ちます。

• 「〜の開発に携わった」とだけ書かれ、役割が不明
• 主語が「チーム」になり、自分が何をしたのか伝わらない
• 技術スタックの列挙だけで、なぜそれを使ったかが書かれていない
• 成果が「効率化に貢献」など曖昧な表現になっている

これらに該当する記述は、可能な限り具体的な行動と数値に書き換えてください。「貢献」「効率化」「改善」といった抽象語を見つけたら、その裏にある具体的なアクションを掘り起こすチャンスです。

サンプル1: Web系自社開発エンジニア

■ プロジェクト名: 自社ECサイトの検索機能リプレイス
■ 期間: 2024年4月〜2024年9月（6か月）
■ 体制: 4名（PM 1、エンジニア 3）／自分の役割: テックリード兼バックエンド担当
■ 使用技術: Python 3.11 / FastAPI / PostgreSQL / Elasticsearch / Docker / AWS（ECS / RDS）

【背景（Situation）】
従来の検索機能はLIKE検索ベースで、商品数20万件のうち検索結果表示まで平均3秒かかり、
離脱率が高止まりしていた。CVR改善のため、検索体験全体のリプレイスが急務となった。

【課題（Task）】
全文検索エンジンの導入と、既存DBとのリアルタイム同期の仕組みを6か月以内に構築する。
ダウンタイムなしの切り替えと、検索応答1秒以内の実現が求められた。

【行動（Action）】
- 技術選定でElasticsearchとMeilisearchを比較し、日本語形態素解析の安定性からESを採用
- インデックス同期はLogstashではなく、コスト最適化のためPythonバッチで自前実装
- カナリアリリースで段階的に切り替え、影響範囲を限定

【成果（Result）】
- 平均検索応答時間: 3.0秒 → 0.4秒（87%短縮）
- 検索からの購入CVR: 1.8% → 2.7%（1.5倍）
- 月間検索ログを分析できる基盤を構築し、後続施策のPDCAを高速化

サンプル2: 受託SES経験者

■ プロジェクト名: 大手金融機関 顧客管理システムの機能追加
■ 期間: 2023年10月〜2024年6月（9か月）
■ 体制: 12名（PM 1、SE 5、PG 6）／自分の役割: SE兼開発リーダー（PG 3名のマネジメント）
■ 使用技術: Java 17 / Spring Boot / Oracle 19c / Jenkins / Gitlab

【背景（Situation）】
顧客の属性情報を扱う基幹システムに、新規キャンペーン機能を追加する案件。
既存システムが10年以上前のアーキテクチャで、影響範囲調査が大きな課題だった。

【課題（Task）】
既存影響を最小化しつつ、9か月で新機能をリリースする。
品質基準として、本番障害ゼロ・パフォーマンス劣化なしが必須要件だった。

【行動（Action）】
- 既存コードの依存関係を可視化し、影響範囲をドキュメント化して関係者と合意形成
- 新機能はFeature Toggle方式で実装し、本番影響を切り離せる設計を採用
- 開発リーダーとして、コードレビュー基準の策定と週次の品質指標レビューを主導

【成果（Result）】
- 計画通り9か月でリリース完了、本番障害ゼロを達成
- 影響範囲調査の手法を社内ナレッジ化し、後続案件で見積り工数を約20%削減
- PG 3名の若手メンバーが、独力でレビュー指摘に対応できるレベルまで成長

このようにSTAR記法でプロジェクト経歴を整理すると、自分が何をして、どんな成果を出したかが明確になります。当サイトでは執筆協力者の匿名事例として「同じ経歴でもSTAR記法で書き直したら、それまで通らなかった企業の書類選考に通った」というケースも報告されており、書き方の工夫だけで結果が変わることを示しています。

未経験・経験者別の職務経歴書の書き分け

職務経歴書は、書き手の立場によって重点を置くべきポイントが大きく違います。未経験者と経験者で何を強調するかを間違えると、せっかくの強みが伝わりません。それぞれの王道パターンを押さえておきましょう。

未経験者の書き方

未経験エンジニアの職務経歴書は、業務経験がない分、別の角度から「実力と熱意」を示す必要があります。中心になるのは、学習履歴・ポートフォリオ・転用可能スキルの3点です。

学習履歴は、独学・スクール・書籍・オンライン講座などを時系列で整理し、合計学習時間と扱った技術を明示します。「Pythonを6か月、約500時間学習し、業務自動化スクリプトを3本作成」のように、具体的な数値と成果物を必ずセットで書きましょう。

ポートフォリオは、職務経歴書の中で最大の差別化要素になります。GitHubのURL、使用技術、開発期間、工夫した点を1〜2件ほど詳しく記載し、面接で深掘りされても答えられる準備をしてください。

転用可能スキルは、前職での経験から「エンジニア職に活かせる要素」を抽出します。営業職ならヒアリング力、企画職なら論理思考、現場仕事ならチームでの段取り力など、どんな職種にも活かせる経験があります。前職を技術と無関係なものとして切り捨てず、エンジニア視点で価値を翻訳してください。

ポートフォリオの作り方はエンジニア転職のポートフォリオの作り方で詳しく解説しています。

経験者の書き方

経験者の職務経歴書では、実績の数値化・技術的深掘り・マネジメント経験の3点が評価軸になります。経験年数と扱える技術を持っている前提で見られるため、「ただ書いてある」だけでは差別化できません。

実績は必ず数値で語ります。「ユーザー数」「売上」「処理速度」「コスト削減」「障害対応件数」「メンバー育成数」など、自分の関わった指標を可能な限り定量化してください。社外秘で具体的な数値が出せない場合は、「約◯倍」「◯%」など丸めた数値でも構いません。

技術的深掘りは、なぜその技術を採用したか・どのような設計判断をしたかを言語化します。「ReactではなくVueを選んだ理由」「マイクロサービス化を見送った背景」など、選択の裏側を語れると技術的成熟度が伝わります。

マネジメント経験がある場合は、必ず別項目として書きましょう。何名のチームを、どの期間、どんな成果を出すまで導いたかを、定量的にまとめます。テックリード・スクラムマスター・採用面接官など、専門外の役割もすべて棚卸ししてください。

共通の注意点

立場に関係なく共通する注意点は、以下の3点です。

1. A4 2〜3枚に収める: 10年以上のキャリアでも、ボリュームの上限は4枚程度に。古い経歴は要約形式に圧縮 2. 誤字脱字を徹底チェック: 提出前に必ず印刷して声に出して読み返す、または第三者に校正を依頼する 3. PDFで提出する: 特に指定がなければPDF形式が安全。Word形式はレイアウトが崩れたり、改変履歴が残る可能性がある

転職活動全体の流れと面接対策はエンジニア転職の面接でよく聞かれる質問と対策で解説しています。

書類通過率を上げる5つのチェックポイント

職務経歴書を書き上げたら、提出前に必ず以下の5項目をチェックしてください。どれも基本ですが、抜け漏れがあると通過率が一気に下がる項目です。

1. 募集要項のキーワードを職務経歴書に含めているか

採用担当者は募集要項に挙げた技術スタックや業務経験で書類をフィルタリングします。職務経歴書の中に募集要項のキーワードが入っていないと、機械的にスクリーニングで落ちる可能性があります。

応募する企業ごとに募集要項を読み直し、自分の経歴と合致するキーワードがあれば必ず職務経歴書内に明示しましょう。テンプレートを使い回すのではなく、応募先ごとに少しずつカスタマイズすることが、書類通過率を上げる近道です。

2. 数値で実績を語っているか

「効率化に貢献」「品質を向上」といった抽象表現は、可能な限り数値に置き換えてください。「処理速度を3倍に向上」「障害発生率を月10件から月2件に削減」「メンバー4名のチームを2年間リード」のように、量・期間・割合を入れるのが鉄則です。

数値があると採用担当者は規模感を具体的にイメージでき、抽象表現の3倍の説得力を持ちます。社外秘で具体数値が書けない場合も、「約」をつけた概算で構いません。

3. 主語が「私は」で一貫しているか

エンジニアの仕事はチームでの取り組みが多く、油断すると主語が「チーム」になりがちです。すると、自分が何をしたのかが見えなくなります。

職務経歴書では、主語は徹底して「私」に統一しましょう。「チームでAPI改修を行った」ではなく「私はAPI改修プロジェクトでバックエンド設計を担当し、メンバー3名のレビューを取りまとめた」と書きます。チームの成果と自分の成果を明確に切り分けるのが、信頼される書き方です。

4. 誤字・脱字・表記揺れがないか

技術用語の表記揺れは、エンジニアの職務経歴書でよくあるミスです。「JavaScript」と「Javascript」、「PostgreSQL」と「Postgresql」、「GitHub」と「Github」など、正式表記を統一してください。

誤字脱字のある職務経歴書は、技術職としての注意深さを疑われます。提出前に印刷して読み直し、できれば一晩寝かせてから再チェックすることをおすすめします。

5. ファイル名は適切か

提出する職務経歴書のファイル名は、「氏名_職務経歴書_YYYYMMDD.pdf」のような形式が標準です。「shokumu.pdf」「最新版.pdf」のような名前は、採用担当者がファイル管理で困ります。

採用担当者は数十人〜数百人分の応募書類を扱うため、ファイル名で氏名と書類種別がすぐにわかるようにしておくのは最低限のマナーです。小さなことですが、こうした配慮が読み手の心証を確実に上げます。

具体的な志望動機の書き方はエンジニア転職の志望動機の書き方・例文も参考にしてください。

FAQ

職務経歴書は何枚以内にまとめるべきですか？

A4で2〜3枚が一般的です。10年以上の経験があっても4枚を超えると採用担当者が読み切れないリスクがあります。直近5年の経験を中心に、古い経歴は要約形式にまとめましょう。冗長な記載を削り、各プロジェクトのSTAR要素を簡潔にまとめることで、読みやすさと情報量を両立できます。

スキルセットに何を書けばよいですか？

業務で使った言語・フレームワーク・DB・インフラ・開発ツールを網羅的に記載します。各スキルに「経験年数」と「自己評価レベル（実務可能・運用経験あり等）」を付けると、採用側が判断しやすくなります。レベル感の判断基準は「面接で深掘りされても説明できるか」です。説明できない技術は書かない方が安全です。

プロジェクト経歴に書ける案件がない（社内SE等）の場合はどう書きますか？

一つの仕事を複数の「役割・成果」単位に分解して記載できます。例えば「社内システム保守」なら、改修・運用・障害対応・新規機能追加など、それぞれの成果を別項目として書くと内容が充実します。日々のルーティン業務でも、改善した点・効率化した数値・対応した障害件数などを言語化すれば、立派なプロジェクト経歴になります。

未経験エンジニアの職務経歴書には何を書けばよいですか？

学習履歴（独学・スクール）、作成したポートフォリオ、前職での転用可能スキル（論理思考・プロジェクト管理・コミュニケーション）を中心に構成します。学習に費やした時間・取り組んだ技術を具体的に書くと意欲が伝わります。ポートフォリオは1〜2件を深く説明し、GitHubのURL・使用技術・工夫した点を明示すると評価につながりやすいです。

職務経歴書はWordとPDFどちらで提出すべきですか？

指定がなければPDFが推奨です。レイアウト崩れがなく、改ざんもされにくいためです。ファイル名は「氏名_職務経歴書_YYYYMMDD.pdf」のように整理した形式が好印象です。Word形式での提出を指定された場合のみWordで送り、その場合も提出前に他のPCで開いてレイアウトが崩れていないか確認しましょう。

エンジニア転職におすすめの転職サービス

エンジニア転職を成功させる近道は、業界特化型のエージェントを活用することです。当サイトが特にお薦めするのは、ITエンジニア転職特化の TechGo（テックゴー）です。無料で相談・登録できます。

ゲーム・エンタメ業界特化の Anykan、AI・データサイエンス未経験者向けの Neuro Dive を含めた4社の徹底比較は エンジニア転職エージェントおすすめ4選 徹底比較 で詳しく解説しています。状況別の最適な1社診断も用意しているので、自分にぴったりの選択肢を見つけたい方はあわせてご覧ください。

職務経歴書の添削や求人紹介まで受けたい場合は、目的に合ったエージェントを選ぶことが近道です。主要なサービスを比較したい方はIT転職エージェントおすすめ6社比較も参考にしてください。

TechGo（テックゴー）の詳しい評判・口コミはTechGo（テックゴー）の評判・口コミで解説しています。レバテックキャリアとの違いが気になる方はTechGoとレバテックキャリアの比較もあわせてご覧ください。

まとめ

エンジニア転職の職務経歴書は、必須6項目（職務要約・職務経歴・プロジェクト経歴・スキルセット・資格・自己PR）の構成と、STAR記法によるプロジェクト記述で大きく変わります。

書類通過率を決めるのは、特別な経歴ではなく「数値による具体性」と「キャリアの一貫性」です。同じ経歴でも、書き方を変えるだけで通る企業・通らない企業が入れ替わります。

最後にもう一度、書類通過率を上げる核となるポイントを振り返ります。

• 必須6項目を順序通り構成する: 職務要約から自己PRまで読み手の負担を最小化
• STAR記法で自分の役割と成果を明示する: チームの成果と自分の貢献を区別
• スキルセットには経験年数とレベルを併記する: 募集要項のキーワードと照合可能に
• 数値で実績を語る: 抽象表現は具体的な指標に置き換える
• 未経験者はポートフォリオと学習履歴で実力を示す: 業務経験の不足を補う

職務経歴書ができたら、ポートフォリオ・志望動機・面接対策と合わせて準備を進めましょう。

• エンジニア転職のポートフォリオの作り方
• エンジニア転職の志望動機の書き方・例文
• エンジニア転職の面接でよく聞かれる質問と対策

書類が整えば、面接の準備にも余裕が生まれます。一つひとつの書類に「自分の言葉」で向き合うことが、納得できる転職への最短ルートです。

START

あなたの“働く”を、今日からシフトする

診断ツールで向いている仕事を知る。気になることは気軽に相談。

最適な職業を診断する