プレイングエンジニアリングマネージャーと一緒に作る自律的な開発組織

この記事は スターフェスティバル スターフェスティバル Advent Calendar 2023の6日目の記事です。 (風邪を引いていたら書くタイミングを逃してしまい今に至ってます) 5日目はzakiさんから「OpenAI APIのJSON ModeとFunction Callingの精度比較」でした。7日目はkogaさんから「monorepoのリポジトリにRelease Drafterを導入して複数のタグを管理する[NestJSプロジェクトを例に]」です！

と、いうわけでタイトルが全てみたいなことを書いていきますが、要するに何が言いたいかというと「今、スタフェスがEM全員がプレイヤーとしても振る舞う開発組織」を実践しているが、割とうまくいっているという実感があります。

なので、この記事では、

• エンジニアリングマネージャー(EM)を、マネージャー専業ではなくプレイングマネージャーで構築するというのはどうか

• プレイングマネージャーを中心に構成するとどういうよさがあるのか

• プレイングマネージャーと一緒に組織を作る重要なポイントはなにか

を簡潔に書いていきたいとおもいます。
本稿における開発組織の手法は「エンジニアリングチーム50名程度まで」の比較的小規模なスタートアップで応用可能な考え方だと思いますので、参考になれば幸いです。

マネージャー専業 vs プレイングマネージャー

まず、基本的な前提のすり合わせという話ですが、自分は「マネジメントは専門職」だと思ってます。
なんとなく長くその組織に所属しているからとかではなく、マネジメントができるようになるためには、知識を手に入れ、実践し、行動に対して起こった結果を振り返り、更にそのマネジメント技術を磨く必要があると思っています。

一方、プレイングマネージャーは、自らがプレイヤー、つまりエンジニアの場合、実際にプロダクトを作ることに関わる、要件定義・技術設計・コードを書くといった、いわゆるエンジニアリングの仕事を継続しながら、EMとしても振る舞う、といったスタイルです。

前職では、自分を含め「EM振る舞いをしていた人たち」は、「結果を出す組織を作るマネージャー」として、特にピープルマネジメントの部分だけを切り出しても目標設定・評価・1on1・その他起こりうる様々な出来事への対応などがあり、そのうえ他の専門職でプレイヤーとしてパフォーマンスを出しながら片手間でマネージャーとしてもパフォーマンスを出すというのは非常に難しい、というか無理と思っていました。

今回のスタフェスは、それとは異なる組織づくりをしてきました。その理由は明確で、リソースが限られていたからです。
しかし、単にリソースが起因だとしても「このサイズの組織が今うまく行くためにはどういう方法をとると良いのだろう」を実践してみようと色々考えてやってみた結果、今の「全員プレイングEMを中心に組織を作る」に行きつき、うまくワークしているのでは？と感じています。

プレイングEMを中心に組織を構成する良さ

これは、EM専業になったときに常に出てくる課題との逆なのですが、

• ドメイン知識が常にアップデートされ、課題に対する意思決定が的確

• 技術面におけるメンバーとのディスカッションがしやすい

• 技術課題と経営課題のバランスを取った目線で動きやすい

特最後のところが重要だな、と思うのですが、マネジメント中心に寄っていったときに陥る罠のひとつに「抽象的に考えるといろんなことが簡単に見える症候群」というのがあります。
自らがエンジニアリングでコードを書かないと、現場で起こっている現象を抽象的な事象として捉え、「こうすれば簡単では」という安易な発想に陥りがちだったりします。
これは、CTOとして気をつけることの1つでもありつつ、すべてのEMが各所で陥りがちなやつだと思っています。

そして自分はその罠にはまらない状態を「現場感がある」と表現しています。
加えて、日々CTOやVPoEと会話するなかでEMの経営目線での視座をあげていくことで「現場感 x 経営視座」の中での意思決定をし易い状況をつくれるのではないかと考えています。

自律した組織というのは、つねに経営からメッセージを発したり指示をするようなマイクロマネジメントをしなくても、ビジョンに向かって自分たちのやらなければいけないこと・やるべきことを定義して率先して取り組み、課題があったら解決し、経営課題としてとりあげるべきならアラートをあげる、ということが行われる組織です。
この「現場感 x 経営視座」のEMが、こうした自立した組織運営に必要な要素だと思います。

プレイングEMで組織を作るためのポイント

とはいえ、EMを一度経験したことのある人なら、プレイヤーとマネージャーを両立することの難しさは知っていることでしょう。

コレに対するポイントは1つだけで「EM配下メンバーの人数を減らす」だけです。

これは、今年↓のスライドにも掲載したのですが、このスライドから半年たった現在、EM配下2〜3名のメンバーがほとんどの状況で動いています。

そして、EMを増やすために必要なことは、

• ちょっと早くても任せられる人にどんどん任せる (たとえばメンバー1名とかで始めてもらう)

これを繰り返します。早めに動き、EMを任せる人を増やしていくことで、20人くらいの部下をもってパンクしたEMから引き継いだEMが初手で10人のマネジメントをしている、といった、パンク悪循環状態を防ぐことができます。
車でも、1つのタイヤがパンクすると他のタイヤに負荷が高まり、パンクのリスクが高まります。パンクするまえに空気圧をチェックし、日常の点検をすることが重要です。

まとめ

と、いうわけで、どうやって経営視座をインストールしつつ現場感を失わないEMと一緒に自律した組織を作っていくんだっけ？という話をしました。

組織の形は会社や構成するメンバーによってあったものを色々試してみる必要があると思いますが、どうもピープルマネジメントばかりに追われてしまうな、エンジニアリングの現場とちょっと距離離れちゃったな、コード書いてないな、といった課題があれば、EM専業とは別の形をとってみるのも、1つ問題解決につながるかもしれませんよ。

メリークリスマス (まだ25日目の記事が残ってるなァ🤔)