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

Transcript

1. 2022/10/06
   ログラス x asken エンジニアリングマネジメント勉強会 「EMになって最初にやったこと」 #EM勉強会
   Yoshiki Iida
   スタートアップ1人目EMになって
   最初にやったこと
   

   View Slide

2. Yoshiki Iida (@ysk_118)
   エンジニアに始まり、スクラムマスター、プロダクトオーナー、マネージャー、執行
   役員を経験し、現場のチームビルディングから部署を超えた会社全体の改善な
   ど、アジャイルな組織づくりの推進を行ってきました。現在は株式会社ログラスに
   てソフトウェアエンジニアとしてプロダクト開発に携わっています。最近またエンジ
   ニアリングマネージャーもはじめました。
   書籍「Scrum Boot Camp The Book 増補改訂版」コラムニスト。
   一般社団法人アジャイルチームを支える会 理事。
   Profile
   

   View Slide

3. ログラスについて
   　　　　　　は事業進捗を正確かつ迅速に可視化することで、
   柔軟で高精度な経営推進を実現する経営管理クラウドサービスです。
   

   View Slide

4. ログラスについて
   

   View Slide

5. ログラスについて
   

   View Slide

6. ログラスについて
   https://note.com/loglass_post/n/n6f216efd31c3
   

   View Slide

7. ● 最初にやったこと
   ● やった結果どうなったか？
   ● 結果の考察
   今日話すこと
   

   View Slide

8. 最初にやったこと
   

   View Slide

9. 最初にやったこと
   https://note.com/ysk_118/n/n845938325243
   

   View Slide

10. ● 定義フェーズ
    ○ 自分を定義する
    ○ 取り組むことの言語化
    ● 実行フェーズ
    ○ 行動で示す
    ○ EMを説明できる人を増やす
    ○ 後継者をつくる（ことを想定して行動する）
    最初にやったこと
    

    View Slide

11. 自分の役割、責務を言語化し、
    組織に説明する。
    ログラスにおけるという
    コンテキストが重要。
    一般論を書くだけでは
    必要性の温度感が上がらない。
    自分を定義する
    

    View Slide

12. ● 1チームから複数チームへ
    ● 人事評価制度の開始
    ● マネジメントのスケール
    ○ 経営陣からそれ以外の人への委譲のトライ
    ログラスにおいては問題解決能力の高いメンバーが集まっているため、
    マネージャー不要論が巻き起こってもおかしくなかった。
    自分を定義するといってもこのフェーズで必要性を理解しきってもらうことは
    不可能なので、実行フェーズで示していくことになる。
    ログラスにおいてなぜEMが必要だったか？
    

    View Slide

13. 先を見据えて何が起きうるか？どんな
    打手があるか？今まず何をしていく
    か？を最初に言語化した。
    戦略レベルのものでなくとも、何に取り
    組もうとしているのか？どうなったら成
    功と言えるのか？は言語化して周囲に
    説明しておきたい。
    取り組むことの言語化
    

    View Slide

14. ● 活動
    ○ 会議体の運用
    ○ 1on1
    ○ エンジニア組織としてのまとまり
    ○ モメンタムを出す
    ● アウトプット
    ○ ポエム
    ○ 外部発信
    行動で示す
    

    View Slide

15. 人が増えてくるとコミュニケーションが非同期
    化したり疎結合化する部分が出てくるため組
    織の全体感を捉えにくくなる。
    全員で何かを議論する場をゆるく運用していく
    と良いだろうと考え、中長期テーマを扱う場を
    作った。
    エンジニア組織としてのまとまり
    noteにも書いています。
    

    View Slide

16. モメンタム（勢い）を醸成することが大
    事。
    採用活動など開発以外のミッションでも
    きちんとEMが活動をリードし、現場を巻
    き込んでいく。
    そして盛り上げるところを盛り上げ、前
    に進んでいる感じを出していく。
    モメンタムを出していく
    

    View Slide

17. EMの頭の中を言語化したもの。
    生煮えの状態でも「こういうことを考えて
    いるぞ」をとにかく出す。
    論理も大事だが、文章に思いを乗せる
    ことが重要。
    ポエム
    

    View Slide

18. 定義を行い、行動した結果と
    して周囲の人は何をやる人
    なのかわかってくれたの
    か？を検証する必要があ
    る。
    初回は定性アンケートをとっ
    た。
    EMを説明できる人を増やす
    

    View Slide

19. EMを説明できる人を増やす
    - 開発チーム以外で巻き込みが必要な場合に、サポートしてくれる
    and リードして
    いってくれる職種
    - 開発組織作りや言語化をしてくれる
    - 技術的(OKRの目標の)リード or サポートしてくれる
    組織の成果最大化にコミットする人。
    組織（チームまたぎ）の成果を最大化するために抽象度の高い課題設定をする人。
    メンバーの評価権利を持っている人
    どうしても責務を抽象的に捉えてしまっており、具体的に何する人なの？をうまく説
    明できないなと感じます。
    チームのパフォーマンス最大化する役目を追っている。
    経営陣との接続だったり、組織課題
    の定義と解決を行なったりしている。特に組織課題の定義が重要だと思っている。
    開発物が定められている状況では、開発物に対する問題はボトムアップで取り扱われるが、
    組織全体への課題はボトムアップでは設定されにくい構造があると思う。
    定期的に現在の組織に対する問題設定をして投げかけてくれるのはありがたい
    。
    

    View Slide

20. EMもといマネージャーは会社のスケールにおいて
    最も重要な役割を持っている。一方で、属人化しや
    すく組織のボトルネックにもなりやすい。
    初期の設計や取り組みを間違えるとスケール自体
    が非常に困難になるため、属人性を大きくしないよう
    に意識しながら後継者探しを行う。
    マネージャーの要件に後継者育成を含めるレベル
    で意識すべきもの。
    後継者をつくる
    

    View Slide

21. やった結果どうなったか？
    

    View Slide

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
    

    View Slide

23. 1EM、2チーム時代は組織全体の決定をするにも合計
    3人で話して具体の方針を決め
    CTOと合意すればよかったのでコストが小さかった。
    2EM、3チーム時代になると、5人＋アルファとなり、合意形成のコストが爆上がりした。
    チームでの独立性が高まり、リーダー
    -EM間の認識合わせのコストも大きくなったし、
    EM-CTO間のすり合わせもコストが上がった。
    組織拡大に伴うオーバーヘッドの増大
    

    View Slide

24. リーダーの責務がマネジメント寄りになっている説
    

    View Slide

25. 結果の考察
    

    View Slide

26. ● 意図
    ○ 過去の経験からEMがあらゆるものを巻き取ってしまう状況・構造は回避したかった
    ○ 組織マネジメントに関する課題を EMの関心ごとに閉じるのではなく、 組織全体の関
    心ごととして捉えられるようにしたかった
    ● 実装
    ○ リーダーには成果が最大化されるようにチームを取りまとめてもらう
    ○ EMとの接点はリーダー
    ○ EMの業務を近くで知ってもらう＋リーダーシップの経験 を積んでもらうを両立できる
    ようにする
    初期の設計思想
    

    View Slide

27. ● まだまだ組織としては若いフェーズのはずなのに、チームやロールの枠が際立っ
    てしまい、意思決定コストが増大した
    ● リーダーの継承が行えたことは良かったが、
    スケールしたことによるオーバーヘッ
    ドを考慮して責務のアップデート
    が必要だった
    ○ 現在の人数規模で3階層コミュニケーションはデメリットの方が大きい
    ○ EMがもっとチームの中に入っていき目標やピープルマネジメント部分のグ
    リップが必要だった
    ● 一方チームよりも抽象度の大きい戦略的な議論
    も取り扱わなければならず両立
    が難しい
    ふりかえり
    

    View Slide

28. ● EMがチームと近い距離感で業務をしていくことは非常に重要ながらも、
    組織全体
    の戦略や、会社全体の戦略の議論に関わるなど、抽象度の高い業務
    も実際には
    存在する
    ● チームの内部の詳細な課題と組織全体の課題のコンテキストスイッチ
    がEMに
    とっては大きなハードルとなる
    ● EMチームの内部でも扱う抽象度によって階層化するか、複数人
    EMがいる場合
    にはPJごとに担当を決めるなどで推進しやすくなる
    ○ しかし、人数が少ない場合には組織がスケールすると負荷が指数関数的に
    上がりボトルネックになってしまう
    EMの仕事の抽象度について
    

    View Slide

29. 抽象度低い
    ● 個人の目標
    ● スプリントバックログ
    ● 機能の実装方針
    ● チームのワーキングアグリーメント
    ● チームの雰囲気づくり
    ● チーム内のプロセス改善
    ● 短期の戦術（機能など）
    ● 局所的な議論
    EMの仕事の抽象度について
    抽象度高い
    ● プロダクト組織全体の目標
    ● プロダクトロードマップ
    ● 機能のニーズ
    ● 会社全体の制度設計
    ● 会社のカルチャー・バリュー
    ● 組織の横断的なフロー整備
    ● 長期の戦略（ビジョンなど）
    ● 俯瞰的な議論
    

    View Slide

30. もう少しブレークダウンすると、
    ● 時間軸
    ● How-What-Why
    ● 組織の影響範囲
    などの軸がある。抽象度が高いとは、
    より長期で、より大きな影響範囲を持ち、なぜそ
    れをやるべきか？というモチベーションの起点となるようなもの
    を取り扱う傾向がある。
    EMの仕事の抽象度について
    

    View Slide

31. 組織構造の今後
    EM
    TL TL
    マネジメントについては
    CTOから権限委譲を進め
    てきた
    EMチームが厚くなり成熟してくれば
    再度階層化したほうがROIが合うよう
    になるかも
    CTO
    CTO、EMからなるマネジメントチー
    ム
    チーム チーム チーム
    EM EM EM
    チームとのコミュニケーションを
    2階層にしてアラインメントしやすくす
    る
    EMチーム
    チーム チーム チーム
    EM EM EM
    CTO,VPoEなど
    技術経営チーム
    

    View Slide

32. ● 初期フェーズからマネジメント体制を整備してきたが、一部早すぎる最
    適化があった
    ○ 特にスケールに対して責務が追従しないケースがあるので、ふり
    かえりやメンテナンスが重要
    ● EM業務の幅広さについてはもっと認知拡大や体系化が必要
    ○ 知ってたけど改めて・・
    まとめ
    

    View Slide