この記事は Engineering Manager Advent Calendar 2023 の21日目の記事になります！
EMは何する人なのか？ 問題
定期的に話題になる内容で、最近も少し話題になったように思います。
色々な意見があり、人によって「コードを書くべき」「コードを書く必要がない」など、全く違う意見もあります。
場面によってやることが変わるのは確かです。
その時にどのような役割を担っているか次第だと考えました。
この記事ではEMの開発への関わり方としてどんなパターンがあるのかを考えてみました。
理解するにはマネジメントをもっと細かく分解して捉えると良いのでは？
マネジメントと一言で言っても、色々なマネジメントが含まれています。
EMを語るときには４つのマネジメント領域で語られることが多いと思います。
- プロダクトマネジメント
- プロジェクトマネジメント
- ピープルマネジメント
- テクニカルマネジメント
EMの役割を考える上では、マネジメントをもっと解像度高く把握していく必要があると考えています。
１人でこの領域の全てを担うことは難しいと考えられて居るのではないかと思います。例えば、プロダクトマネージャーは人を管理するマネージャではないのですが、一部の領域のマネジメントを担当する専門領域としている職種も出てきています。このマネジメント領域は役割を委任する形になります。
この４つのマネジメント領域でそれぞれ何を期待しているかはこちらの記事が非常に参考になるので、ぜひ読んでみてください！
場面によってマネジメントの形が変わる方が当たり前なのでは？
EMはこの様々なマネジメント領域を全てをカバーしますが、状況によって領域に掛ける力に濃淡が発生しています。
特に分かりやすくシーソーになるのが、エンジニアとしてのスペシャリストとしての能力の発揮とマネジメントとしての組織としての活動を強化する能力があります。
「チームの課題状況」、「EM個人の得意領域」、「組織でのEM定義」などに合わせて、EMは場面や人によって違う活動します。
チームメンバーに一部領域に得意な人がいれば、その領域のマネジメントを任せて、EMは違う領域をマネジメントすることがあります。
これは「Engineering Managerという役割がなぜわかりづらいのか」という記事にも紹介されていました。
つまり、エンジニアリングマネージャはマネジメントを行って最終決定などの責任は取りますが、それぞれの領域での現場レベルでは任せれる一部のマネジメントをメンバーに任せていくこともあると考えています。
そのため、場面によって期待される役割や活動は変わることがむしろ自然であると感じます。
チーム、テクノロジー、プロダクトを結合し、チームの力を最大化する
マネージャとなると、重要なのは個の力の発揮だけでなく、チームとしての価値発揮を最大化することです。
どのようなスキルがあればチームとしての結合力を上げて、コラボレーションを生み出せるのでしょうか？
プロダクトとテクノロジーの間を繋げる
テクノロジーとチームの間を繋げる
チームとプロダクトの間を繋げる
それぞれを上手く繋げることで、チームとしての力を生み出すことが必要と言う話が、エンジニアリングマネージャートライアングルの話なのかなと思います。
汎用的な整理だけだと具体的な話が進みにくい
先人のEMの人たちが整理してくれたので、理解が非常に進みました。
しかし、インターネッツで自分のイメージするEMを想像しながらの議論となったとき、この図だけでは議論が難しそうと感じました。肩書きよりも何を解決するべきことに注目するべきではありますが、具体的なEMの動き方のパターンがあった方がお互いのイメージが揃って、議論が進みやすいのではないか？と考え、今回は、６つのパターンに整理してみました。
EMに期待するパターンを６つに整理
Development Project Manager
SI系の開発やプロジェクト型の開発ではこのパターンが非常に多いのではないでしょうか。
機能リリースの一覧とスケジュールがあり、マイルストーンに沿って開発をしたり、あるいは開発のスケジューリングをしながら、開発メンバーと設計や実装のズレがないかを確認しつつ、開発プロジェクトを管理します。
決まった期間の中で、決まった機能の開発を達成するような、プロジェクト型開発で、開発プロジェクトを管理する役割が強いマネージャになります。
人の管理も行いますが、どちらかというとプロジェクトマネジメントの色が濃い役割になると感じます。
Mini-CTO
技術をどのように活用するのか、あるいはどのような未来を描くのか、開発組織の未来に対する意思決定を経営レベルで行う役割です。
エンジニアチームはビジネスの御用聞きではなく、ビジネスメンバーと同等に事業実現のためのエンジニアリングの意思決定を推進しています。
チームの中にEMは入らず、チームは事業実現のための実行部隊になっています。この形式の場合はEMとは別にチームの中にチームリーダーが別で存在することも多いのではないかと思います。
事業的意思決定の場にEMが居て、チームの現場的な進行の細部には関わらない形です。
テクニカルなAI系の事業だとこのスタイルのチームも多くあるイメージです。
Technical Team Lead
テックリードと呼ばれる役割に近いことを行っているEMです。技術的意思決定や技術的リードは行うが、プロジェクト推進やタスク実行はチーム全体で行っている。
EMはテクニカルリーダーではあるが、プロジェクトリーダーではない。テクニカルマネジメントに比重をおいたEMです。個人的にはこの形はEMがボトルネックになりづらい形なので、良いのではないかと思います。
プロジェクトマネジメントやタスクの管理はチーム全員で管理することで、負担を分散します。
Cross-Organization
最近は見るようになってきた役職のTechnical Program Managerもこのパターンに入るのかなと思います。
チーム横断で起こるテクニカルな課題や関心事を整理して、解決に向けて各チームに働きかける役割。複数チームの規模になるとこの役割が居ないときに、各チームの連携の課題によって機能不全になることがあるので、必要なポジションなのではと最近感じています。。
横断的な役割が必要なだけでなく、連携プロセスの構築や課題の整理推進に掛けられるリソースを明確に組織として捻出する必要があるという組織サイズがあると感じます。
この組織サイズを超えるときに、この横断的な問題に対処しないと、一部組織的な機能不全が起きると思います。
逆を言うと、大きな組織でなければ見られない役割かなと思います。
Product Owner
Technical Product Managerもここに含まれるイメージです。
開発するシステムにテクニカルな要素が強いプロダクトをマネジメントする場合に、EMがプロダクトオーナーとして技術と事業の価値を図りながらバランスを取った意思決定をする必要があるときの立ち振舞いになります。
技術的な知見がなければ意思決定が難しいプロダクトを扱っている場合にはエンジニアがプロダクトオーナーになる必要があります。最近出てきたプラットフォームエンジニアなどの役割を持ったチームだと、特に技術的知見をもとにした社内エンジニアをユーザーとした開発を行うため、この役割に近いプロダクトマネジメントが必要だと感じます。
Organization Development / Organizational Designer
開発領域での組織開発と組織デザイン領域を担当します。最近ではジンジニアという言葉も生まれるほどにエンジニア固有の組織づくりについて強い課題感が生まれてきているのではないでしょうか。
確かにエンジニア特有の文化や価値観、システムと技術の間にある課題感などは、専門の知識がある人が組織設計しなければ感覚的にフィットする施策を生み出すことが難しい部分もあるかもしれません。
また、近年はエンジニア採用の激化によってエンジニアの採用難易度は高まっており、採用に掛かる時間的なコストも高まっています。採用に関わる対応としてカジュアル面談、エージェントの連携強化、ダイレクトスカウト、技術広報など、採用専任を置いても手数が足りないくらいの活動が必要な組織もありそうですが、実際は手数が足りずに採用活動の一部を諦めているかもしれません。
それに加え、社内の組織開発や開発者体験の向上なども重要視されています。社内のエンジニアの活躍のためのエンジニア独自の制度設計、イベント施策などの実行も推進が必要でしょう。
さらにはエンジニア組織の理想の構造の設計などを検討するなど、エンジニア独自の文化に成り立つ力の発揮のための人事施策が多く必要になってきていると感じます。 まさにピープルマネジメントを広く深く対応する役割になっています。
６つのパターンの傾向の考察
上の段はチームの中に軸足のあるEMが居て、チームと共に同じタスクを活動することが多いでしょう。チーム内の問題ごとを種別問わず解決するために活動します。
下の段はチームの外に軸足のあるEMが居て、チームに実行の大部分は委譲され、自律的に動きます。
シニアメンバーが揃っているチームだったり、組織が拡大して開発チーム間の課題が多く見られる様になったチームに多い形なのではないでしょうか。
カッツモデルというマネジメントの分け方がありますが、上段はロワーマネジメント、下段はミドルマネジメントを主に担当する役割になっているように感じました。
今回６つのパターンに分けましたが、このパターンの仕事しかしない！というものではなく、このパターンの中でもEMの実際にやっている仕事は横断した役割を担うことも多々あるかなと思います。
状況に合わせて、チーム内の問題を解決したり、チーム間の問題を解決したり、会社全体の課題を解決したり、様々な場面で強い意思決定を作り出す必要があります。
このマネジメント領域で現場からの距離の違いは行うマネジメントの違いにも繋がっているように感じました。
まとめ
EMはどんな関わり方をしたとしてもエンジニアリング領域の責任を期待されていることは確かです。
EMに期待されてる範囲は広く、認識のズレ、期待のズレが起こることは多々あると思います。
今回の分けた例でも、上段のパターンであればコードを書いて欲しいかもしれませんし、下段のパターンであればコードを書くことは不要かもしれません。
自分のチームのEMがどのパターンに当たるのかを確認することで、期待がズレているなどの確認して、認識のズレの辛さが少しでも減らせるなどの活用が出来ると嬉しく思います。
もし、自分の組織はこの中には当てはまらないEMの仕事をやっていて、こんなパターンもあるかもしれないというものがあったら、是非コメントなどで意見を頂けると嬉しいです！