エンジニア転職の職務経歴書｜採用担当者が通過させる書き方と落とし穴

この記事では、エンジニアが転職で職務経歴書を書く際に採用担当者が重視する3つのポイントを解説します。スキル表記・プロジェクト経歴の書き方と、書類で落とされやすいNG例を具体的な例文とあわせて紹介します。

エンジニアの職務経歴書が採用を左右する理由

書類選考の通過率はエンジニア職でも決して高くありません。技術力があっても、職務経歴書の書き方次第で書類選考の段階で落とされるケースが多くあります。採用担当者は1枚の書類を平均30秒程度しか確認しないと言われており、最初の数秒で面接を設定するかどうかの判断がほぼ決まります。

技術力そのものは面接で初めて評価されますが、書類の段階では「面接を設定する価値があるか」を判断されています。職務経歴書は自分の市場価値を証明する文書として機能するものです。

採用担当者が書類審査で最初に確認する3つの項目

採用担当者がエンジニアの職務経歴書を手にしたとき、まず目を向けるのは次の3点です。

履歴書と職務経歴書の役割の違いを理解する

転職活動では履歴書と職務経歴書の両方を提出するのが一般的ですが、この2つの役割は明確に異なります。

書類	役割	記載内容
履歴書	基本情報と経歴の概要を伝える	氏名・住所・学歴・職歴・資格・志望動機など
職務経歴書	スキルと実績を具体的に証明する	プロジェクト詳細・技術スタック・担当範囲・自己PRなど

エンジニアの場合、採用可否に直接影響するのは職務経歴書の完成度です。履歴書は「基本情報の確認」、職務経歴書は「即戦力かどうかの評価」という役割分担を理解したうえで作成することが前提になります。

エンジニアの職務経歴書の基本構成と各項目の役割

エンジニアの職務経歴書はA4で2〜4枚が標準です。経験年数が3年未満であれば2枚、5年以上であれば3〜4枚を目安にします。フォーマットはWordまたはPDFが一般的で、以下の4項目が基本の構成になります。

①職務要約（5行以内で完結させる）

職務要約はページ最上部に記載する自己紹介文です。「誰が・何を・どんな規模で・どんな成果を出したか」を5行以内に収めるのが基本です。採用担当者はここを読んで書類全体を読み進めるかどうかを判断します。

よく見られる失敗は「Webアプリケーション開発に長年携わってきました」のような漠然とした書き方です。「長年」では年数が伝わらず、「Webアプリケーション」だけでは何を得意とするエンジニアかが判断できません。職務要約は書類の「見出し」として機能するものです。

②職務経歴（プロジェクト単位で記載する）

職務経歴は、勤務した企業ごとではなくプロジェクト単位で記載するのがエンジニアの職務経歴書の基本です。各プロジェクトに以下の情報を記載します。

• プロジェクト概要：何を開発したか（システムの種類、規模、ユーザー数など）
• 担当期間：YYYY年MM月〜YYYY年MM月
• チーム規模と自分のポジション：「5名チームのバックエンドリード」「10名PJのメンバー」など
• 担当フェーズ：要件定義・基本設計・詳細設計・実装・テスト・運用保守のうちどれか
• 使用技術：言語・フレームワーク・DB・インフラ・ツールなど
• 実績・貢献：数値で表現できる成果

③テクニカルスキル一覧（スキルマップ）

テクニカルスキル一覧は、保有する技術スキルをカテゴリ別に整理したものです。採用担当者が求人票と照合しやすいよう、表形式でまとめるのが一般的です。

カテゴリ	スキル・ツール	補足
プログラミング言語	Python、Java、TypeScript など	経験年数と主力かどうかを明記
フレームワーク	React、Django、Spring Boot など	実務使用歴を記載
DB・ストレージ	PostgreSQL、MySQL、Redis など	設計経験の有無も記載
インフラ・クラウド	AWS（EC2/RDS/S3）、GCP など	構築・運用経験の有無
その他ツール	Git、Docker、Kubernetes など	実務での使用実績

④自己PR

自己PRは「技術スキルの再説明」ではなく、「入社後にどんな価値を提供できるか」を伝える項目です。多くのエンジニアが技術スタックの繰り返しを自己PRとして書いていますが、採用担当者が評価するのは技術力をどう使ってチームや事業に貢献できるかという視点です。

【項目別】採用担当者が通過させる書き方と例文

職務要約の書き方｜冒頭3行で印象は決まる

職務要約は「私の職歴を読めばわかる」という縮図ではなく、採用担当者に「この人の面接を設定したい」と思わせるための見出しです。書き方のポイントは3点です。

• 専門領域を1文で定義する：「〇〇を得意とする△△エンジニア」という形式で開始する
• 経験の規模感を数字で伝える：「開発経験8年、うち5年はバックエンドのチームリード」など
• 貢献できることで締める：「貴社の〇〇領域で即戦力として貢献できます」という方向性を示す

プロジェクト経歴の書き方｜担当フェーズと役割を明確に

プロジェクト経歴は、職務経歴書の中で採用担当者が最も時間をかけて読む項目です。ここで大切なのは「何をしたか」ではなく、「どんな規模・役割で・何を達成したか」を伝えることです。

プロジェクトの記述は時系列（新しい順）に並べるのが一般的ですが、直近のプロジェクトほど詳しく書き、古いプロジェクトは2〜3行に圧縮するとコンパクトにまとまります。

テクニカルスキルの書き方｜スキルレベルを正確に伝える

テクニカルスキルの記載で最も多い失敗は、使用したことがあるものをすべて並べてしまうことです。採用担当者が確認したいのは「実際に業務で使いこなせるか」であり、触れた程度のスキルを羅列しても評価にはつながりません。

スキルレベルの表現は、経験年数と実務での使用実績を組み合わせると伝わりやすくなります。

レベル感	表現方法の例
業務の主力として使用	「Python（実務5年、主力言語）」「業務設計・コーディングを一貫して担当」
業務で使用経験あり	「TypeScript（実務2年、Reactプロジェクトで使用）」
学習・個人開発で使用	「Rust（個人開発で使用中、業務経験なし）」

業務経験のないスキルを記載する場合は「個人開発レベル」と明示するのが誠実な書き方です。スキルレベルを誇張することは採用後のミスマッチにつながり、双方にとってマイナスになります。

自己PRの書き方｜技術力＋貢献イメージで差をつける

自己PRで採用担当者に評価されるエンジニアは、「技術スタックの再説明」ではなく「自分が入社することで何が変わるか」を伝えています。以下の構造で書くと、採用担当者に残る印象が変わります。

• 強みの定義（1文）：「私の強みは〇〇です」
• 根拠となるエピソード：「〇〇のプロジェクトで△△を実現しました」（具体的な数値や成果を含む）
• 貢献できることで締める：「貴社の〇〇において、△△の形で貢献できると考えています」

職務経歴書を一から作成するのが難しいと感じる場合は、ツールを活用して効率的に下書きを作る方法もあります。職務経歴書の自動作成ツールを選ぶポイントも参考にしてください。

採用担当者が落とすNG例3選と改善パターン

技術力があっても以下の3つの書き方が原因で書類選考を通過できないケースが多く見られます。自分の職務経歴書に当てはまるものがないか確認してください。

NG①：スキルの羅列だけで「使えるレベル」が不明

このような羅列を見た採用担当者は「触れたことがある」のか「業務で使いこなせる」のかが判断できません。スキル数の多さは評価にはつながらず、むしろ「何が本当の専門か」がわかりにくいという印象を与えます。

NG②：プロジェクト概要が抽象的すぎる

この書き方では「どんな規模のシステムを」「どんな役割で」「何ができるエンジニアか」が一切伝わりません。採用担当者は「何を開発したのか」より「あなたがそこで何をしたのか、その結果何が変わったのか」を知りたいと考えています。

NG③：担当業務が「システム開発に従事」だけ

「開発に従事」「保守・運用を担当」という表現は、採用担当者に何も伝えていません。実装だけなのか、設計から関わったのか、テストや運用まで対応できるのかが不明なため、「詳細不明で面接を設定するのはリスクがある」と判断されてしまいます。

担当業務の記載は、担当フェーズを明示することが最低条件です。「要件定義（80%参加）・基本設計・詳細設計・実装・テスト」のように、携わった度合いを示すと伝わりやすくなります。

エンジニア転職特有の書き方のコツ

エンジニアの職務経歴書には、一般的な書き方ガイドではカバーされない特有の課題があります。採用担当者に質問されがちなケースを事前に書類で対処しておくことが、通過率を上げるポイントになります。

機密情報があるプロジェクトの書き方

社名・顧客名・具体的なシステム名が機密に当たる場合は、「書けない情報は書かない」のが原則です。ただし、その場合でもプロジェクトの規模感・使用技術・担当フェーズ・実績は抽象化して記載できます。

「機密情報のため詳細は記載できませんが、面接でお伝えします」という一文を添えると、採用担当者が面接で確認する意思を持てるため、書類通過につながりやすくなります。

副業・個人開発・OSSへの貢献の書き方

副業や個人開発は「業務経験の補完」として有効に機能します。特に未経験分野への挑戦や、業務では試せない技術を使っている場合は、職務経歴書に記載することで採用担当者に「学習意欲と自走力がある」という印象を与えられます。

• 個人開発：技術スタック・機能概要・公開URL（あれば）を明記する。GitHubリンクは名刺代わりになる
• OSSへの貢献：リポジトリ名・コントリビュートの内容（バグ修正・機能追加など）・PRのURLを記載する
• 副業・フリーランス案件：守秘義務がある場合は「業種・規模・技術スタック」のみ記載する

スター数が少なくても、コードの品質やREADMEの丁寧さで技術力と誠実さをアピールできます。GitHubのURLは書類の信頼性を高める補完情報として機能します。

書類の内容に不安がある場合は、転職エージェントによる無料添削や有料サービスを活用する方法もあります。職務経歴書の有料添削サービスを選ぶポイントについても解説しています。

まとめ

• 採用担当者はエンジニアの職務経歴書で「職務要約・直近プロジェクト・テクニカルスキル」の3点を最初に確認する
• スキルの羅列より「経験年数・使用レベル・業務での実績」を組み合わせた書き方が評価される
• プロジェクト経歴は「規模・役割・担当フェーズ・数値実績」の4点を必ず含める
• 機密情報は抽象化・業種表記でカバーし、面接での説明を一文添えることで通過率が上がる
• 副業・個人開発・OSSへの貢献はGitHubリンクとあわせて記載すると学習意欲のアピールになる

職務経歴書は提出して終わりではなく、応募先に合わせてカスタマイズするものです。採用担当者が「面接を設定したい」と思うかどうかは書類の完成度に直接左右されます。

エンジニアの転職職務経歴書に関するよくある質問

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

経験年数によって異なります。3年未満であればA4で2枚、5年以上であれば3〜4枚が目安です。枚数より「採用担当者が30秒で全体像を把握できるか」を優先してください。

プロジェクトに守秘義務がある場合、職務経歴書にどこまで書けますか？

企業名・顧客名・固有のシステム名は書けなくても、「業種・規模（ユーザー数・チーム規模）・使用技術・担当フェーズ・数値実績」は記載できます。「詳細は面接でお伝えします」と添えることで、採用担当者が面接設定の判断をしやすくなります。

スキルシートと職務経歴書の違いは何ですか？

スキルシートは主にエージェントや客先常駐（SES）業界で使われる技術スキル一覧で、フォーマットが固定されている場合が多いです。職務経歴書はプロジェクト詳細・自己PR・実績を含む正式な転職書類です。一般的な転職活動では職務経歴書を提出します。

未経験分野に転職する場合、職務経歴書はどう書けばいいですか？

現在の技術スキルが転職先でどう活かせるかを具体的に書くことがポイントです。たとえばバックエンドエンジニアがデータエンジニアに転職する場合、「SQLを使った分析処理の経験」「大量データ処理の設計経験」を前面に出します。加えて、個人開発や学習中のツール・資格を記載し「不足スキルを積極的に補っている」という姿勢を示すと評価されやすくなります。