エンジニア転職を成功させる職務経歴書の書き方2026
はじめに
エンジニアの転職市場は依然として売り手市場だが、書類選考の通過率は高くない。「技術力には自信があるのに書類で落とされる」という声は多い。
職務経歴書は技術力の証明書ではなく「自分がどんな価値を提供できるか」を伝えるマーケティング資料だ。本記事では、採用担当者の目に留まる職務経歴書の書き方を、サンプルと具体的なポイントで解説する。
免責事項: 本記事は一般的な情報提供を目的としています。転職活動の個別判断はキャリアアドバイザー・転職エージェントにご相談ください。
※本記事の転職サービスリンクにはアフィリエイトリンクが含まれます。明光キャリアパートナーズ でエンジニア転職の無料相談ができます。
採用担当者が職務経歴書を見る時間
採用担当者が最初に職務経歴書を見る時間は平均30秒〜1分と言われている。最初の30秒で「詳しく読む価値がある」と判断されなければ、どれだけ中身が良くても落とされてしまう。
採用担当者が最初の30秒で確認するポイント:
1. 技術スタック（求人要件とのマッチ）
2. 直近の職歴・在籍期間
3. 定量的な実績（数字で示されているか）
4. 読みやすさ（ページ数・フォーマット）エンジニア職務経歴書の基本構成
推奨フォーマット（A4 2〜3枚）
職務経歴書の基本構成:
1. 職務要約（3〜5行）
└─ 経歴の全体像・強みを端的にまとめる
2. スキルサマリ（技術スタック一覧）
└─ 言語・フレームワーク・インフラ・ツールを整理
3. 職務経歴（直近から遡る逆時系列）
└─ 各プロジェクトの役割・実績・使用技術
4. プロジェクト実績（ハイライト）
└─ 特に力を入れた案件の詳細
5. 自己PR / 活かせる強み
6. 資格・学習職務要約の書き方
職務要約は採用担当者が最初に読む部分だ。3〜5行で経歴の全体像と強みを伝える。
悪い例 vs 良い例
悪い例:
Webエンジニアとして5年間働いてきました。フロントエンドからバックエンドまで幅広く経験しており、様々な言語・フレームワークを使ってきました。チームでのコミュニケーションも得意です。問題点:
- 数字・実績がない
- どのレベルかが不明
- どこに強みがあるか不明
- 誰にでも書けるような内容
良い例:
フルスタックエンジニアとして5年間、React/TypeScript（フロント）・Node.js/Go（バック）・AWS（インフラ）を主軸に開発。直近2年はリードエンジニアとして5名チームをマネジメントし、サービスのレスポンスタイムを40%改善・月次デプロイ頻度を月1回→週3回に向上させた実績あり。スタートアップでのゼロイチ開発経験と、大手サービスのスケール対応の両方に強みを持つ。ポイント:
- 5年間という期間
- 具体的な技術スタック
- 5名チームをマネジメントという事実
- 40%改善・週3回という定量的実績
- 強みの領域が明確
技術スタックの書き方
採用担当者が見やすいフォーマット
【技術スキル】
プログラミング言語:
◎ TypeScript（5年） ◎ Go（3年） ○ Python（2年）
△ Java（1年） △ Kotlin（半年）
フロントエンド:
◎ React / Next.js ◎ Vue.js / Nuxt.js
○ Tailwind CSS ○ GraphQL
バックエンド:
◎ Node.js / Express ◎ Echo（Go）
○ FastAPI △ Spring Boot
データベース:
◎ PostgreSQL ◎ MySQL
○ MongoDB ○ Redis
インフラ / クラウド:
◎ AWS（EC2/RDS/S3/Lambda/ECS）
○ GCP（Cloud Run/BigQuery）
○ Docker / Kubernetes（基礎）
○ Terraform（基礎）
ツール / その他:
◎ Git / GitHub ◎ CI/CD（GitHub Actions）
○ Datadog ○ Sentry
○ Figma（読み取り）
◎: 実務4年以上・主力として使用
○: 実務1〜3年・実務レベルで使用可能
△: 実務1年未満・補助的に使用技術レベル表記のポイント
良い表記:
✓ 「React（4年）: SPA/SSR設計・状態管理・パフォーマンス最適化経験あり」
✓ 「AWS（3年）: 月間100万PVのWebサービスのインフラ設計・運用経験」
避けるべき表記:
✗ 「React: 経験あり」（どのレベルか不明）
✗ 「AWS: 少し触ったことがある」（採用側が使えるかどうか判断できない）
✗ 「全般的にできます」（具体性がない）職務経歴の書き方
1プロジェクトの記載フォーマット
【プロジェクト名】: ○○サービスのリアーキテクチャ
期間: 2024年4月 〜 2025年3月（1年）
チーム規模: 8名（PO1名・デザイナー1名・エンジニア5名・QA1名）
役割: リードエンジニア
使用技術: React/TypeScript, Go, PostgreSQL, AWS(ECS/RDS/CloudFront), Terraform
【概要】
月間200万PVのECサービスのフロントエンドとAPIをモノリスからマイクロサービスへ移行。
【担当業務】
・アーキテクチャ設計（マイクロサービス分割方針・API設計）
・Goによる新規APIサーバー構築（5サービス）
・React/TypeScriptによるフロントリプレイス
・TerraformによるインフラのIaC化
・コードレビュー・技術的負債の解消（テストカバレッジ 15%→75%）
【成果・実績】
・ページロード時間 平均3.2秒 → 0.8秒（75%削減）
・サーバーコスト 月32万円 → 月18万円（44%削減）
・デプロイ頻度 月1回 → 週4回（4倍向上）
・バグ報告件数（月次）: 35件 → 8件（77%削減）定量的な実績の作り方
エンジニアが実績を数字で示す際の考え方：
数字にできる実績の例:
パフォーマンス改善:
✓ レスポンスタイム: 500ms → 120ms（76%改善）
✓ ページロード: 4.5s → 1.2s（LCP改善）
✓ エラーレート: 2.3% → 0.1%
開発効率:
✓ デプロイ頻度: 月1回 → 週3回
✓ テストカバレッジ: 20% → 80%
✓ リリースサイクル: 3週間 → 1週間
✓ コードレビュー時間: 平均4時間 → 1時間
コスト削減:
✓ AWSコスト: 月50万 → 月28万（44%削減）
✓ 外注費削減: 年200万 → 社内内製化
ビジネス貢献:
✓ CVR改善: 2.1% → 3.4%（機能実装により）
✓ ユーザー登録数: 月次1,000件 → 3,500件（LP改善）
✓ 解約率: 8% → 3%（UX改善）
数字がない場合の工夫:
✓ 「プロジェクト全体の40%のタスクを担当」
✓ 「1,000万行超のコードベースのリファクタリング」
✓ 「20名以上のエンジニアが利用する社内ツールを構築」ポートフォリオとの連携
職務経歴書にポートフォリオを効果的に組み込む
ポートフォリオリンクの記載例:
【ポートフォリオ・GitHub】
GitHub: https://github.com/your-username
ポートフォリオサイト: https://yourportfolio.dev
主要リポジトリ:
├─ [スター数500+] awesome-cli-tool (Go) - CLIツール開発
└─ [実務級サンプル] microservice-sample (Go/TypeScript)
技術ブログ:
└─ Zenn: https://zenn.dev/your-username（フォロワー800人）
- 「GoでのマイクロサービスAPIデザインパターン」（1.2万views）ポートフォリオを作る際のポイント
採用担当者に刺さるポートフォリオの条件:
1. READMEが整備されている
✓ 何を作ったか・なぜ作ったか・技術選定理由が書かれている
✓ スクリーンショット・デモURLがある
✓ セットアップ方法が明確
2. コードの品質
✓ テストコードがある
✓ CI/CDが設定されている（GitHub Actions等）
✓ Linting・Formattingが適用されている
3. 実用的なプロジェクト
✓ 自分自身が使っているツール・サービス
✓ 実際の問題を解決するもの（チュートリアルコピーは避ける）採用担当者が重視するポイント（職種別）
フロントエンドエンジニア
採用担当が見るポイント（フロントエンド）:
技術:
✓ React/Vue.jsの実務経験年数・規模
✓ TypeScriptの使いこなし（any禁止・型安全性）
✓ パフォーマンス最適化（Core Web Vitals・Lighthouse）
✓ テスト（Vitest/Jest・E2EテストはPlaywright/Cypress）
✓ アクセシビリティへの配慮
実績:
✓ LCP・CLS・FIDなどの改善実績
✓ デザインシステム構築・UI設計への参画
✓ コンポーネント設計（Atomic Design等）バックエンドエンジニア
採用担当が見るポイント（バックエンド）:
技術:
✓ 主要言語の習熟度（Go/Java/TypeScript等）
✓ DBの設計・チューニング経験
✓ API設計（REST/GraphQL/gRPC）
✓ セキュリティ対策（認証・認可・脆弱性対応）
実績:
✓ スケール対応（月間PV・RPS・データ量）
✓ レスポンスタイム改善・N+1解決
✓ マイクロサービス・分散システムの経験インフラ・SREエンジニア
採用担当が見るポイント（インフラ・SRE）:
技術:
✓ AWSまたはGCPの実務経験（資格よりも実績）
✓ IaC（Terraform・CDK等）の使用経験
✓ Kubernetes・コンテナオーケストレーション
✓ 監視・可観測性（Datadog・CloudWatch・Prometheus）
実績:
✓ 可用性・SLOの管理（99.9%稼働等）
✓ インシデント対応・ポストモーテム経験
✓ コスト最適化の実績よくある失敗パターンと対策
職務経歴書の失敗パターン:
失敗1: 「担当しました」の羅列
✗ 「AWSを使ったインフラ構築を担当しました」
✓ 「ECS+RDSで月間50万PVサービスのインフラを設計・構築。従来のEC2構成から移行しコスト35%削減」
失敗2: ページ数が多すぎる/少なすぎる
✗ 1ページに収めようとして情報が少ない
✗ 5ページ以上の冗長な記述
✓ 2〜3ページが最適（経験10年以上なら3ページ可）
失敗3: 読みにくいフォーマット
✗ 箇条書きなし・段落だけの文章
✗ フォントサイズが小さすぎる（9pt以下）
✓ 箇条書き・表・空白を使って視認性を高める
失敗4: コピペのような内容
✗ どの会社でも通用する内容（差別化なし）
✓ 応募先企業の技術スタック・事業課題に合わせてカスタマイズ
失敗5: 過去の技術スタックを全部書く
✗ 5年前に少し触ったJavaも「経験あり」に記載
✓ 実務で戦力として使える技術のみ記載転職エージェントの活用
職務経歴書の作成・ブラッシュアップには転職エージェントの活用が効果的だ。エンジニア専門のエージェントはIT業界の採用基準を熟知しており、職務経歴書のレビューも無料で行ってもらえる。
明光キャリアパートナーズ
明光キャリアパートナーズは、IT・エンジニア職を中心としたキャリア支援サービス。専属キャリアアドバイザーが職務経歴書の添削から面接対策まで一貫してサポートしてくれる。
明光キャリアパートナーズで職務経歴書のプロレビューを受ける ※アフィリエイトリンク
フリーランスボード
フリーランスとして独立・副業を考えているエンジニアには、フリーランス案件に特化したフリーランスボードが役立つ。単価・案件数・技術スタック別に検索でき、現在の市場価値を把握するためにも使える。
フリーランスボードでエンジニア案件の市場価値を確認する ※アフィリエイトリンク
職務経歴書 最終確認チェックリスト
提出前の最終チェックリスト:
【内容面】
□ 職務要約は3〜5行で経歴の全体像と強みを示しているか
□ 技術スタックに習熟レベル・年数を記載しているか
□ 各プロジェクトで定量的な実績（数字）を示しているか
□ チームサイズ・役割・担当割合を明記しているか
□ 応募先企業の技術スタック・求める人物像に合わせて調整したか
【フォーマット面】
□ A4で2〜3ページに収まっているか
□ 読みやすいフォント・サイズ（10〜11pt）を使っているか
□ 箇条書き・表を使って視認性を高めているか
□ 誤字脱字・文体の統一を確認したか
【リンク面】
□ GitHubのURLは正しく機能するか
□ ポートフォリオサイトは最新の状態か
□ 技術ブログのリンクは有効か
【信頼性】
□ 実績の数字は正確か（誇張していないか）
□ 使用したことのない技術を「経験あり」と書いていないか
□ 職歴・在籍期間に齟齬がないか関連記事
まとめ
エンジニアの職務経歴書は「技術力の証明書」ではなく「価値提供の説明書」だ。
重要ポイントのまとめ:
- 最初の30秒で勝負が決まる（技術スタック・実績の数字を上部に）
- 技術スタックは習熟レベルと年数を明記する
- 実績は必ず数字で示す（改善率・規模・期間）
- 1プロジェクトの記載は「概要→担当業務→成果」の流れで
- GitHubとポートフォリオを整備して信頼性を高める
- 応募先ごとにカスタマイズする（使い回しは通過率が下がる）
転職活動は職務経歴書だけでなく、LinkedIn・Zenn・GitHubなどオンライン上のプレゼンスも重要になっている。日常の業務成果を記録しておく習慣をつけ、いつでも最新の状態に更新できるよう準備しておこう。