スタートアップ1人目EMになって 最初にやったこと / The first step of EM

Transcript

1. 2022/10/06 ログラス x asken エンジニアリングマネジメント勉強会 「EMになって最初にやったこと」 #EM勉強会 Yoshiki Iida スタートアップ1人目EMになって 最初にやったこと
2. Yoshiki Iida (@ysk_118) エンジニアに始まり、スクラムマスター、プロダクトオーナー、マネージャー、執行 役員を経験し、現場のチームビルディングから部署を超えた会社全体の改善な ど、アジャイルな組織づくりの推進を行ってきました。現在は株式会社ログラスに てソフトウェアエンジニアとしてプロダクト開発に携わっています。最近またエンジ ニアリングマネージャーもはじめました。 書籍「Scrum Boot Camp The Book 増補改訂版」コラムニスト。 一般社団法人アジャイルチームを支える会 理事。 Profile
3. ログラスについて 　　　　　　は事業進捗を正確かつ迅速に可視化することで、 柔軟で高精度な経営推進を実現する経営管理クラウドサービスです。
4. ログラスについて
5. ログラスについて
6. ログラスについて https://note.com/loglass_post/n/n6f216efd31c3
7. • 最初にやったこと • やった結果どうなったか？ • 結果の考察 今日話すこと
8. 最初にやったこと
9. 最初にやったこと https://note.com/ysk_118/n/n845938325243
10. • 定義フェーズ ◦ 自分を定義する ◦ 取り組むことの言語化 • 実行フェーズ ◦ 行動で示す ◦ EMを説明できる人を増やす ◦ 後継者をつくる（ことを想定して行動する） 最初にやったこと
11. 自分の役割、責務を言語化し、 組織に説明する。 ログラスにおけるという コンテキストが重要。 一般論を書くだけでは 必要性の温度感が上がらない。 自分を定義する
12. • 1チームから複数チームへ • 人事評価制度の開始 • マネジメントのスケール ◦ 経営陣からそれ以外の人への委譲のトライ ログラスにおいては問題解決能力の高いメンバーが集まっているため、 マネージャー不要論が巻き起こってもおかしくなかった。 自分を定義するといってもこのフェーズで必要性を理解しきってもらうことは 不可能なので、実行フェーズで示していくことになる。 ログラスにおいてなぜEMが必要だったか？
13. 先を見据えて何が起きうるか？どんな 打手があるか？今まず何をしていく か？を最初に言語化した。 戦略レベルのものでなくとも、何に取り 組もうとしているのか？どうなったら成 功と言えるのか？は言語化して周囲に 説明しておきたい。 取り組むことの言語化
14. • 活動 ◦ 会議体の運用 ◦ 1on1 ◦ エンジニア組織としてのまとまり ◦ モメンタムを出す • アウトプット ◦ ポエム ◦ 外部発信 行動で示す
15. 人が増えてくるとコミュニケーションが非同期 化したり疎結合化する部分が出てくるため組 織の全体感を捉えにくくなる。 全員で何かを議論する場をゆるく運用していく と良いだろうと考え、中長期テーマを扱う場を 作った。 エンジニア組織としてのまとまり noteにも書いています。
16. モメンタム（勢い）を醸成することが大 事。 採用活動など開発以外のミッションでも きちんとEMが活動をリードし、現場を巻 き込んでいく。 そして盛り上げるところを盛り上げ、前 に進んでいる感じを出していく。 モメンタムを出していく
17. EMの頭の中を言語化したもの。 生煮えの状態でも「こういうことを考えて いるぞ」をとにかく出す。 論理も大事だが、文章に思いを乗せる ことが重要。 ポエム
18. 定義を行い、行動した結果と して周囲の人は何をやる人 なのかわかってくれたの か？を検証する必要があ る。 初回は定性アンケートをとっ た。 EMを説明できる人を増やす
19. EMを説明できる人を増やす - 開発チーム以外で巻き込みが必要な場合に、サポートしてくれる and リードして いってくれる職種 - 開発組織作りや言語化をしてくれる - 技術的(OKRの目標の)リード or サポートしてくれる 組織の成果最大化にコミットする人。 組織（チームまたぎ）の成果を最大化するために抽象度の高い課題設定をする人。 メンバーの評価権利を持っている人 どうしても責務を抽象的に捉えてしまっており、具体的に何する人なの？をうまく説 明できないなと感じます。 チームのパフォーマンス最大化する役目を追っている。 経営陣との接続だったり、組織課題 の定義と解決を行なったりしている。特に組織課題の定義が重要だと思っている。 開発物が定められている状況では、開発物に対する問題はボトムアップで取り扱われるが、 組織全体への課題はボトムアップでは設定されにくい構造があると思う。 定期的に現在の組織に対する問題設定をして投げかけてくれるのはありがたい 。
20. EMもといマネージャーは会社のスケールにおいて 最も重要な役割を持っている。一方で、属人化しや すく組織のボトルネックにもなりやすい。 初期の設計や取り組みを間違えるとスケール自体 が非常に困難になるため、属人性を大きくしないよう に意識しながら後継者探しを行う。 マネージャーの要件に後継者育成を含めるレベル で意識すべきもの。 後継者をつくる
21. やった結果どうなったか？
22. 組織構造の変遷 EM TL TL EM TL TL EM M TL EM TL TL TL EM 1EMが2チームのリーダー とコミュニケーション • リーダーからEMになる人が出てくる • リーダーを交代し新しいリーダーが立つ • 3チーム目ができる M 2EMが3チームのリーダーと コミュニケーション CTO CTO CTO
23. 1EM、2チーム時代は組織全体の決定をするにも合計 3人で話して具体の方針を決め CTOと合意すればよかったのでコストが小さかった。 2EM、3チーム時代になると、5人＋アルファとなり、合意形成のコストが爆上がりした。 チームでの独立性が高まり、リーダー -EM間の認識合わせのコストも大きくなったし、 EM-CTO間のすり合わせもコストが上がった。 組織拡大に伴うオーバーヘッドの増大
24. リーダーの責務がマネジメント寄りになっている説
25. 結果の考察
26. • 意図 ◦ 過去の経験からEMがあらゆるものを巻き取ってしまう状況・構造は回避したかった ◦ 組織マネジメントに関する課題を EMの関心ごとに閉じるのではなく、 組織全体の関 心ごととして捉えられるようにしたかった • 実装 ◦ リーダーには成果が最大化されるようにチームを取りまとめてもらう ◦ EMとの接点はリーダー ◦ EMの業務を近くで知ってもらう＋リーダーシップの経験 を積んでもらうを両立できる ようにする 初期の設計思想
27. • まだまだ組織としては若いフェーズのはずなのに、チームやロールの枠が際立っ てしまい、意思決定コストが増大した • リーダーの継承が行えたことは良かったが、 スケールしたことによるオーバーヘッ ドを考慮して責務のアップデート が必要だった ◦ 現在の人数規模で3階層コミュニケーションはデメリットの方が大きい ◦ EMがもっとチームの中に入っていき目標やピープルマネジメント部分のグ リップが必要だった • 一方チームよりも抽象度の大きい戦略的な議論 も取り扱わなければならず両立 が難しい ふりかえり
28. • EMがチームと近い距離感で業務をしていくことは非常に重要ながらも、 組織全体 の戦略や、会社全体の戦略の議論に関わるなど、抽象度の高い業務 も実際には 存在する • チームの内部の詳細な課題と組織全体の課題のコンテキストスイッチ がEMに とっては大きなハードルとなる • EMチームの内部でも扱う抽象度によって階層化するか、複数人 EMがいる場合 にはPJごとに担当を決めるなどで推進しやすくなる ◦ しかし、人数が少ない場合には組織がスケールすると負荷が指数関数的に 上がりボトルネックになってしまう EMの仕事の抽象度について
29. 抽象度低い • 個人の目標 • スプリントバックログ • 機能の実装方針 • チームのワーキングアグリーメント • チームの雰囲気づくり • チーム内のプロセス改善 • 短期の戦術（機能など） • 局所的な議論 EMの仕事の抽象度について 抽象度高い • プロダクト組織全体の目標 • プロダクトロードマップ • 機能のニーズ • 会社全体の制度設計 • 会社のカルチャー・バリュー • 組織の横断的なフロー整備 • 長期の戦略（ビジョンなど） • 俯瞰的な議論
30. もう少しブレークダウンすると、 • 時間軸 • How-What-Why • 組織の影響範囲 などの軸がある。抽象度が高いとは、 より長期で、より大きな影響範囲を持ち、なぜそ れをやるべきか？というモチベーションの起点となるようなもの を取り扱う傾向がある。 EMの仕事の抽象度について
31. 組織構造の今後 EM TL TL マネジメントについては CTOから権限委譲を進め てきた EMチームが厚くなり成熟してくれば 再度階層化したほうがROIが合うよう になるかも CTO CTO、EMからなるマネジメントチー ム チーム チーム チーム EM EM EM チームとのコミュニケーションを 2階層にしてアラインメントしやすくす る EMチーム チーム チーム チーム EM EM EM CTO,VPoEなど 技術経営チーム
32. • 初期フェーズからマネジメント体制を整備してきたが、一部早すぎる最 適化があった ◦ 特にスケールに対して責務が追従しないケースがあるので、ふり かえりやメンテナンスが重要 • EM業務の幅広さについてはもっと認知拡大や体系化が必要 ◦ 知ってたけど改めて・・ まとめ