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
790
スクラムチームをスケールする〜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
0
500
リーダーになったら未来を語れるようになろう/Speak the Future
sanogemaru
0
390
ソフトウェアの複雑性と認知負荷/Software Complexity and Cognitive Load
sanogemaru
0
33
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.8k
ソフトウェアは捨てやすく作ろう/Let's make software easy to discard
sanogemaru
12
7.1k
SQLアンチパターンを読んでリファクタしてみた / sql-anti-pattern-refactored-2022
sanogemaru
0
630
カオナビのチーム開発の裏側
sanogemaru
0
1.1k
Other Decks in Technology
See All in Technology
【Kaigi on Rails 事後勉強会LT】MeはどうしてGirlsに? 私とRubyを繋いだRail(s)
joyfrommasara
0
260
Digitization部 紹介資料
sansan33
PRO
1
5.5k
Geospatialの世界最前線を探る [2025年版]
dayjournal
1
220
エンタメとAIのための3Dパラレルワールド構築(GPU UNITE 2025 特別講演)
pfn
PRO
0
320
プレーリーカードを活用しよう❗❗デジタル名刺交換からはじまるイベント会場交流のススメ
tsukaman
0
160
なぜAWSを活かしきれないのか?技術と組織への処方箋
nrinetcom
PRO
4
890
ビズリーチ求職者検索におけるPLMとLLMの活用 / Search Engineering MEET UP_2-1
visional_engineering_and_design
1
130
プロダクトのコードから見るGoによるデザインパターンの実践 #go_night_talk
bengo4com
1
2.5k
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
930
セキュアな認可付きリモートMCPサーバーをAWSマネージドサービスでつくろう! / Let's build an OAuth protected remote MCP server based on AWS managed services
kaminashi
3
320
PHPからはじめるコンピュータアーキテクチャ / From Scripts to Silicon: A Journey Through the Layers of Computing Hiroshima 2025 Edition
tomzoh
0
140
能登半島地震において デジタルができたこと・できなかったこと
ditccsugii
0
200
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Done Done
chrislema
185
16k
Docker and Python
trallard
46
3.6k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Become a Pro
speakerdeck
PRO
29
5.5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
35
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/