株式会社はてなでテックリードとして仕事をしている 
id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。
エンジニアリングマネージャーの4領域とは
ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。
- テクノロジーマネジメント
- アーキテクチャやテストなど
- プロジェクトマネジメント
- 見積もりやアジャイル開発など
- プロダクトマネジメント
- ビジョンや仮説検証など
- ピープルマネジメント
- メンバーの成長やメンタリングなど
これらの4つの領域は @hiroki_daichi さんの以下の記事を参考にしています。
qiita.com
「テックリードやスクラムマスターと領域が被る部分がある」など同僚と話したりしてそうなんだと思ったことあったのですが、私はソフトウェアエンジニアであれば役割の有無に限らず全員少なからず意識することにはなるんじゃないかと最近思っています。
EMでなくとも4領域を意識する必要がある
立場に限らずどのメンバーでも意識することになると言われてもピンとこないと思うので私の思う役割ごとの濃淡のイメージを書き出してみます。注意してほしい点としては、ロールに名前がついてはいますが、どのロールも結局チームや会社ごとに求められる仕事はちょっとずつ違うと思うのであくまでも自分はこう思っていますというくらいに思ってもらえれば幸いです。
テックリードの場合
まず私がいまテックリードという役割を持って仕事をしているのでテックリードから考えます。自分の思うテックリードの主務は「テクノロジー領域をリードする」なので、「テクノロジーマネジメント」をメインに担当するものだと思います。
一方で、アーキテクチャを考えたり技術選定をするにあたって結局プロダクトの未来を意識する必要があります。いま自分たちのプロダクトがどういう状況にあるのかを理解し、それを元に意思決定をしたい。プロダクトオーナーとの連携が大事になります。また、テックリードとしても一種の「技術方面のプロダクトオーナー」として振る舞わなければなりません。そう考えると「プロダクトマネジメント」も仕事に関わってきます。
技術的施策を考えるテックリードも技術領域に特化したPOとも言えます
テックリードとして技術的施策をチームに提案する際に意識すべきポイント - stefafafan の fa は3つです
また、テックリードが面白いと思っているという理由だけで技術選定するのも望ましくないはずです*1。大抵のチームは開発速度・開発生産性も求めているはずで、そうなると開発速度をあげるための「プロジェクトマネジメント」にも足をつっこむことになります。
最後に、テックリードは「リード」であり、テックリード1人で全てのコードを書いてリリースする必要はありません。メンバーにどのタスクを割り振ってどうチームを成長させるか、どうメンバーのモチベーションをあげるのかも考えることになります。「ピープルマネジメント」ですね。
最近私が読み始めた「エンジニアリングマネージャーのしごと」では、「情報収集」「意思決定」「ナッジング」「ロールモデル」の4つの動きができているか否かが重要と書かれていました。まさにテックリードも自分で意思決定はしつつも必要に応じて他メンバーに話題を振ってナッジングしたり自分自身がロールモデルとして振る舞うことが大事だなと思ったのでEMでなくとも参考になるかと思いました。
色々と書きましたが、テックリードは「テクノロジーマネジメント」が主務ではあるものの、結局技術をリードするにあたって他の3領域も必ず紐づいてくるので「エンジニアリングマネージャー」ほどではなくともかなり近い働き方を期待されるのかなと思っています。
スクラムマスターの場合
私はスクラムマスターとしてチームにスクラムを導入・普及したことがあります。そんな自分が思うにスクラムマスターはチームのデリバリーを改善することが主務であり、つまりは「プロジェクトマネジメント」に軸足を置きます。
ではスクラムチームの中でスクラムマスターは1人で動いて1人でデリバリーを改善するのでしょうか。もちろんそんなことはありません。スクラムはチームで動くためのフレームワークであり、プロダクトオーナーやデベロッパー含めた連携を必要とします。そこでスクラムマスターはチームのデリバリーを阻害するものをなるべく排除していけるように、かつ意味のないインクリメントを速く出すのではなくしっかりと価値を届けることに成功しているかを確認しなければなりません。
デリバリー速度をあげるにはスクラムイベントがしっかり実施されていることの確認も大事ですが*2、テックリードと連携して課題をどう解消していくかサポートしていく必要があります。テックリードとの連携により「テクノロジーマネジメント」に関わるということです。価値を出すにはプロダクトオーナーと連携する必要があり、「プロダクトマネジメント」にも関わることになります。
スクラムでは個人個人のモチベーションがとても大事です。POやテックリードとの連携が上手く行ったとしても結局他メンバーのやる気が削がれている場合は素早くリリースサイクルが回せなかったりするかもしれません。スクラムマスター自身が1on1のメンターなどをやらないかもしれませんが、調子の悪そうなメンバーがいたらEMへフィードバックするなり何かしらの方法で「ピープルマネジメント」にも少なからず関わっていくことになると思います。
スクラムマスターとEMの違いはというと、名前の通りスクラムを布教することが仕事なので特に「プロジェクトマネジメント」の改善にフォーカスしてもらいます。ただし、デリバリーの改善の中で結局他の領域との兼ね合いは絶対にあるので、必要に応じて色んなメンバーと連携とって進めることを期待されています。
最近目にした @dora_e_m さんのスライドでは、スクラムマスターも見れる領域を広げていくという観点でEMと似たところがあるという話が書かれていてなるほどなと思いました。
speakerdeck.com
スライド中に紹介されていたサイトです。
scrummasterway.com
Individual Contributor (IC) の場合
EMと合わせてよく耳にするICについて。ICのイメージとして「マネジメントをしない」「コードだけ書いているスペシャリスト」みたいな部分があって魅力的に見えるのかなと思うのですが、以下の記事などをみるとそういうわけではないことがわかります。
なお、ICだからといって管理職に必要とされるスキルが全く不要というわけでもありません。職位が上がるにつれて、例えばプロジェクトをリードしたり、チームの内外とコミュニケーションを取りながらプロジェクトを進めることが求められます。小さなプロダクトであれば、実質的にプロダクトマネジメントを担うこともあります。ICというのは、単に部下を持たないというだけのことです。
生涯現役のソフトウェアエンジニアでありたい。IC（Individual Contributor）のキャリアパスがあると自覚するまで10年の軌跡 - Findy Engineer Lab - ファインディエンジニアラボ
部下を持たないだけで結局マネジメントが必要なときはしていそうですね。では結局なんでこんな特別な名前がついているのかというと、高い水準の期待感を持たれている実際に手を動かすソフトウェアエンジニアであるというのを強調したいのかなと思います*3。
ICには何が求められているのかというともちろん高い技術力（テクノロジーマネジメント）は前提としてその上で自力でうまくプロジェクトを回せるプロジェクトマネジメント力、プロダクトへの価値を提供する強いコミットメント（プロダクトマネジメント）だと思います。ピープルマネジメントについては同じチームで働いているメンバーがいるのであれば1ミリも意識しないことはないのではと思いますが、部下を持たないという定義なのであれば4領域の中では優先度は下がるかもしれません。
ロールを持たないソフトウェアエンジニアの場合
ここでは例えば新卒やまだ経験の浅いジュニアエンジニアのことを考えてみます。経験の浅いソフトウェアエンジニアは何を求められているのかを考えると、「一定の技術力を身につけること」と「担当しているプロジェクトの進行を安定させること」だと思います。
まずは目の前のタスク、目の前のプロジェクトの進行を安定させ、さらに今後もどんどん改善できるようになり自立していくまでの道のりをメンターと一緒に探っていくというのがテーマになっていくのではないか
Webアプリケーションエンジニアとして1on1してもらう際に考えていること - stefafafan の fa は3つです
水準はともかく「テクノロジーマネジメント」も「プロジェクトマネジメント」も求められています。いくら技術力があっても会社員として与えられた仕事を決められた期日までに完成させられなければチームとしても会社としても困ってしまうのでそこをいかにコミットできるかという部分で「プロジェクトマネジメント」をかなり意識することになります。
「プロダクトマネジメント」や「ピープルマネジメント」については新卒の時点では優先度はやや低いのかなと思いますが、少しずつ意識させられるものなのかなと思います。「プロダクトにとって今重要なことは何か」をしっかりと意識できてその上で何かしらエンジニアリングで改善が入れられればかなり評価されますし、新卒2年目として1年目のメンターをしたりアルバイトメンバーをしっかりと成長させられればその点もプラスになります。
「エンジニアリングマネージャー」や「テックリード」などと比べると視座の高さの違いはあれど、自身が見える範囲での4つの領域での活動は実は新卒のソフトウェアエンジニアも知らず知らずのうちに期待されていると思います。
結局エンジニアリングマネージャーの役割とは
ここまでどんなロールのソフトウェアエンジニアも結局はEMの4領域を意識するものだと書いてきましたが、それではEM自体の役割はなんなのかということになると思います。私自身EMは経験しておらずそこまで深い知識はありませんが、広い視野と高い視座を持ってチームを（時には複数チームや会社レベルのスコープで）観察し適切な領域へのサポートができる人なのかなと思っています。
会社やチームによってどこが課題なのか、タイミングによっても変わると思います。そんな時にEMは4つの領域が全てチームで満たされているのか、満たされていたとしてもどこかの領域がいま大きなボトルネックになっていないか。ボトルネックになっているなら何かしら自分が動いて助けになることができるか*4を考えるのかなと思っています。
テクノロジーマネジメント、デリバリーマネジメント、ピープルマネジメント、プロダクトマネジメントのそれぞれの象限で、マネジメントが成り立つか
体制を考えるときに意識していること - id:onk のはてなブログ
全員が全員EMだと各々広い範囲の中で改善に取り組めると思いますが、代わりに細かい課題解消のスピード感が足りなかったり見落とされたりする懸念があるんじゃないかと思います。例えば現場でまさにコードを書いているデベロッパーが何度もコードをコピペしていて辟易としていたりしたら、そういった困りはEMよりも距離感が近く「テクノロジーマネジメント」が主務のテックリードが拾い上げて解消していけると良いです。プロジェクトマネジメントも同じで、EMが考えて動くのもよいですが、スクラムマスターのようなスクラムに深くコミットしているメンバーがいるほうが素早く改善を取り入れられます。
EMはあくまでより広い範囲での観察を実施し、テコ入れが必要なところはテコ入れする、大きな変化があるとよいと考える場合はそこに向かって動けるように行動することが求められているのではないかと私は考えています。
終わりに
エンジニアリングマネージャーの4つの領域について、さまざまなロールでどのように意識していくべきかを見ていきました。またエンジニアリングマネージャー自身の役割についても再考してみました。
私自身も今後のキャリアパスとしてEMを目指すのか否かはまだ考え中なところであります。ソフトウェアエンジニアとして今後も働いていく中では「ジェネラリストかスペシャリストか」の2軸だけではなく、今回挙げた4つの軸をどういうバランスでフォーカスしていきたいかを意識するのも一つの考え方なのではないかと思います。みなさまの参考になれば幸いです。
この記事は はてなエンジニア Advent Calendar 2023 の30日目の記事でした*5。明日の担当は 
id:tkzwtks さんです。
*1:面白さも大事だとは思いますが、ここではチームやプロダクトの性質を無視して決めるのはよくないということを伝えようとしています。
*2:実際にはスクラムイベントを実施するだけではベロシティが上がることはなく、振り返るための仕組みが入るので土台作りができるんだと思っています。
*3:エンジニアとしてキャリアを積むと自分は手を動かさずに他のジュニアなエンジニアにコードを書いてもらうことが多そうだけど、ICは自分も設計したりコード書いたりをバリバリやるということなのかなと想像しています。
*4:ここで言う「自分が動く」はEM自身が手を動かすもあると思いますし、チームや会社に働きかけチーム構成や役割の変更を提案するなど、色々やれることはあると思います。
*5:はてなエンジニア Advent Calendar は去年もそうですが、12月25日を過ぎてもしばらく続けています。
