エンジニアの職務経歴書は技術スタックを正確に書いているだけでは書類選考を通過できません。採用担当者が読み取ろうとしているのは「何の言語が書けるか」ではなく「どんな判断を下せるエンジニアか」だからです。この記事では、職務要約・プロジェクト経歴・スキル一覧・自己PRの4項目を、採用担当者視点の書き方と例文つきで解説します。
エンジニアの職務経歴書の書き方【結論】4つの必須項目と例文
結論：職務要約・プロジェクト経歴・スキル一覧・自己PRの4点を押さえる
エンジニアの職務経歴書に決まった様式はありませんが、採用担当者が確実に確認する項目は「職務要約」「プロジェクト経歴」「スキル一覧」「自己PR」の4つです。この順番で書き進めれば、経験年数や職種を問わず一貫性のある書類に仕上がります。
- 職務要約：技術軸・規模・主体性を3〜5行に凝縮する
- プロジェクト経歴：役割・使用技術・フェーズ・規模・個人の貢献の5要素を書く
- スキル一覧：カテゴリ分けと熟練度をセットで記載する
- 自己PR：技術選定の理由と応募先への貢献をSTAR法で伝える
ページ数の目安はA4で2〜3枚です。以下、各項目を順に見ていきます。
職務要約の書き方と例文
採用担当者が1枚の書類に費やす時間は30秒以下と言われます。その短時間で判断が下される職務要約には、「技術領域」「規模・役割」「直近の最大成果」を3〜5行に収めることが求められます。
良い例文
バックエンドエンジニアとしてSaaS系スタートアップで5年の経験があります。主にPython／FastAPIを用いたAPIサーバーの設計・開発に従事し、4〜8名の開発チームでリードポジションを担当してきました。直近では月間アクティブユーザー50万人規模のシステムリアーキテクチャを担い、レスポンス速度の75%改善を達成しています。
NG例
ソフトウェアエンジニアとして5年間、様々な現場でシステム開発に従事してきました。Java・Python・SQLなど複数言語を扱い、チームの一員として開発業務に取り組んできました。「様々な現場」「一員として」では役割・強みが読み取れません。
採用担当者はここを見ている
- 職務要約の1行目で技術領域が分からないと、そこで読み止まることがある
- 「〇〇システム開発の実務経験〇年」だけでは判断材料が少ない
- 「チームでの役割」「使用技術の中心軸」「担当フェーズ」の3点が揃うと評価が上がる
プロジェクト経歴（職務経歴）の書き方と例文
プロジェクト経歴は事実の羅列にしてはいけません。採用担当者が確認したいのは「何をしたか」ではなく、「この人がいることでプロジェクトがどう変わったか」です。新しい順に、以下の5要素を必ず盛り込んでください。
| 要素 | 記述例 |
|---|---|
| 役割 | バックエンドエンジニア（リード） |
| 使用技術 | Python／FastAPI／PostgreSQL／AWS |
| 担当フェーズ | 設計〜テスト・リリース |
| 規模 | 4名チーム・期間6ヶ月 |
| 個人の貢献 | APIレスポンス改善（平均800ms→200ms） |
良い例文
プロジェクト名：ECサイト向け在庫管理システムの刷新
期間：2023年4月〜2024年3月（12ヶ月）
規模：バックエンド5名・フロントエンド3名（計8名）
使用技術：Node.js／TypeScript／PostgreSQL／Redis／AWS（ECS・RDS）
担当フェーズ：要件定義・設計・実装・テスト・リリース
貢献：在庫同期処理の設計を担当。従来のバッチ処理をイベント駆動型に刷新し、在庫反映のタイムラグを1時間から5秒以内に改善しました。
NG例
ECサイトのシステム開発に従事しました。チームの一員として機能開発や保守業務を担当しました。役割・技術・成果のいずれも書かれておらず、誰が読んでも同じ印象しか残りません。
採用担当者はここを見ている
- 「システム開発に従事」だけでは技術力も役割も判断できない
- 数字で語れる改善・成果（速度改善率・バグ削減数・カバレッジ向上）があると説得力が増す
- 参加フェーズが「テストのみ」「保守のみ」だと担当業務の幅が読み取りにくい
スキル一覧の書き方と例文
スキル一覧は熟練度をセットで書かなければ伝わりません。「Python／Java／AWS／Docker」と羅列するだけでは、それぞれの習熟度が不明でポジション適合を判断できないためです。言語・フレームワーク・インフラ・ツールに分けて記載すると、求人票との照合がしやすくなります。
| カテゴリ | 技術・ツール | 経験・熟練度 |
|---|---|---|
| 言語 | Python | 実務5年（設計・実装・レビューが可能） |
| 言語 | JavaScript | 実務2年（フロントエンド補佐業務） |
| フレームワーク | FastAPI／Django | 実務3年（本番運用経験あり） |
| データベース | PostgreSQL／MySQL | 実務4年 |
| クラウド | AWS（EC2・S3・RDS・ECS） | 実務2年 |
| ツール | Git／GitHub／Jira | 日常的に使用 |
採用担当者はここを見ている
- 業務スキルと個人学習の技術が混在していると判断がしにくい
- 「実務〇年」「個人開発での使用経験」など習熟度のヒントがあるか
- 求人票の必須スキルと照合しやすいカテゴリ分けが評価される
自己PRの書き方と例文（STAR法）
エンジニアの自己PRで多い失敗は「スキルセットの再掲」で終わることです。採用担当者はスキルをすでにスキル一覧で確認しているため、自己PRでは「なぜそのスキルを選び、深めてきたのか」という意思決定の背景を伝える必要があります。構成には「STAR法」が使いやすい方法です。
| 要素 | 内容 |
|---|---|
| Situation（状況） | どんな状況・プロジェクトだったか |
| Task（課題） | 何が課題だったか |
| Action（行動） | 自分は何をしたか |
| Result（結果） | どんな成果につながったか |
良い例文
バックエンド開発を軸にキャリアを積んできた理由は、「ビジネスロジックの複雑さに向き合う設計力」に面白さを感じたからです。前職ではスケールアップに伴うDBボトルネック問題を任され、クエリ最適化とキャッシュ戦略の再設計を単独で担当し、平均レスポンスを2.3秒から0.4秒に短縮しました。この経験から、「コードが動く」だけでなく「長期的に保守できる設計」を常に意識しています。
NG例
Java、Python、SQL、AWS、Docker、Gitを使った開発経験があります。チームでの開発経験もあり、コミュニケーション力には自信があります。技術の羅列だけでは何を成し遂げたのか判断できず、「コミュニケーション力」も根拠がありません。
採用担当者がエンジニアの職務経歴書で最初に見ている3つのポイント
各項目の書き方を押さえたら、次は「なぜその書き方が評価されるのか」を理解しておくと、応募先ごとの調整がしやすくなります。採用担当者が職務経歴書全体を通して確認しているのは、次の3点です。
- 技術レイヤー：フロントエンド・バックエンド・インフラ・フルスタックのどのポジションか
- 規模感：どの規模のシステムやチームに関わってきたか
- 主体性：「実装した」「参加した」なのか、「設計した」「提案した」なのか
この3点は職務要約だけでなく、プロジェクト経歴・自己PRのすべてに通底する評価軸です。書類全体で一貫した技術軸が見えているかを提出前に見直してください。
「実装した」で終わらせない—通過率が上がる動詞の言い換え
多くのエンジニアが職務経歴書で「仕様書通りに実装した」「担当チームの一員として開発した」と書いています。採用担当者の目線では、こうした表現は「判断・思考の跡が見えない」書き方として評価が下がりやすいものです。以下の書き換え例を参考に、動詞を見直してください。
| Before（弱い表現） | After（強い表現） |
|---|---|
| ECサイトのAPIを実装した | RESTful APIの設計から担当し、認証・認可の仕組みをゼロベースで構築した |
| バグを修正した | 本番環境のメモリリーク原因を特定し、根本的なリファクタリングを実施した |
| チームで開発した | 技術的負債解消のプロジェクトを提案し、タスク分割・レビュー担当として推進した |
| テスト作業を行った | 単体・E2Eテストの方針を定め、カバレッジを0%から75%まで引き上げた |
採用担当者はここを見ている
- 動詞に注目している。「実装した」「参加した」より「提案した」「設計した」「導入した」が評価される
- 判断の根拠（なぜそうしたか）が書いてある経歴は読み進めてもらえる
- 全プロジェクトに強い表現は不要。リードした案件1〜2件に集中して書けば十分
未経験・第二新卒エンジニアが職務経歴書で気をつけたいポイント
実務経験が浅い場合、「プロジェクト経歴に書くことがない」という不安を抱えがちです。ですが、採用担当者が見ているのは経験の量ではなく、学習に対する主体性と再現性です。前職の経験を技術と結びつけて語れれば、実務経験ゼロでも評価につながります。
実務経験がなくても書ける「学習の実績」の見せ方
- 取得済み・学習中の資格（基本情報技術者試験、AWS認定など）を「取得年月」まで書く
- 個人開発・ポートフォリオは「何を作ったか」より「なぜその構成にしたか」を添える
- 前職での経験（業務改善・課題解決）を「技術で置き換えるとどうなるか」の視点で語る
良い例文（未経験からの転職）
前職では製造業の生産管理部門で3年間、工場ラインの効率化を担当してきました。業務改善のためにExcel VBAを独学で習得し、手作業で行っていた日報作成プロセスを自動化。月あたり40時間の工数削減を実現しました。現在はPython・SQLを学習中で、基本情報技術者試験にも合格しています。業務課題を技術で解決してきた視点をエンジニアとして活かしていきたいと考えています。
NG例
実務未経験ですが、独学でプログラミングを勉強しています。やる気はあるので頑張ります。「やる気」だけでは判断材料にならず、何をどこまで習得したかが伝わりません。
マネジメント経験・転職回数が多い場合の書き方
マネジメント経験の書き方—「管理した」で終わらせない
経験5年以上のエンジニアには「チームリードをしていた」「後輩指導をしていた」という経験を持つ人も多いですが、「3名のチームを管理した」だけでは何も伝わりません。マネジメント経験は「何の問題を、どう解決したか」の文脈で書くことが必要です。
良い例文
チームリードとして4名のエンジニアのタスク管理とコードレビューを担当。入社1年未満のメンバーが多く、レビュー指摘が多くリリースサイクルが遅延していました。ペアプログラミングと週次1on1を導入し、3ヶ月でレビュー指摘件数を平均12件/PRから4件/PRに削減、リリース頻度を月2回から週1回に改善しました。
転職回数が多いエンジニア向けの構成対策
エンジニアは転職市場が活発で、3〜5年で転職するキャリアも珍しくありません。採用担当者は複数の職歴を見るとき、「なぜこの会社を辞めたのか」ではなく「どんな意図でキャリアを積んできたのか」に注目しています。
- 職務要約に「キャリアのテーマ・一貫性」を1行で明記する
- 短期在籍（1年未満）の職歴は事実を書いた上で、次のプロジェクトで得た成長にフォーカスを移す
- 転職ごとに「技術的なステップアップ」や「担当範囲の拡大」が見えるように順序を意識する
採用担当者はここを見ている
- 職歴の数よりも「なぜこの人はここに来たいのか」の文脈が一貫しているかを見ている
- 転職ごとに担当領域・使用技術・役割が広がっていれば、多様な経験として評価される
- 「毎回違う技術を使っている」より「軸となる技術が深化している」ほうが評価されやすい
提出前にチェックすべき3つのポイント
内容を書き終えたら、提出前に必ず以下の3点を確認してください。どれだけ内容が優れていても、体裁の乱れは「注意力に欠ける人」という印象につながります。
- ページ数：A4で2〜3枚に収める。プロジェクト件数が多い場合は直近3〜5件を重点的に、古いものは簡潔にまとめる
- 誤字脱字・表記ゆれ：技術名の大文字・小文字（例：JavaScript、AWS）が統一されているか確認する
- 資格・GitHubの見せ方：資格は「取得年月・資格番号」まで記載し、GitHubは見てほしいリポジトリを一言添えて絞り込む
一人で見直すのが難しい場合は、転職エージェントの無料添削サービスを活用する方法もあります。
フォーマット選びに迷う場合は、エンジニアの職務経歴書テンプレートを使うと、項目の抜け漏れなく整えられます。履歴書と一緒に提出する場合は、転職用の履歴書テンプレートも合わせて確認してください。ハローワーク経由での応募には、ハローワーク用の職務経歴書テンプレートが使いやすい形式です。
まとめ
エンジニアの職務経歴書で採用担当者が評価するのは、技術スタックの多さではなく「どんな判断をしてきたエンジニアか」です。以下の5点を押さえることで、書類通過率は大きく変わります。
- 職務要約に「技術軸・規模・主体性」の3点を凝縮する
- プロジェクト経歴に「個人の貢献」を数値・具体的な施策で表現する
- スキル一覧は熟練度・カテゴリ分けをセットで記載する
- 自己PRはSTAR法で成果まで書く
- 「実装した」を「設計・判断した」に変える言葉の見直しを行う
提出前のチェックまで終えたら、応募先の求人要件に合わせて職務要約の1〜2行を微調整すると、より通過率の高い書類になります。
エンジニアの職務経歴書に関するよくある質問
- エンジニアの職務経歴書に書く量はどのくらいが適切ですか？
-
経験年数によって異なりますが、A4用紙2〜3枚が一般的です。経験が浅い場合（〜3年）は2枚、経験が豊富な場合（5年以上）でも3枚を超えないようにまとめると読みやすい書類になります。プロジェクト件数が多い場合は、直近3〜5件を重点的に記載し、古いものはシンプルな箇条書きにまとめてください。
- スキル一覧に「勉強中」の技術は書いてもよいですか？
-
書く場合は「現在学習中」と明記することが必要です。採用担当者が業務スキルと混同すると誤解につながるため、業務経験のあるスキルと学習中のスキルは明確に分けてください。学習中の技術が応募先の必須スキルに近い場合は、学習期間や成果物を補足すると前向きな評価を得やすくなります。
- 職務経歴書に志望動機は書くべきですか？
-
志望動機は履歴書に書くのが基本で、職務経歴書に重複して書く必要はありません。ただし、キャリアの一貫性を伝えたい場合は、職務要約の最後に「今後は〇〇の領域に注力したい」と1行添えると、志望動機と自然につながる構成になります。
- GitHubのURLを職務経歴書に載せる場合、何を書けばよいですか？
-
見せたいリポジトリを絞り、採用担当者に何を見てほしいかを一言添えることをおすすめします。「GitHubアカウントURL・推薦リポジトリ：〇〇（RESTful API設計のサンプル実装）」のように記載すると印象が変わります。READMEが充実しており、設計の意図が伝わるコメントがあるリポジトリを選んでください。
