エンジニアリングマネージャー(EM)とは?役割やテックリードとの違いを解説
2026年10月16日更新
上長からエンジニアリングマネージャー(EM)を打診されて、引き受けたらコードを書けなくなるのではないかと迷っていないでしょうか。
EMは、日本では2018年ごろから肩書きとして広まり、専任のEMを置く会社が増えてきました。一方で、EMに任される範囲は会社によって大きく異なり、同じ肩書きでもテックリードに近い役割から部長に近い役割まで幅があります。そのため、EMが何をする役職なのかを正しく知っておくことが、打診を受けるかどうかを決める前提になります。
この記事では、以下の内容を解説します。
-
EMの定義と、組織の中での位置づけ
-
EMが担う4つの領域と、テックリードやPdMとの違い
-
EMになった後のコードを書く時間と、求められる技術力
-
EMの年収相場と、年収を左右する要因
-
EMを引き受ける前に上長へ確認したいこと
EMへの打診を受けて、引き受けるかどうか迷っているテックリードやシニアエンジニアの方に、判断の材料になる情報をまとめてお伝えしているので、ぜひ参考にしてください。

著者
伊東 光雄
(Ito Mitsuo)
専門学校卒業後、約12 年間IT サービス事業会社にてシステム開発、インフラ運用管理、自社製品の新規開拓営業に従事。その後、2014 年に株式会社ワークポートに就業しキャリアアドバイザーとして転職相談にお越し頂く求職者に対し、キャリアに関する相談業務~求人企業のご紹介~内定・入社までのサポート及び、入社後のアフターフォロー業務全般に従事。
プロフィール詳細を見る

監修者
五嶋 司
(Goto Tsukasa)
高校卒業後、公的機関にて実務経験を積んだのち、IT・Web・ゲーム業界特化の人材紹介会社Geeklyへ転身 。入社1年足らずでチームリーダーへ昇進し、計5度のMVPを受賞するなど、一貫して高い目標を達成し続けています 。
プロフィール詳細を見る
目次
CONTENTS
エンジニアリングマネージャー(EM)とはどんな役職か
上長からEMを打診されたとき、まず気になるのは、EMが社内でどんな立場の役職なのかでしょう。EMという肩書きは日本では2018年ごろから広まり、専任のEMを置く会社が増えてきました。
EMを一言で表すと、エンジニアチームの成果を最大化する管理職です。また、組織上は課長〜部長相当の管理職として置かれることが多い役職です。ここでは、EMの定義と、組織の中での位置づけを解説します。
エンジニアチームの成果を最大化する管理職である
EMは、エンジニアチームが出す成果に責任を持つ管理職です。プロダクトマネージャー(PdM)が何を、なぜつくるかを決めるのに対して、EMはそれをどうつくるかに責任を持ちます。EMが担う判断には、次のようなものがあります。
-
機能をいつまでにつくるかを決める
-
品質と開発のスピードを両立させる
-
メンバーを育て、チームの力を伸ばす
つまり、EMは人を管理するだけの役職ではありません。開発の見積もりが妥当か、新しい機能にどんな技術的なリスクが潜んでいるかを理解したうえで判断する点が、一般的な管理職との違いです。EMにエンジニアとしての経験が求められるのは、こうした判断に開発の現場を知っていることが欠かせないためです。
組織上は課長〜部長相当の管理職として置かれることが多い
EMは、メンバーの評価や採用に責任を持つライン管理職として置かれます。組織の中では、現場のエンジニアやテックリードと、VPoE・CTOのあいだに入る位置です。社内での格付けは、管掌する範囲の広さによって変わります。
| 管掌する範囲 | 社内での位置づけの目安 |
|---|---|
| 10名前後の1チーム | 課長クラス |
| 複数のチーム | 部長クラス |
| 開発組織の全体 | VPoE・CTO |
求人票でも、EMを労働基準法上の管理監督者として採用すると明記している例があります。管理監督者には、労働時間や休憩、休日に関する規定が適用されません。そのため、テックリード時代に支払われていた残業代が、EMになると支給されなくなる場合があります。
ただし、管理監督者にあたるかどうかは、肩書きではなく、権限や待遇の実態で判断されます。打診を受けたときは、EMという肩書きにどこまでの権限と待遇がついてくるのかを確かめておきましょう。
参考:厚生労働省「労働基準法における管理監督者の範囲の適正化のために」
エンジニアリングマネージャーが担う4つの領域
EMの仕事は、ピープル、テクノロジー、プロジェクト、プロダクトの4つの領域に分けて整理されることがよくあります。それぞれの領域で何を管理し、EMがどう関わるのかの目安は、次の表のとおりです。
| 領域 | 管理する対象 | EMの関わり方の目安 |
|---|---|---|
| ピープルマネジメント(採用・評価・育成・1on1) | 人とチーム | EMが中心になって担う |
| テクノロジーマネジメント(技術選定・技術的負債) | 技術の方針 | テックリードと分担しやすい |
| プロジェクトマネジメント(進行管理・人員配置) | 進め方と人の配置 | PjMやスクラムマスターと分担しやすい |
| プロダクトマネジメント(事業・他部門との橋渡し) | 事業とのつながり | PdMと連携して担う |
ただし、4つの領域すべてを一人で高いレベルでこなすのは難しく、EMは会社の事情に合わせて比重を変えています。小さなチームでは自分も実装するプレイングマネージャー型、規模の大きい会社では評価や採用に集中するピープルマネージャー型というように、どの領域に力を注ぐかは会社によって変わります。以下、それぞれの領域でEMが具体的に何をするのかを見ていきます。
ピープルマネジメント(採用・評価・育成・1on1)
ピープルマネジメントは、EMの仕事の中心になる領域です。主な業務には、次のようなものがあります。
-
採用要件を決め、面接で候補者を見極める
-
メンバーと目標を決め、成果を評価する
-
1on1で悩みやキャリアの希望を聞く
-
相談しやすいチームの雰囲気をつくる
これらは、メンバーの人事評価に責任を持つライン管理職だからこそ担える業務です。そのため、ほかの3つの領域に比べて、テックリードやほかのメンバーに任せにくいという特徴があります。テックリードとしてメンバーの相談に乗ってきた経験は、この領域でそのまま活かせるでしょう。

伊東 光雄
Ito Mitsuo
EMの求人では、採用面接や評価に関わった経験を応募条件に挙げる例が目立ちます。テックリードのうちから面接官やメンターを引き受けておくと、社内でも社外でも、EMとしての素地を説明しやすくなります。
テクノロジーマネジメント(技術選定・技術的負債)
テクノロジーマネジメントは、チームが使う技術の方針を決め、開発を続けやすい状態を保つ領域です。主な業務には、次のようなものがあります。
- 技術スタックやアーキテクチャの方針を決める
- 技術的負債をどこまで受け入れ、いつ返すかを判断する
- 開発環境やツールへの投資を決める
テックリードがいるチームでは、テックリードと分担しやすい領域です。細かな技術の決定はテックリードが担い、EMはその決定がチームと事業にとって妥当かを確かめる役に回ります。EM自身が技術判断を抱え込みすぎると、メンバーと向き合う時間がなくなるので気をつけましょう。
テックリードの役割については、次の記事でも解説しています。ぜひ参考にしてください。

テックリードとは?仕事内容・必要なスキル・年収とキャリアパスを詳しく解説
テックリードの求人情報
Senior Engineering Manager
想定年収
800~2,000万円
勤務地
東京都(港区)
業務内容
アグリゲーション事業・DS事業の開発チームを対象に、以下の業務を担当いただきます。 事業・チームの状況に応じて、優先度や比重は調整します。 ① 開発マネジメント・プロセス改善 • スクラムを中心とした開発プロセスの運営と改善(スプリント計画、見積もり、進捗・リスク管理) • 品質担保の仕組みづくり(設計レビュー・コードレビューの運用、テスト方針、リリースプロセス) • 開発生産性の可視化と改善(開発メトリクスの計測・分析) • 技術的負債の把握と、返済計画の立案・実行 • 障害・インシデント発生時の対応リードと、再発防止策の推進 ② 事業・プロダクトとの連携 • CTO・プロダクトマネージャー・事業部門と連携した、開発ロードマップの策定と優先順位付け • アグリゲーション事業・DS事業それぞれの要件を踏まえた、開発リソースの配分と調整 • 要件が固まりきらない状況での論点整理と、実現可能性・工数の見立て • DS事業における、複数顧客への展開を前提としたパッケージプロダクトの開発推進 • 両事業のチーム間の連携促進、ナレッジ・開発基盤の共有による重複の削減 ③ 技術・アーキテクチャへの関与 • CTO・テックリードと連携した、アーキテクチャ・技術選定への関与 • 技術標準・開発ルールの整備と浸透 • 必要に応じた設計レビュー・コードレビュー ④ピープルマネジメント・組織づくり • 組織拡大に向けた、チーム構成・役割分担の設計 • 将来のマネージャー候補・リードの育成 • メンバーの目標設定、1on1、評価、フィードバック • エンジニア採用への参画(採用要件の定義、面接、候補者へのアトラクト) • メンバーの育成とキャリア支援(技術面・行動面の両方) • チームの心理的安全性の醸成と、エンジニアリング文化の構築 • メンバーの稼働状況・負荷の把握と、適切なアサインメント ⑤AI活用の推進 • AIコーディングエージェント(Claude Code 等)を活用した開発スタイルの定着(全エンジニアにClaude Code Max(5x)を会社負担で支給) • AI導入による生産性メトリクスの計測・可視化と、改善の推進 <開発環境・技術スタック> バックエンド:C#/ASP.NET Core/Entity Framework Core/REST API フロントエンド:TypeScript/React インフラ:Microsoft Azure/Azure SQL Database 開発・運用:GitHub Enterprise/Azure DevOps(Azure Boards)/Microsoft Teams AI開発環境:Claude Code Max(5x)を全エンジニアに支給。 必要に応じてClaude Code Max(20x)やOpenAI Codex Proも会社負担で利用可能
View More
中途_SI事業部_テックリード(2026/10/23~)
想定年収
1,000~1,300万円
勤務地
東京都(港区)
業務内容
本ポジションでは、プロジェクトおよび組織全体の「技術的な意思決定」と「標準化」を主導していただきます。 また詳細な実装や各種テスト等の実務については、メンバーや若手・ミドル層のエンジニアを主導しながら実施していただきます。 ●大規模・ミッションクリティカルなシステムの要件定義・設計 数千万人が利用する通信サービスや公共インフラの基幹NW、データセンターNWの最上流工程を担当。 最新のプロトコルや仮想化技術を駆使し、安定性と拡張性を両立した次世代アーキテクチャをデザインします。 ●アーキテクチャ設計および技術選定の最終意思決定 プロジェクト要件に応じたフレームワークやOSS、各種インフラ・ネットワーク機器の調査・評価を行い、最適な技術を選定・導入。 潜在的な技術的課題やリスクを基本・詳細設計の段階で特定し、プロジェクトマネージャーと連携して解決策を構築。 ●クオリティコントロール チーム全体のコードクオリティを担保するための設計レビュー・コードレビュー方針の策定。 テスト - 品質保証(開発クオリティの確認) ●実装 システムのパフォーマンス・堅牢性を左右するコアモジュール ●自社プロダクト創出への貢献(インキュベーション機能) 大手クライアントの最先端ネットワーク環境で得られた知見や共通の課題を抽出し、使い捨てにしない自社資産(新規プロダクトや機能)へと昇華させるための技術的なアプローチ・検討。 ●チーム全体の技術底上げ(メンター・リード) 若手~ミドル層エンジニア(別募集のジュニア~ミドルポジション等)への具体的な技術指導、技術的なベストプラクティスの共有によるチームの生産性向上。 ●開発環境 開発言語 Typescript / Python / Java フレームワーク React, Flask, FastAPI, SQLAlchemy, Spring プロジェクト管理, CI/CD Redmine, Jenkins 情報共有ツール Slack, Google Meet, Microsoft Teams OS Linux/Unix データベース PostgreSQL, mySQL, MariaDB, ElasticSearch 仮想化技術 OpenStack, Docker, Podman バージョン管理 Git クラウド AWS, Azure, GCP AI Claude Code, ChatGPT/Codex, Gemini その他 OSS 全般
View More
中途_SI事業部_テックリード候補
想定年収
800~1,000万円
勤務地
東京都(港区)
業務内容
本ポジションでは、プロジェクトおよび組織全体の「技術的な意思決定」と「標準化」を主導していただきます。 また詳細な実装や各種テスト等の実務については、メンバーや若手・ミドル層のエンジニアを主導しながら実施していただきます。 ●大規模・ミッションクリティカルなシステムの要件定義・設計 数千万人が利用する通信サービスや公共インフラの基幹NW、データセンターNWの最上流工程を担当。 最新のプロトコルや仮想化技術を駆使し、安定性と拡張性を両立した次世代アーキテクチャをデザインします。 ●アーキテクチャ設計および技術選定の最終意思決定 プロジェクト要件に応じたフレームワークやOSS、各種インフラ・ネットワーク機器の調査・評価を行い、最適な技術を選定・導入。 潜在的な技術的課題やリスクを基本・詳細設計の段階で特定し、プロジェクトマネージャーと連携して解決策を構築。 ●クオリティコントロール チーム全体のコードクオリティを担保するための設計レビュー・コードレビュー方針の策定。 テスト - 品質保証(開発クオリティの確認) ●実装 システムのパフォーマンス・堅牢性を左右するコアモジュール ●自社プロダクト創出への貢献(インキュベーション機能) 大手クライアントの最先端ネットワーク環境で得られた知見や共通の課題を抽出し、使い捨てにしない自社資産(新規プロダクトや機能)へと昇華させるための技術的なアプローチ・検討。 ●チーム全体の技術底上げ(メンター・リード) 若手~ミドル層エンジニア(別募集のジュニア~ミドルポジション等)への具体的な技術指導、技術的なベストプラクティスの共有によるチームの生産性向上。 ●開発環境 開発言語 Typescript / Python / Java フレームワーク React, Flask, FastAPI, SQLAlchemy, Spring プロジェクト管理, CI/CD Redmine, Jenkins 情報共有ツール Slack, Google Meet, Microsoft Teams OS Linux / Unix データベース PostgreSQL, mySQL, MariaDB, ElasticSearch 仮想化技術 OpenStack, Docker, Podman バージョン管理 Git クラウド AWS, Azure, GCP AI Claude Code, ChatGPT/Codex, Gemini その他 OSS 全般
View More
テックリード(Tech Lead)
想定年収
1,000~1,350万円
勤務地
東京都(港区)
業務内容
●このポジションについて GROWTH VERSEのテックリードは、自社プロダクトの課題に向き合い、的確なテクニカルロードマップを描き、それを遂行する役割です。 特定の言語や技術への習熟よりも、設計・アーキテクチャへの造詣の深さを大切にしています。 私たちが大切にしているのは、言われたものを作ることではありません。 顧客がプロダクトを使ったうえで、どのような状態にたどり着きたいのかを自分たちで考え抜き、その先にある感動(Wow)を体験として届けることです。 プロダクトは、顧客が実現したいビジネス活動の一部です。 その中で、私たちのプロダクトが欠かせない役割を担っている状態を、私たちが主導してつくりにいきます。 このポジションで担うこと プロダクトと、その利用者の業務を深く理解する プロダクトが使われる現場の業務に入り込み、業務の流れと課題の構造を理解する 業種が変わっても、相手よりも深く理解することを目指す プロダクトのテクニカルロードマップを描く 事業の目標から逆算して、プロダクトのテクニカルロードマップを描く 設計・アーキテクチャの観点から、何をどの順で進めるかを判断する ロードマップをチームで遂行する 描いたロードマップを、計画で終わらせずにチームを率いて遂行する 進めながら状況を見て、設計・アーキテクチャの判断を重ねる キャリアパス プロダクトのテックリードとして経験を積んだ先に、事業の現場へ入り込む2つの道があります。 M&A先の企業に入り込む道:グループに加わった企業のシステムと開発体制を統合し(PMI)、自社のAI Agentやプロダクトを組み込んで、事業の価値を引き上げる クライアントに入り込む道(FDE):クライアントの現場に入り込み、AI Agentを設計・実装して、業務の成果につなげる また、テックリードマネージャー(Tech Lead Manager)へと役割を広げ、その先にM&Aで加わった事業を担う事業部CTOという選択肢も検討できます。 いずれも決まったものではありません。 ご本人の志向を伺いながら、一緒に検討します。 技術スタック クラウド: AWSがメイン(ECS / Lambda / S3 / Terraform / GitHub Actions) データ基盤: Snowflake などのデータウェアハウス・分析基盤 AI/LLM: Python / LangChain / AI Agent開発フレームワーク 開発文化: IaC / SRE思想 / Agentic SRE / 生成AI活用 / 品質最優先 AI駆動開発: ハーネスエンジニアリングなど、最新のグッドプラクティスにも柔軟に取り組む 社内の開発運用そのものも、すでにAI Agentで回しています。 スプリントのチェックイン、放置されたPRのリマインド、クラウドコストの週次レポートなど、 誰かが手でやっていた定期業務をAgentに移してきました。 いまはそれを Agent Platform として作り直している最中です。 #### 成長環境:DAX Boost Lab 同じClaudeを使っていても、エンジニアのアウトプットには差が出ます。 社内でその差が起きたとき、それを「個人の才能」で片付けず、成長要素を分解して カリキュラム化しました。 教えているのは「ツールの使い方」ではありません。 重点は 事業数値を伸ばすためにAI Agentが最大のパフォーマンスを出せる環境をどう設計するか 教材は空想上のアプリではなく、実際の開発現場に近い課題を扱います 設計しているのは現役の技術責任者(VP of Technology)です 到達段階は3つのPhaseで整理しています。 Phase 1 プレイヤー:自分でAIを動かし、ほぼ最高速度に近い開発ができる状態 Phase 2 マネージャー:複数のAIと周囲のメンバーをマネジメントし、チームとして成果を出す状態 Phase 3 事業部CTO:AI Agentが開発・運用の一部を担う前提で、事業がより少人数で回る環境全体をアーキテクトする状態 学び合いと、アウトプットの文化 TGIF(月次) — Tech部全体で集まるLT会。 2026年7月に第1回を開催しました。 指名枠に加えて有志のLT枠があり、テーマは自由。 1人5分。 オンライン参加もできます 社内勉強会 — プロダクトをまたいだナレッジシェアの場をオンラインで開いています。 ここで話したことが、そのまま社外での登壇のネタになる導線があります 外部イベントへの登壇・共同運営 — 2026年8月には golang.tokyo #44 を共同運営し、 GROWTH VERSEのエンジニアが登壇しました 働き方(正直にお伝えします) 出社を基本としつつ、リモートワークも可能です(基本は出社推奨ですが絶対ではなく、 実際にフルリモートのメンバーもいます) 専門業務型裁量労働制(労働時間の制度であり、出社/リモートとは別の話です) 成果責任型の文化。 時間管理より成果で評価します 必須の対面イベントがあります 全社集会・懇親会(半期/四半期に1回) エンジニアTGIF等(月1回程度)
View More
テックリード(機械学習/ML)|ML技術方針・モデル開発・MLOpsをリード
想定年収
700~1,000万円
勤務地
東京都(千代田区平河町)
業務内容
機械学習領域の技術方針・技術判断 ・事業課題・プロダクト要件を踏まえた機械学習の活用方針の検討 ・機械学習を使用する/使用しない判断を含む技術的な実現方法の選定 ・モデル・アルゴリズム・特徴量等の選定と技術的な妥当性の検証 ・複数の機械学習テーマを見据えた技術方針・開発優先順位の検討 ・精度、開発工数、運用負荷、保守性、コストを考慮した技術的な意思決定 大規模LLMとの連携・活用に向けた技術設計・開発 ・業務要件やユースケースに応じた大規模MLMの選定・評価および技術的な活用方針の策定 ・大規模LLMとのAPI連携や既存システムへの組み込みを見据えたアーキテクチャの設計・実装 ・Pythonを用いたモデル連携機能の開発および推論処理・データ連携の最適化 ・出力精度・応答速度・コストなどの評価指標の設計および検証結果に基づく継続的な改善 ・大規模LLMのプロダクション環境への導入・運用における技術的課題の解決や難易度の高い開発テーマのリード システム設計・MLOpsの推進 ・機械学習モデルをプロダクトに組み込むためのAPI・バッチ処理・推論基盤の設計 ・データ処理・学習・推論パイプラインの設計・構築 ・モデルの本番環境への導入、監視、運用改善 ・精度低下やデータ変化を踏まえた再学習・改善プロセスの設計 ・再現性、可観測性、保守性、運用コストを考慮したMLシステムの改善 開発品質・技術基盤の整備 ・モデル・コード・実験結果・評価設計に関する技術レビュー ・モデルの評価方法や開発手順の標準化 ・技術的負債や運用課題の可視化、改善方針の策定 ・実験管理、CI/CD、モデル監視等を含む開発・運用環境の改善 ・機械学習領域における技術知見のドキュメント化・共有 関係部門との連携・技術支援 ・PdMや事業側と連携した課題整理、技術的な実現可能性の検討 ・アプリケーションエンジニア等との連携によるプロダクトへの機械学習機能の実装 ・AIデータ品質担当との連携による学習・評価データの品質向上 ・開発メンバーへの技術レビューや設計・実装面での支援 ・技術選定の理由、評価結果、リスク等の関係者への説明 ※人員管理や組織マネジメントはEM等と役割を分け、本ポジションでは機械学習領域の技術的な意思決定と開発・運用品質を中心に担っていただきます。 課題や事業上の優先順位はPdM等と連携し、AIデータ品質担当とはデータ品質に関する役割を分担します。
View More
プロジェクトマネジメント(進行管理・人員配置)
プロジェクトマネジメントは、開発をどの順番で、誰が進めるかを決める領域です。EMが担うのは、個別の案件のスケジュール管理よりも、チーム全体の人の配置や負荷の調整です。
-
案件の優先順位を事業側とすり合わせる
-
メンバーの担当と工数を調整し、負荷の偏りをなくす
-
スクラムなど、開発プロセスの改善を進める
スケジュールや納期の細かな管理は、プロジェクトマネージャーやスクラムマスターに任せる会社もあります。ただし、納期の圧力が強まったときに、メンバーが疲弊しないよう調整するのはEMの役目です。一人で両方を兼ねる場合は、納期とメンバーの持続性のどちらを優先するかで迷う場面が増えます。

プロジェクトマネージャー(PM)とは?年収・種類・キャリアアップ方法を徹底解説
プロジェクトマネージャー(PM)の求人情報
部長・グループ長
想定年収
800~1,400万円
勤務地
東京都(中央区日本橋馬喰町)
業務内容
●具体的な仕事内容 配属事業部の部長orグループ長として、エンジニアやPM、PLを束ね、開発プロジェクトまたは運用・インフラ領域の統括をお任せします。プロジェクトの成功とメンバー育成をリーディングいただきます。 <事業成長への貢献> 既存事業の運用改善・収益性向上、新規案件の創出・アップセル、採用・組織拡大への貢献 <プロジェクト管理> 進捗・品質・予算管理、および顧客との折衝(超上流工程から参画)、アップセル <技術選定・アーキテクチャ設計> 現場のテックリードと連携した最適なソリューションの提案 <組織マネジメント> メンバーの評価、1on1、キャリア開発支援 【配属想定】 事業部長と連携し、事業推進いただく部長orグループ長として、下記いずれかの部門への配属を想定しております。 ・フィナンシャルソリューション事業部 創業時からの金融開発や大規模開発 PJ が多数。Java による Web アプリケーション開発を得意とし、500 人月以上の大規模開発実績も遂行可能。銀行向け Web システム・営業店システムをフルスタックで担当する部、システムアーキテクチャを一から提案できる部、プライム案件で LLM を用いたシステム開発に取り組む部など、部ごとに特色があります。大型 PJ が多く、マネジメント経験を積める点も魅力です。 ・フューチャーリンク事業部 業界問わずコンシューマ向け案件が多く、PHP・TypeScript 等での Web アプリケーション開発を得意とします。1 名〜10 名程度まで大小さまざまな案件があり、大規模システムの構築やパブリッククラウドの活用を学べる部、業務アプリケーションを中心にミドルウェア設定・運用保守・移行まで幅広く経験できる部など、部ごとに強みが異なります。今後はスマホアプリ開発領域の拡大も予定しています。 ・アドバンストテクノロジー事業部 プライム案件を中心に、モダンなものからマイナーな技術まで幅広く対応。Web フロントエンド(React/Vue.js)、バックエンド(Go/Node.js/Python)、クラウド(AWS/GCP)を活用し、AI を活用した SDD(仕様駆動開発)など開発効率と品質を高める新しい手法を積極的に取り入れています。デイリーユーザー 100 万人超のモバイルアプリ開発など大企業の重要案件も複数担当し、勉強会もエンジニア主体で盛んに開催しています。 ・ビジネスプロセスアウトソーシング事業部 運用専門部隊として、障害対応をはじめ様々な IT 運用管理をアウトソーシング。開発から運用までトータルで提案できる組織を目指しています。AI の進化により運用保守費用は中長期的に低下していくと見据え、それだけに依存しない新たな収益の柱を自ら生み出すべく、AIOps プロダクト開発にも注力していく予定です。 ・RGA 事業部 AWS/GCP/Azure 等のパブリッククラウドに加え、オンプレミス・プライベートクラウド環境(2 拠点→1 拠点への移行等を含む)の設計・構築・運用も担当。SRE、CI/CD 構築・改善、監視の自動化まで、上流から下流までワンストップで経験でき、アプリケーション側の自動化アーキテクト業務を通じて DevOps 文化にも触れられます。エネルギー企業のサーバーレス基盤や社会インフラ企業の一般ユーザー向けサービス基盤など、様々な案件がございます。
View More
Senior Engineering Manager
想定年収
800~2,000万円
勤務地
東京都(港区)
業務内容
アグリゲーション事業・DS事業の開発チームを対象に、以下の業務を担当いただきます。 事業・チームの状況に応じて、優先度や比重は調整します。 ① 開発マネジメント・プロセス改善 • スクラムを中心とした開発プロセスの運営と改善(スプリント計画、見積もり、進捗・リスク管理) • 品質担保の仕組みづくり(設計レビュー・コードレビューの運用、テスト方針、リリースプロセス) • 開発生産性の可視化と改善(開発メトリクスの計測・分析) • 技術的負債の把握と、返済計画の立案・実行 • 障害・インシデント発生時の対応リードと、再発防止策の推進 ② 事業・プロダクトとの連携 • CTO・プロダクトマネージャー・事業部門と連携した、開発ロードマップの策定と優先順位付け • アグリゲーション事業・DS事業それぞれの要件を踏まえた、開発リソースの配分と調整 • 要件が固まりきらない状況での論点整理と、実現可能性・工数の見立て • DS事業における、複数顧客への展開を前提としたパッケージプロダクトの開発推進 • 両事業のチーム間の連携促進、ナレッジ・開発基盤の共有による重複の削減 ③ 技術・アーキテクチャへの関与 • CTO・テックリードと連携した、アーキテクチャ・技術選定への関与 • 技術標準・開発ルールの整備と浸透 • 必要に応じた設計レビュー・コードレビュー ④ピープルマネジメント・組織づくり • 組織拡大に向けた、チーム構成・役割分担の設計 • 将来のマネージャー候補・リードの育成 • メンバーの目標設定、1on1、評価、フィードバック • エンジニア採用への参画(採用要件の定義、面接、候補者へのアトラクト) • メンバーの育成とキャリア支援(技術面・行動面の両方) • チームの心理的安全性の醸成と、エンジニアリング文化の構築 • メンバーの稼働状況・負荷の把握と、適切なアサインメント ⑤AI活用の推進 • AIコーディングエージェント(Claude Code 等)を活用した開発スタイルの定着(全エンジニアにClaude Code Max(5x)を会社負担で支給) • AI導入による生産性メトリクスの計測・可視化と、改善の推進 <開発環境・技術スタック> バックエンド:C#/ASP.NET Core/Entity Framework Core/REST API フロントエンド:TypeScript/React インフラ:Microsoft Azure/Azure SQL Database 開発・運用:GitHub Enterprise/Azure DevOps(Azure Boards)/Microsoft Teams AI開発環境:Claude Code Max(5x)を全エンジニアに支給。 必要に応じてClaude Code Max(20x)やOpenAI Codex Proも会社負担で利用可能
View More
【VSL】業務系システム/案件推進・顧客調整(言語不問/開発・保守・運用経験者経験者)|金融業界|都内勤務
想定年収
450~600万円
勤務地
東京都(千代田区麹町)
業務内容
金融業界向け業務システムの構想・設計・運用支援を担当いただきます。プログラミングは行わず、業務整理や要件定義前の構想段階から関わるポジションです。お客様と直接コミュニケーションを取りながら、業務課題の解決に向けたシステム構築を支援します。(開発そのもの対応はございません) 【具体的な業務】 ・業務整理・構想段階からの参画 ・各システムの要件定義・調整 ・テスト・運用・保守対応 ・見積もり・予算取り支援 ・顧客(金融機関)との直接折衝 ・チームでの業務遂行(案件ごとに分担) 平均3人くらいのチームでお客様の課題に沿って様々なボリュームの案件を対応しています。 大型の物は1年などの年単位、小型のものはいくつか並行して解決するなど 常にご依頼が絶えない状況です。 これまでの業務システム経験を次の仕事でも活かしたい方に活躍いただけます。 これまで開発・保守の現場で積み重ねてきた知識をベースに、顧客との距離を縮め、案件推進やチーム運営まで仕事の範囲を広げていくキャリアです。 プロジェクト責任者や管理専任者としてではなく、現場実務を理解する立場で案件に入り、顧客・ベンダー・メンバーとともに業務を進めていただきます。 ●働く環境 ・所属 :業務ソリューション事業部 ・有給取得率高!100%の社員も。3連休なども柔軟に取得可能 ・残業少なめ(月平均10~20時間)で、ワークライフバランスが取りやすい ※21時以降の残業不可 ・勤務地:東京都23区内の客先(一人常駐はありません) ・使用PC:現場支給PC ※前もってリリース等による計画された夜間・早朝がまれ(年2~3回想定)に発生しますが、週40時間労働に近い状態に調整しています。
View More
【VSL】金融系システム/案件推進・顧客調整(言語不問/上流工程経験者)|プライム案件で顧客の案件推進|都内勤務
想定年収
450~600万円
勤務地
東京都(千代田区麹町)
業務内容
システム開発プロジェクトを円滑に進めるために、顧客・パートナー企業をつなぎながら案件を推進するポジションです。 設計や開発そのものではなく、スケジュール管理、進捗確認、テスト調整、リリース対応などを通じてプロジェクト全体を支えます。 金融業界向け業務システムの構想・設計・運用支援を担当いただきます。プログラミングは行わず(別担当にて実施)、業務整理や要件定義前の構想段階から関わるポジションです。お客様と直接コミュニケーションを取りながら、業務課題の解決に向けたシステム構築を支援します。 【具体的な業務】 ・業務整理・構想段階からの参画 ・各システムの要件定義・調整 ・テスト・運用・保守対応 ・見積もり・予算取り支援 ・顧客(金融機関)との直接折衝 ・チームでの業務遂行(案件ごとに分担) 平均3人くらいのチームでお客様の課題に沿って様々なボリュームの案件を対応しています。 大型の物は1年などの年単位、小型のものはいくつか並行して解決するなど 常にご依頼が絶えない状況です。 ●これまで培ってきた金融・システム開発の経験を活かし、仕事の範囲を広げたい方に適したポジションです。 「開発だけではなく、もう少し顧客に近いところで仕事をしたい」 「これまでの金融案件経験を活かしながら、案件全体を見る経験を積みたい」 「管理専任になるのではなく、現場経験を活かしながらチームや案件にも関わりたい」 など、これまでのご経験を一段階上げていきたい方に適しています。 ●活かせるご経験例 ・銀行・金融系システムの開発、保守、改修経験 ・COBOLからJavaへのマイグレーションなど、既存システムの更改・移行経験 ・Java、COBOL、SQL、Oracle、DB2等を使用した業務システム経験 ・帳票、バッチ、データ処理・連携等に関わった経験 ・要件定義、設計、開発、テスト等、複数工程への参画経験 ・SES・SIer等で顧客先プロジェクトに参画した経験 ・小規模なチームでのリーダー、サブリーダー、メンバーフォロー経験 ●働く環境 ・所属 :業務ソリューション事業部 ・有給取得率高!100%の社員も。3連休なども柔軟に取得可能 ・残業少なめ(月平均10~15時間)で、ワークライフバランスが取りやすい ※21時以降の残業不可 ・勤務地:東京都23区内の客先(一人常駐はありません) ・使用PC:現場支給PC ※前もってリリース等による計画された夜間・早朝がまれ(年2~3回想定)に発生しますが、週40時間労働に近い状態に調整しています。
View More
006-009SH_ソリューション開発エンジニア
想定年収
600~800万円
勤務地
神奈川県(横浜市)
業務内容
<業務概要> 今回の募集は、ソリューション開発(クラウド、Web)です。 <業務詳細> クラウドネイティブで開発するWebアプリを前提としたソリューション開発(管理)を担当いただきます。スクラムでの開発が多く、プロダクトオーナーやスクラムマスターなどの役割を担当できる方。 <開発PJの一例> 現場向け対話ソリューション「MelBridge」 https://www.mitsubishielectric.co.jp/communication-solution/ 【変更の範囲】会社の定める業務※ ※業務の都合によっては会社外の職務に従事させるため出向又は転任を命じることがある。
View More
プロダクトマネジメント(事業・他部門との橋渡し)
プロダクトマネジメントは、開発チームと事業をつなぐ領域です。何をつくるかを決めるのはプロダクトマネージャー(PdM)ですが、EMはその要望を技術的に実現できる形に落とし込みます。
-
PdMや営業の要望を、実現できる範囲と期間に置きかえる
-
技術的負債や人員不足を、経営層にわかる言葉で伝える
-
機能追加と品質のどちらを優先するかを関係者と決める
PdMがいない会社では、EMが要件の整理まで担うこともあります。担う範囲が広いほど難しさは増しますが、事業の判断に関わった経験は、VPoEやCTOを目指すときの強みになるでしょう。
Web・PdM・クリエイティブの求人情報
サービス開発リード(AI×情報システム)
想定年収
800~1,250万円
勤務地
東京都(品川区)
業務内容
担当するサービスについて、次の5つを担っていただきます。 出発点は「1. 捉える」で、経営の構想を売れるサービスに落とし込む「3. 形にする」も同じ比重です。サービスとして最も大切なのは「5. 型にする」です。 【1. 捉える ― 技術トレンドを誰よりも早くキャッチし、自社での実践につなげる】 ・AIエージェント・生成AI・データ基盤の新しい技術・サービス・トピックスを、国内外の情報源から誰よりも早くキャッチし、何が変わるのか、いまの仕組みを置き換えられるのか、判断の軸を整理します。 ・見極めた技術を、立ち上げリーダーとともに自社の情報システム部門・問い合わせ対応などの社内の環境で実践し、効果と課題を確かめます。 ・AIの中核は先端企業の進化に任せ、当社はその周辺のどこで価値を出すか。 その切り分けと、サービスのアーキテクチャを考えます。 【2. けん引する ― 立ち上げリーダーを、技術でリードする】 ・キャッチした情報と判断の軸、実践の結果をチームに広げ、メンバーそれぞれの情報収集を、チームの知見と技術の標準に変えます。 ・立ち上げリーダーの相談相手として、技術の選定・組み合わせ、セキュリティ・権限・運用のしやすさを含めた要となる判断をリードします。 ・相談相手として関わる範囲は、立ち上げリーダー層に絞ります。 メンバーのマネジメントは立ち上げリーダーが担い、顧客先に分かれて働く多数のエンジニアを直接管理することは求めません。 【3. 形にする ― 経営の構想と顧客の課題を、売れるサービスに設計する】 ・経営トップや顧客の構想・要望の意図をくみ取り、誰のどの課題を解くか、どの範囲で、どの順番で出すかを決め、優先順位をつけてエンジニアが動ける単位に落とし込みます。 ・経営トップの構想や新しい提案について、技術と市場の両面から実現性を確かめて優先順位をつけ、「いま何をやるか」を決めて、チームが迷わず進める状態をつくります。 ・価値(工数削減・期間短縮などの効果を数字で示す)、段階別のメニューと対象範囲、成果物、価格と契約の形、収支と体制を設計します。 ・段階ごとの計画と、進めるかどうかの判断の基準を決め、経営層とすり合わせながら進めます。 出発点は技術ではなく顧客の課題で、最新の技術はそれを解く手段として選びます。 【4. 出して磨く ― 自社・既存顧客で試行し、事業として育てる】 ・自社・既存顧客での試行で効果を測り、本格的な提供へ広げるかを経営と判断します。 ・入り口となる提案メニュー(診断・アセスメントなど)、提案書、導入事例、価格表を整え、営業担当と組んで顧客の前に立ち、技術を語れるプリセールスとして提案と最初の提供を担います。 ・提供を始めたあとも、粗利・受注件数・継続率などの指標を追い、顧客の声をサービスに組み込み、メニュー・提供方法・価格を見直し続けます。 【5. 型にする ― 誰が提供しても同じ品質で届けられる状態にする】 ・提供の手順、成果物のテンプレート、規模別の見積りの算定表、品質の基準、AIの仕組みの構築・運用手順を「型」として整え、立ち上げリーダーとともに現場に広げます。 ・案件ごとの学びを型に戻し、提供するたびにサービスが強くなる仕組みをつくります。 【入社後のロードマップ】 【入社〜3ヶ月】 進行中のサービス(AIの利用ルールの運用支援、AIヘルプデスクなど)と経営の構想をつかみ、使っている技術を棚卸しします。 技術の最新の動向を捉え、自社の環境での実践につなげながら、最初に出すサービスの対象・範囲・優先順位を経営層とすり合わせて決めます。 【3〜6ヶ月】 自社・既存顧客で試行し、効果を測ります。 価値・メニュー・価格・提案書を固め、営業担当とともに既存の顧客に提案します。 技術の判断の軸をチームに広げ、立ち上げリーダーの技術の標準をそろえます。 【6ヶ月〜1年】 社外の顧客への提供実績をつくります。 提供の手順・見積り・品質の型を整え、指標を追いながら、メニュー・価格を改善します。 【1年〜】 サービスの責任者(オファリングオーナー)として、サービスとチームを育てていただきます。 技術の先端を取り込み、AI導入の伴走など次のサービスの立ち上げもリードいただきます。 ※ 進む速さはご経験と成果によって変わります。 どこから担っていただくかは、ご経験をうかがったうえで一緒に決めます。 【あえてお伝えしたい「厳しいリアル」】 【最新の技術を追い続けることが、仕事そのものです】 AIエージェント・データ基盤の領域は、数か月で前提が変わります。 業務の中で情報を集め、見極め続けることが仕事の一部です。 それを楽しめる方には面白く、そうでない方には負担の大きい環境です。 【サービスの形は、これから一緒につくります】 どのサービスを、どの範囲で、どの順番で出すかは、経営と議論しながら具体化している段階です。 決まった計画をなぞる仕事ではなく、経営の構想と市場の動きを踏まえて、目的に立ち返りながら優先順位をつけ、前に進める力が求められます。 【チームのメンバーは、顧客の案件と兼務の人がほとんどです】 運用・ヘルプデスクのエンジニアの多くは、顧客の情報システム部門の現場で日々の業務を担っています。 サービスづくりに関わる時間は、事業の責任者と調整しながら確保します。 【営業を一人で背負う必要はありませんが、顧客の前には立っていただきます】 営業担当と組む体制で進めます。 一方で、試行の段階の提案と最初の提供では、ご自身が技術を語れる立場として顧客と直接向き合います。 【原則「出社」の環境です(リモートワーク不可)】 立ち上げの段階は、経営層・チームのエンジニアとの密なコミュニケーションと、速い意思決定が欠かせないと考えているためです。 【担当していただくサービス】 【サービスの方向性】 情報システム部門の業務を、生成AIを組み込んだ「型のある商品(オファリング)」として届ける(人月の支援からの転換) 【サービスの中身(例)】 ① AIの利用ルールの運用支援:当社のAI活用の知見をもとに、生成AIの利用規程の策定と運用を、実際に動く画面とあわせて提供(顧問・研修へも展開) ② AIヘルプデスク:社内の問い合わせ対応へのAIの組み込み。 対応記録の蓄積と分析、ナレッジ(RAG)・AIエージェントを使った回答の自動化 ③ 情報システム部門の運用の標準メニュー:既存の顧客の業務を棚卸しし、標準メニュー・運用手順・サービスレベル・価格にまとめる 【立ち上げの進め方】 課題の発見 → 対象と提供範囲の絞り込み → 事業計画(価値・価格・収支・体制)→ 型づくり(手順・テンプレート・ツール)→ 自社・既存顧客での試行と効果測定 → 販売開始と改善。 段階ごとに、経営と「進めるか、直すか」を判断しながら進めます。 【いまの進み方】 立ち上げリーダーが自ら手を動かして、サービスの形をつくっています。 自社の情報システム部門・人事の問い合わせ対応と、その記録の蓄積も進めています。 サービスの形は経営と議論しながら具体化している段階で、顧客に出してフィードバックを得るサイクルは、これからつくります。 【一緒に動くメンバー】 サービスの立ち上げリーダー、営業担当、経営層。 必要に応じて、顧客の情報システム部門で運用・ヘルプデスクを担う社内のエンジニア、システム開発のエンジニア ※ どのサービスから担っていただくかは、ご経験をうかがったうえで一緒に決めます。 将来は、AI導入の伴走など、次のサービスの立ち上げにも広げていきます。 【技術環境】 【生成AI】 Microsoft 365 Copilot、Copilot Studio、Azure OpenAI、Dify(LLM/RAG/AIエージェント) 【データ】 Databricks、問い合わせ対応の記録を蓄積・分析するデータ分析基盤 【Microsoft 365】 Microsoft 365、Entra ID、Intune、Exchange Online、SharePoint、Teams 【自動化】 Power Automate、Power Apps、PowerShell 【運用】 ITサービスマネジメント(ITSM)、AIOps 【AI開発ツール】 Cursor、Claude Code ※ 上記にとらわれず、新しい技術・サービスを試し、取り入れることを歓迎します。 従事すべき業務の変更の範囲 →会社の定める業務
View More
<プロダクトマネージャー>
想定年収
800~1,200万円
勤務地
東京都(豊島区)
業務内容
当ポジションのミッションは、GTNが展開する複数事業の課題やユーザー行動データをもとに、 「次に何を作るべきか」を定義し、プロダクトを通じて事業成長を実現することです。 GTNでは、外国人が日本で安心して暮らすための「信頼創造プラットフォーム」の構築を目指し、 住まい・金融・通信・生活支援など、外国人の暮らしに関わる複数領域でサービスを展開しています。 今後さらに事業を拡大していくためには、事業部から上がってくる要望をそのまま開発に渡すのではなく、 ユーザー価値、事業インパクト、開発コスト、緊急度を踏まえ、 何を優先して作るべきかを見極めるプロダクトマネジメント機能が重要になります。 本ポジションでは、経営層・事業責任者・開発チーム・デザイナーと連携しながら、 事業KPIやユーザー行動データを読み解き、プロダクトの方向性、 優先度、仕様、ロードマップを設計していただきます。 単なる要件整理や進行管理ではなく、「言われたものを作る」のではなく、 「事業成長とユーザー価値のために何を作るべきか」を意思決定するポジションです。 ●プロダクト戦略・ロードマップの設計 ・複数事業・複数チームから上がる課題や要望の整理 ・事業KPI、ユーザー行動データ、現場課題を踏まえたプロダクト課題の特定 ・事業インパクト、ユーザー価値、開発コスト、緊急度を踏まえた優先度設計 ・経営層・事業責任者・開発責任者との合意形成 ●仮説検証・データ分析・グロース企画 ・CVR、LTV、契約数、利用率などの事業KPIをもとにした課題分析 ・SQL、GA等を活用したデータ確認、分析 ・プロダクト主導での事業KPI改善に向けた施策立案 ●要件定義・仕様策定 ・抽象的な事業要望を、ユーザー価値とビジネスインパクトの両面から整理 ・実装すべき機能、対象ユーザー、提供価値、期待効果の定義 ・ワイヤーフレーム、プロトタイプ、機能要件の作成 ・リリース後の効果測定を見据えた要件設計 ●ステークホルダーとの合意形成 ・経営層、事業責任者、ビジネスサイドとの優先度調整 ・開発チーム、デザイナー、PjMとの連携 ・優先度のトレードオフ設計 ・プロダクト方針やロードマップに関する社内説明 ●プロダクト品質・UXへの関与 ・ユーザー体験を踏まえたプロダクト改善提案 ・リリース前の仕様確認、品質確認 ・サービス利用者・社内利用者双方にとって使いやすいプロダクト設計の推進 ※変更の範囲:当社で発生するすべての業務
View More
コミュニティエヴァンジェリスト<フルリモート可>EN0146
想定年収
700~900万円
勤務地
北海道
業務内容
社内外のコミュニティ活動を企画・推進し、当社セキュリティ活動の認知向上およびコミュニティエコシステムの形成を担っていただきます。 具体的には以下の業務を担当していただきます。 1:コミュニティ戦略の企画・推進 ・年間活動計画の策定 ・KPIの設計および効果測定 2:コミュニティイベントの企画・運営 ・勉強会、Meetup、カンファレンス等の企画・開催 ・登壇者や協賛企業との調整 3:エヴァンジェリズム活動 ・ブログ、SNS、動画等を活用した情報発信 ・セキュリティに関する啓発活動 4:社外コミュニティとの連携 ・業界団体や技術コミュニティとの関係構築 ・他社や有識者とのネットワーク形成 5:社内外の橋渡し ・コネクションを活かしたリードの創出 ・顧客やコミュニティからのフィードバック収集 ・社内のセキュリティ施策やサービス改善への提言
View More
【神奈川/WEB面接可】ソリューション開発エンジニア(ファシリティ分野)【横断事業推進プロジェクトグループ】
想定年収
800~1,200万円
勤務地
神奈川県(横浜市)
業務内容
データセンターを主とした事業領域をターゲットに、お客様との共創活動(PoC等)や当社グループ関連部門が保有する技術・情報を収集、連携体制を構築することで新規ソリューションの創出と事業化に向けたプロジェクトの推進を担当いただきます。 ●具体的な仕事内容 ・顧客訪問、コンサル活用による顧客課題のヒアリング、顧客価値となるソリューション案の具現化 ・ソリューション案の事業化を見据えたビジネス企画 ・顧客との共創によるソリューション案のPoC開発・実行 ・製品開発に向けた要件定義、設計、運用、販売、カスタマーサクセスまでの一連のプロセスのリーディング ・AIを活用した業務の生産性改善・新たな価値創出 【変更の範囲】 会社の定める業務(※) (※)業務の都合によって会社外の職務に従事するため出向または転属を命じることがあります。 ●使用言語、環境、ツール、資格等 ・使用言語:不問 ・環境:Windows、Web業務システム環境 等 ・ツール:Excel、PowerPoint、Teams、Confluence、Jira など ・資格等:海外ビジネス経験があれば望ましい。
View More
DX推進業務(データ分析/利活用)
想定年収
550~1,100万円
勤務地
東京都(千代田区)
業務内容
<「DX&VX推進部」欠員によるメンバーの募集/正社員> DXという新しい領域で活躍いただだける方を募集します! MIRARTHホールディングスならびにグループ各社(規模:約1,500名)へ向けた情報システム部としての一般的な業務およびDX戦略~推進をお任せ致します。 その中でも特にデータ活用/分析/業務改善周りの業務を主軸として、お願いしたいと考えております。 【具体的には】 ●DX/IT施策検証(企画立案〜計画実施・検証報告まで) ●DX/IT施策における部門間調整 ●DX/IT関連ソリューションの調査、選定 ●DXソリューションの導入、グループ会社への展開導入・定着化 ●・ITシステムの導入、運用業務(インフラ・ネットワーク・セキュリティ・開発等)・社内教育 ※適性や希望を考慮し、できる範囲からお任せしていきます。 【部署の特徴】 メンバー構成:男性6名、女性5名 年齢:20代半ば〜40代 落ち着いた性格の社員が多いです。 効率よく仕事を進めており、ワークライフバランスの改善も叶えられる環境です!
View More
EMと混同されやすい5つの職種との違い
EMは、テックリードやプロジェクトマネージャーなど、近い役割を持つ職種と混同されやすい役職です。会社によっては1人が複数の役割を兼ねるため、違いがわかりにくくなります。5つの職種との違いを整理すると、次の表のとおりです。
| 比較する職種 | その職種の主な責任 | EMとの分担 |
|---|---|---|
| テックリード(TL)との違い | 技術の方針と品質 | 技術はTL、人はEM |
| プロジェクトマネージャー(PjM)との違い | 納期・予算・進捗 | 案件はPjM、チームはEM |
| プロダクトマネージャー(PdM)との違い | 何を、なぜつくるか | 何をはPdM、どうはEM |
| VPoE・CTOとの違い | 開発組織と技術戦略 | EMの上位の役職 |
| スクラムマスターとの違い | スクラムの実践の支援 | 小さなチームで役割が近い |
見分けるポイントは、その職種が何に責任を持つかにあります。EMが責任を持つのは、人とチームです。以下、職種ごとに違いと分担の仕方を見ていきます。
テックリード(TL)との違い
テックリードは、チームの技術的な方針とコードの品質に責任を持つ役割です。アーキテクチャを決め、自分も実装の中心に立ちます。一方でEMが責任を持つのは、メンバーの評価や採用、育成といった人とチームの面です。テックリードを任命し、そのチームの成果に責任を持つのはEMだと分けて考える会社もあります。
テックリードからEMになると、自分の技術力で成果を出す立場から、メンバーを通じて成果を出す立場に変わります。小さなチームでは1人が両方を兼ねることもありますが、その場合も評価する側に立つかどうかで、仕事の中身は大きく変わるでしょう。
テックリードの仕事やキャリアについては、次の記事でも解説しています。ぜひ参考にしてください。

テックリードとは?仕事内容・必要なスキル・年収とキャリアパスを詳しく解説
プロジェクトマネージャー(PjM)との違い
プロジェクトマネージャー(PjM)は、個別のプロジェクトを計画どおりに完了させる責任者です。実行計画をつくり、予算や要員、進捗を管理して、納期までに成果物を届けます。
これに対してEMが責任を持つのは、プロジェクトをまたいで続くチームそのものです。プロジェクトは完了すれば終わりますが、チームとメンバーのキャリアはその先も続きます。PjMが納期と予算を守る立場なら、EMはメンバーが成長し、無理なく働き続けられるかを守る立場です。自社開発企業ではPjMを置かず、EMやPdMが進行管理を分け合うこともあります。
プロダクトマネージャー(PdM)との違い
プロダクトマネージャー(PdM)は、プロダクトで何をつくるか、なぜつくるかを決める役割です。ユーザーや市場を理解し、開発する機能の優先順位を決めます。それに対してEMが責任を持つのは、PdMが決めたものをどうつくるかです。
両者の考えがぶつかる場面もあります。PdMは新しい機能を早く出したい一方で、EMは技術的負債の返済やメンバーの負荷にも目を配らなければなりません。PdMとEMが対等に話し合える関係かどうかで、チームの働きやすさは大きく変わります。打診を受けた会社にPdMがいるかどうかで、EMが担う範囲も変わるでしょう。
VPoE・CTOとの違い
VPoEとCTOは、EMより上位にあたる役職です。CTO(最高技術責任者)は経営陣の一員として、技術の面から事業の方針を決めます。VPoE(Vice President of Engineering)は、エンジニア組織全体の採用や育成、組織づくりに責任を持つ役職です。
EMとの違いは、責任を持つ範囲の広さです。EMが受け持つのは1つ、または複数のチームで、VPoEはそれらをまとめた開発組織の全体を受け持ちます。会社によっては、複数のチームを束ねるシニアEMを経て、VPoEやCTOに就く流れもあります。EMとしてチームを育てた経験は、その先の役職でも求められる力になるでしょう。
スクラムマスターとの違い
スクラムマスターは、チームがスクラムをうまく実践できるように支える役割です。チームの障害を取り除いたり、スクラムの進め方を指導したりして、チームの成果を高めます。ただし、メンバーの人事評価や採用は、スクラムマスターの役割には含まれません。
一方でEMは、評価や採用を含めてメンバーの人事に責任を持つ点で、スクラムマスターと異なります。とはいえ、小さなチームのEMに求められる開発プロセスの改善や関係者との調整は、スクラムマスターの役割と近いものです。スクラムマスターの経験があるなら、EMの仕事の一部としてそのまま活かせます。
EMになるとコードは書かなくなるのか
EMを打診されて真っ先に浮かぶ不安が、コードを書けなくなるのではないかという点です。結論から言うと、EMになると実装に使える時間は減ります。ただし、どれだけ書くかはチームの状況で変わり、求められる技術力の中身も変わっていきます。この問いへの答えは、次の3つです。
-
実装の時間は減るが、ゼロになるとは限らない
-
書く量はチームの規模とEMのタイプで変わる
-
求められる技術力は「書く力」から「判断できる理解」に変わる
実装の時間は減るが、ゼロになるとは限らない
EMになると、1on1や採用面接、他部署との調整に時間を使うため、まとまった時間をとって実装に集中することは難しくなります。エンジニアは割り込みを減らすほど成果を出せる一方で、マネージャーはメンバーからの相談にいつでも応じられることが求められるためです。
とはいえ、コードにまったく触れなくなるわけではありません。EMになってからも続けやすいのは、次のような関わり方です。
-
コードレビューに参加する
-
小さな不具合の修正を引き受ける
-
新しい技術を試作して検証する
リリースの期限を左右する重要なタスクを、EM自身が抱え込まないように意識しましょう。EMの手が止まったときに、チーム全体の開発まで止まってしまうためです。
書く量はチームの規模とEMのタイプで変わる
どれだけコードを書くかは、EM本人の希望よりも、チームの規模と会社がEMに期待するタイプで決まります。目安は次の表のとおりです。
| チームの状況 | コードを書く量の目安 |
|---|---|
| 小さなチームで、EMも開発に入る | 多い |
| テックリードが別にいるチーム | 少ない |
| 複数のチームを受け持つ | ほぼ書かない |
また、メンバーにシニアエンジニアが多いチームでは、EMが自分で書く必要はさらに小さくなります。その場合のEMの仕事は、メンバーが開発に集中できる環境を整えることに移ります。コードを書き続けたいなら、自分も開発に入るプレイングマネージャー型のEMを求めている会社かどうかを見ておきましょう。

伊東 光雄
Ito Mitsuo
EMの求人票に「ハンズオン」や「プレイングマネージャー」とあれば、実装の比率が高いポジションです。面談では、1週間のうち開発に使う時間の目安を聞いておくと、入社後のずれを避けられます。
求められる技術力は「書く力」から「判断できる理解」に変わる
EMに求められる技術力は、自分で速く正確に書く力から、チームの技術的な判断の良し悪しを見極める理解へと変わります。具体的には、次のような場面で技術の理解が必要です。
-
メンバーが提案する設計の良し悪しを判断する
-
開発の見積もりが妥当かを見極める
-
技術的負債のリスクを事業側に説明する
自分ですべてを書ける必要はありませんが、メンバーと技術の話ができる程度の理解は保っておきましょう。そのため、メンバーが扱う技術の知識は、深くなくてもよいので更新し続けることが大切です。書ける状態から、わかる状態へと形を変えながら技術に触れ続けることが、技術から離れすぎないEMの働き方です。
元エンジニアのアドバイザーが対応
EMに必要な4つのスキル
EMに求められるスキルは、テックリードとして求められてきたものとは重心が異なります。主に必要なのは次の4つです。
| スキル | 主に活きる場面 |
|---|---|
| 傾聴・コーチングのスキル | 1on1、評価面談 |
| チームの技術領域を理解する力 | 設計や見積もりの判断 |
| 判断の理由を言語化する力 | 経営層や他部署との調整 |
| プロダクトと事業を理解する視点 | 開発の優先順位づけ |
ただし、4つすべてを最初から高いレベルで備えている人はまれです。自分が詳しくない領域は、メンバーや周囲の力を借りて補えばよいと割り切れる人ほど、EMとして長く働きやすいでしょう。
傾聴・コーチングのスキル
傾聴とコーチングは、1on1でメンバーの悩みやキャリアの希望を引き出すためのスキルです。答えを教えるのではなく、質問を重ねてメンバー自身に考えを整理してもらう点が、テックリードとしての技術指導とは異なります。
このスキルが欠かせないのは、EMが自分より詳しい分野のメンバーも受け持つためです。たとえば、バックエンド出身のEMがモバイルアプリのエンジニアを担当すると、細かな技術的な助言は難しくなります。それでも、相手の話を聞いて考えを整理する手助けができれば、成長は支えられます。メンバーの成長を自分の成果として喜べる人は、このスキルを伸ばしやすいでしょう。
チームの技術領域を理解する力
EMは、自分の専門とは違う領域のメンバーも受け持ちます。そのため、1つの技術を深く極めるのではなく、チームが扱う各領域の基本を広く押さえておく力が求められます。
-
メンバーの専門領域の基本を押さえる
-
その知識を定期的に更新する
-
詳しくない判断は専門のメンバーに意見を求める
とくに3つ目が大切です。自分が専門家ではないと自覚し、わからないことを素直に聞けるEMのもとでは、メンバーも困りごとを言い出しやすくなります。マネジメントに移っても技術への興味を失わず、学び続けられる人が、この力を保ち続けられます。
判断の理由を言語化する力
EMの判断は、メンバーだけでなく、経営層やPdM、営業など多くの人に影響します。そのため、何を決めたかだけでなく、なぜそう決めたかを相手に伝わる言葉で説明する力が必要です。
たとえば、新機能の開発を一部遅らせて、技術的負債の返済に時間を使う場面を考えてみましょう。経営層には「コードが古いから」ではなく、障害が起きる確率や今後の開発スピードへの影響といった事業の言葉で説明すると、納得を得やすくなります。
メンバーへの評価のフィードバックでも同じです。評価の理由を具体的な行動と結びつけて伝えられるかどうかで、メンバーの納得感は大きく変わります。
プロダクトと事業を理解する視点
EMは、開発チームの判断を事業の成果につなげる役割も担います。そのため、自社のプロダクトがどう稼ぎ、ユーザーに何を求められているのかを理解する視点が必要です。
-
プロダクトの売上や利用状況の数字を把握する
-
開発にかかるコストと得られる効果を比べる
-
短期の機能追加と長期の品質のバランスを決める
技術的に正しい判断が、事業にとっても正しい判断とは限りません。完璧な設計にこだわって機能の提供が遅れれば、事業の機会を逃すこともあります。いま返すべき技術的負債と、あえて受け入れる技術的負債を区別して判断できる人は、事業側からも信頼されるEMになれるでしょう。
エンジニアリングマネージャーの年収相場
EMは、エンジニア職の中でも年収の水準が高い役職です。ただし、同じEMでも、企業のタイプや受け持つ範囲によって年収には大きな幅があります。ここでは、求人で提示されている年収の相場と、年収の水準を左右する要因を解説します。
求人ベースの相場は700万〜1,500万円が中心となる
事業会社が公開しているEMの求人票を見ると、提示される年収は700万〜1,500万円の範囲に収まるものが中心です。とくに多いのは800万〜1,200万円の帯で、EM未経験者を対象にした候補枠では、下限が600万円前後まで下がります。
公的な統計を見ても、マネジメント職の年収は高い水準にあります。ITプロジェクトマネージャなどが属する職業分類の平均年収は889万円で、年齢別に見ると次のとおりです。
| 年齢 | 平均年収 |
|---|---|
| 30〜34歳 | 866万円 |
| 35〜39歳 | 968万円 |
| 40〜44歳 | 1,189万円 |
これはEMだけを集計した数字ではありませんが、30代でEMを打診されたエンジニアなら、900万円前後がひとつの目安になるでしょう。求人の相場と照らし合わせて、提示された条件が妥当かを判断する材料にしましょう。
参考:厚生労働省 職業情報提供サイト(job tag)「プロジェクトマネージャ(IT)」
マネジメント職で年収1,000万円を目指す方法については、次の記事でも解説しています。ぜひ参考にしてください。

エンジニアで年収1000万を目指すには?割合・企業・職種と到達ルートを解説
企業のタイプと管掌範囲で年収水準が変わる
同じEMでも、年収の水準を左右する要因は主に2つです。1つは企業のタイプで、外資系企業やメガベンチャーは高く、日系の大手企業は等級制度に沿って緩やかに上がる傾向があります。もう1つは管掌範囲で、1チームを受け持つEMより、複数のチームや開発組織の立ち上げを任されるEMのほうが、提示される年収は高い傾向です。
公的な統計でも、スキルの水準による年収の差が見られます。ITSSは情報処理推進機構が定めるITスキルの指標で、レベルが上がるほど高度な人材を示します。このレベル別にプロジェクトマネージャの年収を見ると、次のとおりです。
| スキルの水準 | 年収の中央の範囲 |
|---|---|
| ITSSレベル3 | 600万〜925万円 |
| ITSSレベル4 | 675万〜950万円 |
| ITSSレベル5以上 | 700万〜1,100万円 |
表の金額は、年収の低いほうから25〜75%にあたる範囲です。なお、テックリード時代の年収が残業代込みだった場合は、EMの提示額と単純に比べないように気をつけましょう。管理監督者として採用されると残業代がつかないため、基本給と賞与だけで今の年収を上回るかどうかを確かめておくことが大切です。

伊東 光雄
Ito Mitsuo
EMの提示年収は、残業代の扱いや賞与の比率によって、同じ金額でも実際に受け取る総額が変わります。テックゴーでは年収交渉をアドバイザーが代行しているので、条件の読み解きや交渉に不安があれば任せてしまいましょう。
参考:厚生労働省 職業情報提供サイト(job tag)「プロジェクトマネージャ(IT)」
平均年収アップ金額144万円
エンジニアリングマネージャーになるための2つのルート
EMの求人では、5年前後の開発経験に加えて、チームリーダーや採用・育成に関わった経験を応募条件に挙げる例が目立ちます。そのうえで、EMになるルートは、社内でテックリードからEMに昇格する道と、EM候補ポジションに転職する道の2つです。
打診を受けている場合は、すでに1つ目のルートの入り口に立っています。社内で求められるEM像が自分に合わないと感じたときは、2つ目のルートも選べます。
社内でテックリードからEMに昇格する
社内での昇格は、すでに知っているメンバーと技術のもとでEMを始められるルートです。チームからの信頼がある状態で始められる点が、転職との大きな違いになります。昇格までは、次の段階を踏むとスムーズです。
-
テックリードとして、1on1や新人のメンターを引き受ける
-
採用面接や目標設定の支援など、マネジメントの一部を担う
-
テックリードとEMを兼ねながら、評価に関わる
-
専任のEMとしてチームを受け持つ
一方で、昨日まで同僚だったメンバーを評価する立場になるため、関係の切り替えに戸惑う人もいます。打診を受けた段階で、評価や採用の権限をどこまで任されるのかを上長とすり合わせておくと、昇格後のずれを避けられます。
EM候補ポジションに転職する
社内でEMのポストが空いていない場合や、社内で求められるEM像が自分に合わない場合は、EM候補として転職する道があります。EM候補とは、入社後しばらくはエンジニアとして開発に加わり、組織になじんでからEMに就くことを前提にしたポジションです。
選考では、マネジメントの肩書きがなくても、次のような経験が評価の材料になります。
- 1on1やメンターとして後輩を支えた
- 採用面接に面接官として加わった
- チームの開発プロセスを改善した
ただし、入社後にEMへ移る時期や条件は、会社ごとに違います。いつ、何を満たせばEMになれるのかを、選考の段階で確かめておきましょう。

伊東 光雄
Ito Mitsuo
マネジメントの肩書きがない経験を、EM候補としてどう伝えるかは悩みやすい部分です。テックゴーには元エンジニアやITコンサル出身のアドバイザーが多く、これまでの経験からEMにつながるものを一緒に棚卸しできます。
EM候補として評価される経験の書き方については、次の記事でも解説しています。ぜひ参考にしてください。

ITエンジニアの職務経歴書の書き方完全ガイド|評価される構成と実例を徹底解説
エンジニア特化の転職エージェント
EMを引き受ける前に確認したい5つのこと
同じEMという肩書きでも、チームの中で一緒に開発するプレイングマネージャー型なのか、チームの外から組織を整えるピープルマネージャー型なのかで、毎日の仕事は大きく変わります。打診を受けたら、返事をする前に、会社が期待しているEM像を上長に確かめておきましょう。確認したいのは、次の5つです。
| 確認すること | 上長への聞き方の例 |
|---|---|
| 管掌するメンバーの人数と構成 | 何人を、どんな構成で受け持つか |
| コードを書く時間がどれくらい残るか | 開発にどこまで関わってほしいか |
| 評価・採用の権限をどこまで持つか | 評価と採用で何を決められるか |
| テックリードやPdMが別にいるか | 技術と仕様は誰が決めるか |
| EMとしての成果を何で評価されるか | 何ができたら成功と言えるか |
以下、それぞれを確かめておきたい理由を解説します。
管掌するメンバーの人数と構成
受け持つメンバーの人数は、EMが1日の時間をどう使うかに大きく影響します。人数が増えるほど1on1や評価に使う時間が増え、自分が開発に入る余地は小さくなるためです。
あわせて、メンバーの構成も確かめておきましょう。構成によって、EMの仕事で比重が大きくなるものは次のように変わります。
| チームの構成 | EMの仕事で比重が大きくなるもの |
|---|---|
| 若手が多い | 育成と立ち上がりの支援 |
| シニアが多い | 開発に集中できる環境づくり |
| 職種が多様 | 各領域の理解と評価のすり合わせ |
人数と構成がわかれば、EMとして何に時間を使うことになるのかが、おおよそ見えてきます。
コードを書く時間がどれくらい残るか
EMの業務は増えるのに、開発の担当はそのまま残るという状態は、打診を受けた直後に起きやすいずれです。上長が「これまでどおり実装も続けてほしい」と考えていれば、1on1や採用と開発が重なり、どちらも中途半端になりかねません。
確認するときは、次の3点を具体的に聞きましょう。
-
1週間のうち、開発に使ってよい時間の目安を聞く
-
担当するのが実装か、レビューや設計の確認かを聞く
-
手放す開発の仕事を、誰に引き継ぐかを聞く
とくに3つ目が曖昧なままだと、EMの仕事と開発の仕事を両方とも抱えることになります。
評価・採用の権限をどこまで持つか
EMは評価や採用に責任を持つ役職ですが、会社によっては、責任だけが渡されて決める権限がないこともあります。引き受ける前に、次の点を確かめておきましょう。
-
評価の最終決定を誰がするかを聞く
-
採用の合否にどこまで関われるかを確かめる
-
昇給や等級の変更に意見を出せるかを確かめる
また、EMは労働基準法上の管理監督者として扱われ、残業代がつかなくなる場合があります。管理監督者にあたるかどうかは肩書きではなく、権限や待遇の実態で判断されるため、権限が小さいのに残業代だけがなくなる状態になっていないかも見ておきましょう。
テックリードやPdMが別にいるか
テックリードやプロダクトマネージャー(PdM)がチームにいるかどうかで、EMが担う範囲は大きく変わります。体制ごとの目安は、次の表のとおりです。
| チームの体制 | EMが主に担う範囲 |
|---|---|
| テックリードとPdMがいる | 人とチーム |
| テックリードだけがいる | 人とチーム、事業との調整 |
| PdMだけがいる | 人とチーム、技術の判断 |
| どちらもいない | 人、技術、進行、事業のすべて |
どちらもいない体制では、EMがすべての領域を1人で抱えることになります。負荷が大きい体制ほど、誰に何を任せられるかを先に決めておくと、引き受けたあとに行き詰まりにくくなります。
EMとしての成果を何で評価されるか
EMになると、評価の基準も、個人の開発の成果からチームの成果へと変わります。EMの成果は、自分の仕事に加えて、自分が影響を与えたチームの成果で決まるためです。それにもかかわらず、評価の基準がテックリード時代のままだと、EMの仕事に力を注ぐほど評価されにくくなります。
確かめておきたいのは、たとえば次のような指標です。
-
チームの開発スピードや品質が上がったか
-
メンバーが成長し、定着しているか
-
必要な人数を採用できたか
EMに何を期待しているのかを、会社がはっきり言葉にしていないこともあります。その場合は、半年後にチームがどんな状態になっていれば成功なのかを、上長と一緒に決めておきましょう。
EMポジションへのキャリア相談ならテックゴー
EMの打診を受けるかどうかを考える中で、社内で求められるEM像が自分の希望と合わないと感じることもあるでしょう。その場合は、自分が描くEM像に近いポジションを社外で探すのもひとつの方法です。テックゴーは、エンジニアに特化した転職エージェントとして、テックリードやシニアエンジニアとしての経験がEMとしてどう活かせるのかを一緒に整理します。
-
元エンジニアのアドバイザーに、EM候補としての評価を相談できる
-
平均年収アップ金額は144万円で、年収を上げる転職の実績がある
-
年収交渉はアドバイザーが代行し、条件面の話し合いを任せられる
-
面接対策は回数無制限で、マネジメント経験の伝え方を練習できる
EMとして次の一歩を考えているなら、まずは今の経験が社外でどう評価されるのかを確かめるところから始めてみましょう。
元エンジニアのアドバイザーが対応
まとめ
この記事では、エンジニアリングマネージャー(EM)の役割と、テックリードやPdMとの違い、コードを書く時間の変化、年収の相場までを解説しました。EMはエンジニアチームの成果に責任を持つ管理職で、ピープル、テクノロジー、プロジェクト、プロダクトの4つの領域のうち、どこに比重を置くかは会社によって変わります。コードを書く時間は減りますが、求められる技術力が書く力から判断できる理解へと変わるだけで、技術から離れるわけではありません。
打診を受けたら、返事をする前に、受け持つメンバーの構成や権限の範囲、成果の評価のされ方を上長に確かめましょう。会社が期待するEM像と、自分が伸ばしたい方向が重なるかどうかが、引き受けるかを決めるいちばんの判断材料です。
社内のEM像が自分の希望と合わない場合は、社外でEMを目指す道もあります。テックゴーでは、元エンジニアやITコンサル出身のアドバイザーが、これまでの開発経験やリーダー経験がEMとしてどう評価されるのかを一緒に整理しています。
面接対策は回数無制限
よくある質問
コードを書くことが好きな人はEMに向いていませんか?
コードを書くことが好きだというだけで、EMに向いていないとは言えません。技術への関心は、メンバーの技術的な判断を見極めるうえで強みになります。
ただし、次のような傾向が強い場合は、EMの仕事を負担に感じやすいでしょう。
・自分の手でつくることが一番のやりがいになっている ・評価や人の感情に向き合うことが強いストレスになる ・成果が見えるまでの時間差に耐えにくい
こうした傾向がある場合は、テックリードやスペシャリストとして技術を深める道も、EMと同じくらい価値のあるキャリアです。
EMになった後、エンジニアに戻ることはできますか?
EMを経験したあとに、エンジニアに戻ることはできます。マネージャーとエンジニアを行き来するキャリアは、海外のテック企業を中心に珍しいものではありません。
EMを経験したあとの主な選択肢は、次のとおりです。
・テックリードやスペシャリストとして現場に戻る ・VPoEやCTOとして、より広い組織を受け持つ ・ITアーキテクトとして設計の専門性を深める
現場に戻る道を残しておくなら、EMの間もコードレビューや技術検証を続け、技術の感覚を保っておきましょう。チームを育てた経験は、エンジニアに戻ったあとも、周囲を巻き込んで開発を進める場面で活かせます。
EMの打診を断るとキャリアに不利になりますか?
打診を断ったからといって、キャリアが不利になるとは限りません。ソフトウェア開発の現場では、技術力の高い個人に向けた評価制度を用意し、マネージャーと同じかそれ以上の給与で処遇する会社もあります。
判断する前に、次の点を確かめておきましょう。
・スペシャリストとして昇格できる等級があるか ・断った場合に任される役割は何か ・時期をずらして再び打診を受けられるか
断る場合は、技術の面でチームにどう貢献したいのかをあわせて伝えると、上長との認識のずれを避けられます。一方で、EMはあとからエンジニアに戻ることもできる経験なので、迷っているなら期間を区切って引き受けてみるのもひとつの方法です。
エンジニアリングマネージャーについて学べる本はありますか?
EMの仕事を体系的に学べる本としては、次のようなものがあります。
・オライリー・ジャパン『エンジニアリングマネージャーのしごと』 ・翔泳社『エンジニアリングマネージャーお悩み相談室』 ・オライリー・ジャパン『エンジニアのためのマネジメントキャリアパス』
打診を受けた段階なら、EMの仕事の全体像をつかめる『エンジニアリングマネージャーのしごと』から読むと、引き受けたあとの働き方をイメージしやすいでしょう。EMになってから日々の悩みにぶつかったときは、具体的な課題ごとに助言をまとめた『エンジニアリングマネージャーお悩み相談室』が役立ちます。
テックリードからCTOまで、マネジメントの段階ごとの役割を知りたい場合は、『エンジニアのためのマネジメントキャリアパス』も参考になります。
