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

by Masaya Hayashi

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

質問・感想・相談・フィードバックなどはSlidoへ！ https://qr.sli.do/fQtLauAjP8TY9ppX2reByM 登壇中に回答できなかったものは Twitter or スポンサーブースにて！

Slide 3

Slide 3 text

書籍あたります！このあと、ぜひSODAのブースへ！ ☕☕☕

Slide 4

Slide 4 text

今日のキーワード

Slide 5

Slide 5 text

「フロー効率」「具体と抽象」今日のキーワード

Slide 6

Slide 6 text

「フロー効率」とは

Slide 7

Slide 7 text

“仕事を「終わらせる」ことを優先する” 「フロー効率」を高めるとは https://techblog.tebiki.co.jp/stop-starting-start-ﬁnishing-f601e2b2600e ※ 記事内では「フロー効率」というワードは出てきません。リソース効率重視フロー効率重視

Slide 8

Slide 8 text

「フロー効率」は「アジャイル開発」とセット仕事のサイズを最小の価値にして状況の変化に対応する引用：https://techblog.tebiki.co.jp/stop-starting-start-ﬁnishing-f601e2b2600e

Slide 9

Slide 9 text

「具体と抽象」とは

Slide 10

Slide 10 text

“具体と抽象の行き来を意識することで、間違いなく世界が変わって見えてきます。” 『具体と抽象』(2014) 僕の一番好きな書籍です。

Slide 11

Slide 11 text

「具体と抽象の往復」とは早くレビューすれば早く終わる！･････････知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する抽象具体サイクルタイム設計を事前に相談すればレビュー後の修正が減る！デプロイ頻度 CI/CDの速度改善変更失敗率 MTTR Four Keys ･･･フロー効率

Slide 12

Slide 12 text

目次プロダクトの急成長と組織の急拡大 1 リソース効率を重視したことによる課題 2 「フロー効率を高める」とは 3 解決した課題、予期せぬ好影響 4

Slide 13

Slide 13 text

株式会社SODA ○ 2020年10月に入社 ○ Webエンジニア→VPoE兼EM (2022年1月〜) ○ ミッション：エンジニアリングマネジメントをいい感じに ⇧⇧⇧ 株式会社サイバーエージェント ○ 2019年新卒入社バックエンドエンジニア ○ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan @rinchsan

Slide 14

Slide 14 text

プロダクトの急成長と組織の急拡大 1

Slide 15

Slide 15 text

プロダクトの急成長組織の急拡大多種多様な「求められる開発生産性」や「発生する課題」

Slide 16

Slide 16 text

国内 No.1 スニーカー・トレカフリマ HYPE DROP メディアコミュニティマーケットプレイス

Slide 17

Slide 17 text

MAU リクエスト数ソースコードプロダクトの急成長

Slide 18

Slide 18 text

2年半で 100万人 → 500万人 MAU プロダクトの急成長

Slide 19

Slide 19 text

負荷スパイク（人気スニーカー発売など） 1万〜2万 rps リクエスト数プロダクトの急成長

Slide 20

Slide 20 text

Goファイル数約6,000ファイル Goコード行数約1,100,000行ソースコード - Go プロダクトの急成長 ※ ちなみに、2022/10時点ではファイル数4,000、コード行数80万。

Slide 21

Slide 21 text

Dartファイル数約2,000ファイル Dartコード行数約230,000行ソースコード - Dart プロダクトの急成長 ※ 現在 WebView → Flutter のリプレイス中。今後もドンドン増えていきます。

Slide 22

Slide 22 text

プロダクト開発組織デプロイ頻度組織の急拡大

Slide 23

Slide 23 text

2年半でエンジニア 2名 → 35名プロダクト開発組織全体では 4名 → 50名プロダクト開発組織組織の急拡大

Slide 24

Slide 24 text

Monthlyでデプロイ約100回デプロイ頻度 D/D/D = 0.3 (Deployments / a Developer / a Day) デプロイ頻度組織の急拡大

Slide 25

Slide 25 text

リソース効率を重視したことによる課題 2

Slide 26

Slide 26 text

エンジニア 2名 → 15名 2020/10 〜 2021/12

Slide 27

Slide 27 text

拡大の様子と発生した課題

Slide 28

Slide 28 text

少ない人数でドンドン開発していく！ぼく CTO レビューお願いします！はい！コード書きまくるぞ！こっちのIssue やります！このIssue やります！最初は2人ですべてを「よしなに」。ほとんどの会社がこうでしょう。

Slide 29

Slide 29 text

少ない人数(?)でドンドン開発していく...？レビューお願いします！こっちのIssue やります！コード書きまくるぞ！レビューしますね！コレやります！すみません、遅延してます！ココどうなってるんですか？「遅延」や「既存実装への質問」など少しずつ不穏な空気が

Slide 30

Slide 30 text

コレ、思ってたよりも大変だ... なかなかタスク終わらん... すみません、遅延してます！少なくはない人数(確信)でもドンドン開発していく！レビューお願いします！レビュー遅くなってすみません！ココどうなってるんですか？スミマセン、遅れてます！よくわからんけどApprove… まぁ書いてる人が一番理解してるから大丈夫... さらに不穏な空気が漂い出す・・・ ※ 誇張しています

Slide 31

Slide 31 text

とりあえず手を動かす工数見積りは軽めでスケジュール遅延は仕方ないガンガン作っていくことを優先

Slide 32

Slide 32 text

事業成長と、それを第一に考える組織文化もちろん、得られたものも

Slide 33

Slide 33 text

もちろん課題も発生

Slide 34

Slide 34 text

(1/5) 成果物が属人化していく・・・知らない！たいへんそう！この機能、変更したいですこの機能、変更したいですあ、一瞬ですね ※ 誇張しています心当たりがある方も多いのでは…？

Slide 35

Slide 35 text

(2/5) 他人のタスクへ無関心になっていく・・・あのスケジュールじゃ大変じゃないのかなぁコレ課題に感じてるのは私だけかも。言わなくていっかたいへんだ... 頑張るって言ってるから大丈夫だよ ※ 誇張しています最悪の場合、「個人事業主の集まり」に…

Slide 36

Slide 36 text

(3/5) 仕様理解やコードレビューが大変に・・・コードレビューおねがいします！でもきっと書いた人が一番理解してるからあってるよね... コレ、この実装でいいのかな... 知らない仕様のキャッチアップたいへんだ... ※ 誇張していますレビュー時間が長いとPRサイズを大きくしたい悪循環に…

Slide 37

Slide 37 text

(4/5) スケジュールも予測しづらく・・・じゃあベテランさんおねがいします！ワシがやれば 1日でできる！私なら3日かかるなぁ... 僕がやったら 1週間かかりそうなのにすごい！ ※ 誇張していますもちろん個人で差が出るのは当たり前だが…

Slide 38

Slide 38 text

(5/5) PdMの認知負荷が高まり、価値あるものに集中しづらく・・・リリース遅れそうです！こちらの返信まだですか！ ※ 誇張していますここの仕様どうしますか？あれ、これ、仕様違うの？ 1人で悩んでて今日何も進んでない... え、これ、今日まで！？

Slide 39

Slide 39 text

組織はさらなる拡大へ

Slide 40

Slide 40 text

エンジニア 15名 → 35名 2021/12 〜 2023/04

Slide 41

Slide 41 text

「フロー効率」を高めれば...？ 2022/01就任の新米VPoEはふとこう思う

Slide 42

Slide 42 text

「フロー効率を高める」とは 3

Slide 43

Slide 43 text

フルサイクルなチーム機能開発は同時に1つチームで計画し、振り返る「フロー効率を高める」とは

Slide 44

Slide 44 text

フルサイクルなチーム機能開発は同時に1つチームで計画し、振り返る「フロー効率を高める」とは

Slide 45

Slide 45 text

“驚くべき開発ツールを持ち、設計、開発、テスト、デプロイ、運用、サポートといったフルソフトウェアライフサイクルへの責任を持つ開発チームだ。” 「フルサイクルなチーム」とは引用：Netﬂixにおけるフルサイクル開発者―開発したものが運用する https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325

Slide 46

Slide 46 text

連携が取りやすいチームサイズバリューストリーム全体に関わる「フルサイクルなチーム」を作るには

Slide 47

Slide 47 text

連携が取りやすいチームサイズバリューストリーム全体に関わる「フルサイクルなチーム」を作るには

Slide 48

Slide 48 text

“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 ※ ただし、ピザはアメリカンサイズとする。

Slide 49

Slide 49 text

“スクラムチームは、敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさがあり、通常は10人以下である。” 『スクラムガイド』 (2020) https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 50

Slide 50 text

“チームとは、5人から9人のメンバーからなる安定したグループで、共有されたゴールのために働く単位のことだ。” 『Team Topologies』 (2021)

Slide 51

Slide 51 text

連携が取りやすいチームサイズバリューストリーム全体に関わる「フルサイクルなチーム」を作るには

Slide 52

Slide 52 text

“You build it, you run it.” 作ったら運用しろ Werner Vogels, CTO of Amazon.com (2006) https://queue.acm.org/detail.cfm?id=1142065 2007年〜2008年あたり本格化したDevOpsムーブメントの先駆者

Slide 53

Slide 53 text

“ストリームとは、ビジネスドメインや組織の能力に沿った仕事の継続的な流れのことだ。” 『Team Topologies』 (2021)

Slide 54

Slide 54 text

“ストリームアラインドチームとは、価値のある単一の仕事のストリームに沿って働くチームのことだ。” 『Team Topologies』 (2021)

Slide 55

Slide 55 text

“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/

Slide 56

Slide 56 text

“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/

Slide 57

Slide 57 text

結局どういうチームを作ればいい？

Slide 58

Slide 58 text

つまり、機能横断なチームを作り、バリューストリーム全体に関わればいい引用：https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 アイデア顧客バリューストリーム PdM デザイナーエンジニアアナリストマーケ・・・

Slide 59

Slide 59 text

「具体と抽象の往復」を意識してみる

Slide 60

Slide 60 text

Stream-aligned Team バリューストリーム Amazon ここまでを「具体と抽象の往復」で振り返るどういうチーム体制にする？･･･知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する抽象具体 Two-pizza Teams You build it, you run it ･･･フルサイクル Team Topologies スクラムガイド･･･

Slide 61

Slide 61 text

フルサイクルなチーム機能開発は同時に1つチームで計画し、振り返る「フロー効率を高める」とは

Slide 62

Slide 62 text

価値が高いものから「終わらせる」 PBIのリファインメント「機能開発は同時に1つ」とは

Slide 63

Slide 63 text

価値が高いものからミニマムで「終わらせ」ていく仕事のサイズを最小の価値にして状況の変化に対応する引用：https://techblog.tebiki.co.jp/stop-starting-start-ﬁnishing-f601e2b2600e

Slide 64

Slide 64 text

“プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。” 「リファインメント」とは https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 65

Slide 65 text

“エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方なのです。” 「エンジニアリング」とは

Slide 66

Slide 66 text

結局どうすればいい？

Slide 67

Slide 67 text

つまり、チームで、細かく分割し、優先度順に並べ、上から順に終わらせていけばいい 1 Sprint以内に終わる仕事A 分割し、1つずつ、協力して「終わらせる」 PdM デザイナーエンジニアアナリストマーケ・・・ 1 Sprint以内に終わる仕事B 1 Sprint以内に終わる仕事C ・・・

Slide 68

Slide 68 text

また「具体と抽象の往復」を

Slide 69

Slide 69 text

スクラムガイドここまでを「具体と抽象の往復」で振り返る色々な機能開発が走ると大変！･･･知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する抽象具体フロー効率 Product Backlog リファインメント･･･最小の価値単位で終わらせる･･･

Slide 70

Slide 70 text

フルサイクルなチーム機能開発は同時に1つチームで計画し、振り返る「フロー効率を高める」とは

Slide 71

Slide 71 text

透明性・検査・適応ベロシティの安定「チームで計画し、振り返る」とは

Slide 72

Slide 72 text

“スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から生まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。” 「経験主義」と「リーン思考」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 73

Slide 73 text

“スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。（中略）これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。” 透明性・検査・適応 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 74

Slide 74 text

“ストーリーのコストに1、 2、3という「ポイント」をつけていたのである。（中略）ストーリーの実装が始まったときに、1週間で達成できるポイント数をすばやく把握するのである。” 『エクストリームプログラミング』(2015) ※ XPの第2版ではストーリーポイントやベロシティの利用を推奨していません。　その理由・背景を学んだ上で本質を理解して利用しましょう。

Slide 75

Slide 75 text

“アジャイルにプロダクトを開発していくなら、やはり、安定したベロシティを目指すべきだった。” ベロシティの安定 https://zenn.dev/team_soda/articles/33cd673975b72e

Slide 76

Slide 76 text

結局どうすればいい？

Slide 77

Slide 77 text

つまり、ベロシティから計画を予測し、ベロシティを安定させるためにチームで振り返ればいい Sprint計画 PdM デザイナーエンジニアアナリストマーケ・・・ベロシティ安定を目指して振り返り PR数、サイクルタイム、運用・調査、緊急対応、技術的スパイク、リファインメント不足、キャッチアップ不足･･･ ※ XPの第2版ではストーリーポイントやベロシティの利用を推奨していません。その理由・背景を学んだ上で本質を理解して利用しましょう。

Slide 78

Slide 78 text

またまた「具体と抽象の往復」を

Slide 79

Slide 79 text

エクストリームプログラミングスクラムガイドここまでを「具体と抽象の往復」で振り返る属人化している！･･･知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する抽象具体透明性検査・適応･･･ベロシティの安定･･･メトリクスがほしい！アジャイル開発ベロシティの計測･･･ ※ XPの第2版ではストーリーポイントやベロシティの利用を推奨していません。その理由・背景を学んだ上で本質を理解して利用しましょう。

Slide 80

Slide 80 text

解決した課題、予期せぬ好影響 4

Slide 81

Slide 81 text

属人化の緩和コミュニケーションコストの減少解決した課題

Slide 82

Slide 82 text

成果物は属人化から属チーム化へ🎉 この機能、変更したいですこの前作ったアレですね 3日くらいでできそうですあ、でも、この考慮が必要？こっちはどうしますか？設計の考慮漏れ、レビューコスト、予期せぬ遅延、PdMの認知負荷、が低減

Slide 83

Slide 83 text

1年やってみて、予期せぬ好影響も

Slide 84

Slide 84 text

チームの自律的な改善チーム協力によるSprint計画達成エンジニアとしての市場価値UP 1年やってみての予期せぬ好影響

Slide 85

Slide 85 text

チームの自律的な改善チーム協力によるSprint計画達成エンジニアとしての市場価値UP 1年やってみての予期せぬ好影響

Slide 86

Slide 86 text

バリューストリーム全体に関わることで、チームで改善が自律的に生まれるレビューコスト高くない？レビューまでのリードタイム長くない？朝会のあとにレビューする？いや、アサインされたらすぐにしよう！ ※ 人事評価に活用されない生産性に関するメトリクスが取得できることも重要 PRの変更行数小さくする？ PRの作成数を増やそう！

Slide 87

Slide 87 text

またまたまた「具体と抽象の往復」を

Slide 88

Slide 88 text

トランクベース開発ここでも「具体と抽象の往復」を意識してみるレビューが大変！ PRサイズを小さく！･･････知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する抽象具体小さいバッチ同期的レビュー･･･アサインされたらすぐにレビュー！

Slide 89

Slide 89 text

チームの自律的な改善チーム協力によるSprint計画達成エンジニアとしての市場価値UP 1年やってみての予期せぬ好影響

Slide 90

Slide 90 text

Sprint計画は、個人の計画ではなく、チームの計画この調査すごい大変だぁベロシティ出せないなぁコレ巻き取ります！わたしはこっちを！チームの協力によってSprint計画を達成し、ベロシティを安定させる ※ ベロシティはチームで見るべき。個人のベロシティを安定させる難易度は高い。 ↑ チームのベロシティ ↑ 個人のベロシティ

Slide 91

Slide 91 text

“アジャイルな方法論では、プロダクトをきちんと届けるために、イテレーションを終わらせて「完成」させるためならどんな作業でも引き受ける覚悟のあるメンバーによる、チームワークと連携を重視します。” 『ELASTIC LEADERSHIP』(2017)

Slide 92

Slide 92 text

チームの自律的な改善チーム協力によるSprint計画達成エンジニアとしての市場価値UP 1年やってみての予期せぬ好影響

Slide 93

Slide 93 text

エンジニアに求められる本質的な能力は「再現性のある課題解決力」言語化意思決定再現性のある課題解決チームが自律的に課題解決していくことは市場価値向上に繋がる採用でも評価でも課題解決力を重視

Slide 94

Slide 94 text

“課題解決できたかどうかという結果だけを見ていると運良く結果が出ることもあるので、この能力を高めていくうえでは、課題解決に至るまでの学びを整理し、再現性を意識させることも効果的です。” 「再現性」と「言語化」

Slide 95

Slide 95 text

“人の真価は、どのような能力があるかより、どのような選択をするかでわかる。 - J.K.ローリング ” 「課題解決」の「意思決定」

Slide 96

Slide 96 text

“スタッフエンジニアの日々のスケジュールは（中略）基本的には共通している。技術的な方向性を設定および修正し、スポンサーあるいはメンターとして行動し、組織の意思決定をサポートする” 『スタッフエンジニア』(2023) ※ 自分1人では出せない課題解決の幅と質を出すにはスポンサーのような動きが重要

Slide 97

Slide 97 text

まとめ

Slide 98

Slide 98 text

「フロー効率」「具体と抽象」今日のキーワード

Slide 99

Slide 99 text

1 Sprint以内に終わる仕事C 1 Sprint以内に終わる仕事B 「フロー効率」を高め、事業を伸ばす引用：https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 アイデア顧客 PdM デザイナーエンジニアアナリストマーケ・・・分割し、1つずつ、協力して「終わらせる」バリューストリーム全体に関わる 1 Sprint以内に終わる仕事A ・・・ベロシティ安定を目指して振り返る Sprint計画ベロシティ

Slide 100

Slide 100 text

疎結合アーキテクチャトランクベース開発「具体と抽象の往復」で課題を解決していくレビューが大変！ PRサイズを小さく！･･･ Four Keysは銀の弾丸ではない。Four Keysが何を抽象化しているかを考える。抽象具体小さいバッチ同期的レビュー DevOps Capabilities ･･･ Four Keys ･･･アサインされたらすぐにレビュー！･･･学習文化逆コンウェイ戦略社内勉強会マイクロサービスモジュラモノリス

Slide 101

Slide 101 text

「フロー効率」「具体と抽象」今日のキーワード