エンジニアの職務経歴書フォーマット｜技術を成果に変える書き方

この記事では、エンジニアの職務経歴書フォーマットの基本構成から、採用担当者が最初の30秒で確認するポイント、職種別（Web・インフラ・SES）の書き分け方まで例文付きで解説します。技術スタックをただ並べるだけの書類から脱却する具体的な方法も紹介します。

エンジニアの職務経歴書フォーマット｜基本5項目

エンジニアの職務経歴書は、以下の5項目で構成するのが基本です。全体のページ数は経験3年未満なら2枚、5年以上なら3〜4枚を目安にしてください。

項目	役割	目安分量
①職務要約	キャリアの概要をひと目で伝える	5〜7行（200文字以内）
②職務経歴（プロジェクト詳細）	具体的な経験・成果を示す	全体の6〜7割
③テクニカルスキル一覧	技術の種類と経験年数を整理する	1セクション（表形式推奨）
④自己PR	強みとキャリア志向を伝える	5〜7行（200文字以内）
⑤資格・アウトプット	保有資格とGitHub・ブログを記載	小セクション

①職務要約（職務サマリー）

職務要約は採用担当者が最初に読む「冒頭の顔」です。5〜7行に凝縮してキャリアの概要を伝えます。「〇〇の開発経験X年。主にバックエンド開発を担当し、〇〇などの実績があります」という構成が基本です。

②職務経歴（プロジェクト詳細）

職務経歴はフォーマット全体の中心となる項目です。プロジェクトごとに以下を記載します。

• 期間：2022年4月〜2023年9月のように月単位で記載
• プロジェクト概要：どんな業界向けのどんなシステムか（1〜2行）
• 担当業務・役割：リーダー/メンバーの別、チーム人数
• 使用技術：言語・FW・ツール・環境（バージョンまで記載するのが理想）
• 成果・実績：数値で示せるものは必ず数値化する

③テクニカルスキル一覧

言語・フレームワーク・ツール・クラウドをカテゴリ別に整理し、経験年数を添えて記載します。「経験あり」だけでは判断できないため、経験年数またはスキルレベル（業務使用可能・独学等）を必ず明記してください。

カテゴリ	スキル	経験年数・レベル
言語	Python、JavaScript	Python：5年（業務）、JS：3年（業務）
FW・ライブラリ	Django、React 18	Django：3年（業務）、React：2年（業務）
クラウド	AWS（EC2、RDS、S3）	3年（業務）
DB	MySQL、Redis	MySQL：4年（業務）
ツール・CI/CD	Git、Docker、GitHub Actions	3年（業務）

④自己PR

強みを3つ程度に絞り、具体的なエピソードで裏付けます。「コミュニケーション能力が高い」のような抽象的な表現は避け、「〇人のチームで〇〇を調整し〇〇を達成した」という実例を添えてください。技術力とヒューマンスキルの両面を書くと採用担当者の印象に残ります。

⑤資格・アウトプット

取得済みの資格（基本情報技術者試験、AWS認定ソリューションアーキテクト等）を記載します。加えて、GitHubのURLや技術ブログ・Qiitaのリンクも記載できる場合は積極的に掲載してください。コードや発信の質が採用担当者に直接伝わります。

採用担当者が最初の30秒で確認する3つのこと

複数の書類を短時間で確認する採用担当者が、エンジニアの職務経歴書を見るとき、最初の30秒で確認するポイントは3つに絞られます。

• ①「使える」技術が明確か：バージョンや経験年数が記載されているか
• ②プロジェクトの規模感と役割：何人チームで何を担当したかが明記されているか
• ③成果が数値で書かれているか：「〜しました」ではなく「〜により〇%改善」と書かれているか

「技術スタックを並べるだけ」から脱却するための書き方

エンジニアの職務経歴書でもっとも多い失敗は、使用技術を列挙するだけで「何をしたか」「どんな成果を出したか」が書けていない点です。特にSIerやSES出身のエンジニアに多いパターンです。

変換のポイントは「技術名」→「技術でやったこと」→「その結果」の3段階で書くことです。この流れを意識するだけで、採用担当者の目に止まる書類に変わります。

職務経歴書全体の構成や書き方の基本については、エンジニアの職務経歴書の書き方でも詳しく解説しています。

職種別フォーマットの書き分けポイント

エンジニアといっても職種によって採用担当者が重視するポイントは異なります。Webエンジニア・インフラエンジニア・SESエンジニアで書き方を変えることで、書類選考の通過率が上がります。

Webエンジニア（バックエンド・フロントエンド）

バックエンドエンジニアは、APIの設計・実装経験を「エンドポイント数」や「1秒あたりのリクエスト数」で具体化すると説得力が増します。データベース設計（ER図作成・テーブル設計）の経験も明記してください。

フロントエンドエンジニアは、使用したFW・ライブラリとバージョンを必ず記載します（例：React 18、Vue 3）。ページ表示速度の改善率やLighthouseスコアの改善数値など、パフォーマンスに関する実績が書けると差別化できます。

インフラ・クラウドエンジニア

クラウドサービス名と具体的な構成を記載します（例：AWS EC2＋ALB＋RDS構成でコスト月20万円削減）。近年の採用ではIaC経験（Terraform、CloudFormation）が高く評価される傾向があります。

• 可用性目標（SLA）や障害対応の実績を数値付きで記載すると差別化できる
• 監視ツール（CloudWatch、Datadog等）の運用経験も忘れずに記載する
• コスト最適化の実績（予算X%削減など）は採用担当者に強い印象を与える

SESエンジニア（客先常駐）

SESエンジニアの職務経歴書で最も多い悩みは「NDAでプロジェクト詳細を書けない」という点です。ただし、業界名・システムの規模感・チーム内の役割は記載可能なケースがほとんどです。

経験年数別フォーマットの調整ポイント

経験3年未満のエンジニア

A4用紙2枚以内にまとめることが基本です。書くべき実務経験が少ない場合でも、学習へのアクティブな姿勢を自己PRで補えます。

• 技術スタックの羅列より「何を学び、どう業務に活かしたか」のプロセスを重視して書く
• 個人開発・OSS貢献・技術ブログがある場合は必ず記載する
• 「未経験の技術を〇週間でキャッチアップし実装した」という学習スピードのアピールが有効
• 資格（基本情報技術者、AWS CLF等）を取得している場合は資格欄を充実させる

経験5年以上のエンジニア

A4用紙3〜4枚が目安ですが、過去の全経歴を書こうとすると読まれなくなります。直近3〜5年間を重点的に書き、それ以前の経験は1〜2行の概要にまとめるのがポイントです。

• マネジメント経験・技術選定への関与・後輩育成の実績を含める
• 「なぜその技術を選定したか」という意思決定の経緯を書くと、上位職への転職で評価される
• 採用担当者は「この人は自社でどのポジションに置けるか」を考えながら読む。リードとして動けるか、メンバーとして動けるかが伝わる書き方を意識する

転職回数が多い場合のフォーマット調整については、職務経歴書の複数社の書き方も参考にしてください。

GitHubやQiitaは職務経歴書に記載すべきか

結論から言うと、記載できるなら記載すべきです。採用担当者は実際にGitHubやQiitaを確認することがあり、コードの書き方や発信内容が直接的な評価材料になります。

アウトプット	記載すべき状態	記載を控えるべき状態
GitHub	実際に動くリポジトリがある・コミット履歴がある	リポジトリがほぼない・更新が数年前・フォークのみ
Qiita・技術ブログ	記事が5本以上・業務に近い技術を扱っている	記事が1〜2本・内容が浅い・更新が止まっている

GitHubを掲載する場合は、「個人開発プロジェクト名：〇〇 | https://github.com/〇〇」のように何のプロジェクトかを一言添えて記載してください。URLだけ貼っても採用担当者が確認するモチベーションが下がります。

書類作成の手間を減らしたい場合は、職務経歴書の自動作成ツールを活用するのも選択肢のひとつです。ただし、自動生成された文章はそのまま提出せず、必ず採用担当者視点で確認・修正してください。

まとめ

• エンジニアの職務経歴書フォーマットは「職務要約・職務経歴・テクニカルスキル・自己PR・資格/アウトプット」の5項目が基本
• 採用担当者が最初の30秒で確認するのは「スキルの具体性」「役割の明確さ」「成果の数値化」の3点
• 技術スタックの列挙にとどまらず、「何を担当し何の成果を出したか」まで書くことが通過率を左右する
• Web・インフラ・SESそれぞれで採用担当者が重視するポイントが異なるため、職種に合わせた書き分けが必要
• GitHubやQiitaは品質が担保できる場合のみ記載し、採用担当者が内容を確認しやすい状態に整えておく

職務経歴書は「過去の作業記録」ではなく、採用担当者に「この人と会いたい」と思わせるための書類です。フォーマットの形式を整えることと同じくらい、記載する中身の質が通過率に直結します。

エンジニアの職務経歴書フォーマットに関するよくある質問

職務経歴書は何ページが適切ですか？

経験3年未満なら2枚、5年以上なら3〜4枚が目安です。5枚を超えると最後まで読まれないことが多く、採用担当者から「要約する力がない」と判断されるリスクがあります。直近の経験を重点的に書き、古い経歴は1〜2行の概要にまとめると適切なボリュームになります。

WordとPDFどちらの形式で提出すればいいですか？

特に指定がない場合はPDF形式が推奨です。PDFは受け取り側の環境でレイアウトが崩れないため、意図したフォーマットで採用担当者に届きます。ただし、転職エージェント経由の転職活動ではWord形式を求められることも多いため、両形式で保存しておくと安心です。

テクニカルスキルに「習得中」の技術を書いても良いですか？

書いて問題ありませんが、「学習中」「勉強中」と明記することが必須です。「使える」スキルと「学習中」のスキルが同一リストに混在していると、採用担当者に誤解を与えます。学習中の技術は「自己学習中」セクションを別に設けて記載し、実務経験のあるスキルとは明確に区別してください。

SESエンジニアでNDAがある場合、プロジェクト詳細はどう書けばいいですか？

NDAがある場合でも「○○業界向けシステムの開発」「チーム規模（X名）」「担当フェーズ（設計/実装/テスト等）」程度の情報は多くのケースで記載可能です。守秘義務の範囲は会社によって異なるため、現職の就業規則を確認してください。完全に書けない場合は「守秘義務のため詳細非公開」と明記する形で問題ありません。

職務経歴書に手書きは必要ですか？

エンジニアの職務経歴書はほぼ全てのケースでPC作成が推奨されます。理由は、技術スタックの一覧表やプロジェクト詳細を整理するためにテーブルを多用するため、手書きでは見やすくまとめることが困難だからです。特に指定がある場合を除き、WordやGoogleドキュメントで作成してPDF化して提出してください。