エンジニアリングマネージャー(EM)とは何をする人か
EMは、エンジニアの育成・評価・キャリア形成を担う「ピープルマネジメント」と、アーキテクチャや技術的負債の意思決定を担う「テクノロジーマネジメント」を両輪で担当するポジションだ。求人票では「エンジニア組織のマネージャー」と一言でまとめられがちだが、実務上の役割はおおむね次の4つに分解できる。
- チームマネジメント:メンバーの評価・1on1・キャリア支援を通じて、個々の技術者が力を発揮できる状態をつくる
- 生産性の向上:開発フローの改善、勉強会や技術投資の意思決定を通じてチーム全体のアウトプットを底上げする
- 経営との橋渡し:エンジニア組織と経営層・事業部門の間に立ち、優先順位やロードマップの交渉を担う
- 技術的負債の管理:どこまで負債を許容し、いつ返済に回すかを判断する
これらは「エンジニアがそのままマネージャーになる」延長線上の仕事ではなく、評価対象が「自分の成果」から「チームの成果」に切り替わる、別の職能だと捉えたほうが実態に近い。かつては優秀なエンジニアがプレイングマネージャーとして技術リードと人事評価を兼任するケースが一般的だったが、チーム規模が大きくなるほど「コードを書きながら評価も見る」という兼務は破綻しやすい。専任のEMを立てて技術判断と人の評価を分離する組織が増えている背景には、この兼務の限界がある。
EMに求められる4つのスキル
役割が「技術」と「人」と「経営」にまたがる分、EMに求められるスキルも一方向には閉じない。求人票や実務での要件を横断すると、次の4つに集約できる。
- コミュニケーション能力:エンジニアと経営層・他部門の間に立ち、双方の意見を翻訳して言語化する能力
- プロジェクトマネジメント能力:開発スケジュールを管理し、決定した仕様をどの手順・日程で作るかをコントロールする力
- ピープルマネジメント:メンバーのキャリア志向を引き出し、能力を発揮させるための1on1・メンタリングのスキル
- 技術的知識:自分で実装しなくても、チームの技術課題を理解し適切な判断ができるレベルの技術理解
どれか1つが突出していれば務まる役割ではなく、4つを一定水準以上でバランスさせる必要がある点が、ICとして技術を極める働き方との最大の違いになる。
EMの役割を「技術・人・経営」の3層で分解する
EMの役割は一枚岩ではない。マネジメント論で知られるロバート・カッツの「テクニカルスキル・ヒューマンスキル・コンセプチュアルスキル」という3分類を借りると、EMが日々向き合う仕事は次の3層に整理できる。
アーキテクチャレビュー、技術選定の最終判断、技術的負債をどこまで許容するかの判断。コードを書く時間は減るが、技術的な意思決定から離れるわけではない。
1on1によるキャリア支援、評価、採用面接、チーム内の対人課題の調整。EMの工数の中で最も比重が大きくなりやすい領域。
経営層・事業部門とのロードマップ調整、人員計画、開発投資の意思決定を「事業の言葉」で説明する役割。
3層の比重は企業・チーム規模によって変わる。フルスタックエンジニアのキャリアで扱ったように、幅広い技術理解が求められる立場ほど、この3層を横断して意思決定する場面が増える。特に組織が大きくなるほどLAYER 3「経営との橋渡し」の比重が上がり、技術の現場から距離ができることに戸惑う人も少なくない。
テックリード・PMとの違いを「権限」で切り分ける
テックリードとの違い:人事権の有無
テックリードとEMは、しばしば同じ人物が兼務しているために境界が曖昧になりやすいが、権限で見ると違いは明確だ。テックリードはシステムに責任を持ち、アーキテクチャや技術選定をリードする「技術領域のリーダー」であり、必ずしも人事評価や1on1の権限を持たない。一方でEMは、テックリードを含めたメンバーの評価・育成に責任を持つラインマネジメントの権限を持つ。海外流のスタイルを取り入れる組織ほど、この2つの役割を分離し、EMの仕事を「テックリードがやらないすべてのこと」と位置づける傾向がある。
PMとの違い:責任のタイムスパンと評価軸
PM(プロジェクトマネージャー)との違いは、責任を持つ対象と時間軸にある。PMは個別プロジェクトのスコープ・スケジュール・コストに責任を持ち、成果は「プロジェクトの成功」で測られる。EMは継続的なエンジニア組織そのものに責任を持ち、採用・評価・育成までがスコープに入るため、成果は「チームの中長期的な成長」で測られる。同じ「マネージャー」でも、PMは短期的なプロジェクトの完了を追い、EMは長期的なチームの状態を追う点が本質的に異なる。
実務では、1つのプロジェクトが終わればPMの責任は一区切りつくが、EMの責任はプロジェクトの完了とは関係なく続く。メンバーが退職すれば採用からやり直し、評価期間が来れば次の評価サイクルが始まる。「プロジェクト単位で区切れる仕事か、区切れない仕事か」で考えると、自分がどちらに向いているかの判断材料になる。
| 役割 | 責任の対象 | 評価軸 | 人事権 |
|---|---|---|---|
| EM | 継続的なエンジニア組織 | チームの中長期的な成長 | あり |
| テックリード | システム・アーキテクチャ | 技術的な意思決定の質 | 基本的になし |
| PM | 個別プロジェクト | プロジェクトの成功(スコープ・納期・コスト) | なし |
スペシャリストとしてキャリアを積む道と比較して自分の適性を考える読者もいるだろう。権限の違いを理解した上で、技術を極める方向と組織を動かす方向のどちらが自分の強みを生かせるかを見極めることが、遠回りを避ける近道になる。技術を極める方向で「テックリードとしてのキャリア」を深く検討したい場合は、テックリードのキャリアパスも参考にしてほしい。
EMは何で評価されるのか(評価軸)
IC(individual contributor、個人として技術で貢献する立場)としての評価は個人のアウトプット(実装量、技術的な貢献)が中心になるのに対し、EMの評価軸はチーム単位に移る。具体的には次のような指標が使われることが多い。
- チームのデリバリー:リリース頻度、計画に対する達成率など、チーム全体のアウトプット
- メンバーの成長・定着:育成の成果、離職率、エンゲージメント
- 技術的負債の状態:負債をどこまでコントロールできているか
- 経営目標への貢献:事業側の目標に対してエンジニア組織がどう寄与したか
自分ひとりの技術力が高くても、チームの評価が伸びなければEMとしての評価にはつながらない。この評価軸の転換を「窮屈」と感じるか「裁量が増えた」と感じるかが、適性を測る一つの目安になる。
年収相場とポジションの実態(2026年8月時点)
JACリクルートメントの調査によると、EMへの転職者の平均年収は1,100万円前後、最高額は2,600万円程度に達する。公開求人ベースで見ると、レンジはおおむね700万〜1,500万円、中心は900万〜1,200万円あたりに集まる。未経験に近いポジションからEMに初挑戦する場合は、600万〜700万円からのスタートも珍しくない。
求人動向としては、ビズリーチ一社だけでもEM関連の求人が1,200件を超えて掲載されており、従来は「エンジニア兼マネージャー」として一人が兼任していた役割を、専任のEMポジションとして切り出す動きが目立つ。専任化が進むほど、実務経験の量より先に「役割理解」そのものを問われる選考が増えていく。
「マネジメント適性」を転向前にセルフチェックする
ソフトウェア開発者の7割が「長期的に技術トラックに残りたい」と回答しているという調査結果がある。マネジメントを「つまらない」「やりたくない」と感じる背景には、技術から離れる不安と対人業務への負荷感が大きい。転向前に、次の観点で自分の適性を確認しておくと判断のブレが減る。
- 自分の成果より、チームの成果で評価されることに納得できるか
- 1on1や評価面談など、対人コミュニケーションに継続的な時間を割くことに抵抗がないか
- 技術的な意思決定を「自分でコードを書かずに」判断・レビューする形に切り替えられるか
- メンバーの不満や対人トラブルの仲裁など、答えのない調整業務にストレス耐性があるか
- 経営層・事業側に対して、技術的な判断を「事業の言葉」で説明する意欲があるか
すべてに強く同意できなくても問題はない。むしろ「技術トラックに残る」という選択も、前述のスペシャリストとしてのキャリアで扱ったように十分に有効な選択肢だ。EMは唯一の正解ではなく、比較した上で選ぶキャリアパスの一つに過ぎない。
EMを目指すなら、次に何をすべきか
EMへの転向を決めたら、次にやるべきことは大きく3つある。
- 社内でEM経験を積む機会を探す:いきなり社外でEMとして転職するより、現職でチームリードやEM代理としての経験を積んでから動くほうが、選考での説得力が上がる
- 年収交渉の材料を整理する:EMのオファーは基準が曖昧になりやすく、年収交渉をエージェントに任せる前にで扱ったように、自分でも交渉材料を用意しておく必要がある
- 複数の選考ルートを持っておく:EM求人は専任化が進んでいるとはいえ、まだ絶対数は多くない。転職エージェントの複数登録で解説した通り、非公開求人へのアクセス経路を複数確保しておくと選択肢が広がる
転向のタイミングも重要な論点になる。40代エンジニアの転職で見たように、年齢によって評価されるポイントは変わり、マネジメント経験の有無が評価を左右する場面も増えてくる。技術一本で勝負するか、マネジメントに舵を切るかの判断は、早いほど選択肢が残る。