ITエンジニアの職務経歴書は、「技術スタック」「担当フェーズ」「チーム規模と役割」「定量的な成果」の4点をプロジェクトごとに構造化して書くのがポイントです。採用側のエンジニアリングマネージャーは、文章の上手さより「何を・どの規模で・どこまで任されたか」を短時間で把握したいため、開発環境を表形式で示し、実績は「応答速度を40%改善」「障害件数を月6件→1件」のように数値で書きます。この記事では、ITエンジニアの職務経歴書の基本構成、プロジェクト経歴の書き方と見本、職種別（Web・インフラ・SE・組み込み）のポイント、職務要約・自己PRの例文、スキルシートとの違いを解説します。
ITエンジニアの職務経歴書の基本構成
| 項目 | 書く内容 | エンジニア特有のポイント |
|---|---|---|
| 職務要約 | 経験年数・領域・代表的な実績を3〜5行 | 「Web系自社サービスでバックエンド8年」のように領域を明示 |
| 職務経歴（プロジェクト単位） | 期間・案件概要・規模・担当フェーズ・役割・開発環境・成果 | 会社単位ではなくプロジェクト単位で区切る。開発環境は表にする |
| テクニカルスキル | 言語・FW・DB・インフラ・ツールを経験年数つきで | 「実務3年」「業務で使用」「学習中」などレベルを併記 |
| 資格 | 基本情報・応用情報・AWS認定・LPIC など | 取得年月と正式名称 |
| 自己PR | 課題解決・技術選定・チームへの貢献のエピソード | 数値と技術的判断の理由を入れる |
職務経歴書全体の基本は職務経歴書の書き方【完全ガイド】で解説しています。ここではエンジニア特有の書き方に絞ります。
プロジェクト経歴の書き方と見本
エンジニアの職務経歴は、会社ごとではなくプロジェクトごとに書きます。1プロジェクトあたり6〜12行を目安に、以下の要素を必ず入れます。
- 期間：2024年4月〜2025年3月（12か月）
- 案件概要：業種・サービスの種類・目的（例：EC サイトのリプレイス）
- 規模：チーム人数・ユーザー数・予算などのいずれか
- 担当フェーズ：要件定義／基本設計／詳細設計／実装／テスト／運用保守 のどこを担当したか
- 役割：メンバー／サブリーダー／リーダー／テックリード／PM
- 開発環境：言語・FW・DB・インフラ・ツール（表形式が読みやすい）
- 成果・工夫：数値で示せる改善、技術的な判断とその理由
＜プロジェクト経歴の見本＞
■ 2024年4月〜2025年3月 ECサイトのリプレイス（自社サービス）
【概要】月間100万PVのECサイトを、モノリスからマイクロサービス構成へ段階的に移行
【規模】開発チーム6名（うちバックエンド3名）／ユーザー数 約30万人
【担当フェーズ】要件定義・基本設計・実装・テスト・運用
【役割】バックエンドリーダー（メンバー2名のレビュー・タスク管理）
【開発環境】TypeScript / Node.js / NestJS / PostgreSQL / Redis / AWS（ECS・RDS・SQS）/ Terraform / GitHub Actions
【成果】
・商品検索APIの応答速度を平均1.8秒→0.4秒に改善（N+1解消・キャッシュ導入）
・CI/CDの整備によりデプロイ頻度を週1回→日次に
・障害対応の手順を整備し、月平均6件の障害を1件に削減
複数のプロジェクトがある場合は、応募先に近いものを詳しく、それ以外は3〜5行に簡略化します。5年以上前の案件は1〜2行にまとめて構いません。
テクニカルスキルの書き方
スキルは「名前を並べる」だけでは伝わりません。経験年数とレベルをセットで書き、応募先の募集要項にあるスキルを上に持ってきます。
| 分類 | 記載例 |
|---|---|
| 言語 | TypeScript（実務5年）、Python（実務2年）、Go（学習中・個人開発で使用） |
| フレームワーク | React / Next.js（実務4年）、NestJS（実務2年）、Django（実務1年） |
| DB・ミドルウェア | PostgreSQL（実務5年・設計経験あり）、Redis、Elasticsearch |
| インフラ・クラウド | AWS（ECS・RDS・Lambda・CloudFront、実務3年）、Terraform、Docker |
| ツール・その他 | GitHub Actions、Datadog、Jira、Figma（仕様確認） |
職種別のポイント
| 職種 | 採用側が見るポイント | 書くべきこと |
|---|---|---|
| Webエンジニア（フロント／バック） | 技術スタックの深さ、パフォーマンス・品質改善の実績 | フレームワークの経験年数、改善の数値、設計・レビュー経験 |
| インフラ・SRE | 運用規模、可用性・コストの改善、IaC・監視の経験 | サーバー台数・トラフィック、SLA達成率、コスト削減率、障害対応 |
| SE（SIer・受託） | 担当フェーズの広さ、顧客折衝、プロジェクト規模 | 要件定義〜運用のどこを担当したか、顧客業種、人月・予算規模 |
| 組み込み・制御 | 対象製品、使用ハード・OS、品質・安全規格 | 製品名（公開可能な範囲）、C/C++・RTOS、規格対応の経験 |
| データ・ML | 扱ったデータ量、モデルの精度・ビジネス効果 | データ規模、精度指標、施策のKPI改善 |
| PM・PL | マネジメント規模、納期・予算・品質の実績 | チーム人数、プロジェクト規模、納期遵守率、採用・育成 |
職務要約・自己PRの例文（ITエンジニア）
職務要約の例文
Web受託開発会社および自社SaaS企業において、Webアプリケーションの設計・開発に8年間従事してまいりました。バックエンド（TypeScript / Node.js / PostgreSQL）を中心にフロントエンド（React）も担当し、直近3年はテックリードとしてメンバー5名の技術支援とアーキテクチャ設計を推進。ECサイトの応答速度70%改善やCI/CD整備によるデプロイ頻度の向上など、計測に基づいた改善で成果を出してきたことが強みです。
自己PRの例文
課題を計測で特定し、技術的な判断で解決することが強みです。担当した自社サービスでは、画面表示に平均4秒かかりユーザーの離脱率が高い課題がありました。APMで原因を特定し、N+1クエリの解消とキャッシュ層の導入を提案・実装した結果、表示速度を1.2秒（70%改善）まで短縮し、離脱率を8ポイント改善しました。技術選定では目的とコストのバランスを重視し、チームが運用できる構成を選びます。貴社でも、計測と改善の積み重ねでプロダクトの価値向上に貢献いたします。
自己PRの構成や他の例文は職務経歴書の自己PRの書き方と例文を参考にしてください。
スキルシートとの違い
SES・受託企業では、職務経歴書とは別に「スキルシート」（案件経歴を表形式で列挙した書類）を求められることがあります。スキルシートは技術と期間の一覧、職務経歴書はそこに役割・成果・強みを加えた文書です。両方求められた場合は、スキルシートの案件一覧と職務経歴書のプロジェクト経歴の期間・技術を一致させてください。
ITエンジニアの職務経歴書でよくあるNG例
- 技術名を並べただけで経験年数・レベルがない
- 担当フェーズが書かれておらず、実装だけなのか設計もしたのか分からない
- 成果が「安定稼働に貢献」のように定性的で、数値がない
- プロジェクトを会社単位でまとめてしまい、案件ごとの規模と役割が見えない
- 社内用語・未公開の製品名をそのまま書いている（規模感が伝わる範囲に置き換える）
- A4 3枚以上になっている（応募先に近い案件以外は簡略化する）
よくある質問
ITエンジニアの職務経歴書は何枚が適切ですか？
A4で2枚が目安です。プロジェクト数が多い場合は、応募先に近い案件と直近3〜5年を詳しく書き、それ以前は1〜2行にまとめます。3枚を超えると読まれにくくなります。
開発環境はどこまで書けばよいですか？
言語・フレームワーク・DB・インフラ・主要ツールをプロジェクトごとに書きます。バージョンは主要なもの（React 18、Node.js 20 など）だけで十分です。応募先の募集要項にある技術は必ず含めます。
未経験からエンジニアに転職する場合、職務経歴書には何を書きますか？
前職の職務経歴に加えて、「学習・開発経験」の項目を設け、学習した言語・作成したアプリ（GitHubのURL）・取得資格を書きます。前職で培った課題解決やチームでの進め方も、エンジニアの仕事に通じる強みとして書けます。
スキルシートと職務経歴書は両方必要ですか？
企業によります。SES・受託では両方求められることが多く、自社サービス企業では職務経歴書のみが一般的です。両方提出する場合は、案件の期間と技術を一致させてください。
まとめ：プロジェクト単位で「環境・フェーズ・役割・数値」を書く
- 職務経歴はプロジェクトごとに、期間・概要・規模・担当フェーズ・役割・開発環境・成果を書く
- 開発環境は表形式、スキルは経験年数とレベル付き
- 成果は「応答速度70%改善」「障害月6件→1件」のように数値で
- 応募先の募集要項にある技術・経験を上に持ってくる
エンジニアの職務経歴書テンプレートでは、この構成の例文が入った状態からAIとの対話で自分の案件に書き換えられます。登録不要・無料で作成でき、PDF・Wordで出力できます。