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

by Kuchitama

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

なぜチーム再編したのか 

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

TeamTopology と  逆コンウェイ戦略 

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Team Topology  ● 逆コンウェイ戦略に基づいて、アーキテクチャを狙った形に収束させる ● 境界面での分割 ● 4つのチームタイプ ○ Stream-aligned team ○ Enabling team ○ Complicated-subsystem team ○ Platform team ● 3つのコミュニケーション ○ Collaboration ○ X-as-a-Service ○ Facilitation Team Topology

Slide 12

Slide 12 text

Team Topology  ● アーキテクチャを理想に寄せたい ● コミュニケーションコストを適正化したい ● 認知負荷を下げたいチームを分割 ● うまくいったのか？ ○ 生産性は上がっているのか？どうやって判断するか

Slide 13

Slide 13 text

Four Keys 

Slide 14

Slide 14 text

Four Keys  DORA(DevOps Research and Assessment) が提唱するデリバリーパフォーマンスを示す4つの指標 DORA Four Keys 指標定義デプロイ頻度本番環境へのリリース頻度バリューストリームのスループット変更のリードタイム変更のコミットから本番環境へのデプロイまでの時間変更障害率意図通り動かないコードをリリースした割合デリバリーの安定性平均修復時間障害から復旧するまでの平均時間

Slide 15

Slide 15 text

Four Keys  DORAが提唱するデリバリーパフォーマンスを示す4つの指標 DORA Four Keys 指標デプロイ頻度早く作って早く出す変更のリードタイム変更障害率バグを出さない、出たら早く直す平均修復時間

Slide 16

Slide 16 text

Four Keys  DORAが提唱するデリバリーパフォーマンスを示す4つの指標組織間での比較が可能 DORA Four Keys 指標デプロイ頻度変更のリードタイム変更障害率平均修復時間

Slide 17

Slide 17 text

Four Keys  DORAが提唱するデリバリーパフォーマンスを示す4つの指標どうやって計測するか DORA Four Keys 指標デプロイ頻度変更のリードタイム変更失敗率平均修復時間

Slide 18

Slide 18 text

18  計測できた！

Slide 19

Slide 19 text

19  計測できた！？リードタイム 42日？??  変更失敗率 27.2% ??? 

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

計測できた！データクレンジング大事！！

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Scrum@Scaleに取り組んだ  逆コンウェイ戦略に則ってチームを分割した  Four Keysで生産性を見えるようになった  各チームの課題に対して改善の取り組めている  ここまでの成果 

Slide 30

Slide 30 text

コンウェイの負債 

Slide 31

Slide 31 text

40人以上のチームで開発  Backend  Frontend  管理画面  Frontend  クソデカチーム構成に沿ったアーキテクチャの爆誕

Slide 32

Slide 32 text

40人以上のチームで開発  Backend  Frontend  管理画面  Frontend  チーム毎の責務に沿ったアーキテクチャになっておらず、密結合なコード

Slide 33

Slide 33 text

チーム間の変更範囲が重なる  各チームの変更のマージ期間が必要に  結果、1スプリント1デプロイに律速  密結合アーキテクチャ  デプロイ頻度の更新余地がない 

Slide 34

Slide 34 text

アーキテクチャの改善を進めないと、デプロイ頻度の改善に取り組めない  どのチームが担当するのか？？？  コンウェイの法則の力だけでは解決できないガチガチの密結合アーキテクチャ  密結合アーキテクチャの分解  DXチーム(Developer eXperience)が誕生

Slide 35

Slide 35 text

ストリームアラインドチーム間で落ちる課題の解決  アジャイルのライトウィングを守る  開発者体験の改善  プログレッシブな守りのチーム  ビジネス目標の達成をゴールにしない  DXチーム(Developer eXperience)  負債の返済を頑張っていきます DX 

Slide 36

Slide 36 text

まとめ 

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Thank you for your listening. 