激録・開発密着10ヶ月!! 拡大したスクラムチームの衝突

Regional Scrum Gathering Tokyo 2025 着 密 発 開 ・ 録 激 ! ! 月 ヶ 0 1 衝突 ヨシッ!! 拡大したスクラムチームの 衝突 Daikin Ltd. アジャイル内製化チーム Photo by Morinibu

共通のゴールに向かって 複数のスクラムチームが 自律的に協力して行動するために 何が必要となるのか 2

自己紹介 未経験４名 内製化組織１３名 https://codezine.jp/article/detail/19731 3

• https://codezine.jp/article/detail/19731

自己紹介 4

自己紹介 Agile Coach Aチーム ストリームアラインド Bチーム ストリームアラインド Cチーム プラットフォーム PO PO PO SM SM SM Dev Dev Dev Maneger Dev PO = Product Owner SM = Scrum Master Dev = Developper Dev Dev Maneger Dev

自己紹介 • 2023.07 スクラムフェス大阪 「大手空調メーカーでプロダクト価値にうるさい開発チームができるまで」 • 2024.01 RSGT 2024 「激録・開発密着10ヶ月！！〜消えたスプリントゴールの行方〜」 • 2024.09 スクラムフェス三河 「すべてがモブになる」 • 2024.11 スクラムフェス沖縄 「【地獄のデイリースクラム】アンチパターンぜんぶやってみた」 • ▶︎ 2025.01 RSGT 2025 「激録・開発密着10ヶ月！！〜拡大するスクラムチームの衝突〜」 6

自己紹介 ダイキン工業株式会社 森鳰 武史 Takeshi Morinibu Team Manager (Sta • 好きなこと • 価値検証 Engineer) ・2016年〜 研究職（データサイエンス） • 組織設計 • ゲーム開発 ・2019年〜 ソフトウェアエンジニア（内製開発） 博士（情報科学） 日本オペレーションズ・リサーチ学会 関西支部運営委員 ff 7

自己紹介 ダイキン工業株式会社 好きなこと 平松 尚人 Naoto Hiramatsu ・チーム体制を考える Scrum Master ・リファクタリング ・ドメイン駆動設計 • 現在入社6年目 • 開発歴 4年 • スクラムマスター歴 2年 • プロダクトオーナー歴 半年 8

目次 1. はじめに 2. プロダクトゴールへの注力 ‣ チームトポロジー ‣ ドメイン駆動による分割 3. 自律性な協調 ‣ 重要価値指標 ‣ 意思決定の透明化 4. チーム間の連携 ‣ Spotifyモデル ‣ フィードバックの誤謬 5. まとめ 9

はじめに スケーリングしようと考えたわけではなく、 • 2023年 RSGT2024 • スプリントゴールの改善を開始 • スプリントゴールが有効に機能するように • 2024年 RSGT2025 • プロダクトゴールの検査が進展 • プロダクトゴールの課題が見つかった 課題を一つ一つ改善した結果、チームが連携できるように https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19280/10 10

• https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19280/10

プロダクトゴールに 注力できない 11

2. プロダクトゴールへの注力 当初のチーム体制 データ分析・提案機能 Aチーム（6名） PO Bチーム（６名） PO レポート作成機能 データ基盤 契約管理 SM SM Dev Dev Dev Dev Maneger Dev Maneger Dev Dev Dev 12

2. プロダクトゴールへの注力 目標：商材の契約数を増やす ストリームアラインド ユーザー 分析工数削減 プラットフォーム 基盤の安定化 開発者 Aチームの関心事（プロダクトゴール） スイッチングコストや認知負荷が高い状態 13

興味をもった スクラムマスターと共に リチーミングに取り組んだ 14

2. プロダクトゴールへの注力 • ストリームアラインドチーム：ビジネス価値にフォーカスしてフルスタックで開発 • プラットフォームチーム：ストリームアラインドの認知負荷を下げる チーム間の関係性に特に着目 https://platformengineering.connpass.com/event/321642/ 15

• https://platformengineering.connpass.com/event/321642/

「プラットフォームを製品化するための役割と責任は、 顧客向け製品が成功するのと同じように設定されるべき」 16

2. プロダクトゴールへの注力 顧客との協調 顧客（開発者）との協調 「プラットフォームを製品化するための役割と責任は、 顧客向け製品が成功するのと同じように設定されるべき」 プラットフォームチームにもPOを置いて開発するべきはないか 🤔 17

AWS Re:invent 2023に参加 各ドメインごとにチームを分けたことにより成功した事例の紹介 ドメイン駆動設計 ✖ チームトポロジー 18

ドメインを整理して チームの境界を引き ドメインを移行する https://www.amazon.co.jp/実践ドメイン駆動設計-Object-Oriented-SELECTION-ヴァーン・ヴァーノン/dp/479813161X 19

2. プロダクトゴールへの注力 各チームが担当しているドメインを把握(コンテキストマップ) Bチーム 外部のチーム Aチーム 20

ドメイン駆動による分割 あるべきドメインのまとまりと境界線を引く Cチーム データ基盤(プラットフォーム) 外部のチーム Bチーム 契約管理・資料化 (ストリームアラインド) Aチーム データ分析（ストリームアラインド) 21

ドメイン駆動による分割 Before Aチームが考慮すべきユーザーが多かった Aチーム データ分析 ドメイン ユーザー タイプA Bチーム データ基盤 ドメイン 契約・報告 ドメイン ユーザー タイプB 知るべきことが多く認知負荷が高い 22

ドメイン駆動による分割 After 考慮すべきユーザーが限定され、認知負荷が下がった Aチーム Cチーム Bチーム データ分析 ドメイン データ基盤 ドメイン 契約・報告 ドメイン ユーザー タイプA ユーザー タイプB 各チームがプロダクトゴールに注力できるようになった 23

新たな課題 24

注力はできるようになったが... • 🤔 プロダクトゴールは局所最適化していないか • 🤔 プロダクト全体のバックログを管理すべきではないか • 🤔 チーム間の連携はうまくできているのか 意思決定に対して自信を持てていない 25

プロダクト 全体の優先度を 管理しよう 26

エグゼクティブメタスクラム（メタスクラム） https://scruminc.jp/scrum-at-scale/ 27

• https://scruminc.jp/scrum-at-scale/

あるチームの反発を招いてしまった • Aチームとして • 技術獲得と負債解消の計画をもっていた • メタスクラム • 市場価値の観点のみでやるべきことを判断していた もっと多面的な観点で意思決定すべきなのでは 28

Evidence Based Management（EBM）の重要価値領域 CO2排出量 技術獲得 削減効果の 増加 電力料金の削減 人材 リード 育成・獲得 タイム https://www.servantworks.co.jp/posts/ebm-kva/ 空調制御の 自動化 技術負債 29

• https://www.servantworks.co.jp/posts/ebm-kva/

市場価値だけでなく 組織能力も考慮して 意思決定しよう 30

メタスクラムにDev（テックリード）を呼んだ PO PO PO Dev Dev Dev メタスクラム 適時、SMも呼んで様々な観点で議論した 31

▶︎ ▶︎ 表面的な議論にしかならなかった • 🤔 代表POが判断した方がいいんじゃない？ 統率しなければチーム単独で意思決定できない • 🤔 それよりうちのチームの技術負債の方が深刻じゃない？ 他チームの意思決定に信頼がない 32

各チームは 単独で意思決定できない と捉えている 33

各チームは 自律して意思決定できる と捉えている 34

意思決定の 過程や結果を透明化して 判断の改善を繰り返す 35

横の連携で意思決定に必要な情報を集める Aチーム Bチーム Cチーム メタスクラム PO PO PO スクラムMT SM SM SM Dev Dev Dev 集めた情報をもとに意思決定はチーム毎に行う 36

プロダクトゴールとスプリントゴールに対する公開質問会 週次共有会 Aチーム Bチーム Cチーム PO PO PO SM SM SM Dev Dev Dev スクラムマスター 視点からの質問 次に、より良い意思決定ができるように改善を繰り返す 37

▶︎ ▶︎ ▶︎ 意思決定の透明性と検査がもたらしたもの 意思決定に対する納得性 局所最適性の検査 チームの判断能力は高められるという認識 各チームの意思決定に対して信頼と自信がついた 38

当初の課題 • 🤔 各チームのプロダクトゴールは局所最適化していないか • 🤔 プロダクト全体のバックログを管理すべきではないか • 🤔 チーム間の連携はうまくできているのか 39

当初の課題 • ✅ 各チームのプロダクトゴールは局所最適化していないか • ✅ プロダクト全体のバックログを管理すべきではないか • 🤔 チーム間の連携はうまくできているのか 40

今の状況はSpotifyモデルと似ている Spotify モデル 内製化組織 Manager https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf Aチーム Bチーム Cチーム PO PO PO SM SM SM Dev Dev Dev 41

• https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Spotifyモデルに対する指摘 • Processes for cross-team collaboration must be de ned. Autonomy does not mean leaving teams to self-organize every problem. チーム間の連携のプロセスを定義する必要があります。 自律性とは、チームがあらゆる問題を自ら解決できるようにすることを意味 しません。 https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model fi https://www.jeremiahlee.com/posts/failed-squad-goals/ 42

• https://www.jeremiahlee.com/posts/failed-squad-goals/
• https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model

チーム間の 連携のプロセス 43

経験的卓越性の活用 チームトポロジーで連携はパターン化されている ✖ • 💡発揮された卓越性(良い連携)に気づく • 💡認識することでその発生頻度が増える 連携の頻度をあげるために卓越性を認識 https://amzn.asia/d/cG7vtkw https://amzn.asia/d/9lMpjKX 44

• https://amzn.asia/d/cG7vtkw
• https://amzn.asia/d/9lMpjKX

経験的卓越性の活用 チームを越えて優先度が高い機能を実装 ストリームアラインド プラットフォーム データ分析 ドメイン データ基盤 ドメイン 来週中にデータ基盤に すでにスプリント始まってい 新機能が欲しい るから、来週中は厳しいかも 負荷 No プラットフォームがストリームアラインドのボトルネックになる 45

経験的卓越性の活用 チームを越えて優先度が高い機能を実装 負荷 ストリームアラインド プラットフォーム データ分析 ドメイン データ基盤 ドメイン 負荷 ①新機能の目的を伝える ②受け入れ条件を設定 ③開発してプルリクエスト ④承認してデプロイ OK コラボレーションによりリソースのボトルネックを解消 46

まとめ 47

▶︎ ▶︎ ▶︎ ▶︎ ▶︎ 小さなチームが自律して連携するまで • チームの認知負荷を小さく保つ チームトポロジーをもとにドメインの境界で分割 • チームの意思決定を信頼できるようにする チームの意思決定を透明化 検査に晒すことで判断能力を強化 • 効果的なチーム間の連携を実現する チームトポロジーのパターンをベース 良い連携を認知してその発生を加速 48

Regional Scrum Gathering Tokyo 2025 ご清聴 た し ま い ざ ご う と ありが Photo by Morinibu アジャイル内製化組織