はじめに

こんにちは！EventHub CTOの井関です。

これは EventHub Advent Calendar 2024 の24日目の記事です。昨日はCorpIT/RevOpsマネージャの横山さんの 2024年は、私の筋トレ元年でした。そちらもぜひご覧ください！

今年は、普段人前に出るのが苦手な私が人生初のピッチイベント(CTO of the year 2024)に出場することになりました。これは、人事の磯さんのサポートのおかげです。イベント当日の内容については、ログミーさんが記事にまとめてくれていますので、興味のある方はぜひご覧ください！

logmi.jp

ピッチは6分間という限られた時間内で伝えたいことを絞り込む必要があり、内容を省略する作業は非常に難しかったです。今回は、その中でも特に省略した「マネジメント体制」について詳しくまとめたいと思います。

現在EventHubでは14名のエンジニアで4つのチームを組成しています。

各チームのマネージャにはプロダクト・テクノロジー・プロジェクト・プロダクトマネジメントの4つのマネジメント領域全てを任せる構成をとっています。

なぜ、このような体制をとったのか事業面・組織面に関しては伝えたことがありますが思いの部分をあまりまとめたことがなかったので、その点を今回はまとめます。

ピープルマネジメントの壁

創業初期は代表の山本と二人で創業したため、肩書はCTOでありながら1人で設計から実装までの全てをこなすような体制でした。

最初は資金が少なく、正社員を雇う余裕もなかったため、業務委託を中心にエンジニアを少しずつ増やしていきました。そして、次第にプロダクトマネジメントやプロジェクトマネジメントなどの領域も私が担当するようになりました。事業が成長するにつれて、エンジニアも増え、ピープルマネジメントの必要性を感じ始めました。しかし、この「人をマネジメントする」ことは予想以上に難しく苦労しました。

この壁を乗り越えようと、知り合いや紹介してもらったCTO・EMの方々10人ほど話を聞いたのですが、それぞれの意見がまったく異なっていて、逆に悩みが深くなりました。

階層構造を作らずに50人ぐらいまではCTO一人で組織を見た方が良いという意見があると思ったら、早い段階で構造化し組織を分割すべきという意見もありました。CTOはコードを書かずに組織設計に回るべきという意見もあれば、CTOが率先してコードを書き方針を示すべきという意見もありました。

どの方も現職で成果を出していたのでどれも正解なのは間違いないとは思いますが、事業・組織、そしてCTOの思考によって全く逆の方針をとっていることもあり驚きました。ただ、全員が一貫していたのは自身で考え抜いて経験を重ね今のスタイルを構築したことが分かり、単に数時間ヒアリングしただけの自分が見よう見まねで取り入れても成果につながるような単純なものではないことも思い知らされました。

壁の乗り越え方

組織を成長させるためには、私自身がピープルマネジメントのスキルを身につけることが必要でした。しかし、スキルの向上と組織の成長のペースが一致せず、スキルが追いつかないという現実に直面しました。

そのギャップを埋めるために、代表のりえさんにサポートを頼んだり、チームメンバーに支えてもらいカバーしてもらうこともたくさんありました。ピープルマネジメントを一人でこなすのは難しかったですが、周りの力を借りて自分の得意領域で成果を出しながら進めることができました。

周りに支えてもらい苦労しながらの挑戦でしたが、少しずつスキルを身に着けたことで見えた景色は大きく変わりました。ピープルマネジメントのスキルが身についたことでプロダクト・プロジェクトマネジメントにまつわる業務での動きに影響があったりと、各スキルが他の領域で生きる場面が多いことにも気づきました。

チームとしての成果を最大化するために

チームマネージャに求めている役割は端的にまとめてしまうとチームの成果の最大化です。

それを実現する方法はチームマネージャ自身の強みや志向性も影響しますし、メンバーの強み・志向性にも大きく影響します。そのため役割を限定してしまい、渡す権限が不十分になってしまうとその人にあった方法を模索することができず思うような成果を出せなくなってしまいます。

私がピープルマネジメントの壁にぶつかった時にテクノロジー・プロジェクト・プロダクトの領域から離れてピープルマネジメントだけに集中しなければならないという制約が課されていたら、相当しんどい状況になっていたと思いますし、どこかで挫折してしまったと思います。自分の得意領域を活かしつつ、周りの協力を得ながら足りないスキルを補填していける環境は創業者としての権限や信頼があったからこそ実現ができたものだと思います。

このような環境を創業者でなくても作れる要素は何かと考えてとった方法が4つのマネジメント領域を全て任せる形です。

マネージャという役割に関して

組織が成長してくためには、マネージャーの数を増やすことが重要です。しかし、これは単にマネージャの肩書を持った人を増やすことを意味するわけではありません。本質的には、チームや組織の成果に責任を持ち、そのために行動する人を増やすことが求められます。

二日前に岡本さんが記事の最後の方で エンジニアの「より良くしたい」を拡げる仕事 とまとめてくれてますが、これはまさに上のようなメンバーの割合を増やすための仕事です。

メンバーとマネージャの間には根本的には壁があります。任せられる領域・責任が広がることでどうしても求められるスキルなどは変わってきます。そのため、メンバーからマネージャになることは非連続で急な変化を求められてしまうものになります。

ただ、ここの段差が大きいとよりメンバーとマネージャの意識にも差が出てきてしまいもっとマネジメントに挑戦しづらい環境になります。誰しもがチームの成果に向き合い行動ができる環境を作り出すためには、メンバーからマネージャへの挑戦をよりなめらかで連続的にする必要があります。

メンバーとマネージャの段差をなめらかにすることで、少しずつマネージャに挑戦できる環境を作ることができ意欲がある方には少しずつひとつ上の業務に挑戦できる環境を作れます。また、挑戦したいメンバーが増えればチーム成果に責任を持とうと行動する方が増えてよりマネージャへの挑戦のハードルを下げることができ挑戦しやすい環境になります。

この状態を作るために4つのマネジメント領域全ての権限を渡せる環境を作りました。

一見すると4つのマネジメント全てを求めることは何でもできる万能人間しかマネージャになれないというようにハードルを上げてしまっているように見えますが、駆使できる能力の幅を広げることでむしろ挑戦するハードルを下げることができます。