職種・体制

Engineering Manager

（えんじにありんぐまねーじゃー／エンジニアリングマネージャー）

登場（海外）: 2017年
国内で見られるように: 2019年ごろ
更新: 2026-08-24

一言でいうと

開発チームの成果と、メンバーの成長・評価に責任を持つ職種です。現場ではEMと略されます。

この職種の出自と登場時期

開発現場に管理職を置くこと自体は古くからありますが、「エンジニアリングマネージャー」という職種として整理されたのは2010年代後半です。2017年に Camille Fournier が『The Manager's Path』を出版し、メンターからテックリード、チームのマネージャー、マネージャーのマネージャー、そして組織を運営する立場までの段階を示しました。技術者が管理職へ進む道筋が、初めて体系立てて共有されます。

同時に、管理職に進まない技術職の道（Staff Engineer 以降）も整理されました。この2本立てが共有されたことで、この職種は「昇進の結果」ではなく「別の職種への転換」として理解されるようになります。

国内では2019年前後から求人票と組織図に定着し、コミュニティでの発信も活発です。ただし、プレイングマネージャーとして実装を続ける形と、管理に専念する形の両方があり、求人票では実装比率の確認が必要です。

ミッション

問われるのは、担当チームが継続して成果を出せる状態にあるかどうかです。自分の生産性ではなく、チームの生産性と、そこにいる人が成長しているかで評価されます。

そのため、短期の成果と中長期の育成の配分が判断の中心になります。目の前の納期を優先し続けると、数か月後にチームの力が落ちます。

主な業務範囲

目標と計画の設定。事業側の要求をチームの計画へ翻訳し、優先順位を決める
1on1と育成。メンバーの状況を把握し、成長の方向を一緒に決める
評価とフィードバック。等級と報酬の判断を行い、その根拠を本人へ伝える
採用。求人票の作成、面接、オファーの意思決定に関わる
組織の運営。チーム編成、開発プロセスの改善、他部署との調整を担当する

求められる能力

実装は手放してよいものの、メンバーの設計とコードの妥当性は自分で判断できる必要があります。難易度を見誤ると、計画も評価も同時に狂います。

仕事の中心は people management の実務です。評価を伝える力、対立を扱う力、採用で見極める力が問われます。加えて、事業側と技術側の言葉を相互に翻訳する役割も担います。

この職種に就く人のキャリア経路

多いのはテックリードからの移行です。チームの技術判断を担うなかで、育成と調整の比重が増して転換する流れが一般的です。他社でマネジメント経験を積んだ人が中途で入るケースもあります。

そこから先は、VPoE として組織全体を見る道、CTO、プロダクトマネージャーへ移る道、技術職へ戻って Staff Engineer になる道に分かれます。

隣接職種との違い

職種	責任の中心	EMとの違い
テックリード	担当チームの技術判断	技術に責任を持つ。EMは人と成果に責任を持つ
VPoE	開発組織全体の運営と成果	対象が組織全体。EMは担当チームが単位
Staff Engineer	チームを越えた技術課題の解決	技術で影響を出す。EMは人と組織を通じて影響を出す
プロダクトマネージャー	作るものの決定と優先順位づけ	何を作るかを決める。EMはどう作れる体制にするかを決める

採用担当の見極めポイント

求人票では、実装の比率と評価権限の有無を明記してください。プレイングマネージャーを想定しているなら、その旨を書かないと入社後に齟齬が生じます
職務経歴書では、評価と採用に関わった経験を確認してください。評価の記述がないなら、低い評価をどう伝えたかを面接で聞いてください
チームの状態を正直に伝えてください。立て直しが必要な状況を伏せて採ると、着任後の期待とずれます

求人・市場の傾向

需要は増え続けていますが、マネジメント経験のある候補者は限られ、テックリード層から育てる前提の募集が増えています。マネジメント経験の有無は職種カテゴリでは分かれないため、経歴の記述で判断してください。

チームの人数と構成、期待する時間配分、上位の組織体制。これらが書かれていない求人は、候補者側で役割を判断できません。