エンジニアリングマネージャーはじめました(2周目)
こんにちは、ログラスの飯田です。
この記事は Engineering Manager Advent Calendar 2021 の9日目の記事です。
1年のふりかえり
1年前以下の記事を書きました。
この1年を振り返ってみると、
・コードを書くこと8割
・採用を中心とした組織的なこと2割
といった割合で結果としてはエンジニアリングに向き合えた1年だったかなと思っています。
とにかく手を動かしながらプロダクトを作っていくことに集中できたことは本当に取り組めてよかったです。
何よりほっとしたことは、「自分は2年現場から離れていても戻った時にはエンジニアとしてバリューを出せる」と思えたことです。これは私が転職の際に向き合わなければいけない最も大きな恐怖でした。
実際に1年の中でいくつか大きめの機能開発のリードを任せてもらえたことでそれは完全に払拭されました。
さて、ログラスは幸いにも採用が順調に進んでおり絶賛組織拡大していっている最中です。エンジニアについても2チームに分かれて開発をしてみるというくらいには大きくなりました。
結論から言うと11月から徐々にエンジニアリングマネージャー（以下EM）業を再開しています。
エンジニア戻ったんやないんかい！というつっこみもありそうですが、上に書いた通りコードを書きたくなったらいつでも戻れる、と思えたことが非常に大きく、今は組織をスケーラブルにしていくため自分の経験してきたことを全方位で出力していくことに興味が大きくなっています。
現状はまだチームに属しながらEM業を回していますが、そのうち手を動かさない時期があってもいいし、逆に手を動かしたくなったら動かせるような組織設計をしたいと考えています。
2周目のエンジニアリングマネージャー、そして1人目ということでその意思決定の背景といくつかチャレンジしようと思っていることがあるので紹介しようと思います。
なぜEMを引き受けたか
私がログラスに来た目的のひとつに現場でエンジニアリングに向き合いたいという目的がありました。
EM業というのは直接手を動かさない仕事も増えていくので目的からは逆行するところもあるわけですが、そもそもなぜ現場でエンジニアリングしたかったかと言えば「持続的な開発組織を作りたい」「そのために課題の解像度を上げて意思決定したい」という根源的なモチベーションがあったからでした。
しかし、やってみると意外と普通に手を動かせるところもあり、また過去に蓄積してきた経験が生きた場面もありました。
そこで「あれ？これ自分が手が動かない、手を動かさないといけないと思い込んでいただけだったのでは？」と思うようになりました。
つまり、何かの意思決定をする際に解像度が足りなければ手を動かせばいいじゃん、そうでなければ他の人に任せてもいいじゃん、というシンプルな考えです。
では、そういうフレキシブルな組織を作ろう、ということでEM業にもう一度向き合ってみることにしました。
なぜスタートアップにEMが必要なのか？
スタートアップのアーリーフェーズではマネジメントが大きく求められることはありません。練度の高いメンバーであればあるほど個々がうまく協調しあって連携していくためマネジメントが課題として顕在化することがそもそも少ないです。
しかしながら、チームの人数が10名を超えてきたあたりで1チームではやるには人数が多過ぎて議論がまとまりにくくなるなどの問題が出てきます。
そうすると、チーム分割などを検討し始め、それぞれのチームが追うミッションを全体最適でどうバランシングするか？やそれぞれの成果をどう評価するか？などを考える必要が出てきます。
今でこそEMというロールが一般化されてきた感はありますが、シードフェーズからEMを置く会社は少ないのではないかと思います。
しかし、このような組織の設計は、システムにおける「テストがあること」や「リファクタリングの文化があること」と同レベルで重要なことだと思っています。
テストがない巨大なアプリケーションに途中からテストを書いていくことが非常に難しいように、組織が大きくなってから制度を作って導入することはとても難しいものとなるからです。
なので、このフェーズから組織基盤を整えていくことは将来の組織のLTVを向上させることに繋がると考えています。
ロールの存在理由と関心事と責任範囲
EMをはじめていくにあたり、ログラスのEMとは現時点では何をする人間なのか？を言語化していくことにしました。
これを元に各メンバーと対話していきながら今やるべきことにフォーカスしていくということを進めています。
また、EMを置くことでCTOとの棲み分けはどうするのか？という疑問も出てきます。
これについても以下のように責務の言語化をアップデートしていくということを進めてもらっています。
やらなければいけないのは、クラスの責務を考える時のように、そのロールの存在理由と関心事と責任範囲を明確にすることです。
これをやっていかないとこれはどこにエスカレーションすべきなのか？誰に相談したらいいのか？ということがわからず余計に組織のコミュニケーションコストが発生します。
長期的にパフォームする組織を作るために
スタートアップはリスクをとって短期的に大きな成長率を作る手段ですが、うまくいった場合にはそのまま長期的に走り続けることになります。
スタートアップだから短期で攻める、のではなくスタートアップだからこそすぐ大きくなる可能性もあるわけで急激に大きくなってもその後長く走り続けられる仕組みを考えていく必要があります。
1個人にフォーカスしたときには、常に新しいことにチャレンジし続けられていることや、それによって常に成長実感が持てていることなどの要素があるとその会社で長く働くことができると思っています。
そのためには、何をすれば評価に繋がるのかやキャリアの選択肢の自由度があることが必要です。
そのひとつのモノサシとしては人事制度まわりの整備がありますが、これに限らず色々な足回りを今から整備していこうと思っています。
個人的なチャレンジとしては自分自身が長く働き続けられるようにするために、マネジメントと自ら手を動かしてエンジニアリングすることを行き来できる組織を作りたいと思っています。
これを実現するのは非常に難しいと思っています。
普通にやるとEMの責務は重くなりがちで、そうするとEMをやりたがる人も増えません。しかし、マネジメントが機能しなくなると組織もスケールしません。組織がスケールしないと（多くの場合）会社の成長も伸びません。
誤解のないように書いておくとプレイングマネージャーを良しとしているわけではありません。
会社や組織の全体最適のため、戦略的にマネジメントに振る、エンジニアリングに振るをうまく切り替えられることが望ましいという考えです。
結局大きな課題を目の前にしたときに、一観点だけでは足りず、抽象と具象を行ったり来たりしながら向き合う必要があるよね、ということに過ぎません。
一度大きな責務を持つとそこにロックインされがちなのですが、それをフレキシブルにすることでよりパフォーマンスを上げられるのではないかと思っています。
実現していくのは非常に難しい挑戦ですが、個々としてもエンジニア組織としても、最高といえるエンジニア組織を創っていきたいなと思っています。
ログラスでは、システムと組織を一体となって考えられるエンジニアを募集しています！
EMをやっていた人もEMに興味のあるエンジニアの方もぜひお話ししましょう！
この記事が気に入ったらサポートをしてみませんか？