Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スクラムチームをスケールする〜LeSS導入3ヶ月の振り返りと課題〜/scaling-the-s...
Search
Genki Sano
January 11, 2024
Technology
2
810
スクラムチームをスケールする〜LeSS導入3ヶ月の振り返りと課題〜/scaling-the-scrum-team
Genki Sano
January 11, 2024
Tweet
Share
More Decks by Genki Sano
See All by Genki Sano
やる気のない自分との向き合い方/How to Deal with Your Unmotivated Self
sanogemaru
2
700
リーダーになったら未来を語れるようになろう/Speak the Future
sanogemaru
0
620
ソフトウェアの複雑性と認知負荷/Software Complexity and Cognitive Load
sanogemaru
0
43
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
2k
ソフトウェアは捨てやすく作ろう/Let's make software easy to discard
sanogemaru
12
7.2k
SQLアンチパターンを読んでリファクタしてみた / sql-anti-pattern-refactored-2022
sanogemaru
0
630
カオナビのチーム開発の裏側
sanogemaru
0
1.2k
Other Decks in Technology
See All in Technology
TypeScript 6.0で非推奨化されるオプションたち
uhyo
15
5k
Bedrock のコスト監視設計
fohte
2
220
マルチドライブアーキテクチャ: 複数の駆動力でプロダクトを前進させる
knih
0
9.8k
JavaScript パーサーに using 対応をする過程で与えたエコシステムへの影響
baseballyama
1
140
グローバルなコンパウンド戦略を支えるモジュラーモノリスとドメイン駆動設計
kawauso
3
8.4k
クラスタ統合リアーキテクチャ全貌~1,000万ユーザーのウェルネスSaaSを再設計~
hacomono
PRO
0
150
アジャイル社内普及ご近所さんマップを作ろう / Let's create an agile neighborhood map
psj59129
1
140
Greenは本当にGreenか? - B/GデプロイとAPI自動テストで安心デプロイ
kaz29
0
130
Dev Containers と Skaffold で実現する クラウドネイティブ開発環境 ローカルのみという制約に挑む / Cloud-Native Development with Dev Containers and Skaffold: Tackling the Local-Only Constraint
bitkey
PRO
0
130
AIと自動化がもたらす業務効率化の実例: 反社チェック等の調査・業務プロセス自動化
enpipi
0
780
不確実性に備える ABEMA の信頼性設計とオブザーバビリティ基盤
nagapad
4
7.2k
膨大なデータをどうさばく? Java × MQで作るPub/Subアーキテクチャ
zenta
0
120
Featured
See All Featured
Being A Developer After 40
akosma
91
590k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
980
For a Future-Friendly Web
brad_frost
180
10k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Statistics for Hackers
jakevdp
799
230k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
31
2.7k
Thoughts on Productivity
jonyablonski
73
4.9k
A better future with KSS
kneath
239
18k
Fireside Chat
paigeccino
41
3.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
118
20k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.1k
Transcript
スクラムチームをスケールする 〜LeSS導入3ヶ月の振り返りと課題〜 2024.01.11 @RSGT2024 | Genki Sano © kaonavi, inc.
タレントマネジメントシステム「カオナビ」 社員の個性・才能を発掘し 戦略人事を加速させるタレントマネジメントシステム © kaonavi, inc. 2
自己紹介 © kaonavi, inc. 3 所属 : 株式会社カオナビ 職種 :
バックエンドエンジニア 役割 : テックリード 趣味 : コーヒー、サウナ、ライブ参戦 X(Twitter) : @sanogemaru 佐野 元気 Genki Sano
本セッションのモチベーション © kaonavi, inc. 4 • LeSSを導入して実験の途中 • 成功した話だけじゃなくて、失敗した話を聞きたい •
議論のネタとして使いたい
INDEX 1. チームをスケールした背景 2. なぜ LeSS なのか 3. 導入のプロセス 4.
導入後の変化と課題 5. 将来の展望 6. まとめ © kaonavi, inc. 5
INDEX 1. チームをスケールした背景 2. なぜ LeSS なのか 3. 導入のプロセス 4.
導入後の変化と課題 5. 将来の展望 6. まとめ © kaonavi, inc. 6
スケール以前のチーム体制 © kaonavi, inc. 7 PO ENGINEER DESIGNER QC TEAM
スケール以前のチーム体制 © kaonavi, inc. 8 PO ENGINEER DESIGNER QC TEAM
運用していく中で 課題が出てきた
チームをスケールした動機 © kaonavi, inc. 9 ユーザーにとって一連した動作になりやすい2つの機能を 別々の2チームで運用していた 機能A 機能B 運用を担当
運用を担当 2つの機能を セットで触る ユーザー チームA チームB
チームをスケールした動機 © kaonavi, inc. 10 以下のような問題が発生 • 機能開発するのに、毎回同じチームとの連携が必要 • 連携する機能について、関係性は深いがよく知らない
• etc.
チームをスケールした動機 © kaonavi, inc. 11 機能A 機能B 運用を担当 運用を担当 2つの機能を
セットで触る ユーザー チームA チームB
チームをスケールした動機 © kaonavi, inc. 12 機能A 機能B 運用を担当 運用を担当 2つの機能を
セットで触る ユーザー チームA チームB 合併した 新チームの誕生!
本当にスケールする必要ある? © kaonavi, inc. 13
本当にスケールは必要なのか © kaonavi, inc. 14 チームのスケールを考える前に、まずは1 つのチームを維持したままうまくやる方法 は本当にないのか、というのをギリギリま で考え抜いてください。 ※引用:
スクラムの拡張による組織づくり - 複数のスクラムチームをScrum@Scaleで運用する
本当にスケールは必要なのか © kaonavi, inc. 15 以下の理由からスケールさせることにした • ビジネス的に短期的なアウトプットが維持されることが重 要だった •
失敗した時に戻しやすくしたかった
INDEX 1. チームをスケールした背景 2. なぜ LeSS なのか 3. 導入のプロセス 4.
導入後の変化と課題 5. 将来の展望 6. まとめ © kaonavi, inc. 16
※引用: 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 LeSS(Large-Scale Scrum)とは © kaonavi,
inc. 17 LeSSは、1つのプロダクトを複数 チームで協働するために考えられた スクラムです。
LeSS(Large-Scale Scrum)とは © kaonavi, inc. 18 LeSSはスクラムの原理・原則、目的、要 素、洗練された状態を大規模な状況にでき るだけシンプルに適用したものです。 ※引用:
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
LeSS(Large-Scale Scrum)とは © kaonavi, inc. 19 スクラムを シンプルに適用し 拡張したもの
※引用: 16th Annual State Of Agile Report 他の大規模アジャイルフレームワーク ©
kaonavi, inc. 20
※引用: 16th Annual State Of Agile Report 他の大規模アジャイルフレームワーク ©
kaonavi, inc. 21
LeSSを選択した理由 © kaonavi, inc. 22 小規模から導入しやすい フレームワークであるため SAFe や S@S
の場合、ある程度の規模の組織に対して適用させるフレームワークであり、具体的に SAFe では ART の最低人数が 50 名と定められている。 一方で LeSS は、2 チームから始められるシンプルなフレームワークであるため、今回のケースにはぴっ たりだと考えた。
INDEX 1. チームをスケールした背景 2. なぜ LeSS なのか 3. 導入のプロセス 4.
導入後の変化と課題 5. 将来の展望 6. まとめ © kaonavi, inc. 23
導入後に目指した姿 © kaonavi, inc. 24 PO ENGINEER DESIGNER QC TEAM
導入後に目指した姿 © kaonavi, inc. 25 PO ENGINEER DESIGNER QC TEAM
UNIT UNIT
導入時に行ったこと © kaonavi, inc. 26 1. キックオフの実施 2. 各種イベントの 目的とゴールを整理
導入時に実施した内容としては以下の2点
導入時に行ったこと © kaonavi, inc. 27 1. キックオフの実施 LeSS導入の背景と目指す姿を共有する時間を作った。 狙いとしては、以下の2点。 •
現状の課題を共有し、変化に対しての抵抗感を減らす • 目指す姿を共有し、チームとしての一体感を持ちやすくする
導入時に行ったこと © kaonavi, inc. 28 2. 各種イベントの目的とゴールを整理 LeSS を実践する上で、各種イベントは下記のような性質がある。 •
現行の1チームで行うスクラムとの違いが出やすい • 具体のイメージがしやすく、疑問・質問が出やすい そのため、先に情報の整理を行った。
INDEX 1. チームをスケールした背景 2. なぜ LeSS なのか 3. 導入のプロセス 4.
導入後の変化と課題 5. 将来の展望 6. まとめ © kaonavi, inc. 29
LeSS導入後に起こった課題 © kaonavi, inc. 30 導入後に起こった課題として、代表的なものは以下の3点 1. POの手が回らなくなった 2. LeSSに対する認識にズレが生じた
3. チームとしての一体感が薄い
LeSS導入後に起こった課題 © kaonavi, inc. 31 導入後に起こった課題として、代表的なものは以下の3点 1. POの手が回らなくなった 2. LeSSに対する認識にズレが生じた
3. チームとしての一体感が薄い
課題1. POの手が回らなくなった © kaonavi, inc. 32 ※引用: 大規模スクラム Large-Scale Scrum(LeSS)
アジャイルとスクラムを大規模に実装する方法 LeSSのプロダクトオーナーは、簡単に過 負荷になってしまいます。
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 33 PO の業務をチームに委任していく
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 34 代表的な取り組み • 受入条件の記入をQC中心に実施 •
ユニットPO制の導入 PO の業務をチームに委任していく
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 35 代表的な取り組み • 受入条件の記入をQC中心に実施 •
ユニットPO制の導入 PO の業務をチームに委任していく
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 36 よかったこと • QC が早い段階で仕様を把握出来るようになった
• テスト分析を先に行えるようになり、テスト設計の時間を短 縮できた
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 37 新たな課題 • 受入条件が機能に向きやすくなってしまった
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 38 代表的な取り組み • 受入条件の記入をQC中心に実施 •
ユニットPO制の導入 PO の業務をチームに委任していく
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 39 PO ENGINEER DESIGNER QC
TEAM UNIT UNIT
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 40 PO ENGINEER DESIGNER QC
TEAM UNIT UNIT ユニットPO
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 41
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 42 ※引用: 大規模スクラム LeSS の各スクラムチームに「チームPO制」を導入してみた
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 43 ユニットPO制は、まだ実験中...
課題1. POの手が回らなくなった(解決策) © kaonavi, inc. 44 ユニットPO制は、まだ実験中... これから自分たちの形にしていく!
LeSS導入後に起こった課題 © kaonavi, inc. 45 導入後に起こった課題として、代表的なものは以下の3点 1. POの手が回らなくなった 2. LeSSに対する認識にズレが生じた
3. チームとしての一体感が薄い
課題2. LeSSに対する認識にズレが生じた © kaonavi, inc. 46 ある日のオーバーオールレトロスペクティブにて
課題2. LeSSに対する認識にズレが生じた © kaonavi, inc. 47 ある日のオーバーオールレトロスペクティブにて チームとして 目指している先が よく分からない
課題2. LeSSに対する認識にズレが生じた © kaonavi, inc. 48 ある日のオーバーオールレトロスペクティブにて チームとして 目指している先が よく分からない
ユニット間で LeSSやスクラムの 知識に差分がある ように思えて 劣等感を感じる
課題2. LeSSに対する認識にズレが生じた © kaonavi, inc. 49
課題2. LeSSに対する認識にズレが生じた © kaonavi, inc. 50 ある日のオーバーオールレトロスペクティブにて チームとして 目指している先が よく分からない
ユニット間で LeSSやスクラムの 知識に差分がある ように思えて 劣等感を感じる
課題2. LeSSに対する認識にズレが生じた © kaonavi, inc. 51 ある日のオーバーオールレトロスペクティブにて LeSS や スクラム
における いいチームが よく分からない ユニット間で LeSSやスクラムの 知識に差分がある ように思えて 劣等感を感じる
課題2. LeSSに対する認識にズレが生じた © kaonavi, inc. 52 ある日のオーバーオールレトロスペクティブにて LeSS や スクラム
における いいチームが よく分からない LeSS や スクラム の知識に自信がない
課題2. LeSSに対する認識にズレが生じた(解決策) © kaonavi, inc. 53 勉強会を開催 • 週1回/30分 •
スクラムの基本から、LeSS本を網羅するまで • チーム全員でやる
課題2. LeSSに対する認識にズレが生じた(解決策) © kaonavi, inc. 54 勉強会を開催 • 週1回/30分 •
スクラムの基本から、LeSS本を網羅するまで • チーム全員でやる 時間を伸ばす or 頻度を増やす を検討中
LeSS導入後に起こった課題 © kaonavi, inc. 55 導入後に起こった課題として、代表的なものは以下の3点 1. POの手が回らなくなった 2. LeSSに対する認識にズレが生じた
3. チームとしての一体感が薄い
課題3. チームとしての一体感が薄い © kaonavi, inc. 56 チームの合併時に取った戦略 合併前のチームの開発フローを崩さないが、 なるべく連携が取りやすいようにする
課題3. チームとしての一体感が薄い © kaonavi, inc. 57 チームの合併時に取った戦略 合併前のチームの開発フローを崩さないが、 なるべく連携が取りやすいようにする 短期的なアウトプットが維持されること
制約として以下が存在
課題3. チームとしての一体感が薄い © kaonavi, inc. 58 起こったこと • プロダクトバックログが2つある •
異なる完成の定義がある • ユニットで独自の進化を遂げるようになってきた
課題3. チームとしての一体感が薄い © kaonavi, inc. 59 合併前とあまり変わらないのでは? 起こったこと • プロダクトバックログが2つある
• 異なる完成の定義がある • ユニットで独自の進化を遂げるようになってきた
課題3. チームとしての一体感が薄い(解決策) © kaonavi, inc. 60 オーバーオールレトロスペクティブを全員参加 にする
課題3. チームとしての一体感が薄い(解決策) © kaonavi, inc. 61 ※引用: Introduction to LeSS
| less.works
課題3. チームとしての一体感が薄い(解決策) © kaonavi, inc. 62 ※引用: Introduction to LeSS
| less.works 全員でやってみる
課題3. チームとしての一体感が薄い(解決策) © kaonavi, inc. 63 オーバーオールレトロスペクティブを全員参加 にする まだ実施はしておらず、これからやる予定
INDEX 1. チームをスケールした背景 2. なぜ LeSS なのか 3. 導入のプロセス 4.
導入後の変化と課題 5. 将来の展望 6. まとめ © kaonavi, inc. 64
将来の展望 © kaonavi, inc. 65 第1段階 第2段階 第3段階 現在 半年後
n年後
将来の展望 © kaonavi, inc. 66 第1段階 第2段階 第3段階 現在 半年後
n年後 今の施策を 着実に進める
将来の展望 © kaonavi, inc. 67 第1段階 第2段階 第3段階 現在 半年後
n年後 グループからチームへ 今の施策を 着実に進める
やろうとしていること 将来の展望 © kaonavi, inc. 68 ユニットを統合してみる 期待する効果 • 同じ1つのチームという意識を持ちたい
• プロダクトバックログを1つにしたい
将来の展望 © kaonavi, inc. 69 第1段階 第2段階 第3段階 現在 半年後
n年後 グループからチームへ 他チームと協力して 組織全体での ムーブメントを起こす 今の施策を 着実に進める
INDEX 1. チームをスケールした背景 2. なぜ LeSS なのか 3. 導入のプロセス 4.
導入後の変化と課題 5. 将来の展望 6. まとめ © kaonavi, inc. 70
まとめ © kaonavi, inc. 71 • タックマンモデルで言う「混乱期」真っ只中 • 最も大切な時期なので、コンフリクトを恐れずに意見をぶ つけ合って、いいチームを作っていきたい
We are hiring!! https://corp.kaonavi.jp/recruit/