この記事では、ITエンジニアの転職で使える職務経歴書のテンプレートと書き方を解説します。バックエンド・フロントエンド・インフラ別のひな形と、採用担当者が書類選考で最初に確認する3つのポイント、よくあるNG例の改善パターンも紹介します。
エンジニアの職務経歴書に必要な5つの項目と基本構成
エンジニアの職務経歴書は、A4サイズで2〜4ページが目安です。経験年数が3年未満であれば2ページ、5年以上であれば3〜4ページが適切な分量です。フォーマットはWordまたはPDFで作成し、提出前にPDF変換するのが一般的です。
構成は以下の5つの項目で成り立ちます。この順番通りに書くことで、採用担当者がストレスなく読み進められる書類になります。
- ① 職務要約
- ② 職務経歴・プロジェクト詳細
- ③ 技術スキル一覧
- ④ 保有資格・認定
- ⑤ 自己PR
① 職務要約(キャリアの核心を150〜200文字で伝える)
採用担当者が職務経歴書を開いて最初に読むのが職務要約です。「何ができる人か」を150〜200文字程度で簡潔にまとめます。経験年数・得意領域・直近の役割・保有技術の中核を1〜3文に凝縮します。
職務要約の記載例
Webアプリケーションのバックエンド開発を中心に7年の経験を持ちます。直近3年はPython/Django環境での開発をリードし、10名規模のチームでテックリードとして要件定義から設計・リリースまでを担当しました。マイクロサービス化やCI/CD整備など、開発効率の改善にも取り組んでいます。
② 職務経歴・プロジェクト詳細(採用担当者が最も時間をかけて読む部分)
採用担当者がエンジニアの職務経歴書で最も注目するのが、このプロジェクト詳細のセクションです。在籍した会社ごとに記載し、その中でプロジェクトを時系列で書いていきます。
各プロジェクトには以下の情報を含めることが基本です。
| 項目 | 記載内容 |
|---|---|
| プロジェクト名 | ◯◯システム開発 / ◯◯サービスリニューアルなど |
| 期間 | 20XX年XX月〜20XX年XX月 |
| チーム規模 | 全体◯名(うちエンジニア◯名) |
| 役割 | メンバー / サブリード / リードエンジニア / PM |
| 担当フェーズ | 要件定義・基本設計・詳細設計・実装・テスト・リリース |
| 使用技術 | 言語・FW・DB・インフラをカテゴリ別に記載 |
| 業務内容 | 担当した機能・実装・改善内容を箇条書きで記載 |
③ 技術スキル一覧(カテゴリ別に整理する)
使用言語・フレームワーク・データベース・インフラ・ツール類をカテゴリ別に整理します。スキルシートとは異なり、職務経歴書では「経験年数」または「習熟レベル(業務レベル・個人開発レベルなど)」の目安も記載すると採用担当者が判断しやすくなります。
技術スキル一覧の記載例
- 言語:Python(業務5年)、JavaScript(業務3年)、TypeScript(業務2年)
- フレームワーク:Django、FastAPI、React、Next.js
- データベース:PostgreSQL、MySQL、Redis
- インフラ:AWS(EC2 / RDS / S3 / Lambda / ECS)、Docker、Kubernetes
- その他:GitHub Actions(CI/CD)、Agile / Scrum
④ 保有資格・認定(客観的な証明として記載する)
基本情報技術者試験、応用情報技術者試験、AWS認定ソリューションアーキテクト、情報処理安全確保支援士(登録セキスペ)など、取得済みの資格を記載します。複数の資格がある場合は取得年が新しい順に並べると整理して見えます。
資格欄で採用担当者が確認するのは「その資格がポジションに必要かどうか」よりも、「継続的にスキルアップする姿勢があるか」という点です。取得年が古くても、現職での活用実績と合わせて記載することで評価につながります。
⑤ 自己PR(強みと今後の方向性をセットで伝える)
自己PRはエンジニアとしての強みと、今後どういった仕事をしたいかという方向性をセットで伝えます。200〜300文字が適切な分量です。「コミュニケーション能力があります」「チームワークを大切にしています」といった抽象的な表現では採用担当者の目に止まりません。
「何ができる」ではなく「どんな課題を解決してきたか」を中心に据えて書くことで、他の応募者との差別化につながります。
採用担当者が30秒で判断するエンジニア職務経歴書の3つのポイント
採用担当者がエンジニアの職務経歴書を最初に読む時間は、平均30秒前後と言われています。この30秒で「詳しく読みたい」と思わせられるかどうかが、書類選考の通過を大きく左右します。
採用担当者はここを見ている
- プロジェクトの規模(チーム人数・期間)と自分の役割が一目でわかるか
- 技術スタックの羅列ではなく、なぜその技術を使ったかが伝わるか
- 数字・具体性がある実績か、それともただの業務記述か
ポイント①:プロジェクトの「規模と役割」を冒頭2行に書く
採用担当者が職務経歴書を開いて最初にスキャンするのは、プロジェクトの概要部分です。ここに「◯名チームで」「リードエンジニアとして」「要件定義から設計・実装まで担当」という情報が入っているかどうかで、読み進めるかどうかが決まります。
NG例
「〇〇システムの開発業務を担当しました。Javaを使用し、バックエンドの実装を行いました。」
→ 規模・役割・担当フェーズがすべて不明で、採用担当者は何も判断できない
良い例
「8名チーム(エンジニア5名)で在庫管理システムのリプレイスを担当。サブリードとして詳細設計・実装・コードレビューを一貫して担い、Java/Spring Bootを中心に開発を推進しました。」
→ 規模・役割・担当内容・使用技術が1文で伝わる
このように、プロジェクト詳細の冒頭2行に「規模・役割・担当フェーズ」の3要素を詰め込むことで、採用担当者の読む速度が上がります。
ポイント②:技術選定の「なぜ」を1〜2文で添える
「使用技術:Python、Django、PostgreSQL、AWS」という羅列は、多くの応募者が書いています。採用担当者の目に止まる書類は、技術を「なぜ選んだか」「使った結果どうなったか」の理由付けが添えられています。
ただし、説明が長くなりすぎるのも逆効果です。1〜2文の補足で十分です。
技術選定の補足例
- 「DB接続コストの削減のためRedisによるキャッシュを導入し、APIレスポンスタイムを平均40%短縮」
- 「TypeScript導入によりコードの型安全性を担保し、バグ発生件数を前フェーズ比で3割削減」
- 「インフラをEC2のオンプレ構成からECS/Fargateへ移行し、デプロイ頻度を月1回から週3回に改善」
このような記載があると、採用担当者は「技術を道具として使いこなしている」という印象を持ちます。技術への理解が浅い応募者はこの補足が書けないため、差別化ポイントになります。
エンジニアの職務経歴書の書き方をより詳しく知りたい方は、採用担当者が実際に何を見ているかを解説したガイドも参考にしてください。

ポイント③:数字のない実績はチームへの貢献で語る
「数字で表せる実績がない」と感じているエンジニアは少なくありません。特に社内システムの保守・運用や、BtoB製品の一機能開発などは、売上数字や利用者数と直接結びつかないケースが多いです。
そのような場合は、「チームへの貢献」として実績を言語化するアプローチが有効です。
- 「週10件以上のコードレビューを担当し、コードの品質標準化を推進」
- 「テスト自動化を導入し、リグレッションテストの工数を月30時間削減」
- 「技術ドキュメントを整備し、新メンバーのオンボーディング期間を4週間から2週間に短縮」
- 「開発合宿を企画・主導し、チーム内の技術共有を促進。翌四半期の属人化リスクが低減」
採用担当者は、大きな数字よりも「問題を発見して改善できる人か」「チームの生産性に貢献できる人か」という視点で書類を読んでいます。
完全無料の履歴書・職務経歴書作成ツール
「サクレキ」質問に答えるだけで、選考書類がカンタンに完成
- 自己PR・志望動機も例文付きで安心
- スマホからでもOK。たった3分で履歴書・職務経歴書が完成
- 自動フォーマットで書き間違いゼロ
\ 完全無料・簡単3分で完成! /
無料で履歴書・職務経歴書を作成する →【職種別テンプレート】エンジニア職務経歴書のひな形
以下のテンプレートは、そのままコピーして自分の情報を埋めていく形で使えます。職種によって強調すべき技術スタックや担当フェーズが異なるため、自分のポジションに合ったひな形を選んでください。
なお、職務経歴書の自動作成ツールを使いたい方は職務経歴書の自動作成ツールおすすめ7選も参考にしてください。

バックエンドエンジニア向けテンプレート
職務要約
Webアプリケーションのバックエンド開発を中心に【 】年の経験を持ちます。主な実績は【 】の開発・設計で、直近では【チーム規模】のチームにて【役割】として従事しています。API設計・データベース設計・インフラ管理まで一貫して担当できます。
職務経歴・プロジェクト詳細(記入例)
【20XX年XX月〜20XX年XX月】株式会社◯◯
プロジェクト名:◯◯管理システム開発
規模:◯名(エンジニア◯名) 役割:サブリード
担当フェーズ:要件定義 / 基本設計 / 詳細設計 / 実装 / テスト
使用技術:Python / Django / PostgreSQL / Redis / AWS(EC2・RDS・S3)/ Docker
業務内容:
- ◯◯機能のAPI設計・実装(Python/Django REST Framework)
- データベース設計・インデックスチューニングによるクエリ高速化
- Redisを用いたセッション管理・キャッシュ機構の実装
- チーム内のコードレビュー担当(週◯件)
技術スキル一覧
- 言語:Python(業務◯年)、Go(業務◯年)
- フレームワーク:Django、FastAPI、Gin
- DB:PostgreSQL、MySQL、Redis、MongoDB
- インフラ:AWS(EC2・RDS・S3・Lambda)、Docker、Terraform
- その他:GitHub、GitHub Actions(CI/CD)、Agile/Scrum
フロントエンドエンジニア向けテンプレート
職務要約
React / Next.jsを中心としたフロントエンド開発を【 】年担当しています。UI/UXの設計から実装・パフォーマンス最適化まで幅広く経験があり、直近では【チーム規模】のチームで【役割】として新機能の開発をリードしました。アクセシビリティ対応やテスト自動化の整備にも取り組んでいます。
技術スキル一覧
- 言語:JavaScript(業務◯年)、TypeScript(業務◯年)
- フレームワーク:React、Next.js、Vue.js(Nuxt.js)
- スタイリング:Tailwind CSS、CSS Modules、styled-components
- テスト:Jest、React Testing Library、Playwright
- その他:Storybook、Figma連携、Webpack / Vite
インフラ・SREエンジニア向けテンプレート
職務要約
AWSを中心としたクラウドインフラの設計・構築・運用を【 】年担当しています。Infrastructure as Codeを推進し、TerraformによるIaC化やCI/CDパイプラインの整備を主導した実績があります。直近では可用性向上とコスト最適化を両立する構成設計をリードしました。
技術スキル一覧
- クラウド:AWS(EC2・ECS・RDS・S3・CloudFront・Route53・Lambda ほか)
- IaC:Terraform、AWS CDK、CloudFormation
- コンテナ:Docker、Kubernetes(EKS)
- CI/CD:GitHub Actions、CircleCI、ArgoCD
- 監視:Datadog、CloudWatch、PagerDuty
- 言語:Python(スクリプト)、Bash
エンジニアがやりがちな3つのNG例と改善パターン
採用担当者が書類を落とす判断をする際、技術力よりも「書き方の問題」で通過率が下がっているケースは非常に多いです。以下の3つは、エンジニアの職務経歴書に頻出するNGパターンです。
NG①:使用技術の羅列だけでプロジェクト背景がない
NG例
「Java、Spring Boot、MySQL、AWS、Docker、Kubernetes、Redisを使用した開発業務に従事。」
→ 何のシステムを作ったか、どんな役割だったかが何もわからない
改善例
「社内向け勤怠管理システムのリプレイスプロジェクトで、5名チームのメンバーとして詳細設計・実装を担当。Spring Boot + MySQLでRESTful APIを構築し、コンテナ化(Docker / Kubernetes)によってデプロイの安定性を向上させました。」
NG②:「〇〇システム開発に従事」で終わっている
「ECサイトの開発に従事しました」「社内システムの保守・運用を担当しました」という記述は、採用担当者から見ると情報量がほぼゼロです。
NG例
「ECサイトの開発・保守・運用に従事。フロントエンドとバックエンドを担当しました。」
→ 「フロントもバックも担当」は一見経験豊富に見えるが、どちらも浅い印象を与えるリスクがある
改善例
「月間200万PVのBtoC向けアパレルECサイトの機能追加・改修を担当。React / Next.jsによる商品検索機能のリニューアルを主導し、ページ表示速度(Core Web Vitals)を改善。LCPを3.2秒から1.8秒に短縮しました。」
NG③:チーム規模と自分の役割が書かれていない
同じ「開発担当」でも、20名チームのメンバーと3名チームのリードでは、求められる経験値がまったく異なります。採用担当者は「チームにおける自分の立ち位置」から、スケーラビリティやコミュニケーション能力を推定しています。
数字で表せない実績がある場合の書き方のヒントは、職務経歴書 実績なし 例文|数字ゼロでも通過する書き方のコツでも詳しく解説しています。

職務経歴書・スキルシート・ポートフォリオの使い分け
エンジニアの転職活動では、複数の書類を提出するよう求められるケースがあります。それぞれの目的と役割の違いを理解することで、何をどの書類に書けばいいかが明確になります。
職務経歴書とスキルシートは何が違うのか
| 書類 | 目的 | 主な内容 | ページ数 |
|---|---|---|---|
| 職務経歴書 | キャリアの経緯・実績・人物像を伝える | 職務要約・プロジェクト詳細・自己PR | 2〜4ページ |
| スキルシート | 技術スタックを一覧で確認させる | 言語・FW・DB・インフラの習熟度表 | 1ページ |
スキルシートは、採用担当者が技術要件とのマッチングを素早く確認するためのリストです。一方、職務経歴書は「この人がどんな人物か」「どんな課題を解決してきたか」を伝えるための書類です。
スキルシートを求められた場合でも、職務経歴書は必ず提出するのが基本です。スキルシートだけでは人物像が伝わらず、書類選考を通過しにくくなります。
GitHubとポートフォリオは職務経歴書に書くべきか
GitHubのプロフィールURLやポートフォリオサイトのURLは、職務経歴書の冒頭(基本情報の欄)またはスキル一覧の末尾に記載するのが一般的です。
ただし、記載するのは「見せられる状態にあるリポジトリ・サイトのみ」という原則を守ってください。コードが少ない・READMEが整備されていない・使い回しのボイラープレートしかないGitHubを記載しても、採用担当者の評価には逆効果になります。
採用担当者が見るポートフォリオのチェックポイント
- READMEに「何のプロジェクトか・使用技術・起動方法」が明記されているか
- コミット履歴が一定のペースで続いているか(学習継続性の証明)
- 個人開発であれば、業務との差異(技術選択・アーキテクチャ)が説明できるか
経験年数別:エンジニア職務経歴書の書き方のポイント
経験年数によって、採用担当者が職務経歴書に期待する内容は変わります。ジュニアとシニアでは強調すべき点が異なるため、自分のフェーズに合わせて書く軸を調整することが必要です。
経験1〜3年(ジュニアエンジニア)
採用担当者がジュニアエンジニアの書類で見ているのは、技術スキルの水準よりも「成長速度」と「仕事への向き合い方」です。担当した機能の難易度が低くても、「自分でどう工夫したか」「結果として何が改善されたか」を丁寧に書きます。
- プロジェクトの役割は「メンバー」でも、担当した機能の背景課題を書く
- 学習・資格取得など、業務外でのスキルアップ状況を補足する
- コードレビューでのフィードバックを受けて改善した実例があれば積極的に記載する
経験4〜7年(ミドルエンジニア)
ミドルエンジニアの転職では、「技術的な幅」と「チームへの貢献」の両方を示すことが求められます。採用担当者は、個人としての技術力に加えて「チームを動かせるか」「仕様・設計の判断を任せられるか」を見ています。
- 担当フェーズに「要件定義」「基本設計」が含まれるかどうかを明示する
- コードレビューやドキュメント整備など、チームの底上げに関わった実績を書く
- 技術選定の判断に関与した経験があれば、その背景と結果を記載する
経験8年以上(シニア・テックリード)
シニアエンジニアの職務経歴書では、「組織・チームにどう貢献できるか」の軸が中心になります。個別の実装スキルよりも、組織の技術的な意思決定・育成・仕組み化への関与が評価の軸になります。
- 採用・評価・育成への関与状況を明記する(「エンジニア採用面接を月◯件担当」など)
- アーキテクチャ設計・技術スタック選定の意思決定への関与を具体的に書く
- エンジニアリング組織の課題と、自分が主導した改善施策をセットで記載する
完全無料の履歴書・職務経歴書作成ツール
「サクレキ」質問に答えるだけで、選考書類がカンタンに完成
- 自己PR・志望動機も例文付きで安心
- スマホからでもOK。たった3分で履歴書・職務経歴書が完成
- 自動フォーマットで書き間違いゼロ
\ 完全無料・簡単3分で完成! /
無料で履歴書・職務経歴書を作成する →まとめ
- エンジニアの職務経歴書はA4で2〜4ページ。職務要約・職務経歴・技術スキル・資格・自己PRの5項目が基本構成
- 採用担当者が30秒で見る3点は「プロジェクト規模と役割」「技術選定の理由」「数字または貢献の実績」
- 職種別テンプレート(バックエンド・フロントエンド・インフラ)をベースに、自分の情報を埋めていくと効率的
- 「技術スタック羅列」「◯◯開発に従事」「役割が不明」の3パターンは落とされやすいNG例
- スキルシートとポートフォリオは補完資料。職務経歴書は必ず別途作成・提出する
書類が完成したら、転職エージェントへの添削を活用するのも一つの手です。採用担当者視点からのフィードバックを受けることで、通過率が大きく変わります。
エンジニアの職務経歴書に関するよくある質問
- エンジニアの職務経歴書はA4何枚が適切ですか?
-
経験年数が3年未満であれば2ページ、5年以上であれば3〜4ページが目安です。ただし、ページ数よりも「採用担当者が読みやすいか」を優先してください。無理に1ページに収めようとして情報を削りすぎるのも、情報量が少なすぎて評価されないケースにつながります。
- 職務経歴書にGitHubのURLは書いたほうがいいですか?
-
書ける状態にある場合は書いたほうが有利になります。ただし、READMEが整備されていない・コミット履歴がほぼない・個人情報が含まれるリポジトリが公開されているといった状態のまま記載するのは逆効果です。提示できるコードがある場合のみ記載してください。
- 未経験からエンジニアに転職する場合、職務経歴書には何を書けばいいですか?
-
前職の職務経歴に加えて、エンジニアとしての学習経歴(プログラミングスクール・独学の期間と取り組んだ内容)とポートフォリオの成果を記載します。採用担当者が未経験採用で見ているのは「学習継続性」と「問題解決への姿勢」です。ポートフォリオのREADMEに開発の背景・工夫した点を丁寧に書くことが書類通過率を上げるポイントになります。
- エンジニアの職務経歴書はWordとPDFどちらで提出すべきですか?
-
企業から指定がない場合はPDFでの提出が基本です。PDFは環境に関係なく表示が崩れないため、採用担当者側で読み取りのトラブルが起きにくい形式です。作成はWordやGoogleドキュメントで行い、提出直前にPDF変換する流れが一般的です。
- 職務経歴書にスキルシートは別途必要ですか?
-
企業からスキルシートの提出を求められた場合のみ用意します。求められていない場合、職務経歴書の技術スキル一覧のセクションにまとめて記載する形で十分です。ただし、SIerやSES企業ではスキルシートを必須としているケースが多いため、企業の採用要件を事前に確認してください。


コメント