なぜその職務経歴書は「読まれずに」落ちるのか
多くのエンジニアの職務経歴書が通過しない理由は、経験不足ではなく伝え方にある。「〇〇システムの開発を担当しました」という一行の記述は、採用担当者に何も伝えない。規模（何人体制・何ヶ月）・役割（設計/実装/リーダー等、どこを担当したか）・技術（言語・フレームワーク・インフラ）・成果（数値化された結果）の4点がセットになって初めて、読み手はその人が「どんな判断を下せるエンジニアか」を評価できる。
逆に言えば、経験年数や在籍企業の知名度がそれほど高くなくても、この4点セットが揃っている職務経歴書は、書類選考の通過率が明確に上がる。まずはこの前提を押さえた上で、具体的な構成に入る。
職務経歴書・履歴書・スキルシートの違いを整理する
この3つは混同されがちだが役割が異なる。履歴書は氏名・学歴・職歴の事実を時系列で示す公式書類、職務経歴書は担当業務・実績・自己PRを自由形式でまとめてアピールする書類、スキルシートはIT業界特有の書類で「どの技術を、どのプロジェクトで、どの役割で使ったか」を一覧化したものだ。
| 書類 | 目的 | フォーマット | 自己PR欄 |
|---|---|---|---|
| 履歴書 | 本人確認・経歴の事実証明 | 厚労省様式が主流 | 簡易的にあり |
| 職務経歴書 | 実績・強みのアピール | 自由形式（編年体/キャリア式） | あり（重要項目） |
| スキルシート | 技術力・案件経験の一覧化 | SES/フリーランス業界の定型が多い | 省略されることが多い |
正社員応募では履歴書＋職務経歴書の2点が基本。SES・受託開発出身者や、案件ベースで多くのプロジェクトを経験してきた人は、これに加えてスキルシートの提出を求められることが多い。求人によって求められる書類が違うため、応募先の募集要項を確認し、指定がなければ職務経歴書に技術一覧の項目を組み込んでスキルシートを兼ねる形にするとよい。
通過率を上げる基本構成｜5ブロックテンプレート
エンジニアの職務経歴書は、次の5ブロックで組み立てると過不足なく仕上がる。
職務経歴はSTARフレームワークで書く
③の職務経歴が最も読まれる部分であり、通過率を左右する核心でもある。ここで有効なのがSTARフレームワーク（Situation / Task / Action / Result）だ。一行の作業記述ではなく、状況→課題→行動→結果の順で書くことで、読み手は「この人が現場でどう考え、何を動かしたか」を追体験できる。
Situation（環境）
チーム規模、開発体制、自分が入った時点の状況
Task（課題）
解決すべき課題、任された目標
Action（行動）
自分が具体的に何を選択し、実行したか
Result（結果）
数値化された成果、チームや事業への影響
成果は可能な限り数値化する。「パフォーマンスを改善した」ではなく「レスポンスタイムを1.2秒→0.4秒に短縮」、「開発を効率化した」ではなく「CI実行時間を40%削減し、リリース頻度を週1→週3に増加」のように書くと、判断材料としての説得力が一段上がる。
Before / After｜同じ経験でもここまで伝わり方が変わる
ECサイトのバックエンド開発を担当。APIの実装や既存機能の改修を行った。チームメンバーと協力しながら開発を進めた。
[S] 5名体制（自分含むエンジニア3名・PM1名・デザイナー1名）のECサイトリニューアルプロジェクトに参画。[T] 注文確定までの離脱率が高く、決済API周りのレスポンス遅延が課題だった。[A] 決済処理を同期呼び出しから非同期キュー処理に設計変更し、実装からリリースまでを担当。[R] 決済完了までの平均応答時間を2.8秒→0.9秒に短縮し、決済ページの離脱率を約18%改善した。
Beforeは「何をしたか」の作業ログにとどまっているのに対し、Afterは体制・課題・自分の判断・数値成果が一続きの文脈として読める。同じ実務経験でも、書き方次第でここまで伝わる情報量が変わる。
自己PRの組み立て方
自己PRは職務経歴の「まとめ直し」ではなく、そこから読み取れる強みを応募先の求める人物像に接続する場所だ。「①自分の強み（一言）→②その根拠となる職務経歴上のエピソード→③応募先でどう活かせるか」の3段構成でまとめると、200〜300字でも説得力のある文章になる。強みを3つ以上詰め込むと薄まるため、応募先との関連性が高いものに絞り込むのがポイントだ。
経験年数別の書き方
同じテンプレートでも、経験年数によって重心を置くべき場所が変わる。
0〜3年目：実装力と学習速度を示す
実績の絶対量が少ない時期は、担当した機能の技術的な難しさと、そこで何を学び取ったかを丁寧に書く。「未経験からどれだけ早く戦力化したか」を示す成長曲線も評価材料になる。個人開発やOSS活動があれば積極的に記載する。
3〜7年目：技術選定と裁量の広さを示す
この層では「言われたものを作った」から一歩進み、設計判断や技術選定に自分がどう関与したかを書く。複数プロジェクトを経験している場合は次章の「プロジェクトが多い場合のまとめ方」を参照してほしい。
7年目以降・マネジメント経験あり：意思決定とチームへの影響を示す
シニア層・テックリード層になると、個人の実装力よりも「意思決定の質」と「チーム・事業への影響範囲」が評価軸になる。メンバーの育成、技術的負債の解消判断、複数チームをまたぐ調整といった経験は具体的なエピソードとして書く。マネジメント職への転換を本格的に検討している場合は、求められる評価軸がさらに変わるため、エンジニアリングマネージャー転職の評価軸も合わせて確認しておくと、職務経歴書に書くべき要素の解像度が上がる。
職種別に押さえるべきポイント
基本構成は共通だが、職種によって採用担当者が重視する情報が異なる。
| 職種 | 重視される情報 |
|---|---|
| Webアプリ/自社開発 | 担当フェーズ（企画〜運用のどこか）、使用言語・FW、チーム開発の進め方（アジャイル運用経験等） |
| SES/受託・SE | 工程ごとの経験年数（設計/開発/テスト/保守）、業務ドメイン（金融・流通等）、体制内での役割 |
| インフラ/社内SE | 対象システムの規模（サーバ台数・利用者数）、障害対応実績、セキュリティ・運用改善の実績 |
| SRE/プラットフォーム | 可用性・信頼性への数値貢献（SLO達成率、MTTR短縮等）、監視・自動化基盤の構築経験 |
インフラ/社内SE領域は担当システムの「規模」を具体的な数字（サーバ台数、利用者数、扱うデータ量）で示せるかが特に重要になる。SREやプラットフォームエンジニア領域を目指している場合は、信頼性指標を軸にした経歴の組み立て方や市場動向をSRE転職のロードマップで詳しく解説しているので参考にしてほしい。
なお、外資系企業への応募を視野に入れている場合は、成果の数値化や英語レジュメの作法など、職務経歴書に求められる粒度そのものが変わってくる。外資エンジニア転職の選考突破術も合わせて確認しておくとよい。
プロジェクトが多い場合のまとめ方
SES・受託開発でキャリアを積んできたエンジニアほど、経験プロジェクト数が多く「全部書くと5枚を超えてしまう」という問題に直面しやすい。この場合、全プロジェクトを均等に詳細記述するのは逆効果になる。
- 直近・応募先に関連する3〜5案件のみをSTARで詳細記述する
- それ以外は「プロジェクト一覧」として、期間・役割・技術・規模を1行ずつの表形式でまとめる
- 工程別（設計/開発/テスト/保守・運用）の経験年数を別途集計し、経験の深さを一覧で示す
- 言語・フレームワーク・インフラ・業務ドメインを別項目に切り出し、スキルの幅を明確化する
この形にすると、職務経歴書全体は2〜3枚に収まりつつ、詳細を知りたい採用担当者には「聞けば深掘りできる」余地も残せる。面接段階でさらに詳しいプロジェクト一覧を提示する運用も有効だ。面接がどのように進むかを事前に把握しておくと、職務経歴書のどの部分を厚く準備すべきかも見えやすくなる。エンジニア転職の面談の流れと評価軸も参考にしてほしい。
GitHub・Qiita・ポートフォリオの載せ方
個人開発の成果物やアウトプットがある場合、職務経歴書の「その他」欄にURLを記載するのは有効なアピール材料になる。ただし載せ方には注意点がある。
- ある程度整理され、READMEが書かれているリポジトリを選んで載せる
- コミット履歴が継続的で、放置されていないものを優先する
- Qiita・Zennなどの技術記事があれば、アウトプット力の証明として記載する
- 作りかけ・動作しないコードをそのまま公開リンクとして貼る
- 学習用の写経コードしかないリポジトリをメインとして提示する
「見せられる実績が特にない」場合は、無理にGitHubを載せる必要はない。中途半端なコードを見せるより、職務経歴の記述を厚くする方が評価につながりやすい。
自分の職務経歴書、客観的に見てどう映る？
書いた内容が「伝わる形」になっているか、模擬面接形式で技術的な受け答えごと事前に確認しておくと、書類通過後の面接でも慌てずに済む。
技術面接の模擬対策を受ける提出前チェックリスト｜やってしまいがちなNGパターン
内容以前の部分でつまずくケースも多い。提出前に以下を確認しておきたい。
- 誤字・脱字がある（エンジニアの場合、記述ミスは「実装でもミスをしやすい人」という印象につながりやすい）
- スキルの羅列だけで終わり、どのプロジェクトでどう使ったかが書かれていない
- NotionやMarkdownファイルのままなど、企業指定外の形式で提出している
- 自分本位のレイアウトで、書きたいことだけを詰め込んでいる
- 枚数が多すぎる（目安は2〜3枚、多くても4枚以内）、または逆に情報不足で1枚に収まりすぎている
- フォントサイズや罫線がバラバラで、読み手にとって視認性が悪い
フォーマット・枚数・提出形式の基本
用紙サイズはA4縦が基本。枚数は職務要約を含めて2〜3枚、経歴が長い場合でも4枚以内に収めるのが目安になる。作成ツールはWordが無難だが、社内SE・SES業界ではExcel形式のスキルシートテンプレートが指定されることも多い。作成後は必ずPDF化してから提出し、環境によるレイアウト崩れを防ぐ。
職務経歴書、客観的な視点で一度添削してもらいませんか
自分では気づきにくい「伝わらない書き方」は、転職エージェントに一度見てもらうと具体的に指摘してもらえる。書類選考の通過率を上げたい段階で相談するのがおすすめ。
よくある質問
職務経歴書でタブーとされることは？
誤字脱字、スキルの羅列だけで終わる記述、指定外フォーマットでの提出、自分本位で読み手を意識しないレイアウトが代表的なタブー。いずれも内容以前の「読みやすさ」で評価を落とす原因になる。
システムエンジニアの職種の書き方は？
担当工程（要件定義/設計/開発/テスト/保守）ごとの経験年数を明示し、業務ドメイン（金融・流通・医療等）と体制内の役割を併記するのが基本形。プロジェクト数が多い場合は主要案件のみ詳細記述し、残りは一覧化する。
エンジニアの職務経歴書の役割は？
履歴書が経歴の事実証明であるのに対し、職務経歴書は「規模・役割・技術・成果」を通じて、応募先で同じように成果を出せる人材かどうかを判断してもらうための書類。自己PRで職務経歴の内容を面接につなげる役割も持つ。
職務経歴書は何枚が適正?
目安はA4で2〜3枚、経歴が長くても4枚以内。プロジェクト数が多い場合は主要案件のみ詳細記述し、残りを一覧形式でまとめることで枚数を抑えられる。
まとめ
エンジニアの職務経歴書は、経験年数や実績の量そのものよりも「規模・役割・技術・成果」がSTAR形式で具体的に伝わるかどうかで通過率が変わる。経験年数・職種ごとに重視すべき軸を押さえ、プロジェクトが多い場合は主要案件への絞り込みと一覧化を組み合わせる。仕上がったら書類だけで終わらせず、客観的な添削と面接対策までセットで進めておくと、次のステップにそのままつながる。
参考・出典
フリーランスAIエンジニア。AIパイプライン開発と技術キャリアについて発信しています。