スクラムチームの立ち上げから複数フィーチャーチームへのスケーリングに至るまで

Transcript

1. スクラムチームの立ち上げから 複数フィーチャーチームへのスケーリングに至るまで Sho Kitawaki KDDI CORPORATION System Management Department 2020年 9月 26日
2. 自己紹介 © 2020 KDDI 1 名前： 北脇 翔（きたわき しょう） 所属： KDDI システムマネジメント部 仕事： アプリケーション開発 役割： Scrum Master / Engineer 経験： インフラ〜アプリまで広く(浅く)
3. サービスのご紹介 2  豊富なチャージ方法と決済方法  会員数が2,300万超 au PAY 残高による支払い au PAY 残高へのチャージ au ショップ 現金 他 小売店舗 キャッシュバック 通信料合算 KDDIサービス ポイント クレジットカード オンライン © 2020 KDDI au PAY プリペイドカード じぶん銀行 au PAY アプリ au PAY 残高 Android iOS Apple Pay
4. 本日お話したいこと • スクラムを導入した話 - なぜ導入したのか - 導入にあたってどんなことをしたか • スクラムチームをスケールした話 - なぜスケールしたのか - どうやってスケールしたのか • やってみた気付き - 良かったこと - 苦労した(している)こと © 2020 KDDI 3
5. 当時の開発体制 4 当時(1年半前)フロントアプリの開発体制は、 企画部門と開発チーム(スマホアプリ、サーバ)が3つ (※サービスの開発体制はもっとたくさん) © 2020 KDDI 企画部門 開発 (サーバ) 開発[社内] (アプリ) 開発[社外] (アプリ)
6. 当時の開発体制 5 そんな体制の中、1つの開発チームと企画チームに スクラム導入しました（これが前半のお話） 企画部門 開発 (サーバ) 開発[社内] (アプリ) 開発[社外] (アプリ) スクラム導入 © 2020 KDDI
7. 6 なぜ、スクラムを導入したのか？ © 2020 KDDI
8. なぜスクラムを導入したか？ 2019年の大型リリース後、企画-開発で目指す姿をディスカッション 目指す開発の姿   開発の優先順位がチームで共通認識となった状態 2週間程度でアプリをアップデートできる状態 これを埋めたい！ 現状(当時) © 2020 KDDI  開発の要件毎の優先度が決まっていない、要件変更が急に発生する  開発着手〜リリースまでに最低1ヶ月程度要する 7
9. なぜスクラムを導入したか？ 2019年の大型リリース後、企画-開発で目指す姿をディスカッション 目指す開発の姿   開発の優先順位がチームで共通認識となった状態 2週間程度でアプリをアップデートできる状態 それ、スクラムで、できるんじゃない？ 現状(当時) © 2020 KDDI  開発の要件毎の優先度が決まっていない、要件変更が急に発生する  開発着手〜リリースまでに最低1ヶ月程度要する 8
10. なぜスクラムを導入したか？ 大事(だと思う)なこと • スクラムを導入することが目的ではない • でも、現状の課題に適してそう - 短い開発サイクルで改善を繰り返す - 優先順位の明確化 - 実績多数 • あくまで、目指す開発の姿と現状の差を埋めるために、 スクラムが適しているんじゃない？という発想 • まずはやってみる © 2020 KDDI 9
11. スクラムの導入にあたって スクラムやろうと決めたが何から始めよう・・・ • 企画も開発もアジャイル、スクラムの理解はばらばら - 経験者 〜 用語も知らないメンバーまで様々 • 企画と開発のメンバーがお互いの業務をちゃんと知らない ワークショップをやろう © 2020 KDDI 10
12. 2つのワークショップを開催 企画・開発の各担当者が - スクラムのフレームワークと各自の役割を理解する - バックログ作成と優先順位付けの考え方を理解する 《アジャイル導入ワークショップ》 アジャイル/スクラムの概要・目的等の勉強会 © 2020 KDDI 《PO実践ワークショップ》 疑似サービスを使ったストーリー作成、バックログの 作成・見積もり 11
13. イベント・プロセスの設計 12  プロダクトバックログを作った  1週間スプリントでイベント設計 PBL SBL Excel 1 Week Sprint Redmine Mon Tue Wed Thu Fri BLリファイン メント SPレビュー デイリースクラム PO © 2020 KDDI Devチーム[社内] (アプリ) 振り返り プランニング
14. やってみてどうだった？ 13 ▪課題解決のアクション 12 発生 Sprint 課題 アクション 達成 Sprint SP2 プロダクトバックログが整備されていない 要件の優先順位がわからない バックログ/更新ルールの整備とリファインメント の定例化 SP5 SP2 企画-開発間でのコミュニケーションが足りない 連絡手段が統一されていない PO-Dev全員でSlack利用、アカウント整備 SP9 SP6 企画内レビューで仕様変更の手戻りが多い 実機レビューを定例化 アプリのレビュー環境を整備 SP5 SP2 優先タスクを見落としがち Redmineのスプリントバックログが見づらい Redmineのタスクツリーを優先順位で設定、 SP1 使い方を共有 SP5 Slackでの問い合わせ方法(聞き方)を決める、投げっぱなし で回答リードタイムがかかる 質問はClosedQuestion、案を出して確認 をルール化 SP7 SP4 Slackでスピーディーに確認できるようになったが、QAが仕様 書に反映されおらず認識漏れがある QA結果をSlackにPIN留め、朝会後に毎日 チーム内共有する SP5 4 SP3 スプリントレビューの事前準備や周知が足りない スプリントレビューの実機準備とレビューコメント SP5 メモ作成&Slack通知を毎週持ち回り化 2 SP4 実装、PRレビュー以外の作業をした際の適切なタスクがない バッファチケットの共有、入力方法の再周知 アクションした課題の数 10 8 6 取組 着手 SP4 … 0 © 2020 KDDI SP2 SP4 SP6 SP8 SP10
15. やってみてどうだった？ 14 ▪課題解決のアクション 12 発生 Sprint 課題 アクション 達成 Sprint SP2 プロダクトバックログが整備されていない 要件の優先順位がわからない バックログ/更新ルールの整備とリファインメント の定例化 SP5 SP2 企画-開発間でのコミュニケーションが足りない 連絡手段が統一されていない PO-Dev全員でSlack利用、アカウント整備 SP9 SP6 企画内レビューで仕様変更の手戻りが多い 実機レビューを定例化 アプリのレビュー環境を整備 SP2 優先タスクを見落としがち Redmineのスプリントバックログが見づらい Redmineのタスクツリーを優先順位で設定、 SP1 使い方を共有 SP5 Slackでの問い合わせ方法(聞き方)を決める、投げっぱなし で回答リードタイムがかかる 質問はClosedQuestion、案を出して確認 をルール化 SP7 SP4 Slackでスピーディーに確認できるようになったが、QAが仕様 書に反映されおらず認識漏れがある QA結果をSlackにPIN留め、朝会後に毎日 チーム内共有する SP5 4 SP3 スプリントレビューの事前準備や周知が足りない スプリントレビューの実機準備とレビューコメント SP5 メモ作成&Slack通知を毎週持ち回り化 2 SP4 実装、PRレビュー以外の作業をした際の適切なタスクがない バッファチケットの共有、入力方法の再周知 アクションした課題の数 10 8 半年ほどやってみて、徐々に浸透 SP5 6 取組 着手 SP4 … 0 © 2020 KDDI SP2 SP4 SP6 SP8 SP10
16. やってみてどうだった？ 良かったこと • 案件の優先順位がわかるようになった • レビューのフィードバックで認識違いなどを早めにキャッチアップできた 一方で課題も・・・ • 事業案件が多く1チームではアウトプットに限界がある • アプリだけ速くなってもリリースできない場合がある © 2020 KDDI 15
17. やってみてどうだった？ 16 良かったこと • 案件の優先順位がわかるようになった • レビューのフィードバックで認識違いなどを早めにキャッチアップできた 一方で課題も・・・ • 事業案件が多く1チームではアウトプットに限界がある • アプリだけ速くなってもリリースできない場合がある リリースサイクルの ボトルネックを探りたい © 2020 KDDI バリューストリームマップ を作ってみた
18. バリューストリームマップ PO / Devの各担当者でリリースまでのタスクを洗い出し - リリースまでのプロセスを相互理解する - リリースボトルネックを抽出する (1)タスクの洗い出し © 2020 KDDI (2)タスクを順番に並べて全体プロセスを作成 17
19. バリューストリームマップの気付き 企画 アプリ開発 (社内) アプリ開発 (社外) サーバ開発 アプリ リリース POが各開発チームに要件説明していて 負荷が大きくリードタイムを要する サーバ リリース © 2020 KDDI サーバとアプリの待ち合わせ リードタイムが長い 18
20. バリューストリームマップの気付き 確かにスクラムは導入したけど・・・ 企画部門 スクラム バック ログ 開発[社内] (アプリ) © 2020 KDDI 開発 (サーバ) 開発[社外] (アプリ) 19
21. バリューストリームマップの気付き プロダクトのバックログは1本ではない。企画部門は各開発チームに それぞれ要件を提示し、サーバとアプリの開発で優先度が不一致の状態。 要求 仕様 企画部門 スクラム バック ログ 開発[社内] (アプリ) © 2020 KDDI 開発 (サーバ) 要求 仕様 開発[社外] (アプリ) 20
22. 1チームスクラムの課題(再掲) • 事業案件 (要求アウトプットが大きい)が多く1チームでは アウトプットに限界がある (スケールするにしても、緊急対応もあるので柔軟な開発も必要) スクラムチームを複数チームにスケーリング • アプリだけ速くなってもリリースできない場合がある - POが各開発チームに要件説明、リードタイムを要する - サーバとアプリの待ち合わせリードタイムが長い © 2020 KDDI 21
23. スクラムチームのスケーリング スクラムチームの複数チームへのスケーリングを検討。 複数チームでのスクラムイベント設計はLeSSを参考に。 © 2020 KDDI 22
24. 複数チームでのイベント設計 • 各チームのイベント • 全チーム合同のイベント 2h/w 2h/w 15m/d 0.5h/w 1h/w ② デイリースクラ ム スプリント レビュー ① バックログをタスク に分解し各タスク を見積もる。 タスクは1日以内 のサイズ。 チームの進捗、 課題を確認。 スプリントの成果物を 実機でレビュー。 チーム内 振り返り。 各開発 チーム 各開発 チーム 開発チーム 全員 各開発 チーム スプリントプランニング ① 1 Week Sprint をそれぞれ設計 1h/w バックログリファインメント 23 0.5h/w 振り返り ② バックログ① バックログ① バックログ① チームA バックログ② バックログ② チームB バックログ③ バックログ③ チームC … どのチームがどのバックログを 実施するかを決める。 バックログを、開発着手できる 状態(Ready)にする。 © 2020 KDDI タスク② タスク③ バックログを優先順に並び替える。 (直近のスプリント分) PO タスク① 開発チーム 全員 PO 開発チーム 全員 PO 振り返りのPO/チーム 間共有。 PO 開発チーム 全員
25. 1チームスクラムの課題(再掲) • 事業案件 (要求アウトプットが大きい)が多く1チームでは アウトプットに限界がある (スケールするにしても、緊急対応もあるので柔軟な開発も必要) スクラムチームを複数チームにスケーリング • アプリだけ速くなってもリリースできない場合がある - POが各開発チームに要件説明、リードタイムを要する - サーバとアプリの待ち合わせリードタイムが長い クロスファンクショナルなフィーチャーチーム © 2020 KDDI 24
26. コンポーネントチームからフィーチャーチームへ • これまでは、アプリとサーバが別々のコンポーネントチーム • アプリとサーバが同一チームに属するクロスファンクショナルな フィーチャーチームに変更 © 2020 KDDI 25
27. スクラムチームのスケーリング まとめ 1チームスクラム アプリ開発チーム(社内) バックログ 26 スクラムチームのスケーリング後 優先順を 決める JIRA バックログA 開発チーム(社内) アプリ/サーバ バックログB 案件 PO アプリ開発チーム(社外) 案件 バックログC PO サーバ開発チーム バックログD 開発チーム(社内) アプリ/サーバ … 開発チーム(社外) アプリ • POが各チームに要件を個別に説明(負荷大) 一元的な案件の優先度はなし • 全チームイベントで要件共有(PO負荷低減) • バックログの優先順位を一元化して明確化 • アプリとサーバに別れたコンポーネントチーム • アプリとサーバの待ち合わせリードタイムが発生 • アプリとサーバが同じチーム(フィーチャーチーム)で 最優先のバックログを実行 © 2020 KDDI
28. 27 やってみた © 2020 KDDI
29. 28 どうだった？ © 2020 KDDI
30. 結果から・・・ 29 ▪再掲： 2019年の大型リリース後、企画-開発で目指す姿をディスカッション 目指す開発の姿   開発の優先順位がチームで共通認識となった状態 2週間程度でアプリをアップデートできる状態  バックログの1本化で優先度が明確になった  25回以上/年 のリリースが達成 現状(当時) © 2020 KDDI  開発の要件毎の優先度が決まっていない、要件変更が急に発生する  開発着手〜リリースまでに最低1ヶ月程度要する
31. スクラムチームのスケーリングの振り返り 30 ▪スクラムイベント チームアンケート結果(5段階) No. 項目 1-1 1-2 1-3 1-4 1-5 1-6 デイリースクラム スプリントプランニング スプリントレビュー レトロスペクティブ オーバーオールレトロスペクティブ プロダクトバックログリファインメント 平均 順位 4.5 4.4 4.1 4.4 3.4 3.6 1 3 4 2 6 5 良かった点 • デイリースクラムでコンポーネントに関わらずタスクのゴール・優先順が把握できる • チーム内振り返りは、チームの課題が解決しやすくなった 改善点 • 全体振り返りは、チームのローカルな改善になりがちで参加意識が薄れてしまう • バックログリファインメントで全チームのバックログを2h/wの間に Readyにすることは困難 © 2020 KDDI
32. スクラムチームのスケーリングの振り返り 31 ▪チーム変更 チームアンケート結果(5段階) No. 項目 2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 2-10 2-11 イベントなど、発言しにくい雰囲気がある やることが不明確な時、自分やチームで何をするべきか見極め実施することができる 自分の担当分野だけではなく、チームメンバーの担当タスクをサポートすることができる チーム間の情報共有はうまくいっている 社内と社外の拠点間の情報共有は上手くいっている POとの情報共有がスムーズにできている 開発するアイテムについてなぜ開発するのか、ユーザにとっての価値がわかる ユーザの利用シーンを考えてもっとこうしたらいいという提案ができるようになった サーバとアプリ間で、いずれかの開発待ちでリードタイムが伸びることがなくなった コンポーネントチームからフィーチャーチーム化を進めました。どちらが良いと感じたか メンバーの幸福度はアップしている 良かった点 ・アプリとサーバが同じチームになりリードタイムの短縮を実感 改善点 ・ユーザの利用シーンを考えた開発からの提案 © 2020 KDDI 平均 順位 3.5 3.8 3.6 3.4 3.3 3.6 3.5 3.1 3.8 3.5 3.5 7 2 3 9 10 4 6 11 1 5 7
33. 新たな課題への取り組み 改善点 ▪チーム合同のイベントに改善点が多い • バックログリファインメントの2h/wの間に、全チームのバックログ をReadyにすることは困難 • ユーザの利用シーンを考えた開発からの提案 ▪アクション • 全体のバックログリファインメントを見直し - 全体のバックログリファインメントは要件概要+QAのみ - 各開発チームとPOでリファインメント • POからの仕様を待つのではなく開発チームでも仕様案作成をリード - ConfluenceやCacooを使いチームでモブ設計ワークを実施 © 2020 KDDI 32
34. 33 他にもいろいろ取り組んでいますが・・・ 本日はここまで！ © 2020 KDDI
35. 34 Thank you © 2020 KDDI