エンジニアリングマネージャー（EM）とは？　役割から求められるスキル、テックリードとの違いを解説 [1/2]

定義が難しいエンジニアリングマネージャー（EM）の役割

エンジニアリングマネージャー、通称EMという職種の定義は、非常に難しいとされています。その理由は、この役割が置かれる状況、つまり企業の規模や事業フェーズ、チームの構成によって求められる職務内容が大きく異なるためです。絶対的な職務記述書のようなものは存在せず、プロダクト開発における「マネジメントらしいこと」を包括的に期待されるケースも少なくありません。

この曖昧さが、多くのEM、あるいはEMを目指すエンジニアにとって、自身の軸足をどこに置くべきかという共通の悩みとなっています。

かつては「エンジニアリングマネージャー」という言葉自体が存在しなかったこともあり、自身としては役割を明確に意識しないまま、いわば「野生の勘」でマネジメントらしき業務を遂行していたと『エンジニアのためのマネジメント入門』の著者である佐藤大典氏は語っています。

例えば、チームリーダーとしてプロジェクトを推進する中で、自然とプロジェクトマネジメントやテクノロジーマネジメントを担うようになり、「いつの間にかコードを書く時間が減っていた」という経験を持つ人もいます。

キャリアを重ね、組織長のような立場になると、複数のリーダーの評価に携わるようになり、初めてピープルマネジメントの領域に触れることになります。しかし、それでもなお、マネジメントの本質を掴みきれないまま、手探りで業務を進めていたという声は少なくありません。

状況が変化し始めたのは、1on1ミーティングのような手法が普及し、マネジメントが体系的に語られるようになってからです。上司との対話を通じて、メンバーの気づきを促すコミュニケーション手法や、チームビルディングにおける間接的なアプローチの有効性を知ることで、マネジメントが探求すべき専門分野であるという認識が広まりました。

個々のメンバーやチームへの関わりから、次第に組織全体のマネジメント、さらには経営に近い視点へと関心が移っていく中で、EMという役割の輪郭が徐々に形作られてきたのです。

チーム、組織、そして経営が一体となって初めて成果が生まれるという理解が深まるにつれ、EMの職務範囲もまた、その接続点として広がりと深みを持つようになりました。このように、EMの役割は歴史的経緯や組織の文脈の中で流動的に形成されてきたため、一意な定義が困難となっているのです。

EMのミッション

EMの役割は組織によって千差万別ですが、その多様性の根底には共通する1つのミッションが存在します。それは、「担当するチームのアウトプットを最大化すること」です。

EMは自身が直接手を動かして成果物を生み出すのではなく、チームという集合体が継続的に高いパフォーマンスを発揮できる環境を構築し、その結果として生み出されるアウトプットの総和に責任を負います。

EMの価値は、単に自身が管轄するチームのアウトプットだけで測られるものではありません。そのチームが他のチームと連携し、組織全体に与えた影響のアウトプットも含まれます。つまり、EMの成果とは、自身のチームのアウトプットと、そのチームが影響を与えた他のチームのアウトプットの総和であると定義されます。

この視点を持つと、EMの仕事は単なる人員管理に留まらず、チーム間の連携を促進し、組織全体の生産性を向上させるためのハブとしての役割を担っていることがわかります。個人の成果に注力していたエンジニアがEMにキャリアチェンジする際、この「チームのアウトプット」にコミットするというマインドセットの転換は、時に葛藤を生むこともありますが、EMとしての価値を発揮するための根幹となる考え方です。

また、EMは短期的なプロジェクトの成功だけを目指すのではありません。プロジェクトが終了してもチームは存続し、次の挑戦に向かいます。そのため、チームが長期的に、そして継続的に価値を生み出し続けられるような場、すなわち持続可能な開発体制や文化を築くことが極めて重要な責務となります。

これには、メンバーのキャリア相談に応じたり、適切な人員計画を立てたり、公正な評価制度を運用したりといった、ピープルマネジメントの側面が色濃く関わってきます。現場で発生する課題やボトルネックを1on1などを通じて吸い上げ、それを次のチームの目標設定に反映させていく。

このような地道な活動を通じて、チームの長期的な成長をデザインしていくことこそが、EMに求められる本質的な価値と言えるでしょう。

EMは実際はいわゆる中間管理職です。なので自分が「会社のやりたいことをこう持っていくんだ！」というのとはちょっと違って、チームが現場で戦っているところで、メンバーがどうアウトプットを出せるかに注目をしています。

アンドリュー・S・グローブの『HIGH OUTPUT MANAGEMENT』という書籍がありますが、マネージャーの価値というか「（マネージャーは）何をやるんだ？」という時にチームのアウトプットとそのチームの連携する役割だと思っています。

チームのアウトプットと影響を与えた他のチームのアウトプットの総和なので、自分自身でよりもチームのアウトプットに注力するというのにけっこう葛藤がありましたが、これをふだんは考えています。

あともう1つあって、やはり短期的な個々のプロジェクトではないんですよね。「プロジェクトの終わりがある程度見えてきたら解散」というわけじゃなく、そこから次のプロジェクトが始まるかもしれないし、プロジェクトをやっていく中で「あ、ここが問題だな」と思うことが次のプロジェクトにつながるかもしれません。

なので、チームがそれを長期的、継続的にコミットできる場を作ることが、エンジニアリングマネージャーには求められているのではないかなと私は思いながらふだん仕事をしています。なので（スライドを示して）ここはピープルやチームのマネジメントを主にやっているわけですね。

引用：ICのままか、EMになるべきか…　ソフトウェアエンジニアの僕が悩み抜いて出した答え（ログミーBusiness）

EMとテックリードの役割分担

EMの役割を考える上で、テックリード（TL）との関係性は非常に重要です。書籍『Googleのソフトウェアエンジニアリング』では、EMとTLは二人三脚で歩むことを推奨されていると株式会社ビットキーの佐藤正大氏は語ります。

このアプローチの根底にあるのは、プロダクト開発における責任範囲を分割し、それぞれの専門家が専任で役割を果たすほうが、1人がすべてを抱え込んで燃え尽きてしまうよりも効果的であるという考え方です。

具体的に役割を分担すると、テックリードは「製品の技術的な側面」に責任を持ちます。これには、技術的な意思決定、アーキテクチャの設計、技術的優先度の判断、開発速度の管理、そしてプロジェクトマネジメント全般が含まれます。TLの重要な責務は、チームの各メンバーがそれぞれのスキルセットやレベルに最も適したタスクに取り組めるよう保証することです。

一方でEMーは、「チームが担当する製品がビジネス要件を満たすことを保証しつつ、テックリードを含むチーム全員の成績、生産性、満足度に責任を持つ」と定義されます。EMはピープルマネジメントの側面と、ビジネスの要求に応える側面に主眼を置きます。この2つの要求は必ずしも一致しないため、EMは時として難しい立場に置かれることになります。

この関係性をより深く理解するための1つの考え方として、「EMの仕事は、テックリードがやらないすべてである」と捉える方法があると佐藤正大氏は語ります。

技術的な側面を担うTLの役割は、エンジニア経験者にとっては比較的理解しやすいものです。アーキテクチャ設計やプロジェクト管理の大変さや責任の重さは、多くのエンジニアが身をもって知っています。その困難さを理解しているからこそ、EMは「TLが自身の業務に集中できる環境を整えるために、他に何が必要か」という視点で動くことができます。

TLがどのようなサポートを求めているか、どのような状況を望んでいるかを先回りして察知し、その環境を整備することがEMの重要な貢献となり得ます。

プロダクトの価値を生み出す源泉がテクノロジーの力であると考えるならば、TLの生産性を最大化することがチームの成果を最大化することに直結します。したがって、EMはTLを全面的に信頼し、技術的な領域を大きく委任することが賢明です。

そして、TLが技術的なリーダーシップを存分に発揮できるよう、組織的な課題や人間関係の調整、キャリア支援といった、技術領域以外のあらゆる課題を引き受ける。この明確な役割分担と相互の信頼関係こそが、EMとTLが効果的に「二人三脚」で歩むための鍵となります。

EMに求められるスキル

EMには、チームを率いるマネジメント能力だけでなく、より広い視野、すなわち経営の視座が求められます。自身のチームの業務が会社全体の戦略の中でどのように位置づけられ、事業の成長にどう貢献するのかを理解し、メンバーに伝えていくことが重要な役割の1つだからです。

しかし、マネージャーという立場にいながらにして、経営層と同じ視座を持つことは容易ではありません。それは「鶏が先か、卵が先か」という問いに似ており、そのポジションに就かなければ得られない視点というものが確かに存在します。

キャリアを積み、VPoEやCTOといった経営に近いポジションに就くと、自然と見る範囲は広がります。個別のチームやプロジェクトだけでなく、開発組織全体、さらには事業全体を俯瞰し、「何を考えていかなければいけないのか」という問いのスケールが大きく変わります。

かつては経営層の決定を「見上げる」立場だったのが、自らが「広い視点に立つ」側になることで、物事の捉え方や発信する言葉の深みが格段に増します。

では、まだマネージャーの段階にいる人物が、この経営視座をどのようにして手に入れれば良いのでしょうか。その鍵となるのが「追体験」です。自身が直接その立場を経験せずとも、経営層の視点や思考プロセスに触れる機会を積極的に作ることで、その考え方を疑似的に体験し、自身の行動に反映させることが可能になります。

例えば、CTOやVPoEといった経験者が運営するポッドキャストや勉強会は、その絶好の機会です。彼らが「経営メンバーはこういう視点で物事を捉える」「事業成長のためにはこういう点が重要になる」といった内容を発信するのを聞くことで、参加者は新たな視点を得ることができます。

直接的な経験ではないものの、「世の中にはこういう考え方があるのだ」と知ることは、日々の業務における意思決定やメンバーとのコミュニケーションに変化をもたらすきっかけになります。少し意識して行動を変えるだけで、これまでとは違った結果が生まれるかもしれません。

この「追体験」は、マネージャーがメンバーに対して働きかける際にも非常に重要です。メンバーに自分と同じ視点を持ってもらうために、ただ指示を出すのではなく、その背景にある組織の状況や戦略的な意図を丁寧に説明する。これにより、メンバーはマネージャーの視点を追体験し、より主体的に業務に取り組むことができるようになります。