逆コンウェイを信じて チーム再編したけどうまくいってるの？ を Four Keysで計測する

ScrumFest三河2023の登壇資料です。
Scrum@ScaleでTeam Topologyを取り入れたチーム分割をして、FourKeysの計測と改善にとりくんだ事例を紹介します。
https://confengine.com/conferences/scrum-fest-mikawa-2023/proposal/18745/four-keys

Transcript

1. 逆コンウェイを信じて
 チーム再編したけどうまく いってるの？
 
 を Four Keysで計測する
 2023/09/16 ScrumFest三河
 国平清貴

2. 自己紹介: 国平清貴(口玉)
 X: @kuchitama
 （株）モンスターラボ EM
 受託開発の会社
 Joe Justice さんの弟子
 CSMの研修受けただけ

3. なぜチーム再編したのか

4. なぜチーム再編したのか 
 かなり大規模(当社比)
 ピザ🍕 2枚じゃ足りない
 コミュニケーションが複雑化
 　をなんとかした結果、
 　　PMに負荷が集中
 1つのチームで大きなリポジトリを 触る
 40人以上のチームで開発
 Backend
 Frontend
 管理画面
 Frontend

5. 最初は請負+ウォーターフォール
 
 なぜチーム再編したのか 
 課題
 　品質: 日々デプロイされる バグ
 　ハードワーク:
 　　夜遅くまで続くテスト
 修正
 　　電話
 デプロイ
 　相次ぐ離任:
 体調不良
 バーンアウト
 
 ビッタビタに攻める開発
 2021
 2020/10
 請負
 2022
 ★ 
 Open
 ★ 
 Release
 new feature
 ★ 
 東京五輪

6. なぜチーム再編したのか 
 弊社の偉い人からの提案
 ちゃんと体制を整えないとお客さまとサービ スの課題を解決できない
 
 
 Scrumをちゃんとやろう
 結果Agileコーチ参加

7. なぜチーム再編したのか 
 40人超えのチームでどうScrumを実践する か
 Scrum@Scale しよう！
 どうするScrum

8. スクラム@スケールについて スクラム@スケールとは スクラム@スケールは単一のスクラムチームで機能するやり方を複数のチームに拡張し、管理機能を最小 限に抑える構造を目指す tag=kuchitama-22 で どうチームを分割するか
9. TeamTopology と
 逆コンウェイ戦略

10. コンウェイの法則
 システムを設計する組織は、その 構造をそっくりまねた構造の設計 を生み出してしまう
 
 逆コンウェイ戦略
 システムに反映したいアーキテク チャーに合うようなチーム構造に する
 TeamTopologyと逆コンウェイ戦略

11. Team Topology
 • 逆コンウェイ戦略に基づいて、アーキテクチャを狙った形に収束させ る • 境界面での分割 • 4つのチームタイプ ◦ Stream-aligned team ◦ Enabling team ◦ Complicated-subsystem team ◦ Platform team • 3つのコミュニケーション ◦ Collaboration ◦ X-as-a-Service ◦ Facilitation Team Topology
12. Team Topology
 • アーキテクチャを理想に寄せたい • コミュニケーションコストを適正化したい • 認知負荷を下げたい チームを分割 • うまくいったのか？ ◦ 生産性は上がっているのか？ どうやって判断するか
13. Four Keys

14. Four Keys
 DORA(DevOps Research and Assessment) が提唱するデリバリーパ フォーマンスを示す4つの指標 DORA Four Keys 指標 定義 デプロイ頻度 本番環境へのリリース頻度 バリューストリームの スループット 変更のリードタイム 変更のコミットから本番環境へのデプロイまでの時 間 変更障害率 意図通り動かないコードをリリースした割合 デリバリーの安定性 平均修復時間 障害から復旧するまでの平均時間
15. Four Keys
 DORAが提唱するデリバリーパフォーマンスを示す4つの指標 DORA Four Keys 指標 デプロイ頻度 早く作って早く出す 変更のリードタイム 変更障害率 バグを出さない、出たら早く直す 平均修復時間
16. Four Keys
 DORAが提唱するデリバリーパフォーマンスを示す4つの指標 組織間での比較が可能 DORA Four Keys 指標 デプロイ頻度 変更のリードタイム 変更障害率 平均修復時間
17. Four Keys
 DORAが提唱するデリバリーパフォーマンスを示す4つの指標 どうやって計測するか DORA Four Keys 指標 デプロイ頻度 変更のリードタイム 変更失敗率 平均修復時間
18. 18
 計測できた！
19. 19
 計測できた！？ リードタイム 42日？??
 変更失敗率 27.2% ???

20. スプリントでの各チームの成果物 を、スプリントの終わりにまとめて デプロイ用のブランチにまとめてい る
 計測の課題
 スプリントの開始から終わりまでの コミットが全てまとまったPRが作ら れてノイズに...
 一部、複数チームを兼任している メンバーがいる
 メンバーだけでチームの指標を測 れず、各PRがどのチームの作業 なのか紐付けが必要

21. デプロイのためのPRは特定のラ ベルを付与して、計測対象から除 外
 計測の課題(解決)
 スプリントの開始から終わりまでの コミットが全てまとまったPRが作ら れてノイズに...
 メンバーだけでチームの指標を測 れず、各PRがどのチームの作業 なのか紐付けが必要
 各PRにチームに紐づいたラベル を設定して、計測対象を絞り込み

22. 計測できた！ データクレンジング大事！！
23. PRのレビューが特定のメンバーに 集中して、ボトルネックになってい る
 その結果、リードタイムが改善しな いのではないか
 レビュー対応するメンバーを増やし て、ボトルネックを解消しよう
 改善1: レビューが集中問題

24. 改善1: レビューが集中問題(結果)

25. 一定の効果があり、レビュー時間 が短縮できた
 ただし、まだ一部のシニアメンバー に集中していて、スケールできて いない
 改善1: レビューが集中問題(結果)

26. 変更障害率を下げたい
 お客様もPRのレビューに参加
 改善2: 変更障害率の改善

27. お客様もPRのレビューに参加
 
 レビューの厚さを維持できなくなっ てきた
 改善2: 変更障害率の改善(後日談)
 リードタイムも改善したい

28. お客様もPRのレビューに参加
 リードタイムも改善したい
 
 
 レビューの厚さを維持できなくなっ てきた
 
 改善2: 変更障害率の改善(後日談)
 見事なV字回復
29. Scrum@Scaleに取り組んだ
 逆コンウェイ戦略に則ってチームを分割した
 Four Keysで生産性を見えるようになった
 各チームの課題に対して改善の取り組めている
 ここまでの成果

30. コンウェイの負債

31. 40人以上のチームで開発
 Backend
 Frontend
 管理画面
 Frontend
 クソデカチーム構成に沿ったアーキテクチャの爆 誕
32. 40人以上のチームで開発
 Backend
 Frontend
 管理画面
 Frontend
 チーム毎の責務に沿ったアーキテクチャになって おらず、密結合なコード
33. チーム間の変更範囲が重なる
 各チームの変更のマージ期間が 必要に
 結果、1スプリント1デプロイに律速
 密結合アーキテクチャ
 デプロイ頻度の更新余地がない

34. アーキテクチャの改善を進めないと、デプロ イ頻度の改善に取り組めない
 どのチームが担当するのか？？？
 コンウェイの法則の力だけでは解決できない ガチガチの密結合アーキテクチャ
 密結合アーキテクチャの分解
 DXチーム(Developer eXperience)が誕生
35. ストリームアラインドチーム間で落ちる課題 の解決
 アジャイルのライトウィングを守る
 開発者体験の改善
 プログレッシブな守りのチーム
 ビジネス目標の達成をゴールにしない
 DXチーム(Developer eXperience)
 負債の返済を頑張っていきます DX

36. まとめ

37. クソデカチームをScrum@Scaleで分割
 Four Keysで各チームの生産性を見える化
 生産性改善に取り組む
 クソデカチームの負債を返済している途中
 まとめ
 参考文献 tag=kuchitama-22 で
38. Thank you for your listening.