スタートアップ1人目EMが1年でやってきたこと
こんにちは、ログラスでエンジニアリングマネージャー（以下EM）をしております飯田です。
昨年12月にEMをはじめましたという記事を書いてから早くも3Qの月日が流れ現在4Q目を過ごしています。
私自身は前職でも現職でもエンジニア→EMというキャリアとなっており、現職ログラスでも1人目EMとして立ち上げを行ってきました。
当時EM取り組むにあたり、掲げていたことがいくつかあります。ざっくりまとめると、
エンジニア ⇄ EMで必要であれば柔軟に行き来できるようなフレキシブルな組織を作りたい
スタートアップの初期フェーズから盤石なマネジメント基盤を作りたい
長期でパフォームし続けられる組織を作りたい
です。
この記事ではこの3Qの中で取り組んできたことと、それによって上記のやりたかったことに近づいたのか？をご紹介できればと思います。
スタートアップのマネジメントのスケールに悩んでいる人（EMに関わらず）には関心を持っていただけるテーマかなと思いますので、質問・感想などあればぜひTwitterなどでコメントいただけるとうれしいです。
やってきたこと
チーム分割
まず、EMになった2021年11月は大きな変化が2点ありました。
それまで1チームだった開発チームを2チームに分割
これに伴い、開発組織内にチームリーダーを設置
自身はまだ手を動かしつつ徐々にEM業の比率を増やしていく
ログラスはそれまでは1チームのスクラムチームで1年の間開発してきました。1チームの中で徐々に人が増えてくる過程で機能横断的なチームを作る取り組みをしたり、ペアプロ・モブプロで業務知識を浸透させたりするなど様々な改善を行ってきました。
しかし、2021年11月時点ではエンジニアが9名の体制になっており、1つのスクラムチームとしては限界を迎えていました。
そこでPros/Consを丁寧に言語化し、チーム分割を行いました。
チーム分割したタイミングでチームの外から横断的にチームを支援する役割が必要でありこのタイミングでのEM就任はほぼ必然でもありました。
また、チーム分割を行ったタイミングで新しく部門に閉じた役割として2名のリーダーを配置し、それぞれの役割などをすり合わせながらチーム組成を行ってきました。
チームリーダーの設置
チーム分割やリーダーの配置についてはどんな会社でも遅かれ早かれ取り組むことになる課題かと思います。
このリーダーの置き方については、振り返ってよかったと感じることが2点あります。
1チーム→2チームという最小の分割で新しくリーダーを任命できたこと
創業後2年程度でこのようなマネジメント構造の導入にトライできたこと
あくまで一般論ですが、いきなり複数チームに分割する場合だったり、上場直前になってトライするようなケースを考えると今の何倍もハードルが高かったであろうと思います。
ある程度組織が大きくなってからでは、チームひとつをまとめるにも色々と難易度が高い状態になっているためリーダーとしても成功体験を積むことが難しい状況になっているはずです。
EMをスケールさせることも非常に難しいことではあるのですが、それ以前にやらなければいけないのがリーダーのスケールです。
人が増えていったとき、リーダーを中心にチームビルディングを行い、目標に向かってチームの足並みを揃えていくことになります。組織のスケールにおいてはこのプロセスの再現性を上げていくことが最も重要で、そういう意味では初期の2チームの分割時のリーダーは実はとても重要なミッションを負っていました。
リーダーは役割であり、上下関係ではない
マネジメント関連の本を読むとたいていこのようなことが書いてあると思います。
理想論としては理解できますが、実際の組織でそれを実現するにはどうしたらいいでしょうか？
ログラスの答えは「リーダーを担った者が後任を育て、継承していくこと。そして、自身がリーダーを外れても、それが降格ではなくただのバトンタッチであることを証明すること」です。
これを実現するにはリーダーをやりきったと言えることが必要ですので、実感を持ってまで時間のかかる取り組みになります。
しかし、いくらマネージャーが口で役割だよ、上下ではないよと言っても、実績がないことにはなかなか難しいところでしょう。
この顛末がどうなったか？は後半でお話します。
CTOとの業務の棲み分け
EM就任直後ではそれぞれで以下のような言語化を行っていました。
CTOの取り組むべきこと
非機能要件の具体化、組織上の優先度を適切に上げるための情報を生み出す
経営戦略をエンジニアリングの視点で透明化し、エンジニアに伝えること
生産性を上げること。資金によって生産性を上げる、時間を買うアプローチを支援する、開発チームが改善できる領域を広げつつ、領域外について取り組む
その他、開発チームだけでは解決できない機能、意思決定を行う
EMの取り組むべきこと
チームで決められないことを決める
人事に関すること
特にチームの目標の評価に関わる部分についての調整など
チーム間の足並みを揃える場の設定
キックオフとか、フォーマットとか
会社の仕組み上必要なマネジメント機能
チームの支援
上記を実現するための技術研鑽
ざっくり言うとCTOは経営視点での戦略に関する意思決定、EMは組織マネジメントおよび組織に関する意思決定と棲み分けました。このフェーズではCTOがマネジメントにフルコミットする会社もあるかと思いますが、ログラスはマネジメントの大部分は権限委譲してもらい取り組んできました。
等級制度の導入
ログラスでは私がEMになるまで、人事制度の策定は経営陣を中心に進められていました。またOKRの運用や、評価・報酬まわりの運用も始まっていました。
EM就任時、全社としても1人目のマネージャーだったので評価などを引き継ぐのも最初の取り組みとなりました。ここで困るのはこれまで経営陣の中で議論されてきた評価の基準などをどのようにスケールするか？です。
特に評価を引き継いでいくにあたり、様々なケースでの基準のすり合わせが必要になります。
Aさんの成果XとBさんの成果Y（成果Xとは別軸の成果）のどちらを高い評価にすべきか？
Aさんの成果XとBさんの成果X’（成果Xとほぼ一緒）のどちらを高い評価にすべきか？
・・・
これらを議論しやすくするためには共通のモノサシが必要になります。それが等級制度です。
等級はそれぞれのメンバーにどのような期待がかけられるのか？を等級別に言語化したものです。つまり成果の評価の前にそもそもベースとなる期待値があります。評価はその成果が期待を上回ったのかどうか？をもとに議論されていきます。
等級制度自体は本来であればHR側で主導していくものだと思いますが、当時は全部署において非常に高い採用目標が掲げられており、採用の体制整備とアクション実行が喫緊の課題となっていました。
したがって、経営陣以外のマネジメント運用の主体者として等級制度策定の推進を担わせてもらい、HRメンバー、経営陣にレビューいただくような形で策定を進めてきました。
最近ですとEM経験者がHRになるケースも増えてきました。実際私自身も前職では開発組織の執行役員をやりながら人事部門に半分籍を置いて活動していたこともあり、よくある流れの中で取り組むことになったな、という感想を持っています。
他社のヒアリングもさせていただきましたが、エンジニア出身の人事（ジンジニア）のつながりも非常にありがたい存在でした。
結果としては半年間かかりましたが、様々な方のサポートがありなんとかこのフェーズを走れるだけの初版の等級制度を作ることができました。この場をお借りして感謝申し上げます。ありがとうございました。
とはいえまだ課題は残っており、全社共通で抽象的な要件になっているところを各部署で詳細化していくことや、等級と紐づいた給与レンジの調整等、運用する中で出てくる課題がまだ残っています。
現在はHR側の体制も強化されたのでリードはHR側が主導しつつ、制度を運用する立場として解像度高く改善を進めていきたいと思っています。
採用活動
この3Qは足元のプロダクト組織の整備、全社でのマネジメント体制の整備に加えて、採用活動にもフルコミットしてきました。前述のとおり、HR側も最大限採用に集中してもまだ足りないというくらいの状況でした。
個人としてもこれまでの人生でも採用活動はたくさんしてきましたが、全然ぬるかった・・と思わされるほどでした。
エンジニア採用の責任者として取り組んだ具体としては、採用目標に対しての必要なカジュアル面談数やスカウト数などを可視化して追えるような体制整備を整えました。
当初はCTOの狂気的なコミットメントによりエンジニア採用の大半の成果が生み出されていましたが、その役目を私が引き継ぎいったん全員で満遍なく追っていけるような体制を構築しました。その後さらに別のメンバーに引き継いだことによって大幅な効率化が実施され、現状ではかなり安定的な体制に収束したと思っています。
その成果もあり、現在では開発チームが3チーム体制となるまで拡大することができました。
ログラスは今も全員での採用活動を続けています。
根底には一緒にプロダクトを作る大事なメンバーなのだから自分たちで採用活動を行うという考えがあると思っています。
スカウトの文章を書くのが初めてで慣れない、といった話は当然あるのですが、結局はレジュメをどう読んで、どんなアトラクトをするのか、他人任せにせず自分で考えることでチームに対しても自分で動かしている感が生まれるのだと思います。
こちらも世代交代をしながら継続して試行錯誤を重ねていきたいところです。
開発組織を強くする中長期を考える取り組み
ログラスにはレヴェリーという謎の会議があります。
元々は全社でやっていた取り組みで、全員で中長期のことを考えようというものなのですが、これを部門のほうに持ち込みました。（ワンピースの世界会議からきているようです。）
その時々で目の前の業務とはちょっと視点の異なるテーマを扱い、みんなで議論することで視座を上げるような取り組みをしています。（例えば私たちは今は現在リモートと出社のハイブリッドですがフルリモートになったら何が起きるか？や、IPOしたときのことを想像して、その前夜に何を考え過ごすのか？など）
普段の業務から離れてちょっと先のことを考える時間を取るということは個人的に思い入れがあり、部門単位でも実施したいと考えEMになってからエンジニア組織でも始めました。
例えば、評価が終わった後にいい評価とは？悪い評価とは？を全員で考えてみるといったことをしたこともあります。
この場の目的としては2点あり、
EMとメンバーのコミュニケーション
EMの考えていることを伝える
EMの関心ごとをメンバーにも考えてもらう
メンバー同士のコミュニケーション
答えの異なるものでも共有して理解を深める
といったものです。
もちろん長期に対しての明確なアウトプットを求めることもありますが、どちらかというと話して視点を合わせたり視点の違いを理解することに価値を見出しているところがあります。
マネジメントのフィードバックサイクルを回す
現在開発チームは毎スプリントでスプリントレビューを実施していますが、これをEMの業務についてもやったほうがいいのでは？という意見をもらいエンジニア組織マネジメントSprint Reviewを実施しています。
まだ開始してから日が浅いのでログとしては少ないですが、EMの仕事は油断するとすぐ何しているかよくわからない人になってしまいがちなので、このような場を作っていくことで理解しやすくなるし、フィードバックも可能になるため透明性がぐっと上がったように感じています。
EMの後継者
さて、これまで色々と取り組んできてそれなりに成果と言えるようなアウトプットも出せたのではないかと感じていますが、これを1人でやり続けることは組織にとって非常にリスクであり2人目EMを立てることが喫緊の課題でした。
CEOとの1on1でも早めに手を打っていかないとまずいということを何度も話してきました。
そして・・
2人目EMとして勝丸さんが就任しました
こちらの記事で最もお伝えしたかったことがこちらです。ついにEMが2名体制になりました！🎉
これまで3Q分を1人で走り続けてきましたが、3チームのエンジニア組織を1人のEMでみていくことは不可能です。
採用と既存メンバーへの打診と並行して検討してきましたが、現状はまだマネジメント領域についても荒地のような状況なので、ある程度歴史的経緯がわかっているほうが体制の安定化には近道であろうと考えました。
そこで直近でリーダーを経験してきた勝丸さん(@shin1988)への打診を行い、快諾いただきました。
勝丸さんがどんな人か？はこちらの記事をぜひご覧ください。
2人目EM就任までの難しさ
ログラスではこれまでEMとして長期で取り組んだ経験のあるメンバーは私以外にいませんでした。したがってEMとは未知の役割であり何をするのか？からすり合わせる必要があります。
難しい点としては、そもそも打診を受けてもらえるか？からハードルが高いということがあります。よくわからない役割というだけでハードルが高いというのに、これまでの私の動きによってネガティブなイメージが大きくなってしまっていたら打診すらも難しかったと思います。
逆に良い点としては、EMをこれまで経験したことがないメンバーが取り組んでいくことによって自分が既に当たり前と思ってしまっている暗黙知的な考えや業務を言語化するいい機会になるという側面もあります。これによりさらにEMが理解しやすいものになり再現性が向上していくと良いなと思っています。
組織の新陳代謝を戦略的に生むこと
ここまでの話を読むと「あれ、リーダーは上下関係じゃないって言っておきながらリーダーからEMになるのはリーダーじゃなくなったけど実質上にいっただけっぽいな」と思うかもしれません。
これだけではありません。
実は同タイミングで勝丸と同じく3Q分リーダーを担ってきた佐藤ゆいとさん(@Yuiiitoto)がリーダーを後継者に渡してイチチームメンバーに戻っています。
これによってリーダーが役割であるということを証明できたと思っています。
チームリーダーを設置し、それぞれのチームリーダーがワークすること
チームリーダーからEMになる人が出ること
チームリーダーからメンバーに戻る人が出ること
それぞれのチームでチームリーダーの後継者をつくれること
2チームから3チームに増えた時にもすべてのチームでチームリーダーが存在すること
リーダーシップの重要性を実務経験をもとに語れる人が複数人存在すること
以上がこの3Qで組織として取り組めたことです。
全体の開発プロセスはまだまだ課題はたくさんあるのですが、まずはチームが存在し続けられることが大前提です。チームが存在すれば少しづつでも改善は進んでいきます。逆にチームが崩壊すれば改善どころではありません。
このような組織の新陳代謝を少しづつ生んでいくことで組織が成長していけるのではないかと考えています。
極端なことを言うと自分がEMを外れることも一つの新陳代謝だと思います。自分しかできないものというのは本当にごく僅かなもので、大半のことは誰でもできるしこのポジションは自分じゃないと務まらないというのは大抵の場合過信か属人化排除を怠っているだけかと思います。
そう言うわけでいろんな人がチャレンジ可能なフレキシブルな組織運営を理想としています。
今後取り組んでいきたいこと
現状の課題は、組織全体の同期的なプロセスとチーム個別の局所的なプロセスの最適な切り分けが道半ばであるということが大きな課題だと思っています。
もっと簡単な言葉で言うと、まだ1チーム時代のプロセスを引きずってしまっているところがあるように思っています。もっとチームに権限を渡し、チームでの意思決定を促し、チームにナレッジをためていくことで全体のアジリティも高められるのではないかと考えています。
チームの独立性を高めるとEM的には「全体の方向性として正しい方向に向かっているのか？」を判断する難易度は上がりますが、それでも個々のチームの自治をより強化していくフェーズに入ったなと感じています。
翻訳レビューに参加させていただいた「エンジニアリングマネージャーのしごと」をご恵投いただきました。
— Yoshiki Iida / ログラス (@ysk_118) August 20, 2022
マネジメント系の本は抽象度が高いものも多いですが、この本はとても実践的な内容になっており日々の業務で迷った時にも助けてくれる本です。
初めてチャレンジするときに欲しかった！ pic.twitter.com/9O9ZSaFAS8
ちょうどいいタイミングでいい感じの本も出たので組織としてもしっかりナレッジをためていければと思っています。
We are hiring!
最高のチームで最高のプロダクトを作りたい人、最高のプロダクトを作るチームをチームの外から支えたい人、どんな関わり方もWelcomeです。
ログラスのマネジメント体制も絶賛進化していっている途中ですので、ぜひカジュアルにお話ししましょう！
この記事が気に入ったらサポートをしてみませんか？