はーい、メリークリスマス！
すでに良い子のところにはプレゼントが配達済みなナウ25日で、サンタさんが寝室に戻る足音を聞きながら、私からのプレゼントは堂々と遅配なTO☆SHI☆NO☆SE、みなさまいかがお過ごしですか。
Engineering Manager（以下EM）の不要論という、クソデカ主語の飛ばし記事を書こうとして、遅刻してたんじゃ世話ないですが、こちらの記事は Engineering Manager Advent Calendar 2021 の24日目の記事になります！遅れてごめんなさい！
EMって要るの？要らないの？（自己紹介）
まずはお前誰だよってことで自己紹介させていただきますが、今年の4月からキャディ株式会社でエンジニアリングマネージャーをしております @hiraiva です。
元々うっかりCTOをさせていただいていたうっかり八兵衛なこともあって、現職入社後こんなインタビュー記事も作っていただきました。ありがたや。私の下の名前は二郎って言うんですけどね。
んで、今はEMなわけで、EMって本当に世界にとって必要なんだろうか、君のいない世界には何の意味もないのに、ってたまに思うんですよね。だって、世界を変えるために作っているものがソフトウェアプロダクトだったとして、ソフトウェアエンジニアさえ居ればソフトウェアって作れるじゃないですか？ それに比べて、EMって開発しないこともあるし、人のお話を聞いてるだけのこともあるし、予定調整ばっかりしてることだってある。1日8時間しかないはずの労働時間が、12時間会議と面接で埋まったことがありますか？ 意味ある会議だったらいいですけどね。ただ、自分が本当にエンジニアリングーをマネジメントしているのかわからなくなることはあるわけです。エンジニアリングーはエド・はるみのイントネーションで読んでくださいね。
というわけで、EMって実はいらないんじゃね？ ソフトウェアエンジニアがいればソフトウェア作れるし、よしんばマネジメントが必要だったとしてもプロダクトマネージャーやプロジェクトマネージャーがいればいいんじゃね？ という思いに駆られるお気持ち駆動開発（ODD）をここに表明するわけです。
とはいえ、世の中には色んな形でEM業を立派に全うされているみなさまがいらっしゃいます。そういった方々がどういう活躍をしているのか考えてみないことには、本当にEMがこの世界に不要なのかどうかわからないはず、ということで世の中にはどんなEMがいらっしゃるのかを、私の独断と偏見で分類してみました。私の伝え聞いた話やどこかで読んだ記事などから私の中の集合知を結集して、結果、何となくのイメージで分類した、MECEでもなく、何の裏付けもない分類ですので、何卒ご容赦ください。すいません、殴らないでください（右の頬）、殴らないでください（左の頬）。
EMの組織・チームへの関わり方パターン
まず、チーム伴走型と組織横断型に大きく分類してみました。
その上で、それぞれの型に属するであろうパターンについて検討しています。
そろそろ茶番は終わり。急に真面目になるよ！
チーム伴走型
多くの場合、開発チームに専任で配属され、チームに伴走するタイプのEMです。
開発へもコミットパターンとピープルマネジメント主体パターンの二つに分けてみました。
開発へもコミットパターン
EM自身の技術力や技術スタックがその開発チームの要求水準を満たしている場合や、単にEMも開発したい場合に発生しやすいように思います。
実際の開発活動にも入り込んでいくことから、スクラムマスターを兼任することもあるでしょうし（ただ、ちょっとスクラムアンチパターン）、比較的小さいチームだと思いますがプロダクトマネージャーを兼任するパターンも存在しそうです。
このパターンの利点は直接開発にも関わることで、直接的なマネジメントがしやすいことだと思います。プロダクトやプロジェクトのマネジメントについては直接コントロールができますし、ピープルマネジメントについても同じ開発チームメンバーとして共感やリスペクトを得やすいでしょう。
反対に欠点はそのまま裏返しですが、どうしても開発チームの当事者としての目線になりやすいことだと思います。プロダクトやチームを客観的に見る視点は意識しないと持ちにくく、より広い視点からの全体最適はしにくい立場ということになります。
ただ、エンジニア出身でEMをはじめる場合はトライしやすい形ではあると思います。
ピープルマネジメント主体パターン
コーチングの経験やスキルや才能を持ったEMが、組織からの要請によってこのパターンになる場合が多いように思います。逆に言うと自然発生的にこのパターンになりにくいイメージがあり、おそらくはチームメンバーの育成や自己組織化に課題があるか、それらが重要だとチームの外側の誰かに思われている場合にこの差配がなされることが多いでしょう。
このパターンの利点は、間接的なマネジメントになるのでレバレッジかけやすく、これだけに集中すれば複数チーム担当しやすいかもしれません（やりたいかはともかく）。それに、全くピープルマネジメントがなされていないチームに相対したときの威力も大きいと思います。
逆に欠点は、特に既にある程度うまくいっているチームだとピープルマネジメント自体の効果が見えづらいことがあることや、間接的なマネジメントに留まるので当事者になりきれず（コーチングとしては正しくはある）、チームメンバーからのリスペクトがない状態だとワークしづらいことでしょうか。
加えて、マネジメントやコーチングに経験のあるEMか、カリスマ性のある人でないとやりづらい部分はあるかもしれません。
組織横断型
特定のチームに所属したりせずに、横断的にエンジニアリング組織などに対してマネジメントを行うタイプのEMです。
EM of EMsパターンとふんわりミッションベースパターンの二つに分けてみました。
EM of EMsパターン
EMを束ねるEMというパターンです。多くの場合、そのEMは各EMを通してエンジニアリング組織全体をマネジメントすることになります。または、単にEMsのピープルマネジメントだけを追加の役割として持っている人を指すこともあるとは思います。
チームが複数あって、チーム伴走型のEMが増えてきた場合に必要となることがあります。VPoEがその役割を果たすこともあるでしょう。
ただ、EMという役割は、チーム伴走型のEMであっても、戦略的にチームの上長という体を取らないことも多いと思っています。そのようなマネジメントポリシーだった場合、EMの中だけにラインマネジメント的なパラダイムが発生してしまっていいのかという懸念があります。もちろんEM of EMsとEMsの間に信頼関係があれば問題はないのですが。
ピープルマネジメントだけを行うケースであれば、上記の問題は発生しないかもと思いつつ、組織論的には同じような役割で一緒に仕事をしていない人たちは意外と利害が一致しにくい側面があると感じています（これはPdMもちょっと一緒かも）。そういった集団に役割の偏りを発生させること自体が、十分な信頼関係を下敷きにしていないと、時にハレーションの元となる、かもしれません。
ふんわりミッションベースパターン
特定のチームに伴走するわけではなく、エンジニアリング組織全体や事業に対してふんわりとミッションを持ち、その遂行をゴールとして柔軟に動くパターンです。
VPoEがそういった立場になることも多いと思いますし、EMがそうなる場合は組織規模に対してEMの数が少ないときになりやすいでしょう。
利点としては、特定チームに関するタスクに専有されてしまうことがなく、組織や事業の状況に応じて必要な動きができることですが、同時に時として、高度の柔軟性を維持しつつ臨機応変に、となってしまうのが欠点です。
VPoEに限らず、役員やVPはこういった立場に近いことも多いと思いますが、定量目標の持ちにくいエンジニアリング担当はその成果や存在意義を明確にしづらいという欠点もあると思います。
で、EMは要るの？要らないの？
真面目なの限界なので、そろそろまたふざけたくなってきましたが、クソデカ主語に対する最低限の説明責任は果たさねばネバーランドなので続けます。
以上の分類から、EMには色々な形があることがわかりましたが、いずれのパターンでもEMが持っている役割は、EMだけが持っているわけではないことが多いように思います。
チーム伴走型の場合、開発へもコミットパターンもピープルマネジメント主体パターンも、EMだけが持っている役割はピープルマネジメントだけのようにも見えます。開発はエンジニアができますし、プロダクトやプロジェクトのマネジメントはそれぞれPdMやPjMが持っていることもあるからです。
そこで、ピープルマネジメントについて検討すると、それ自体をEMでない誰かが肩代わりするというケースもなくはないと思いますし、そもそもセルフマネジメント力の強いチームメンバーが揃っている場合はピープルマネジメント自体が不要になるでしょう。
組織横断型についても同様です。EM of EMsパターンはそもそもEMがいなければ必要とされないものですし、ふんわりミッションベースパターンは役員やVPがやっていることと似ているので、どんなものをEMが持っていたとしても分解して分担することができるでしょう。他の役員やVPが持ちにくいものとして、エンジニアリングを横断的に見る人がいないと言うならCTOがいればいいでしょう。
つまり、EMが持っている役割を分解したり肩代わりすれば、EMをなくすことができるのです。
以下の記事では、実際にそれを実践したプロセスや座組が説明されています。
この記事は本記事を書くにあたってとても励まされたのでこっそりお礼を言わせてください。ゆのんさんありがとう。
EMが要らないケース
他にもEMをなくすことができるケースがないか、具体的に考えてみます。
"理想的な"スクラムチーム
語弊を恐れず言えば、スクラムって賢くてハイスキルで人柄も良い人達が自律的に協働して無駄なく成果を出すための枠組みに感じることもあります。
現実的にはありえないかもしれませんが、動機・ソフトスキル・ハードスキルともに完璧なエンジニアが集まったら理想的なスクラムチームができるし、そこにEMは要らないのかもしれません。
もう少し現実的に理想的なチーム
実在しえない理想とまではいかなくても、まるで家族のような阿吽の呼吸のベテランチーム、利害の一致したプロフェッショナル傭兵集団、みたいなチームなら、わざわざEMがいなくてもうまくいきそうです。
ただ、こういうチームは天然物で狙って作れないことも多いし、たいていはスケールさせづらいチームですね。不純物が入り込むと崩壊していくピュアなチーム。逆に言うと、チームをスケールさせようと思うと、不確実性が一定入り込むからEMのような柔軟に不確実性に対応する役割が必要になるのかも。チームがピュアな状態では必要なく、清濁合わせ飲んでスケールさせたりしていくときにある種のバッファーとして必要になる存在。それって、デモンズソウルの第六聖女・アストラエアみたいですね。アストラエアさん好きなので言いたかっただけです。
さらに言えば、明らかに天然物のピュアな理想なチームとは言えなくても、そのチームが理想に近いかどうか、組織のカオスエンジニアリングをすればわかるのかもしれません。
Googleが従業員に対して実践している「カオスエンジニアリング」とは？ - GIGAZINE
EMが居なくてもチームの生産性が落ちないとしたら、そのチームはある種理想に近い状態なのかもしれませんし、スクラムマスター同様、自らをクビにできるチームを目指すことが、少なくともチーム伴走型EMの目指すべき姿なのかもしれません。
結局、EMは要るの？要らないの？
ここまでのことをまとめると、EMだけが持つことになりやすいのはエンジニアのピープルマネジメントで、それすらも不要にすることは可能ではあるということがわかりました。
一方、ピープルマネジメントがうまくいっていないことが明確ならEMの介在価値も明確になりやすいですし、チームをスケールさせていく上で不確実性が発生しうるなら未然に防ぐ意味も込めてEMを配置する意味はあるのだと思います。
逆に言うと、一定チームがうまくいっているなら、EM自身がチームにとって足りないピースを自ら設計しないといけないかもしれませんし、EMが必要ないということはチームにとって幸せなことなのかもしれませんね。
身も蓋もない帰着ですが、やはりEMは組織やチームにとって手段の一つに過ぎないんですよね。
数ある手段の中から、組織やチームのゴールに対して最適な手段を考え続けることが本質的なことだというか、でもそれってEMの役割だったりもするよねっていうか、でもEM自身も手段だから手段が手段を考えていることになって…おっと、こんなところでメビウスの輪が完成してしまいました。永遠のクリスマスに閉じ込められてしまう前に、この記事を終わりとしたいと思います。
メリークリスマス！