キャリアメディア / 職務経歴書

エンジニアリングマネージャーの職務経歴書の書き方｜書類通過率を上げる実例テンプレート

職種：エンジニアリングマネージャー ｜更新日 2026/7/4

エンジニアリングマネージャー（EM）の転職市場では、書類選考の段階で候補者の大半が脱落する。その主因は技術力や実績の不足ではなく、「EMとしての職務経歴書をどう書くか」という表現の問題にある。個人の技術貢献を記述するエンジニア時代の書き方から脱却できていない職務経歴書は、採用担当者が最も注目するマネジメント思考・組織貢献・事業インパクトの観点が抜け落ちている傾向がある。

本稿では、EMの職務経歴書に特有の構造的な問題を整理したうえで、通過率に差が出やすい記述の型と、実例に近い形のケーススタディを示す。

EMの職務経歴書が難しい3つの理由

技術とマネジメントの両軸を同時に示す必要がある

EMのポジションは企業ごとに定義が異なる。スペクトラムの一方には「テックリード寄りのEM」があり、他方には「ピープルマネジメント中心のEM」がある。採用企業が求める像を特定し、そこに合わせて技術貢献とマネジメント貢献の比重を調整することが求められる。一律の書き方では、技術重視の企業には「マネジメントしか書いていない」と映り、マネジメント重視の企業には「エンジニアの書類と変わらない」と映りやすい。

成果の可視化が困難なケースが多い

エンジニアであれば「◯◯の機能を実装し、ページ速度を30%改善」という形で成果を数値化できる。しかしEMの仕事は、採用・育成・1on1・プロセス改善・組織設計といった活動が中心であり、直接的なアウトプットが数値に現れにくい。この課題を放置すると、職務経歴書全体が「業務の羅列」になり、貢献の大きさが伝わらない。

“プレイヤーからマネージャーへ”の転換が書かれていない

EMへのキャリアチェンジを経て初めてマネジメントに就いた人の場合、IM（個人貢献者）時代の記述とEM時代の記述の間に思考の断絶が生じることがある。採用担当者は「なぜこの人はマネジメントを選んだのか」「マネジメントを通じて何を実現しようとしているのか」を読み取ろうとしている。その文脈が書かれていない職務経歴書は、説得力に欠ける傾向がある。

構成の全体像：推奨フォーマット

EMの職務経歴書は以下の順序で構成するのが一般的に有効とされる。

A4用紙換算で2〜3枚が実務上の目安となる。1枚に収めようとすると情報が削られすぎ、4枚を超えると読み手の集中力が低下しやすい。

各セクションの書き方

サマリー：最初の150字で採用担当者の判断を引き出す

サマリーは採用担当者が最初に読む箇所であり、「この候補者を次のステップに進めるか」の仮判断が下される。EMのサマリーには以下の3要素を含めることが有効とされる。

1. マネジメント経験の概要（チーム規模・年数・領域）
2. 技術的なバックグラウンド（専門領域・スタック）
3. 軸となる強みと志向（組織設計・採用強化・技術戦略など）

記述例：

バックエンドエンジニアとして5年間の開発経験を経て、3年間エンジニアリングマネージャーに従事。最大12名のチームを管掌し、採用・育成・スプリント運営・技術戦略の策定を担ってきた。組織の成長フェーズにおける採用体制の構築と、エンジニアの自律的な意思決定を促す1on1設計に強みを持つ。

スキルセット：技術とマネジメントを分けて記載する

スキルを一覧で並べる際は、カテゴリを明示することが重要となる。技術スキルとマネジメントスキルが混在していると、どちらの強みも薄まって見える傾向がある。

技術スキル例：Go / Python / AWS（EC2・RDS・Lambda） / Kubernetes / PostgreSQL / GitLab CI

マネジメントスキル例：採用面接設計 / 評価制度の策定・運用 / OKR運用 / 1on1設計 / エンジニア組織のロードマップ策定 / スプリント計画・ベロシティ管理

ドメイン知識例：BtoB SaaS / フィンテック / アジャイル開発（Scrum） / セキュリティコンプライアンス（SOC2対応経験）

職務経歴：数値・チーム規模・文脈を必ずセットで書く

職務経歴の各社記述で最も差が出るのが「数値化と文脈の組み合わせ」である。数値があっても文脈がなければ意味が伝わらず、文脈だけあっても抽象的すぎて説得力を欠く。

弱い記述の例：

開発チームのマネジメントを担当。メンバーの育成や採用活動を推進した。

強い記述の例：

急成長フェーズにあるプロダクトチームのEMとして、エンジニア5名から12名への拡張期を担当。採用面接プロセスを再設計し、選考リードタイムを従来比で約40%短縮。四半期ごとの1on1設計を標準化し、メンバーの中途退職率が前年度と比較して半減した（定量的な補足は在職中データに基づく目安）。

「何人のチームを」「どんな状況で」「何をして」「どうなったか」の4点が揃うと、読み手が具体的なイメージを持ちやすくなる。

ケーススタディ：Series Bスタートアップに転職したEMの書類通過例

背景

• 候補者：34歳、バックエンドエンジニアを6年経験後、現職で2年間EM
• 転職先：Series B・SaaS企業（エンジニア組織20名規模）
• 応募ポジション：エンジニアリングマネージャー（プラットフォームチーム担当）

書類通過のポイント

1. サマリーで「組織フェーズの適合性」を明示した

転職先が「PMFを経て組織をスケールさせるフェーズ」にあることを踏まえ、サマリーに「グロースフェーズでの採用体制構築」「チームの自律性向上」というキーワードを含めた。採用担当者が「このフェーズに合っている」と即座に判断できる設計を意図した。

2. STAR形式でプロセス改善の実績を1件深掘りした

• Situation（状況）：スプリントのベロシティが安定せず、リリーススケジュールの予測精度が低い状態だった
• Task（役割）：EMとして開発プロセスの安定化を担う
• Action（行動）：スプリントレトロスペクティブの構造を見直し、バックログリファインメントの頻度を週1回に変更。見積もり精度を向上させるためのプランニングポーカー導入を主導
• Result（成果）：3ヶ月でベロシティのばらつきが約35%低減し、リリース予定日に対する達成率が向上。結果として、プロダクトマネージャーとの信頼関係が改善された

3. 技術スキルを「現在も通用するか」の観点で取捨選択した

5年以上前に主に使用していたスキルは削除し、現在のチームで実際に活用しているスタックのみを記載した。EMポジションであっても技術の現役感を示すことは、技術組織への適合性を伝える上で有効とされる。

よくある質問

Q1. コードを書いていない期間が長い場合、技術スキルはどう記載すればよいですか？

コーディングから離れている場合でも、アーキテクチャレビュー・コードレビュー・技術仕様の策定といった「技術的判断に関与した経験」は記載する価値がある。完全にコードを書いていない場合は「主に技術レビューおよびアーキテクチャ設計のレビューを担当」と記載し、無理に現役感を演出しないことが重要とされる。虚偽に近い記載は面接で必ず露見し、信頼を損なう。

Q2. マネジメントの成果を数値化できない場合はどうすればよいですか？

定量化が難しい場合は「定性的な変化」を具体的に記述することで補完できる。「チームの心理的安全性が向上した」という表現ではなく、「メンバーが自発的に技術的負債の解消案を提案するようになり、週次の改善PRが平均3件から8件に増加した」という形で、行動変容の痕跡を示すことが有効とされる。

Q3. EMとして年収はどの程度を期待できますか？

企業の規模・ステージ・事業ドメインにより相場観は大きく異なるが、国内のIT・SaaS企業においてEMポジションは概ね800〜1,400万円台の範囲で提示されることが多い傾向がある。大手外資系テック企業では上限がさらに高くなるケースも見られる。ただしこれはあくまで相場感の目安であり、個人の経験年数・チーム規模・技術の専門性によって個別に異なる。

Q4. 職務経歴書に「マネジメント哲学」や「大切にしていること」を書いてもよいですか？

職務経歴書本体に含めることは一般的に少ないが、サマリーの末尾や「自己PR」欄として設ける場合には有効なことがある。ただし、抽象的な価値観の羅列は読み手に届きにくい。「自律的なチームを育てることを重視しており、そのため1on1では指示ではなく問いかけを中心に設計している」というように、行動の具体性と紐づけた形で表現することが求められる。

まとめ

EMの職務経歴書で通過率に差が出るのは、技術力やマネジメント経験そのものではなく、それをどう構造化して伝えるかという表現の設計力にある。サマリー・スキルセット・職務経歴の各セクションを「採用企業のフェーズと文脈に合わせて組み替える」ことが、書類選考を通過するための実務的な基本となる。数値化が難しい成果であっても、行動変容や構造的な変化として記述することで説得力を持たせることができる。STAR形式を活用した深掘り記述は、読み手にEMとしての思考プロセスを伝える上で特に有効とされる。自身の職務経歴書が現在の市場における訴求力を十分に持っているかどうか、専門のキャリアアドバイザーに確認してみることが一つの選択肢となる。