Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Masaya Hayashi

July 13, 2023
Tweet

More Decks by Masaya Hayashi

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  4. 今日のキーワード

    View Slide

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

    View Slide

  6. 「フロー効率」とは

    View Slide

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

    View Slide

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

    View Slide

  9. 「具体と抽象」とは

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. もちろん課題も発生

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. 組織はさらなる拡大へ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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ムーブメントの先駆者

    View Slide

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

    View Slide

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

    View Slide

  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/

    View Slide

  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/

    View Slide

  57. 結局どういうチームを作ればいい?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  66. 結局どうすればいい?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  76. 結局どうすればいい?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    チームの
    ベロシティ

    個人の
    ベロシティ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  97. まとめ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide