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

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

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

Masaya Hayashi

July 13, 2023
Tweet

More Decks by Masaya Hayashi

Other Decks in Programming

Transcript

  1. 「具体と抽象の往復」とは 早くレビュー すれば早く終わる! ・・・ ・・・ ・・・ 知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する 抽象 具体 サイクルタイム

    設計を事前に相談 すればレビュー後の 修正が減る! デプロイ頻度 CI/CDの速度改善 変更失敗率 MTTR Four Keys ・・・ フロー効率
  2. Monthlyで デプロイ 約100回 デプロイ頻度 D/D/D = 0.3 (Deployments / a

    Developer / a Day) デプロイ頻度 組織の急拡大
  3. 少ない人数でドンドン開発していく! ぼく CTO レビュー お願いします! はい! コード 書きまくるぞ! こっちのIssue やります!

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

    すみません、 遅延してます! ココどうなって るんですか? 「遅延」や「既存実装への質問」など少しずつ不穏な空気が
  5. コレ、思ってた よりも大変だ... なかなかタスク 終わらん... すみません、 遅延してます! 少なくはない人数(確信)でもドンドン開発していく! レビュー お願いします! レビュー遅く

    なって すみません! ココどうなって るんですか? スミマセン、 遅れてます! よくわからんけ どApprove… まぁ書いてる人 が一番理解して るから大丈夫... さらに不穏な空気が漂い出す・・・ ※ 誇張しています
  6. “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 ※ ただし、ピザはアメリカンサイズとする。
  7. “You build it, you run it.” 作ったら運用しろ Werner Vogels, CTO

    of Amazon.com (2006) https://queue.acm.org/detail.cfm?id=1142065 2007年〜2008年あたり本格化したDevOpsムーブメントの先駆者
  8. “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/
  9. “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/
  10. つまり、ベロシティから計画を予測し、ベロシティを安定させるためにチームで振り返ればいい Sprint計画 PdM デザイナー エンジニア アナリスト マーケ ・・・ ベロシティ 安定を目指して振り返り

    PR数、サイクルタイム、 運用・調査、緊急対応、 技術的スパイク、 リファインメント不足、 キャッチアップ不足 ・・・ ※ XPの第2版ではストーリーポイントやベロシティの利用を推奨していません。その理由・背景を学んだ上で本質を理解して利用しましょう。
  11. エクストリーム プログラミング スクラムガイド ここまでを「具体と抽象の往復」で振り返る 属人化している! ・・・ 知識を武器に具体と抽象を往復することで課題解決の幅も質も向上する 抽象 具体 透明性

    検査・適応 ・・・ ベロシティの安定 ・・・ メトリクスが ほしい! アジャイル開発 ベロシティの計測 ・・・ ※ XPの第2版ではストーリーポイントやベロシティの利用を推奨していません。その理由・背景を学んだ上で本質を理解して利用しましょう。
  12. バリューストリーム全体に関わることで、チームで改善が自律的に生まれる レビューコスト 高くない? レビューまでの リードタイム 長くない? 朝会のあとに レビューする? いや、アサイン されたら

    すぐにしよう! ※ 人事評価に活用されない生産性に関するメトリクスが取得できることも重要 PRの変更行数 小さくする? PRの作成数を増 やそう!
  13. 1 Sprint以内に終わる仕事C 1 Sprint以内に終わる仕事B 「フロー効率」を高め、事業を伸ばす 引用:https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 アイデア 顧客 PdM デザイナー

    エンジニア アナリスト マーケ ・・・ 分割し、1つずつ、協力して 「終わらせる」 バリューストリーム全体に関わる 1 Sprint以内に終わる仕事A ・・・ ベロシティ安定を目指して振り返る Sprint計画 ベロシティ
  14. 疎結合 アーキテクチャ トランクベース開発 「具体と抽象の往復」で課題を解決していく レビューが大変! PRサイズを小さく! ・・・ Four Keysは銀の弾丸ではない。Four Keysが何を抽象化しているかを考える。

    抽象 具体 小さいバッチ 同期的レビュー DevOps Capabilities ・・・ Four Keys ・・・ アサインされたら すぐにレビュー! ・・・ 学習文化 逆コンウェイ戦略 社内勉強会 マイクロサービス モジュラモノリス