ITエンジニアの職務経歴書は「何をやってきたか」を伝える書類だが、実際の採用現場では「何ができるエンジニアなのか」が3分以内に伝わる構成でないと書類段階で落ちてしまう。本記事では、Webアプリケーション／バックエンドSRE／テックリードの3職種について、実際にそのまま参考にできるサンプル文例を提示する。3名とも架空のサンプル人物だが、実在感のある経歴・数値・技術選定の記述にしてあるため、自分の経歴に置き換える際のテンプレートとして使ってほしい。

この記事でわかること

  • 採用担当が職務経歴書で見ている3要素（役割・成果・再現性）
  • 書類通過率を上げる6つの書き方ルール
  • Webアプリケーションエンジニア（5年目）の記載サンプル
  • バックエンド／SREエンジニア（8年目）の記載サンプル
  • テックリード／マネージャー候補（12年目）の記載サンプル
  • 職種別に強調すべきポイントの早見表
  • NGパターン集と、それぞれの修正方針

採用担当が職務経歴書で見ている3要素

職務経歴書の構造イメージ

中途採用の書類選考は、候補者1人あたり3〜5分の判断時間しか取れないことが多い。その短時間で採用側が確認しているのは、次の3点に集約される。

1. 役割（Role）

どのポジションで、どの範囲まで責任を持っていたか。実装メンバーなのか、設計までやったのか、技術選定の決裁権を持っていたのか、採用面接まで関与したのか。同じプロジェクトでも役割によって評価軸が変わるため、「何を担当したか」を具体的に書き切ることが第一の関門になる。

2. 成果（Outcome）

担当した結果、何がどれだけ変わったか。定量化が困難な業務でも、前後比較・期間・対象規模を添えると伝わる。「貢献した」「改善した」といった抽象語だけでは採用側は判断できないため、代替指標を使ってでも数値を添える意識が重要になる。

3. 再現性（Reusability）

そのエンジニアが別の会社・別のプロダクトで同じ成果を出せるか。成果を導いた「思考プロセス」と「意思決定の根拠」が書かれていると、再現性があると判断されやすい。シニア帯になるほど、この再現性の言語化が評価の中心になる。

書類通過率を上げる6つの書き方ルール

ルール1：冒頭にサマリーを3〜5行で置く

採用担当が最初に読むパート。ここで候補者の輪郭（専門領域・担当プロダクト・技術スタック・役割）が掴めないと、それ以降の詳細は読まれない。箇条書きではなく、散文で「どんなエンジニアか」を要約する。

ルール2：STAR法で実績を構造化する

Situation（状況）・Task（課題）・Action（取った行動）・Result（結果）のフレームで実績を整理する。特にAction部分で「なぜその方法を選んだか」の判断基準を書くと、再現性が伝わる。

ルール3：成果は必ず数値化する

前後比較・期間・対象規模の3点を添える。「レスポンスタイムを改善」ではなく「p95レスポンスタイムを850ms → 320msに短縮（6ヶ月）」と書く。数値が取れない場合は、チーム人数・ユーザー数・トランザクション数など、代替指標で規模感を示す。

ルール4：技術タグを整理する

使った技術の羅列ではなく、「役割ごと」に整理する。言語・FW・DB・クラウド・ツールを系統別に並べ、経験年数と習熟度（主力／設計レビュー対応可能／一部実装経験）を添えると粒度が揃う。

ルール5：レベル表現を統一する

「精通」「経験あり」「使ったことがある」が混在していると、採用側はレベルを推測できない。自分の中で「主力」「設計レビュー可能」「一部実装経験」の3段階など基準を決め、文書全体で統一する。

ルール6：古い経歴は時系列を圧縮する

直近3〜5年のプロジェクトを厚めに書き、それ以前は「学んだこと／獲得したスキル」のサマリーにまとめる。10年以上前のプロジェクト詳細を詳しく書いても、現在の技術スタックと乖離しているケースが多く、読み手の負荷になる。

書き方の原理はITエンジニアの職務経歴書テンプレート｜採用に刺さる書き方7要素で7要素に分解しているので、本記事のサンプルと合わせて使うと構成の見通しが立ちやすい。

サンプル1：Webアプリケーションエンジニア（5年目）

※以下は架空のサンプル人物です。記載内容はフィクションであり、実在の人物・企業とは関係ありません。

【職務要約】
BtoB SaaSのWebアプリケーション開発に5年従事。直近2年は契約管理SaaSの開発チームでフロントエンド・バックエンド両面を担当し、機能単位での設計・実装・運用を独力で回せるレベル。TypeScript／Next.js／Node.js／PostgreSQLを主戦力とし、直近は決済連携と検索基盤のリプレイスをリード。チーム6名のスクラム開発でテックリード補佐のロールも担当。

【主要プロジェクト】

プロジェクト1：契約管理SaaS 検索基盤のリプレイス
期間：2025年4月〜2025年12月（9ヶ月）
役割：テックリード補佐、設計・実装・運用
チーム：6名（エンジニア4名、PdM1名、QA1名）

背景／課題：契約書全文検索のp95レスポンスが2.3秒に達し、契約数が多い企業テナントから解約リスクとしてエスカレーションされていた。既存構成はPostgreSQLのGINインデックス依存で、検索精度・速度ともに頭打ち。

行動：ElasticsearchとOpenSearch、pgvector拡張の3案を比較し、運用チームのSQL資産を活かせる点とセマンティック検索の導入を見据えてpgvector + BM25ハイブリッドの構成を採用。既存の検索APIをRustでリライトしつつ、段階的にCanaryリリース。

成果：p95検索レスポンスを2.3秒→380msに短縮。検索関連のチャーン理由での解約問い合わせを9件/月→0件に。エンタープライズ向け契約の更新率が前年同期比で改善。

プロジェクト2：決済プロバイダ移行
期間：2024年7月〜2024年12月（6ヶ月）
役割：バックエンド実装リード
チーム：4名

背景／課題：既存決済プロバイダの手数料コスト増加と国際カード対応の遅れを受けて、Stripeへの移行を決定。稼働中の契約10,000件超の継続請求を無停止で移行する必要があった。

行動：移行中の二重請求リスクをEventSourcing化した請求ログで可視化。契約単位で移行ステータス管理テーブルを設計し、ロールバック可能な段階移行フローを構築。

成果：顧客への請求停止なしで移行完了、決済関連のインシデント件数ゼロ。決済手数料を月あたり概算で15%削減。

【スキルタグ】
主力：TypeScript（5年）、Next.js（3年）、Node.js（5年）、PostgreSQL（5年）、AWS（4年）
設計レビュー可能：Rust（1年）、Docker／ECS、CI/CD（GitHub Actions）、Elasticsearch／pgvector
一部実装経験：Python、Go、Terraform、Datadog
開発プロセス：スクラム、ADR運用、RFC文化、ペアプロ

このサンプルの強みは、「役割が具体的」「成果が数値化されている」「技術選定の思考プロセスが見える」の3点が揃っていること。Webアプリケーションエンジニアのサンプルとして、そのまま構成を流用しやすい。

サンプル2：バックエンド／SREエンジニア（8年目）

※以下は架空のサンプル人物です。記載内容はフィクションであり、実在の人物・企業とは関係ありません。

【職務要約】
インフラエンジニアとしてキャリアを開始し、クラウド基盤の設計・運用を経てSREロールに移行。現職のフィンテックスタートアップでは、ピーク時QPS 4,000超の決済APIの信頼性を担う。AWS／Kubernetes／Terraformを主軸に、オンコール体制の整備・SLO設計・ポストモーテム文化の定着まで責任範囲とする。直近はコスト最適化プロジェクトもリード。

【主要プロジェクト】

プロジェクト1：Kubernetes基盤の再設計と信頼性向上
期間：2024年4月〜2025年6月（15ヶ月）
役割：SREリード
チーム：SRE 3名、開発チーム連携 約20名

背景／課題：単一AZ運用のEKSクラスタで、AZ障害時に決済APIが15分以上停止するインシデントが発生。事業側からダウンタイムに対する強いコミット要求が出ていた。

行動：マルチAZ化・Cluster Autoscaler導入・PDB整備・Chaos Engineeringの月次演習導入。DBレイヤーはAurora Globalに切り替え、リージョン障害時のフェイルオーバー手順をRunbook化。SLOを「決済API 99.95%」に設定し、エラーバジェット運用を開始。

成果：AZ障害シナリオでの自動復旧時間を15分→45秒に短縮（Chaos演習計測値）。四半期あたりのP0インシデント件数を4件→0件に削減。エラーバジェット消化率の可視化で開発チームのリリース判断が迅速化。

プロジェクト2：クラウドコスト最適化
期間：2025年7月〜2025年12月（6ヶ月）
役割：横断プロジェクトリード
チーム：SRE 2名、開発チーム3チーム

背景／課題：AWSコストが前年比35%増で経営課題として浮上。単純なリザーブドインスタンス購入では限界があり、アーキテクチャ側の最適化が必要だった。

行動：コストアロケーションタグを全サービスに設定、CUR（Cost and Usage Report）とAthenaを組み合わせたダッシュボードを構築。Graviton対応、Spot活用、S3ライフサイクル見直し、NATゲートウェイ経路最適化の4施策を並行実施。

成果：月あたりAWSコストを約28%削減（削減絶対額で月600万円規模）。SLOに影響を与えず、コスト監視ダッシュボードで継続的に可視化される運用に落とし込んだ。

【スキルタグ】
主力：AWS（7年、SA Pro保有）、Kubernetes／EKS（4年）、Terraform（5年）、Linux／システム運用
設計レビュー可能：GCP、Datadog／NewRelic、Prometheus／Grafana、Argo CD、SLO/エラーバジェット運用
一部実装経験：Go、Python、Rust、Istio、Karpenter
その他：オンコール体制設計、Chaos Engineering運用、ポストモーテム文化醸成、SOC2監査対応

SRE／バックエンド系の職務経歴書で評価されるのは、「定量的な信頼性指標」「運用プロセスの整備」「事業インパクト」の3軸。このサンプルはSLO・エラーバジェット・コスト削減額という、経営との対話にも使える数字が揃っている点が参考になる。クラウド資格の優先順位に沿って認定資格を組み合わせると、書類段階での評価に厚みが出る。

サンプル3：テックリード／マネージャー候補（12年目）

※以下は架空のサンプル人物です。記載内容はフィクションであり、実在の人物・企業とは関係ありません。

【職務要約】
12年間のエンジニアキャリアを通じて、Webアプリケーション開発からテックリード、エンジニアリングマネージャー候補へ段階的に役割を広げてきた。直近5年は複数チーム横断のテックリードとして、プロダクト戦略と技術戦略の橋渡しを担当。採用面接官として3年で50名超の選考に関与、新卒オンボーディング設計、社内勉強会立ち上げなど、組織への貢献範囲も広い。次キャリアはVPoE／EM／Staff Engineerのいずれかを視野。

【主要プロジェクト】

プロジェクト1：プロダクト基盤のモジュラモノリス化
期間：2023年1月〜2024年12月（24ヶ月）
役割：テックリード、アーキテクト
チーム：3チーム30名横断

背景／課題：創業期からのRailsモノリスが肥大化し、デプロイ競合・テスト実行時間・新規メンバー立ち上げ時間が経営課題化。完全マイクロサービス化は組織規模に対して過剰と判断し、モジュラモノリス路線を選択。

行動：ドメイン境界を洗い出すイベントストーミングを月次ワークショップで実施。パッケージ構成の指針（ADR）を10本策定し、モジュール間のAPI契約をInternal RPC化。並行して新卒3名のオンボーディングをこのプロジェクト内で設計し、ドキュメントと実装両面の学習効果を得た。

成果：CI実行時間を42分→11分に短縮、デプロイ頻度を週2回→日次へ改善。新卒エンジニアの独力コミット到達期間を平均12週→5週に短縮。ADR文化が全社に波及し、その後のプロジェクトでも設計判断の透明性が高まった。

プロジェクト2：エンジニア採用プロセス再構築
期間：2023年7月〜2024年3月（9ヶ月）
役割：採用プロジェクトリード（人事部と共同）
チーム：エンジニア5名、HR 2名

背景／課題：採用充足率が目標の60%にとどまり、採用スピードと候補者体験の両立が課題。コーディング試験の評価観点がバラバラで、面接官によって合否判定が揺れていた。

行動：ルーブリック方式の評価シートを整備、面接官トレーニングを四半期ごとに開催、オファー後の候補者アンケートを制度化。カジュアル面談→技術面接→カルチャー面接→経営面接のプロセスに所要期間を定義し、HRと共同でSLA化。

成果：採用充足率60%→95%に改善、内定辞退率30%→14%に低下。面接官間の合否判定のばらつき（標準偏差）を半減。採用基準の言語化が組織文化の共通言語にもつながった。

【スキルタグ】
主力：アーキテクチャ設計、技術戦略、テックリード経験（5年）、採用（3年）、1on1・育成
実装主力技術：TypeScript／Ruby／Go、PostgreSQL、AWS、Kubernetes
組織運用：スクラム、スクラムオブスクラム、OKR運用、ADR／RFC文化、ポストモーテム運用
対外活動：技術カンファレンス登壇2回、技術ブログ継続寄稿

テックリード／マネージャー候補の書類で差がつくのは、「技術×組織×事業」の3レイヤーを横断する記述。実装の細部よりも、プロジェクトを通じて組織と事業に何を残したかを書くことが評価につながる。マネージャー vs ICの分岐についてはマネージャーとICの分岐点にまとめている。

職種別の強調ポイント早見表

職種 最も強調すべき項目 数値化しやすい指標 ありがちな失敗
Webアプリ（フロント／バック） 機能単位の設計判断、UX改善、プロダクトインパクト p95レスポンス、コンバージョン率、エラーレート、リリース頻度 技術スタックの羅列のみで、判断プロセスが書かれていない
バックエンド／SRE 信頼性設計、運用プロセス、コスト最適化 SLO達成率、MTTR、インシデント件数、コスト削減額 障害対応の武勇伝化、再現性のある仕組みへの言及不足
データ／ML／AIエンジニア 本番運用実績、評価設計、ビジネス接続 モデル精度、A/Bテスト結果、トークン消費、推論レイテンシ Kaggle・研究題材の羅列に終始し、プロダクション経験が不明瞭
テックリード／EM 技術×組織×事業の橋渡し、育成・採用成果 チーム生産性、離職率、採用充足率、リリース頻度改善 「マネジメント」を抽象語のみで済ませ、具体的な行動が見えない
QA／テストエンジニア 品質戦略、自動化率、シフトレフト推進 バグ流出率、自動化カバレッジ、リリース前リードタイム テスト実行者の立場に見える書き方（戦略側の関与が伝わらない）

NGパターン集

NG1：技術の羅列だけで役割が書かれていない

「TypeScript、React、Node.js、PostgreSQL、AWS、Docker、Kubernetes、Terraform...」と技術名の羅列で職務経歴書が終わってしまうパターン。使ったツールの一覧は情報密度が低く、採用側は「どのレベルで使えるのか」「どんな判断をしてきたのか」を読み取れない。技術タグは補助情報にとどめ、本文は役割・判断・成果を主軸にする。

NG2：抽象化しすぎて具体が消える

「大規模プロジェクトで品質改善に貢献」「複数の技術的課題を解決」「チームの生産性を向上」——このような抽象語のみの記述は、評価しようがない。「大規模」「複数」「向上」の具体的な数値・事例・判断を最低1つは添えることが、書類通過の最低ラインになる。

NG3：肩書だけで中身が見えない

「リーダー」「マネージャー」「アーキテクト」などの肩書を並べるだけで、実際の仕事内容が書かれていないパターン。同じ「リーダー」でも、実装も書きながら設計レビューしていた現場と、ほぼ実装をせずにステークホルダー調整だけをしていた現場では評価軸が異なる。肩書は補助情報として、実際の業務内容を書き切る。

NG4：直近と古い経歴の情報量が逆転している

10年以上前のプロジェクトを詳しく書き、直近2年が薄いパターン。採用側は直近3〜5年の経験を最も重視するため、情報量の配分を逆にする。古い経歴は「このプロジェクトで〇〇の基礎を身に付けた」とサマリー化し、直近を厚く書く。

NG5：応募先に関係ない成果を羅列している

職務経歴書はテンプレート化しつつも、志望軸と強調ポイントは応募先に合わせて差し替える必要がある。SREポジションに応募するのに、フロントエンドの詳細を1ページ使って書いても刺さらない。汎用版と応募先カスタマイズ版の2系統で管理するのが実務的だ。

NGパターンの修正は、面接対策の入り口でもある。面接での深掘りは書類の書き方とセットで設計するのが効率的で、ITエンジニアの面接準備にプロセス全体の整理がある。

テンプレート配布ツール＆関連記事

書類作成の起点になるリソースを整理しておく。

まとめ

  • 採用担当が見ているのは「役割・成果・再現性」の3要素。この3つが冒頭1ページで伝わる構成を作る。
  • サマリー3〜5行＋STAR法＋数値化＋技術タグ整理＋レベル表現統一＋時系列圧縮の6ルールで、書類の完成度が変わる。
  • Webアプリ／SRE／テックリードで強調すべきポイントは異なる。職種別のサンプルを自分の経歴に置き換えて使う。
  • NGパターン（技術羅列／抽象語／肩書のみ／古い経歴過多／応募先無視）は事前に潰せる。
  • テンプレート配布記事と面接準備記事をセットで活用し、書類→面接→交渉までを通しで設計する。

（本記事のサンプルは全て架空の人物によるフィクションです。実在する個人・企業・プロジェクトを示すものではありません。本サイトはTechGoのアフィリエイトパートナーであり、リンク経由の申込で収益が発生する場合があります）