フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話

https://dev-productivity-con.findy-code.io/
株式会社SODAのセッション資料です。

Transcript

1. 2023/07/13 開発生産性 Conference フロー効率を重視して 「2年半でエンジニア2名→35名」 の急拡大組織で 高い生産性を実現した話 @rinchsan
2. 質問・感想・相談・フィードバックなどはSlidoへ！ https://qr.sli.do/fQtLauAjP8TY9ppX2reByM 登壇中に回答できなかったものは Twitter or スポンサーブース にて！
3. 書籍あたります！ このあと、ぜひSODAのブースへ！ ☕☕☕
4. 今日のキーワード
5. 「フロー効率」 「具体と抽象」 今日のキーワード
6. 「フロー効率」とは
7. “仕事を「終わらせる」こと を優先する” 「フロー効率」を高めるとは https://techblog.tebiki.co.jp/stop-starting-start-finishing-f601e2b2600e ※ 記事内では「フロー効率」というワードは出てきません。 リソース効率重視 フロー効率重視
8. 「フロー効率」は「アジャイル開発」とセット 仕事のサイズを最小の価値にして状況の変化に対応する 引用：https://techblog.tebiki.co.jp/stop-starting-start-finishing-f601e2b2600e
9. 「具体と抽象」とは
10. “具体と抽象の行き来を意識 することで、 間違いなく世界が変わって 見えてきます。” 『具体と抽象』(2014) 僕の一番好きな書籍です。
11. 「具体と抽象の往復」とは 早くレビュー すれば早く終わる！ ･･･ ･･･ ･･･ 知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する 抽象 具体 サイクルタイム 設計を事前に相談 すればレビュー後の 修正が減る！ デプロイ頻度 CI/CDの速度改善 変更失敗率 MTTR Four Keys ･･･ フロー効率
12. 目次 プロダクトの急成長と組織の急拡大 1 リソース効率を重視したことによる課題 2 「フロー効率を高める」とは 3 解決した課題、予期せぬ好影響 4
13. 株式会社SODA ◦ 2020年10月に入社 ◦ Webエンジニア→VPoE兼EM (2022年1月〜) ◦ ミッション：エンジニアリングマネジメントをいい感じに ⇧⇧⇧ 株式会社サイバーエージェント ◦ 2019年新卒入社 バックエンドエンジニア ◦ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan @rinchsan
14. プロダクトの急成長と組織の急拡大 1
15. プロダクトの急成長 組織の急拡大 多種多様な「求められる開発生産性」や「発生する課題」
16. 国内 No.1 スニーカー・トレカフリマ HYPE DROP メディア コミュニティ マーケットプレイス
17. MAU リクエスト数 ソースコード プロダクトの急成長
18. 2年半で 100万人 → 500万人 MAU プロダクトの急成長
19. 負荷スパイク（人気スニーカー発売など） 1万〜2万 rps リクエスト数 プロダクトの急成長
20. Goファイル数 約6,000ファイル Goコード行数 約1,100,000行 ソースコード - Go プロダクトの急成長 ※ ちなみに、2022/10時点ではファイル数4,000、コード行数80万。
21. Dartファイル数 約2,000ファイル Dartコード行数 約230,000行 ソースコード - Dart プロダクトの急成長 ※ 現在 WebView → Flutter のリプレイス中。今後もドンドン増えていきます。
22. プロダクト開発組織 デプロイ頻度 組織の急拡大
23. 2年半で エンジニア 2名 → 35名 プロダクト開発組織全体では 4名 → 50名 プロダクト開発組織 組織の急拡大
24. Monthlyで デプロイ 約100回 デプロイ頻度 D/D/D = 0.3 (Deployments / a Developer / a Day) デプロイ頻度 組織の急拡大
25. リソース効率を重視したことによる課題 2
26. エンジニア 2名 → 15名 2020/10 〜 2021/12
27. 拡大の様子と発生した課題
28. 少ない人数でドンドン開発していく！ ぼく CTO レビュー お願いします！ はい！ コード 書きまくるぞ！ こっちのIssue やります！ このIssue やります！ 最初は2人ですべてを「よしなに」。ほとんどの会社がこうでしょう。
29. 少ない人数(?)でドンドン開発していく...？ レビュー お願いします！ こっちのIssue やります！ コード 書きまくるぞ！ レビュー しますね！ コレやります！ すみません、 遅延してます！ ココどうなって るんですか？ 「遅延」や「既存実装への質問」など少しずつ不穏な空気が
30. コレ、思ってた よりも大変だ... なかなかタスク 終わらん... すみません、 遅延してます！ 少なくはない人数(確信)でもドンドン開発していく！ レビュー お願いします！ レビュー遅く なって すみません！ ココどうなって るんですか？ スミマセン、 遅れてます！ よくわからんけ どApprove… まぁ書いてる人 が一番理解して るから大丈夫... さらに不穏な空気が漂い出す・・・ ※ 誇張しています
31. とりあえず手を動かす 工数見積りは軽めで スケジュール遅延は仕方ない ガンガン作っていくことを優先
32. 事業成長 と、それを第一に考える組織文化 もちろん、得られたものも
33. もちろん課題も発生
34. (1/5) 成果物が属人化していく・・・ 知らない！ たいへんそう！ この機能、 変更したいです この機能、 変更したいです あ、一瞬ですね ※ 誇張しています 心当たりがある方も多いのでは…？
35. (2/5) 他人のタスクへ無関心になっていく・・・ あのスケジュール じゃ大変じゃない のかなぁ コレ課題に感じてる のは私だけかも。 言わなくていっか たいへんだ... 頑張るって言って るから大丈夫だよ ※ 誇張しています 最悪の場合、「個人事業主の集まり」に…
36. (3/5) 仕様理解やコードレビューが大変に・・・ コードレビュー おねがいします！ でもきっと書いた人 が一番理解してる からあってるよね... コレ、この実装 でいいのかな... 知らない仕様の キャッチアップ たいへんだ... ※ 誇張しています レビュー時間が長いとPRサイズを大きくしたい悪循環に…
37. (4/5) スケジュールも予測しづらく・・・ じゃあベテランさん おねがいします！ ワシがやれば 1日でできる！ 私なら3日 かかるなぁ... 僕がやったら 1週間かかりそう なのにすごい！ ※ 誇張しています もちろん個人で差が出るのは当たり前だが…
38. (5/5) PdMの認知負荷が高まり、価値あるものに集中しづらく・・・ リリース 遅れそうです！ こちらの返信 まだですか！ ※ 誇張しています ここの仕様 どうしますか？ あれ、これ、 仕様違うの？ 1人で悩んでて 今日何も 進んでない... え、これ、 今日まで！？
39. 組織はさらなる拡大へ
40. エンジニア 15名 → 35名 2021/12 〜 2023/04
41. 「フロー効率」を高めれば...？ 2022/01就任の新米VPoEはふとこう思う
42. 「フロー効率を高める」とは 3
43. フルサイクルなチーム 機能開発は同時に1つ チームで計画し、振り返る 「フロー効率を高める」とは
44. フルサイクルなチーム 機能開発は同時に1つ チームで計画し、振り返る 「フロー効率を高める」とは
45. “驚くべき開発ツールを持 ち、設計、開発、テスト、 デプロイ、運用、サポート といったフルソフトウェア ライフサイクルへの責任を 持つ開発チームだ。” 「フルサイクルなチーム」とは 引用：Netflixにおけるフルサイクル開発者―開発したものが運用する https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325
46. 連携が取りやすいチームサイズ バリューストリーム全体に関わる 「フルサイクルなチーム」を作るには
47. 連携が取りやすいチームサイズ バリューストリーム全体に関わる 「フルサイクルなチーム」を作るには
48. “We try to create teams that are no larger than can be fed by two pizzas” ピザ2枚で満腹になる サイズでチームを作る AWS Whitepapers, Amazon.com (2014) https://docs.aws.amazon.com/ja_jp/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html ※ ただし、ピザはアメリカンサイズとする。
49. “スクラムチームは、敏捷性 を維持するための十分な小 ささと、スプリント内で重 要な作業を完了するための 十分な大きさがあり、通常 は10人以下である。” 『スクラムガイド』 (2020) https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
50. “チームとは、5人から9人 のメンバーからなる安定し たグループで、共有された ゴールのために働く単位の ことだ。” 『Team Topologies』 (2021)
51. 連携が取りやすいチームサイズ バリューストリーム全体に関わる 「フルサイクルなチーム」を作るには
52. “You build it, you run it.” 作ったら運用しろ Werner Vogels, CTO of Amazon.com (2006) https://queue.acm.org/detail.cfm?id=1142065 2007年〜2008年あたり本格化したDevOpsムーブメントの先駆者
53. “ストリームとは、ビジネス ドメインや組織の能力に 沿った仕事の継続的な流れ のことだ。” 『Team Topologies』 (2021)
54. “ストリームアラインドチー ムとは、価値のある単一の 仕事のストリームに沿って 働くチームのことだ。” 『Team Topologies』 (2021)
55. “Create cross-functional teams that include representatives from each functional area of the software delivery process” デリバリープロセスの 関係者全員を含む 機能横断チームを作れ DevOps Capabilities にも Generative organizational culture (創造的な組織文化) https://dora.dev/devops-capabilities/cultural/generative-organizational-culture/
56. “The team understands how work moves through the business from idea to customer, including products or features.” アイデアが顧客に届くまで の仕事の流れをチームが 理解している DevOps Capabilities にも Visibility of work in the value stream (バリューストリームでの作業の可視性) https://dora.dev/devops-capabilities/process/work-visibility-in-value-stream/
57. 結局どういうチームを作ればいい？
58. つまり、機能横断なチームを作り、バリューストリーム全体に関わればいい 引用：https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 アイデア 顧客 バリューストリーム PdM デザイナー エンジニア アナリスト マーケ ・・・
59. 「具体と抽象の往復」を意識してみる
60. Stream-aligned Team バリューストリーム Amazon ここまでを「具体と抽象の往復」で振り返る どういう チーム体制にする？ ･･･ 知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する 抽象 具体 Two-pizza Teams You build it, you run it ･･･ フルサイクル Team Topologies スクラムガイド ･･･
61. フルサイクルなチーム 機能開発は同時に1つ チームで計画し、振り返る 「フロー効率を高める」とは
62. 価値が高いものから「終わらせる」 PBIのリファインメント 「機能開発は同時に1つ」とは
63. 価値が高いものからミニマムで「終わらせ」ていく 仕事のサイズを最小の価値にして状況の変化に対応する 引用：https://techblog.tebiki.co.jp/stop-starting-start-finishing-f601e2b2600e
64. “プロダクトバックログアイ テムがより小さく詳細にな るように、分割および定義 をする活動である。これ は、説明・並び順・サイズ などの詳細を追加するため の継続的な活動である。” 「リファインメント」とは https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
65. “エンジニアリングで重要な のは「どうしたら効率よく 不確実性を減らしていける のか」という考え方なので す。” 「エンジニアリング」とは
66. 結局どうすればいい？
67. つまり、チームで、細かく分割し、優先度順に並べ、上から順に終わらせていけばいい 1 Sprint以内に終わる仕事A 分割し、1つずつ、協力して 「終わらせる」 PdM デザイナー エンジニア アナリスト マーケ ・・・ 1 Sprint以内に終わる仕事B 1 Sprint以内に終わる仕事C ・・・
68. また「具体と抽象の往復」を
69. スクラムガイド ここまでを「具体と抽象の往復」で振り返る 色々な機能開発が 走ると大変！ ･･･ 知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する 抽象 具体 フロー効率 Product Backlog リファインメント ･･･ 最小の価値単位で 終わらせる ･･･
70. フルサイクルなチーム 機能開発は同時に1つ チームで計画し、振り返る 「フロー効率を高める」とは
71. 透明性・検査・適応 ベロシティの安定 「チームで計画し、振り返る」とは
72. “スクラムは「経験主義」と 「リーン思考」に基づいて いる。経験主義では、知識 は経験から生まれ、意思決 定は観察に基づく。リーン 思考では、ムダを省き、本 質に集中する。” 「経験主義」と「リーン思考」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
73. “スクラムでは、検査と適応 のための 4 つの正式なイベ ントを組み合わせている。 （中略）これらのイベント が機能するのは、経験主義 のスクラムの三本柱「透明 性」「検査」「適応」を実 現しているからである。” 透明性・検査・適応 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
74. “ストーリーのコストに1、 2、3という「ポイント」を つけていたのである。（中 略）ストーリーの実装が始 まったときに、1週間で達成 できるポイント数をすばや く把握するのである。” 『エクストリームプログラミング』(2015) ※ XPの第2版ではストーリーポイントやベロシティの利用を推奨していません。 　 その理由・背景を学んだ上で本質を理解して利用しましょう。
75. “アジャイルにプロダクトを 開発していくなら、やは り、安定したベロシティを 目指すべきだった。” ベロシティの安定 https://zenn.dev/team_soda/articles/33cd673975b72e
76. 結局どうすればいい？
77. つまり、ベロシティから計画を予測し、ベロシティを安定させるためにチームで振り返ればいい Sprint計画 PdM デザイナー エンジニア アナリスト マーケ ・・・ ベロシティ 安定を目指して振り返り PR数、サイクルタイム、 運用・調査、緊急対応、 技術的スパイク、 リファインメント不足、 キャッチアップ不足 ･･･ ※ XPの第2版ではストーリーポイントやベロシティの利用を推奨していません。その理由・背景を学んだ上で本質を理解して利用しましょう。
78. またまた「具体と抽象の往復」を
79. エクストリーム プログラミング スクラムガイド ここまでを「具体と抽象の往復」で振り返る 属人化している！ ･･･ 知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する 抽象 具体 透明性 検査・適応 ･･･ ベロシティの安定 ･･･ メトリクスが ほしい！ アジャイル開発 ベロシティの計測 ･･･ ※ XPの第2版ではストーリーポイントやベロシティの利用を推奨していません。その理由・背景を学んだ上で本質を理解して利用しましょう。
80. 解決した課題、予期せぬ好影響 4
81. 属人化の緩和 コミュニケーションコストの減少 解決した課題
82. 成果物は属人化から属チーム化へ🎉 この機能、 変更したいです この前作った アレですね 3日くらいで できそうです あ、でも、この 考慮が必要？ こっちは どうしますか？ 設計の考慮漏れ、レビューコスト、予期せぬ遅延、PdMの認知負荷、が低減
83. 1年やってみて、予期せぬ好影響も
84. チームの自律的な改善 チーム協力によるSprint計画達成 エンジニアとしての市場価値UP 1年やってみての予期せぬ好影響
85. チームの自律的な改善 チーム協力によるSprint計画達成 エンジニアとしての市場価値UP 1年やってみての予期せぬ好影響
86. バリューストリーム全体に関わることで、チームで改善が自律的に生まれる レビューコスト 高くない？ レビューまでの リードタイム 長くない？ 朝会のあとに レビューする？ いや、アサイン されたら すぐにしよう！ ※ 人事評価に活用されない生産性に関するメトリクスが取得できることも重要 PRの変更行数 小さくする？ PRの作成数を増 やそう！
87. またまたまた「具体と抽象の往復」を
88. トランクベース開発 ここでも「具体と抽象の往復」を意識してみる レビューが大変！ PRサイズを小さく！ ･･･ ･･･ 知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する 抽象 具体 小さいバッチ 同期的レビュー ･･･ アサインされたら すぐにレビュー！
89. チームの自律的な改善 チーム協力によるSprint計画達成 エンジニアとしての市場価値UP 1年やってみての予期せぬ好影響
90. Sprint計画は、個人の計画ではなく、チームの計画 この調査 すごい大変だぁ ベロシティ 出せないなぁ コレ 巻き取ります！ わたしは こっちを！ チームの協力によってSprint計画を達成し、ベロシティを安定させる ※ ベロシティはチームで見るべき。個人のベロシティを安定させる難易度は高い。 ↑ チームの ベロシティ ↑ 個人の ベロシティ
91. “アジャイルな方法論では、 プロダクトをきちんと届け るために、イテレーション を終わらせて「完成」させ るためならどんな作業でも 引き受ける覚悟のあるメン バーによる、チームワーク と連携を重視します。” 『ELASTIC LEADERSHIP』(2017)
92. チームの自律的な改善 チーム協力によるSprint計画達成 エンジニアとしての市場価値UP 1年やってみての予期せぬ好影響
93. エンジニアに求められる本質的な能力は「再現性のある課題解決力」 言語化 意思決定 再現性のある課題解決 チームが自律的に課題解決していくことは市場価値向上に繋がる 採用でも評価でも課題解決力を重視
94. “課題解決できたかどうかと いう結果だけを見ていると 運良く結果が出ることもあ るので、この能力を高めて いくうえでは、課題解決に 至るまでの学びを整理し、 再現性を意識させることも 効果的です。” 「再現性」と「言語化」
95. “人の真価は、どのような能 力があるかより、どのよう な選択をするかでわかる。 - J.K.ローリング ” 「課題解決」の「意思決定」
96. “スタッフエンジニアの日々 のスケジュールは（中略） 基本的には共通している。 技術的な方向性を設定およ び修正し、スポンサーある いはメンターとして行動 し、組織の意思決定をサ ポートする” 『スタッフエンジニア』(2023) ※ 自分1人では出せない課題解決の幅と質を出すにはスポンサーのような動きが重要
97. まとめ
98. 「フロー効率」 「具体と抽象」 今日のキーワード
99. 1 Sprint以内に終わる仕事C 1 Sprint以内に終わる仕事B 「フロー効率」を高め、事業を伸ばす 引用：https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 アイデア 顧客 PdM デザイナー エンジニア アナリスト マーケ ・・・ 分割し、1つずつ、協力して 「終わらせる」 バリューストリーム全体に関わる 1 Sprint以内に終わる仕事A ・・・ ベロシティ安定を目指して振り返る Sprint計画 ベロシティ
100. 疎結合 アーキテクチャ トランクベース開発 「具体と抽象の往復」で課題を解決していく レビューが大変！ PRサイズを小さく！ ･･･ Four Keysは銀の弾丸ではない。Four Keysが何を抽象化しているかを考える。 抽象 具体 小さいバッチ 同期的レビュー DevOps Capabilities ･･･ Four Keys ･･･ アサインされたら すぐにレビュー！ ･･･ 学習文化 逆コンウェイ戦略 社内勉強会 マイクロサービス モジュラモノリス
101. 「フロー効率」 「具体と抽象」 今日のキーワード