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

エンジニアが抱えるEMというキャリアパスへの葛藤

自ら手を動かしてプロダクトを作り上げることに喜びを感じるタイプのエンジニアにとって、EMというキャリアパスは、時に大きな葛藤を伴います。
かつてはマネージャーになることが唯一のキャリアアップと見なされる風潮もありましたが、現在では専門性を追求し続けるインディビジュアル・コントリビューター（IC）の道と、マネジメントへの道が同等に評価されるキャリアラダーが整備されている企業は少なくありません。

どちらの道を選ぶべきか、唯一の正解はありませんが、いくつかの観点から考えることで、自身にとってより良い選択をする手助けになります。

1つの重要な判断基準は「インパクトの大きさ」です。一般的に、キャリアラダーを上に進めるほど、より広範囲へのインパクトが求められます。

ICの場合、そのインパクトは個人の技術力や成果によってもたらされます。卓越したスキルで困難な技術課題を解決したり、チーム全体の生産性を飛躍的に向上させるツールを開発したりすることで、大きなインパクトを生み出すことは可能です。

しかし、組織が大きくなるにつれて、チーム間や部門全体、さらには全社的な課題解決に貢献することが求められるようになると、IC一人の力でインパクトを出すことの難易度は格段に上がります。

一方で、エンジニアリングマネージャー（EM）のアウトプットは「チームのアウトプットの総和」です。EMはチームを率い、メンバーの能力を最大限に引き出すことで、1人では到底成し遂げられない大きなインパクトを生み出すことができます。

そのため、より上位のラダーが求める広範囲へのインパクトという観点では、EMのほうが比較的達成しやすい構造になっていると言えるかもしれません。もちろん、人や組織への興味が薄い場合、EMの仕事は苦痛になる可能性が高いため、自身の志向性を見極めることが大前提となります。

重要なのは、この選択が1度きりの不可逆なものではないということです。企業によっては、EMからICへ、あるいはその逆へとキャリアを行き来することが可能です。実際にEMを経験した後にICに戻るエンジニアも少なくありません。そして、そのEMとしての経験は、ICとしてのキャリアにおいて非常に価値のあるものとなります。

マネジメントの視点を理解しているICは、プロジェクトの優先順位付けや関係者との調整、チーム目標への貢献といった、コーディング以外の重要な側面で高い能力を発揮できます。仕事の勘所を理解しているため、チームにとって非常に頼りになる存在となるのです。

キャリアの選択に悩んだ際は、短期的なスキルの獲得だけでなく、長期的にどのようなインパクトを生み出したいのか、そしてどちらの道が自身の成長と満足につながるのかを多角的に検討することが重要と言えるでしょう。

佐藤：はい、わかりました。まず今EMをやっている方は、もっと突き詰めるといろいろなものが知れてすごく深い領域で楽しめると思うので、もっとどんどんやってみたらいいかなと思っています。

一方で、いつでもソフトウェア開発やコードを書くこともできるので、そっちの道にもいつでも行けるんだぞと、思っておくといいんじゃないかなと思います。

まだやったことがない人は、ぜひ小さなことでもいいのでやってみること、始めてみることをお勧めしています。やはり人生何があるかわからないので、「やってみたら意外に楽しいじゃないか」ということも多いと思うんですよね。

新多：そうなんですよね。

佐藤：そうなんですよね。やらない限り、それは絶対にわからないので、小さなこと、例えば会議のファシリテーションでもぜんぜんかまわないので、まずは自分でマネジメントに触れてみることを始めてみると、きっといろいろなキャリアを築けるようになるんじゃないかなと思います。ぜひトライしてほしいなと思います。

引用：マネジメントされる側も「マネジメントとは何ぞや？」を知るべき　うまくマネージしてもらうためにメンバーレイヤーが意識したいこと【あらたまが聞くエンジニアリングマネージャー仕事の極意】（ログミーBusiness）

改善の延長線上にあるEMというキャリア

エンジニアリングマネージャー（EM）という職務は、何か特別なスキルセットを持つ人だけが担えるものではなく、多くのエンジニアが日常的に行っている「チームを良くするための活動」の延長線上にあると捉えることができます。

この視点を持つことで、EMへのキャリアチェンジに対する心理的なハードルは大きく下がり、より自然なステップとして受け入れることが可能になります。

多くのエンジニアは、自身の担当業務を遂行する中で、プロダクトをより良く、より速くユーザーに届けるための改善活動に取り組みます。その際、着手しやすいのは自身の得意領域であるシステム領域です。

例えば、CI/CDパイプラインを高速化したり、Linterを整備してコード品質を一定に保つ仕組みを導入したりといった活動が挙げられます。これらは明確な無駄を排除し、開発効率を直接的に向上させるため、効果を実感しやすい改善です。

しかし、こうしたシステム的な改善には限界があります。コストパフォーマンスの良い改善策をやり尽くすと、次なる改善の矛先は自然とチーム全体のプロセスやコラボレーションへと向かいます。

コードレビューがより円滑に進むような仕組みを考案したり、定常的な作業の負荷を軽減するスクリプトを作成したり、チーム内のドキュメンテーション文化を見直したりと、改善のスコープは個人のタスクからチーム全体へと広がっていきます。

そして、チームレベルでの課題も一通り解決されてくると、「プロダクトを成長させるために、次に最もインパクトが大きい改善は何か」という問いが生まれます。ここで至るのが、「個々のメンバーの成長を促し、支援すること」の重要性です。

各メンバーの成長を考慮してタスクを割り振る。1on1や日々の雑談を通じてそれぞれの得意・不得意や興味の方向性を見極める。評価を通じて長期的な成長を支援する。これらの活動は、一見すると従来のエンジニアリング業務とは異質に見えるかもしれません。

しかし、その根本にある動機を辿れば、「CIを速くする」ことも「メンバーの成長を支援する」ことも、「良いプロダクトを安く早く顧客に届けたい」という一貫した目的のための手段であることがわかります。やっていることの表層だけを見れば多岐にわたりますが、その本質はすべて「プロダクトを成長させるための改善活動」なのです。

この気づきを得た時、EMという役割は、裁量権が大きく、ジェネラリスト的な志向を持つエンジニアにとって、自らの能力を最大限に発揮できる非常に魅力的なポジションであると理解できるでしょう。

エンジニアとしての改善活動と、EMとしてのピープルマネジメントは、プロダクトの成長という観点で見れば、シームレスにつながっているのです。

EMを目指すためにメンバーレイヤーから始められること

マネジメントは、マネージャーという役職に就いた人だけが学ぶべき専門分野ではありません。むしろ、チームに所属するすべてのメンバー、特に将来のキャリアを考えるエンジニアにとって、マネジメントの基礎を理解しておくことは非常に有益です。

マネジメントされる側が「マネジメントとは何か」を知ることで、マネージャーとのコミュニケーションは円滑になり、より効果的にサポートを引き出し、自身の成長と評価に繋げることが可能になります。

例えば、1on1ミーティングの目的が、マネージャーからの指示伝達ではなく、メンバー自身の内省を促し、気づきを得るための場であると理解していれば、メンバーはより主体的に対話に臨むことができます。「マネージャーはこういう目的でこの質問をしているから、自分はこう内省して答えを導き出そう」と考えることで、1on1の質は格段に向上します。

このように、マネジメントの「やり方」を知ることは、マネジメントを「受ける」際のパフォーマンスを高めるのです。

情報が乏しく、手探りで学ぶしかなかった時代とは異なり、今では多くのEM経験者がポッドキャストや勉強会、ブログなどを通じて積極的に情報発信を行っています。これらのコミュニティに参加することで、多様なロールモデルに触れ、自身のキャリアの選択肢を広げることができます。

さらに重要なのは、マネジメントの仕事は、メンバーレイヤーであっても「つまみ食い」できるものが数多く存在するということだとLayerX EMの新多真琴氏は語ります。マネージャーの仕事をただ待つのではなく、自ら積極的に関わっていく姿勢がキャリアを切り拓きます。

例えば、会議のファシリテーション役を買って出る、プロジェクト管理の一部を引き受けて進捗の取りまとめを行う、新メンバーのオンボーディングをサポートするなど、リーダーやマネージャーの仕事を観察し、「これは自分にもできそうだ」と思うものがあれば、積極的に手を挙げてみることが推奨されます。

こうした小さな成功体験を積み重ねることで、マネジメント業務への理解が深まるだけでなく、仕事に対してより主体的にコミットできるようになります。

できることが増えるのは、純粋に楽しい経験です。この楽しさと成功体験を結びつけることで、マネジメントという仕事が、誰かから与えられる堅苦しいものではなく、自らの成長とチームへの貢献を実感できる魅力的な活動であると捉えられるようになるでしょう。