コトラ（広報チーム） 
エンジニアリングマネージャーの基本
エンジニアリングマネージャーの定義
エンジニアリングマネージャーとは、エンジニアが継続的に成果を出せるよう、チームと組織を整える役割です。一般にEMと略されることもあります。
自ら実装する場面がある一方で、主な責任は個人の開発成果ではありません。メンバーの成長支援、目標設定、採用、評価、業務の進め方の改善、他部署との調整などを通じて、チーム全体の成果を高めることが求められます。
役割の範囲は会社や組織の規模によって異なります。小規模な組織では、開発やプロジェクトの進行管理を兼務する場合があります。組織が大きくなるほど、人と組織に関する役割を中心に担うケースが増えます。
求められる背景と組織における位置づけ
ソフトウェア開発では、事業の変化、顧客からの要望、技術の更新などに対応しながら、継続して価値を届ける必要があります。開発する人数が増えるほど、個人の努力だけで成果を維持することは難しくなります。
たとえば、担当範囲が曖昧で仕事が重複する、経験のあるメンバーに業務が集中する、育成の時間が取れないといった問題が起こりやすくなります。こうした状態を改善し、チームとして安定して開発できる環境をつくるために、エンジニアリングマネージャーが置かれます。
組織においては、現場のエンジニアと経営・事業部門の間に立つ存在です。現場の課題を事業側に伝えるだけでなく、事業上の目標を開発チームが実行できる形に整理する役割も担います。
技術と組織をつなぐ役割
エンジニアリングマネージャーには、技術を理解しながら、組織運営にも目を向ける姿勢が必要です。すべての技術課題を自分で解決する必要はありませんが、開発上の難しさや影響範囲を理解し、適切な判断や支援につなげることが重要です。
たとえば、新機能の追加を急ぐ場面では、品質の確保、既存システムへの影響、運用負荷、担当者の稼働状況を踏まえる必要があります。技術的な事情を知らずに納期だけを優先すると、障害や手戻り、メンバーの負担増加につながるおそれがあります。
一方で、技術的な理想だけを追い求めても、事業の優先順位や利用者の要望とずれることがあります。技術と事業の両面を見ながら、現実的な着地点をつくることがエンジニアリングマネージャーの重要な仕事です。
管理職との違い
エンジニアリングマネージャーは管理職として扱われることがありますが、両者は必ずしも同じ意味ではありません。管理職は人事評価や予算管理、組織運営などを担う職位を指すことが多く、エンジニアリングマネージャーは開発組織の成果を高めるための役割を指します。
そのため、エンジニアリングマネージャーが評価権限を持つ組織もあれば、別の管理職と協力して評価を行う組織もあります。また、肩書きが管理職ではなくても、開発チームの育成や採用、改善を主導している場合は、実質的にエンジニアリングマネージャーに近い働きをしているといえます。
重要なのは肩書きではなく、チームが継続して成果を出すために、人・技術・仕事の進め方を整える責任を持つことです。
エンジニアリングマネージャーの主な役割
開発チームの目標設定と進行管理
エンジニアリングマネージャーは、事業の目標を踏まえ、開発チームとして達成すべき目標を明確にします。目標は単に機能を完成させることだけではありません。品質の改善、開発の速度向上、障害の減少、運用の安定化、技術的な課題の解消なども対象になります。
目標を設定した後は、進捗やリスクを確認し、計画どおりに進まない場合に対応します。遅れが起きたときは、担当者を責めるのではなく、見積もりの前提、業務量、依存関係、仕様変更などの原因を整理することが大切です。
必要に応じて、優先順位の見直しや作業の分担変更、関係者との調整を行います。チームが無理な計画を抱え続けないようにすることも、進行管理の一部です。
メンバーの育成と評価
メンバーの成長を支援することは、エンジニアリングマネージャーの中心的な役割です。担当業務の割り振りだけでなく、本人がどのような力を伸ばしたいのか、今後どのような仕事に挑戦したいのかを把握します。
育成では、難易度が高すぎる仕事を一方的に任せるのではなく、本人の経験や状況に応じて支援の量を調整します。必要に応じて、相談相手をつける、目標を小さく分ける、振り返りの機会を設けるといった工夫をします。
評価を行う場合は、成果だけで判断しないことが重要です。担当した役割、課題の難しさ、周囲への働きかけ、成長の過程なども踏まえ、納得感のある説明を行います。評価基準を日頃から共有し、期待される行動を明確にしておく必要があります。
採用とチームづくり
採用は人数を増やすためだけの活動ではありません。現在のチームに不足している力を把握し、事業や組織の将来に必要な人材を考えることが重要です。
エンジニアリングマネージャーは、募集する役割の整理、選考基準の設計、面談や面接への参加、候補者への情報提供などに関わることがあります。採用時には、技術的な経験だけでなく、チームの働き方や求める役割との相性も確認します。
入社後に力を発揮できる環境をつくることもチームづくりの一部です。新しく入ったメンバーが、誰に相談すればよいか、どのように開発を進めるか、何を期待されているかを理解できるように支援します。
開発の進め方と働く環境の改善
開発チームが抱える問題には、個人の努力では解決しにくいものがあります。たとえば、確認作業が多すぎる、情報が特定の人に集中している、手作業が多く負担になっている、会議が多く開発時間を確保できないといった問題です。
エンジニアリングマネージャーは、こうした課題を見つけ、仕組みとして改善します。作業の流れを整理する、情報共有の場を設ける、手順を文書化する、会議の目的を見直すなど、継続できる方法を選ぶことが重要です。
働く環境の改善には、心理的に相談しやすい雰囲気づくりも含まれます。問題や不安を早めに共有できるチームは、大きな手戻りや離職のリスクを抑えやすくなります。
事業部門や他チームとの連携
開発チームだけで、顧客に価値を届けることはできません。企画、営業、顧客対応、デザイン、運用など、さまざまな部門やチームとの連携が必要です。
エンジニアリングマネージャーは、開発側の制約やリスクを伝えるとともに、他部門の目的や優先順位を理解します。双方の認識にずれがある場合は、何を優先するのか、どこまでを今回の範囲とするのかを整理します。
部門間の対立を避けるだけでなく、共通の目標に向けて協力できる状態をつくることが求められます。
エンジニアリングマネージャーの仕事内容
定例会議と情報共有
日常業務では、チーム内外での情報共有に多くの時間を使います。定例会議では、進捗、課題、優先順位の変更、他チームとの連携事項などを確認します。
ただし、会議を増やすこと自体が目的ではありません。参加者が何を決めるのか、どの情報を持ち帰るのかを明確にし、必要な会議だけを設計することが大切です。共有だけで済む内容は、文書やチャットなどを活用する方法もあります。
また、重要な決定事項や背景を記録しておくことで、参加できなかったメンバーも状況を把握しやすくなります。
メンバーとの面談と日常的な支援
定期的な面談では、業務の進み具合だけでなく、困っていること、チームとの関係、成長したい方向などを確認します。エンジニアリングマネージャーにとって面談は、評価のためだけの場ではなく、メンバーが力を発揮できる状態をつくるための場です。
日常的には、相談への対応、仕事の優先順位の調整、他メンバーとの橋渡しなどを行います。相談を受けた際は、すぐに答えを出すだけでなく、本人が考えられるように問いかけることも有効です。
一方で、業務量が過大であったり、人間関係の問題が起きたりしている場合は、早めに具体的な対応を取る必要があります。
開発計画の調整と優先順位づけ
開発計画は、一度決めたら終わりではありません。市場や顧客の状況、障害の発生、仕様変更、メンバーの稼働状況などにより、見直しが必要になります。
エンジニアリングマネージャーは、どの仕事を先に進めるべきかを関係者と確認し、チームが取り組む順番を整えます。その際は、売上や顧客への影響だけでなく、品質、保守のしやすさ、将来の開発への影響も考慮します。
すべての要望に同時に応えることはできません。対応しないことや後回しにすることを明確にし、その理由を関係者に説明することも重要です。
課題の把握と解決の推進
チーム内の課題は、遅延や障害のように明確な形で現れるとは限りません。発言が減る、同じ質問が繰り返される、一部の人に依頼が集中するなど、小さな兆候として現れることもあります。
エンジニアリングマネージャーは、会議、面談、日常のやり取り、開発の状況から課題を把握します。その上で、原因を個人の能力だけに求めず、役割分担、情報の流れ、意思決定の方法、業務量などを確認します。
解決策を実行した後は、改善したかどうかを振り返ります。一度の対応で終わらせず、チームの運営方法として定着させることが必要です。
採用活動と入社後の受け入れ
採用活動では、候補者との面談や面接に加え、選考基準のすり合わせ、現場の魅力や課題の説明、入社後の役割設計などを行います。採用を急ぐあまり、必要な役割が曖昧なまま選考を進めると、入社後のミスマッチにつながります。
入社後は、開発環境の準備、チームの紹介、担当業務の説明、相談先の設定などを進めます。最初から大きな成果を求めるのではなく、組織や製品、開発の流れを理解できる段階を設けることが重要です。
受け入れの手順を整備しておくと、新しいメンバーだけでなく、支援する既存メンバーの負担も抑えられます。
プロジェクトマネージャーとテックリードとの違い
エンジニアリングマネージャーとプロジェクトマネージャーの役割分担
プロジェクトマネージャーは、特定のプロジェクトを期限、範囲、予算、品質などの観点から進める役割です。計画を立て、関係者を調整し、予定どおりに目的を達成することに重点を置きます。
一方、エンジニアリングマネージャーは、プロジェクトが終わった後も含めて、開発チームが継続的に成果を出せる状態をつくる役割です。メンバーの育成や評価、採用、チームの働き方の改善などに責任を持ちます。
両者は密接に連携します。プロジェクトマネージャーが計画上の課題を把握し、エンジニアリングマネージャーが人員配置やチーム運営の面から支援する、といった分担が考えられます。
エンジニアリングマネージャーとテックリードの役割分担
テックリードは、技術面でチームを導く役割です。設計の方針、技術的な判断、品質の基準、技術課題の解決などを主導します。開発の現場に近い立場で、技術的な方向性を示すことが多い役割です。
エンジニアリングマネージャーは、技術的な判断が円滑に進むよう、体制や優先順位、関係者との連携を整えます。また、テックリードが技術面に集中できるよう、採用、育成、業務負荷の調整などを担う場合もあります。
ただし、エンジニアリングマネージャーにも技術理解は必要です。技術の詳細をすべて決めるのではなく、適切な人に判断を任せ、その判断を事業や組織の意思決定につなげます。
役割が重なりやすい場面
開発組織では、役割が明確に分かれていないことも少なくありません。たとえば、優先順位づけはプロジェクトマネージャー、エンジニアリングマネージャー、事業責任者のいずれも関わることがあります。技術的な課題についても、テックリードだけでなく、エンジニアリングマネージャーが判断に参加する場面があります。
役割が重なること自体は問題ではありません。問題になるのは、最終的に誰が決めるのか、誰に相談すればよいのかが不明確な状態です。
役割分担を決める際は、担当する業務だけでなく、意思決定の責任者、相談先、情報共有の方法を明確にしておくことが重要です。
少人数の組織で兼務する場合の考え方
少人数の組織では、一人がエンジニアリングマネージャー、プロジェクトマネージャー、テックリードの役割を兼ねることがあります。この場合、兼務そのものよりも、役割ごとの視点を意識して切り替えることが大切です。
たとえば、技術的に最適な選択を考える場面と、メンバーの成長機会を考える場面、納期とのバランスを考える場面では、重視する点が異なります。一人で抱え込まず、チーム内で技術判断を担う人や進行管理を補助する人を育てることも必要です。
組織が成長したら、兼務を前提とした運営を見直し、役割を分けるタイミングを検討します。
エンジニアリングマネージャーに必要な力
メンバーの成長を支える対話力
エンジニアリングマネージャーには、相手の話を聞き、状況や考えを理解する力が求められます。指示を出すだけでは、メンバーが抱える不安や困難を把握できません。
対話では、事実と感情を分けて確認することが有効です。何が起きているのか、どこに難しさを感じているのか、本人はどのような支援を求めているのかを丁寧に聞き取ります。
また、すべてを管理者が解決する必要はありません。本人が自分で判断し、周囲と協力して進められるよう支援することが、長期的な成長につながります。
チームの状況を整理して判断する力
開発チームでは、納期、品質、技術的な課題、メンバーの負荷、事業上の要望など、複数の要素が同時に動きます。エンジニアリングマネージャーには、情報を整理し、何を優先すべきかを判断する力が必要です。
判断の際は、目の前の問題だけでなく、中長期的な影響も考えます。短期的な納期を守るために無理を続けると、品質低下や疲弊によって、その後の開発速度が落ちる可能性があります。
判断の理由を説明し、関係者が納得できるようにすることも重要です。結論だけでなく、前提や優先順位を共有することで、チームは自律的に動きやすくなります。
技術を理解し適切に任せる力
エンジニアリングマネージャーは、技術に関するすべての答えを持つ必要はありません。しかし、技術的な議論の意味や、選択による影響を理解できなければ、適切な支援や判断は難しくなります。
重要なのは、自分で細部まで決めることではなく、誰に判断を任せるべきかを見極めることです。専門性を持つメンバーの意見を尊重しながら、必要な情報を得て、事業上の判断と結びつけます。
技術から離れすぎると、現場との対話が難しくなる場合があります。実装量は減っても、設計の背景や開発上の課題に継続して関心を持つことが大切です。
関係者を巻き込む調整力
開発チームの課題には、チーム内だけでは解決できないものがあります。優先順位の変更、必要な人員の確保、他部署との連携、意思決定の遅れなどには、関係者を巻き込む働きかけが必要です。
調整では、相手の立場や目的を理解した上で、開発チームの状況を具体的に伝えます。単に「人手が足りない」と伝えるのではなく、何が起きており、どのような影響があり、どの選択肢があるのかを整理すると合意を得やすくなります。
意見が対立する場合も、感情的な対立にせず、共通の目的に立ち返って話し合う姿勢が求められます。
課題を仕組みで解決する力
同じ問題が何度も起こる場合、個人の注意力や頑張りだけに頼る解決策では不十分です。エンジニアリングマネージャーは、問題が再発しにくい仕組みを考えます。
たとえば、属人化が課題なら情報を共有する場や文書を整えます。確認漏れが起きるなら、作業の手順や確認項目を見直します。業務が偏るなら、役割分担や育成計画を調整します。
仕組みは複雑である必要はありません。チームが無理なく続けられ、実際に課題の改善につながる方法を選ぶことが重要です。
エンジニアリングマネージャーになるための準備
エンジニアとしての経験を生かせる領域
エンジニアとしての経験は、エンジニアリングマネージャーにとって大きな基盤になります。開発の難しさ、見積もりの不確実性、障害対応の負担、技術的な改善の必要性を理解していることは、現場に合った判断につながります。
特に、設計やレビュー、他メンバーへの支援、開発プロセスの改善、部署横断の調整などを経験していると、マネジメントへの移行に生かしやすくなります。
ただし、優れたエンジニアであることと、優れたエンジニアリングマネージャーであることは同じではありません。個人で成果を出す力に加え、他者が成果を出せる環境をつくる視点が必要になります。
小さなマネジメント経験の積み方
いきなり大きな組織を任されなくても、日常業務の中でマネジメント経験を積むことはできます。たとえば、新しく入ったメンバーの支援、会議の進行、開発の振り返り、チーム内の課題改善、小規模なプロジェクトの進行役などが挙げられます。
こうした経験では、自分が作業を進めることよりも、周囲が動きやすくなるように考えることが重要です。目的を共有する、役割を明確にする、困りごとを早めに拾う、振り返って改善する、といった行動を意識します。
経験を積んだ後は、うまくいったことだけでなく、判断に迷ったことや失敗したことも記録し、次の行動に生かすとよいでしょう。
プレイヤーから役割を移す際の注意点
プレイヤーからエンジニアリングマネージャーへ役割を移す際には、自分で手を動かす量を減らす必要が出てきます。これまで得意だった仕事から離れることに、不安や物足りなさを感じることもあります。
しかし、すべての難しい仕事を自分で引き受けると、メンバーの成長機会を奪い、管理業務も後回しになりやすくなります。自分が直接解決するべき問題と、メンバーに任せて支援するべき問題を分けることが重要です。
また、以前と同じ感覚で開発の細部に介入しすぎると、責任の所在が曖昧になる場合があります。任せる範囲と確認するポイントを明確にし、必要なときに支援する姿勢を持つことが求められます。
よくあるつまずきと改善の方法
エンジニアリングマネージャーになったばかりの時期には、以前の成功体験がそのまま通用しないことがあります。代表的なつまずきは、自分で解決した方が早いと考えて仕事を抱え込むことです。この状態が続くと、チームの自律性が育たず、管理者自身も疲弊します。
改善するには、仕事を任せる際に、目的、期待する成果、期限、相談してほしい条件を明確にします。最初から完全に任せきりにするのではなく、途中で確認する機会を設けると、双方の不安を減らせます。
また、メンバーとの関係づくりを後回しにすることもつまずきにつながります。業務上のやり取りだけでなく、定期的な対話を通じて状況を知り、信頼関係を築くことが重要です。
自分に合うエンジニアリングマネージャー像の考え方
エンジニアリングマネージャーに唯一の正解はありません。技術に強い人、育成や対話に強い人、組織の仕組みづくりに強い人など、それぞれに持ち味があります。
まずは、自分がどのような場面でチームに価値を出せるかを考えます。その上で、現在の組織に必要な役割と、自分が伸ばすべき力を整理するとよいでしょう。
大切なのは、理想的な管理者像をそのまままねることではありません。チームの状況や事業の段階に合わせて、メンバーが安心して成長し、継続して成果を出せる環境をつくることが、エンジニアリングマネージャーとしての本質です。
