組織の規模が大きくなったときにマネージャーは何を考えるべきなのか

アソビュー! Advent Calendar 2021の12日目です。

アソビュー!ではエンジニアリングマネージャーとたまにバックエンドのソースコードを書いている服部です。

はじめに

明日から急に今マネジメントしている人数の4倍の人数をマネジメントすることになったら。。。

今期より20名超のメンバーが所属するグループのマネージャーとなり、前期と比較すると約4倍の規模のマネジメントをすることになりました。

半年ほど経ってみて道半ばですが、「もっと早くからこういうこと考えておけばよかったな」と、振り返ってみると本当に当たり前のことですが、
今できていないことや今後やりたいことも含め、自分の気付きを書きます。

組織構造の変化をちゃんと捉える

前期までは4名という少数のグループだったので1チームでの開発でしたが、20名超を1チームでの開発となると、

  • 開発観点でのコミュニケーションパスの増加
  • マネジメント観点でのスパン・オブ・コントロール

によって生産性の低下が懸念されるため、チームを4つに分け、各チームにリーダーという役割をもつメンバーをアサインする判断をしました。

コミュニケーションパスの増加
4名チームの場合 : 6
20名チームの場合 : 190
スパン・オブ・コントロールについて
一般的に一人が管理できる人数は8~10人とされています。
両方に当てはまりますが、
アマゾンCEOのジェフ・ベゾスが提唱されている、2枚のピザを分け合える最適な人数であるべき「2枚のピザ理論」も有名です。

この体制にすることで、リーダーには各チームのメンバーのマネジメントを行ってもらい、私は各リーダーのマネジメントを行えばやっていける

と思っていたのですが、チームの構造が変化したことによる影響をちゃんと理解できていませんでした。

f:id:takayasu-hattori:20220405114831j:plain

1階層増えたピラミッド構造になっている。たった1階層ですがこれがもたらす変化は大きかった。

体制の構造変化をしっかり捉えられていれば、後述する自分の役割の変化や役割の変わったメンバーへのフォローがもっと早くできていたと思います。

自分の役割の変化に気づく

少数メンバーのチームをマネジメントしていた時の自分の役割としては

  • チームのスクラムマスター業務
  • バックエンドの開発者
  • メンバーの目標設定や1on1
  • 事業サイドとの打ち合わせ
  • etc…

を実施する、完全にプレイングマネージャースタイルでした。

ただ、組織構造が変わったにも関わらずこのスタイルを貫いた結果、

  • 開発面で自分がボトルネックになっている
  • 開発でボトルネックになっているという焦りにより、各種打ち合わせに対して身が入っていない

という、チーム全体の生産性を下げている状態になっていました。

これはチームの人数が増えたことによる1on1等の増加や、チームが増えたことによる事業サイドとの打ち合わせの増加、スケールし続ける開発を担保するための採用面談の増加等による
自分の開発に当てられる時間が少なくなったことに気付けていなかったため、起きてました。

この状態になったときに初めて「今のままでは組織崩壊につながる」と気付き、この人数とチーム体制になったときに自分の役割はなんだろう、と改めて考えました。

その結果、今の自分の役割は
開発をいかにチームに任せるか、そして各チームの生産性をどうすれば上げることができるのか
というところにようやくフォーカスできました。

腐ってもエンジニア、コーディングするのは好きですし楽しかったですが、これに気づけて自分が手を動かすということを良い意味で諦めることができました。

役割の変わったメンバーに気付く

体制が変わった事により、自分だけでなく明確に役割が変わったメンバーがいます。今回はリーダーに焦点を当てます。

今回複数チーム体制に分けたことで明確に「リーダー」という役割をお願いしたメンバーがいます。
全員バックグラウンドが違うので、前職や私と一緒に仕事するまでに経験したことがあることもないことも含め、下記のような業務をリーダーとして期待し、お願いしてました。

  • チームメンバーとの1on1
  • チームのスクラムマスター業務
  • 事業サイドとの打ち合わせ
  • etc…

新しい業務が増えたにも関わらず、「あとは頑張ってくれ」状態でお願いしてしまっており、私自身あまりフォローできてなかったなと感じてます。今回各人すべての業務をしっかりこなしてくれてました。おそらく各人が自分たちでインプットし、PDCA回してくれていた賜物かと思いますが、
本来であれば

  • いいインプット材料を伝える
  • ある程度ガードレールを引いたり、守るべきところは守ってあげる
  • 期待値の調整、権限移譲レベルの確認
  • 1on1での業務相談の深堀り

等のフォローをもっとすべきだったかと思います。

ここでは役割の変わったメンバーを例として挙げましたが、わかり易い例でいうと

  • 体制変更によるチームが変わったメンバー
  • 担当するプロダクトが変わったメンバー
  • 入社したばかりのメンバー

のような自分の状況や周りの環境が変化したメンバー(すべてのメンバーですね)にも同様のアプローチが必要です。

みんなにもっと頼る

自分で全部やらねば・把握せねば、という意識が強く、あまり周りに頼るということができてませんでした。

ふと我に返って見渡してみれば、仕様を詳細に把握している人、ソースコードを精確にかつ素早くかける人、人との対話が上手な人、優秀なメンバーが揃ってることを忘れていました。
実際頼ると本当にみんな心強い。自分で考えて多方面とコミュニケーションとりつつ業務やプロジェクトをしっかり終わらせてくれる。

業務を丸投げする、ではなくちゃんと頼ることで、能力向上やできなかったことをできるようになる、ということも大事なマネジメントの1つだと感じてます。

まとめ

まとまりのない感じになってしまいましたが、新米エンジニアリングマネージャーの私が半年で感じたやっとけばよかったこと、これからやらないといけないことをツラツラと書いてみました。

これからマネジメント業務に携わる・挑戦する誰かのちょっとしたより所になればいいなと思ってます。

最後に

アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています!ご興味がありましたらお気軽にご応募いただければと思います!