ビッグテックでのEM経験からひも解く、エンジニアのキャリアパスとEMの仕事内容

自己紹介

はじめまして。BoostDraftでエンジニアリングマネージャをしている吉田と申します。今回はソフトウェアエンジニア(SWE)のキャリアパスと、キャリアパス上の選択肢の一つであるエンジニアリングマネージャ(EM)の仕事について書いてみようと思います。ソフトウェアエンジニアとして、キャリアアップに興味を持たれている方の参考になれば幸いです。また、日頃「エンジニアリングマネージャって何をしているの？」と聞かれることが多いので、この記事を通してエンジニアリングマネージャの仕事にも少し焦点を当ててみたいと思います。

初めてですので最初に簡単に自分の経歴をお話しします。冒頭に「BoostDraftのエンジニアリングマネージャ」と自己紹介しましたが、実はBoostDraftに参加してからはまだ1年も経ちません。BoostDraftの前にはMicrosoftに26年半ほど在籍し、そのうち前半の12年半はソフトウェアエンジニア、後半の約14年はエンジニアリングマネージャとして主にWindowsの開発に携わりました。

そういうわけですので、これから自分自身がソフトウェアエンジニアとしてステップアップしてきた経験やエンジニアリングマネージャとして他のソフトウェアエンジニアのキャリアパスを見てきた経験をもとにお話ししますが、その経験の大部分はBoostDraftではなくMicrosoftで得たものとなります。いずれにしても、ソフトウェア業界は人材の流動性の高い業界ですので、キャリアパスに対する考え方は一つの会社を超えて業界全体で共通な部分も多いのではないかと思います。

職種とレベル

前置きが長くなってきたので本題に移りましょう。Microsoftでのソフトウェアエンジニアのキャリアパスは(そして前述した通り基本的な考え方は他の会社でも共通しているのではないかと思いますが)下図のように非常にシンプルです。

まず、職種(役割)としてICとマネージャの二つがあります。ICとはIndividual Contributorの略で、部下を持たず、自分自身が手を動かして成果を出す役割の人を指します。これがつまり(狭義の)ソフトウェアエンジニアです。一方、マネージャはICと対照的に、部下を持ち、チームを運営し、チーム全体で成果を出す役割の人を指します。これがエンジニアリングマネージャです。

また、職種とは独立なもう一つの軸としてレベルがあります。Microsoftでは各レベルの名前は1, 2, Senior, Principal, Partnerとなっていましたが、会社によって違う呼び方も存在します。例えばシニアソフトウェアエンジニア(Senior software engineer)の上のレベルをスタッフソフトウェアエンジニア(Staff software engineer)と呼ぶ会社もあります。ICとマネージャの両方を含めた広義のソフトウェアエンジニア全体でのキャリアステージは、職種とレベルの2次元のテーブル上で例えば「Seniorのマネージャ」とか「PrincipalのIC」などと表現することができます。

この図からはいくつかの面白い事実が読み取れます。まず、基本的には「キャリアアップ」とはレベルを上げていくことです。端的に言えば給与レンジはレベルごとに決まります。もちろん一つのレベルの中にも例えば「Seniorになりたて」から「ほとんどPrincipalみたいなSenior」まで幅があるので、一つのレベルの中でさらに細かいステップアップの段階を刻むことができますし、それに合わせて給与が少しずつ上がっていくことは一般的です。その一方、レベルが変わるときの給与へのインパクトはやはり大きいです。逆に言うと、一つ上のレベルとして認められるためには、以前のレベルと比較してそれだけ明らかな違いが必要ということになります。

同時に、「給与レンジはレベルで決まる」の裏返しですが、「職種の違いは給与レンジに関係ない」のも面白いポイントです。世の中には「マネージャになると給料が上がる」とか、そこからさらに展開して「だからマネージャの方がICより偉い」といった価値観もあるかもしれませんが、少なくともソフトウェアエンジニアの世界にはこの考え方は当てはまりません。ICであろうがマネージャであろうが同じレベルであれば給与レンジは同じですし、レベルの高いICの方がレベルの低いマネージャよりも給与が多くなります。そして、これが保証されていることで、ICからマネージャへの一方通行の遷移だけではなく、マネージャをやっていた人がICになる、という方向の遷移も普通に起こる環境が作られます。ICからマネージャ、あるいはマネージャからICへの遷移は「昇格」や「降格」ではなく、「役割の変化」にすぎません。

ただし、図にもあるようにレベル 1やレベル 2には基本的にマネージャのポジションはありません(もちろん例外はありますが)。レベル 1というのは社会人になったばかりの新卒のソフトウェアエンジニアが最初に割り当てられるレベルですが、さすがにそこでいきなりエンジニアリングマネージャの役割を任せられることはありません。裏を返せば、マネージャの役割を果たすためにはソフトウェアエンジニアとしてSeniorレベルに到達していることが前提、最低でもそのレベルの経験値が求められる、ということです。

レベル＝スコープの大きさ

さて、ここまででキャリアアップとは基本的にはレベルを上げていくことだとお話ししましたが、それではレベルを上げていくためには何をしたらいいのでしょうか。別の言い方をすれば、とあるレベルとその一つ上のレベルでは具体的に何が違うのでしょうか。

実はこれもかなりシンプルで、一言でいえば「レベル＝スコープの大きさ」と考えておけば大きく間違えることはありません。もう少しイメージしやすいように、IC職の各レベルに求められるスコープを具体的に書いてみると以下のようになります。(注：あくまでも私個人の経験に基づく肌感覚を簡潔にまとめたものであり、会社として明文化された定義ではありません。)

レベル	スコープ
1	レベル1の中でも初期の頃は、先輩に指導してもらいながらでないと一人では仕事が完結できないような状態。そこから成長していき、最終的には小さめのフィーチャーやコンポーネントを一人で完全にownするようになる。
2	自分が一人でownするフィーチャーやコンポーネントの規模感・複雑度がレベル1と比べて大きくなる。後輩の指導などもできるようになる。そこからさらに成長していき、最終的には複数人で共同で作業する規模のプロジェクトで重要な仕事を任されるようになる。
Senior	複数人で共同で作業する規模のプロジェクトでリーダー的な役割を担う。技術的な方針を決めて他のチームメンバーをガイドする。技術力の高さ・成果の大きさはチームメンバーの中でトップクラス。チームを引っ張る役回りだが、一方でマネージャではないので、基本的には責任範囲は自分が直接手を下した仕事に限定される。
Principal	複数のチームにまたがるような影響力を発揮する。採用する技術の決定やその技術を使うための指導を複数チームにまたがる規模で行う。多くの機能に共通する基盤アーキテクチャを設計し、他の人がそれを使えるようにエバンジェライズやサポートをする。
Partner	Principalよりもさらに抽象度の高い技術的な意思決定、より広範な組織に対する影響力を発揮する。社外にも顔が見える有名人として業界全体に影響を及ぼす人もいる。もはや技術各論の指導者を超えて精神的指導者レベル。

それぞれのレベルにおけるスコープの規模感はマネージャ職でも同じですが、こちらもイメージしやすいように具体的に書いてみると以下のようになります。

レベル	スコープ
Senior	技術力やリーダーシップに対する期待値はSenior ICと同じだが、自分が直接手を下して成果を出すのではなく、ピープルマネージメントやプロジェクトマネージメントを通してチームの成果を最大化し、チーム全体を成功に導くことが仕事。
Principal	複数のチームにまたがるような影響力を発揮する。ICのマネージャではなくマネージャのマネージャになる人も出てくる(つまり自分の下に2階層の組織がある)。
Partner	マネージャのマネージャが基本。のみならずマネージャのマネージャのマネージャなど、より大きな組織全体を見るようになる。マネージャではなくDirector(ディレクタ)と呼ばれることもある。

ちなみに、一人のマネージャが持つ直属の部下の数(部下の部下は含めない)、いわゆるspan of controlですが、これまで見てきた範囲でいうとソフトウェアエンジニアリングの世界では10人未満、おそらく7～8人前後のチームが一番多いように思います。個人的にはこれでも少し多く感じ、多くて6人、できれば5人くらいのチームが最適ではないかと思っています。ただし、少なすぎるとチームとしてできることが限られてきてしまうので、単純に少ない方がいいとも言い切れません。

エンジニアリングマネージャの仕事

レベルによってスコープの大きさは違えど、ICのソフトウェアエンジニアの仕事は基本的にはフィーチャーやコンポーネントのオーナーとなり必要な設計作業や実装作業をするということで、割とイメージがしやすいのではないかと思います。一方、エンジニアリングマネージャの仕事は、それをご自身で経験されていない限り今一つつかみどころがないと感じる方が多いかもしれません。そこで、次にエンジニアリングマネージャの仕事、求められている役割をもう少し詳しく見ていきたいと思います。

ここには人によって異論が出るかもしれませんが、個人的にはエンジニアリングマネージャの仕事・責任は以下の3つの柱で説明できると考えています。

• チームで採用する技術的な方針を決定し、その決定に責任を持つ。
• チームが取り組んでいるプロジェクトのプロジェクトマネージメントを行い、適切なリソース(=人数×時間)で適切なクオリティの成果を出すことに責任を持つ。
• チームメンバーのピープルマネージメントを行い、チームメンバーの成長に責任を持つ。

ちなみに行動として「何をするか」だけではなく、「その結果どうなるのか」という結果にコミットするところが一つのポイントで、逆にいうと結果にコミットしているからこそ、その結果にたどり着くために必要なことは何でもやってよいという裁量が与えられていると言えると思います。以下、もう少し具体的に掘り下げます。

まず、一点目の技術的な方針決定ですが、ここはSenior以上のICのソフトウェアエンジニアとかなりオーバーラップします。ただし、敢えて違いを説明するなら、エンジニアリングマネージャの場合、技術的な提案は必ずしもゼロからすべて自分の知識だけで構築する必要はなく、それこそチーム内の信頼するICに大半の部分を任せてしまっても構いません。一方、決定した方針に関する最終的な責任はICのソフトウェアエンジニアではなくエンジニアリングマネージャに帰属します。仮に自分が考えた方針でなくとも、その方針を採用すると決めた責任はエンジニアリングマネージャにあるということです。例えば、チームの外や上層部からその技術を選んだ理由を聞かれればそれを説明し、その方針が正しいという主張ができる必要があります。また、あとになってその方針が間違いだったという結論が出た際には、次回同じような問題があった時に同じ間違いを繰り返さないためにどうすればよいのかを考え、その仕組みを作る責任も伴います。

二点目のプロジェクトマネージメントは、簡単に言えば、与えられたリソースが一定だとしたときにそのリソースで得られる成果を最大化する仕事です。ただし、実際には話はそんなに単純ではなく、「成果」の大きさには複数の要素が複雑に絡んでいます。例えば「機能の豊富さ(多いほど良い)」、「品質の高さ(高いほど良い)」、「コードのメンテナンス性の高さ(高いほど良い)」、「プロジェクト完了までにかかった時間(短いほど良い)」などの要素があり、それらを総合的に判断して全体的な「成果」を最大化する最適解がどこかを見つけるのは一筋縄ではいかない仕事です。さらに言えば前提として書いた「与えられたリソースが一定」というのも必ずしも正しくはなく、必要な量のリソースを確保する(要はチームメンバーを増やすことを要求する)のもエンジニアリングマネージャの仕事の一つだったりしますから、パラメータはさらに増えます。

プロジェクトマネージメントにおいては、これらの要素の間で成果を最大化するためのトレードオフの判断を常に迫られます。わかりやすいトレードオフの例は機能の豊富さとプロジェクトにかかる時間です。機能の豊富さという一次元の軸しかなければ「機能は多ければ多いほどいい」という話ですが、現実には製品のリリースタイミングというのは製品の価値(つまり成果の大きさ)を決定する重要な要素の一つです。10個の機能を持った製品を来年リリースするよりも、6個の機能を持った製品を今年リリースする方が価値が高いということはよくあります。製品に機能を入れないという判断をするのは難しいものですが、そこを見誤ると製品価値の最大化に失敗することがあります。ほかにも、あと一つ機能を足すと製品全体の実装コストが2倍になるようなケースではその機能を作らない判断が正しい場合もありますし、機能を足すことで品質が落ちてしまうことも避けなければなりませんから、考慮しなければならないトレードオフは多岐にわたります。

また、プロジェクトに参加しているのはロボットではなく人間ですから、チーム内の士気や雰囲気が悪くなれば生産性が落ちます。これも「成果の最大化」にとっては敵ですから、プロジェクトマネージメントではチームの士気を保つためにタスクのアサインの仕方に緩急を付けたり、チアリーディングのようなことも必要です。

最後に三点目のピープルマネージメントですが、これはチームメンバーが最大のパフォーマンスを発揮できるようにサポートし、さらに将来に向けて成長していけるようにサポートする仕事です。もう少しかみ砕いて言えば、メンバーが現在の仕事をしやすくするために障害物を取り除いたり他の人とつないだりする一方、将来に向けては少し挑戦しがいのある仕事を見つけてきて課題を与えたり、改善点に本人が気づけるように適切なフィードバックをしたり、ということをします。

ICとマネージャは上下関係ではなく役割の違い、とは前にも書きましたが、会社のいわゆる上司部下ではなく、芸能人・タレントとそのマネージャ、という関係をイメージするとわかりやすいかもしれません。もちろんピープルマネージャには人事権があったりチームメンバーの給与を決める権限があったりする場合もありますから、そこに力関係や上下関係が全く存在しないというのは詭弁になります。ですが、力で脅してチームメンバーを動かすよりも、チームメンバーが気持ちよく働ける状況を作ることの方が生産性の向上につながり、ひいてはチームの成果を大きくすることは現代では常識と言っていいでしょう。

エンジニアリングマネージャのやりがい

エンジニアリングマネージャの仕事内容が少しわかってきたところで、改めて、マネージャ職のやりがいとは何でしょう？目の前にICとマネージャの二つの職種の選択肢があった時に、エンジニアリングマネージャを選ぶ理由があるとしたら、それはどういうものでしょうか。これも個人的な意見の域を出ませんが、次に私の考えるマネージャ職のやりがい、ICではなくマネージャのキャリアを選ぶ理由をお話しします。もちろん、マネージャではなくICを積極的に選ぶ理由も同じくらいあるのですが、ここではエンジニアリングマネージャの仕事に焦点を当てているため、そちらは割愛します。

私がソフトウェアエンジニアから初めてエンジニアリングマネージャになった時、真っ先に感じたのは急に目の前が開けたような感覚でした。ソフトウェアエンジニアとして働いていた同じチーム、同じプロジェクトのまま、そのチームのエンジニアリングマネージャになったために余計強く感じたのかもしれませんが、それまで自分たちのチームがやっていた仕事が「なんで重要なのか」、「より大きな組織、ひいては会社全体の目標にどういう風につながっているのか」という「仕事のコンテキスト」が急にはっきり見えたのを覚えています。エンジニアリングマネージャになって初めて参加するミーティングや初めて触れる情報があり、それが視野を広げてくれたのです。

例えて言うなら、チームメンバーの他の人が平地に立っているのに、自分一人だけ山の上に登って遠くまで見渡せている状態とでも言えばいいでしょうか。この、「遠くまで見える」、「仕事のコンテキストがわかる」というのはマネージャ職の魅力の一つだと思います。一方、これをマネージャの「特権」にしておいてはいけません。急に目の前が開けた感覚に衝撃を受けたのと同時に、ICのソフトウェアエンジニアだった時の自分にはそれが見えていなかったのだという事実も同様に衝撃的でした。山の上に登っているのが自分だけであるならば、そこで見てきたことをチームメンバーに共有するのは自分の義務だ、と感じたのを今でも覚えています。

次に大きいのは、自分一人ではできない規模の仕事をチームとしてやり遂げられることの喜びです。これはSenior以上のICでも言えることではありますが、マネージャの方が自分が直接的に手を下して出す成果が少ない分、チームで出す成果により明確に集中しやすいという側面があると思います。

また、マネージャは「鶴の一声」を求められる機会が多いです。客観的なデータを基に論理的に考えれば答えが一つであるようなケースはいいのですが、実際の仕事の場面では不十分な情報しか無いために機械的に意思決定ができないことは珍しくありません。そのような時、責任の所在があいまいになる多数決ではなく、誰かが鶴の一声で物事を決める必要があり、多くの場合それはマネージャの役割です。もちろん責任が伴いますが、チームの仕事の方向性に大きな影響力を持つというのはやりがいにつながると思います。

もう一つの大きなやりがいは、ピープルマネージャとしてチームメンバーの成長のサポートができる、というところです。これもSenior以上のICでもある程度経験できますが、マネージャはより直接的にチームメンバーの成長に関与し、またその機会も多いです。ピープルマネージャの一番の喜びは、自分のチームメンバーが評価され、昇進するのを目にすることです。

まとめ - キャリアアップのための考え方

今回の記事では最初に広義のソフトウェアエンジニアは大きくIC職とマネージャ職に分けられ、どちらもキャリアのステップアップは自分がownするスコープの大きさに対応していくことをお話ししました。また、ICとマネージャの違いは役割の違いであり、ICからマネージャ、マネージャからICの両方向の遷移が任意のレベルで可能であるという考え方を説明し、最後にICと比べて謎の多いマネージャの役割と、敢えてICではなくマネージャを選ぶ理由となるやりがいについてページを割きました。皆さんがソフトウェアエンジニアのキャリアパスの中で現在どのステージに立っているのか、また、そこから先にどのようなキャリアアップの方向性があるのかを考えるためのヒントになれば幸いです。

ちなみに、BoostDraftではICのソフトウェアエンジニア、エンジニアリングマネージャともに積極的に採用中です。BoostDraftの製品は不特定多数のユーザを対象にしたものではなく、特定領域のプロフェッショナルを対象とした専門性の高い製品です。そのため、開発チームとユーザの距離が近く、ユーザの生の声を直接受けてインクリメンタルに製品を改善・拡張する開発体制がとられています。自分の開発したソフトウェアをユーザに実際に使ってもらいたいエンジニアにとって、非常に手ごたえのある環境です。ご興味をお持ちの方はぜひ弊社のオープンポジションについてもご確認ください。
BoostDraft - Current Openings (workable.com)