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でスケールさせた話/Scaling Scrum team with...
Search
A1
August 04, 2021
Programming
0
5.2k
スクラム開発チームをLessでスケールさせた話/Scaling Scrum team with Less
開発チームをLessを導入してスケールさせた事例の紹介になります。
A1
August 04, 2021
Tweet
Share
More Decks by A1
See All by A1
Kotlin2でdataクラスの copyメソッドを禁止する/Data class copy function to have the same visibility as constructor
eichisanden
1
190
短納期でローンチした新サービスをJavaで開発した話/launched new service using Java
eichisanden
6
3.7k
トラブルゼロで乗り切ったTypeScript移行/trouble-free TypeScript migration
eichisanden
3
3.2k
息の長いサービスのフロントエンドを少し改善する営み/frontend-improvement
eichisanden
3
2.6k
実はGitLabで使えるmermaid.js/gitlab-mermaid.js
eichisanden
1
520
既存 Web アプリケーションへの React.js 適用/react for web application
eichisanden
0
1.6k
楽楽明細でやってるChatOps/Development with ChatOps
eichisanden
0
1.1k
jshell概要
eichisanden
0
85
楽楽明細の開発を支える技術
eichisanden
0
580
Other Decks in Programming
See All in Programming
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
170
距離関数を極める! / SESSIONS 2024
gam0022
0
290
色々なIaCツールを実際に触って比較してみる
iriikeita
0
330
Quine, Polyglot, 良いコード
qnighy
4
650
Jakarta EE meets AI
ivargrimstad
0
670
Click-free releases & the making of a CLI app
oheyadam
2
120
Tauriでネイティブアプリを作りたい
tsucchinoko
0
370
OSSで起業してもうすぐ10年 / Open Source Conference 2024 Shimane
furukawayasuto
0
110
Arm移行タイムアタック
qnighy
0
330
A Journey of Contribution and Collaboration in Open Source
ivargrimstad
0
970
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
300
카카오페이는 어떻게 수천만 결제를 처리할까? 우아한 결제 분산락 노하우
kakao
PRO
0
110
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
506
140k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
What's in a price? How to price your products and services
michaelherold
243
12k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Designing Experiences People Love
moore
138
23k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Rails Girls Zürich Keynote
gr2m
94
13k
A better future with KSS
kneath
238
17k
How GitHub (no longer) Works
holman
310
140k
Thoughts on Productivity
jonyablonski
67
4.3k
Six Lessons from altMBA
skipperchong
27
3.5k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Transcript
©2021 RAKUS Co., Ltd. #RAKUSMeetup 2021.08.04 / RAKUS Meetup Eiichi
Mita スクラム開発チームを Lessでスケールさせた話
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪自己紹介 Eiichi Mita
@eichisanden 2014年にラクスに中途入社 以来、楽楽明細の開発に従事 フロントエンドもバックエンドもどっちもやるエンジニア 認定スクラムマスター 趣味はSplatoon2(永遠のA帯) 2
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪今回お話するプロダクト「楽楽明細」 3 •
請求書などの帳票を発行するSaaS • ローンチから6年ほど経過しているが成長しているサービス • アプリケーションはモノリシック
©2021 RAKUS Co., Ltd. #RAKUSMeetup 1. 分割前の話 2. 大規模スクラム手法 Less
3. 分割してみる 4. 分割後の話 5. まとめ 4 Contents
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪はじめに • 大規模スクラムLess(Large-Scale
Scrum)の導入事例を紹介します • 1チームスクラムと共通する話やチームビルディングの話もしま す • 発表者はスクラムマスターの役割を担っています 5
©2021 RAKUS Co., Ltd. #RAKUSMeetup 1. 分割前の話 2. 大規模スクラム手法 Less
3. 分割してみる 4. 分割後の話 5. まとめ 6
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪チームを分割することになった背景 1スクラムチームを鍛え続けるのが理想ではあるが… •
肥大化していくプロダクトバックログ • この機能がないと契約できない…(顧客) • この機能がないと競合他社と勝負できない…(営業) • 問い合わせを減らしたいので機能を直して欲しい…(CS) • 潜在顧客にリーチするためこの機能を早く提供したい…(PO) 7
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪チームを分割することになった背景 ニーズに応えるために… •
数年スパンでメンバーを増やしていく人員計画 • 9人/1チームで収まりきらなくなった 8
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ 人数が増えてきたらどうすれば良い? 9 Eak
K.<https://pixabay.com/ja/users/eak_kkk-907811/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1044891>による Pixabay <https://pixabay.com/ja/?utm_source=link-attribution&utm_medium=referral&utm_campaign=image&utm_content=1044891>からの画像
©2021 RAKUS Co., Ltd. #RAKUSMeetup 1. 分割前の話 2. 大規模スクラム手法 Less
3. 分割してみる 4. 分割後の話 5. まとめ 10
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪大規模スクラムの手法 • 「スクラムガイド」は1チーム
での状況が中心に扱われてる • SAFe/DAD/Nexus/Scrum of Scrumsなど、スクラムをスケー ルさせる手法がある • その中でLessを採用した 11 5th State of Agile Reportより引用 https://stateofagile.com/
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪Lessを採用した理由 • 我々のチーム規模に丁度よかった
• 1チームスクラムとの差分が少ない • 役割、成果物、プロセスの追加が殆どない • 元々スクラムをやっているのでメンバーの 負担が少ないと考えた • 単純明快さに惚れた • 公式サイトの「調整と統合」が秀逸 12 上司に紹介されてこの本を読んでいて、実はかなり前から導 入を密かに狙っていました。 ちなみにScrumの本としても良書です ただ話す -------------------- チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題 があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されて います。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合 にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけ です。立ち上がって話に行ってください。 https://less.works/jp/less/framework/coordination-and-integration
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪Lessとは • 「Less
is Scrum」なので、スクラムの原理・原則はそのまま適用される。 • 経験主義、透明性、自己管理チームなど… • 10の原理原則、フレームワーク、 ガイド、実験で構成されている • More with Less • 役割やプロセスは少なくして もっと多くのものを得る • 2~8チームでの開発に対応している。 • それ以上の規模は「Less Huge」が対応している。 13
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪Lessのルール(構造) • 1~3チームに1人のSM
• SMは専任でフルタイム • チームは自律的、多能工、同一ロケーション、長期存続である • 殆どのチームは顧客中心のフィーチャーチームであること 14
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪Lessのルール(プロダクト) • 1人のプロダクトオーナー
• 1つのプロダクトバックログ • 全てのチームで共通のDoneの定義 • 各チームで個別の拡張版Doneの定義を持つこともできる 15
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪Lessのルール(スプリント) • 各チームのスプリントのサイクルは揃える
• 各スプリントの終りにはコードを統合する • スプリントプランニングの1部は複数チームで行う • スプリントプランニングの2部は基本、チーム別で • 関連のあるものは集まって行う • デイリースクラムはチーム単位で行う • スプリントレビューは全体で1つ • ふりかえりはチーム単位で行った後に全体でも実施 16
©2021 RAKUS Co., Ltd. #RAKUSMeetup 1. 分割前の話 2. 大規模スクラム手法 Less
3. 分割してみる 4. 分割後の話 5. まとめ 17
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪分割の方針 • 1チーム5名~6名の2チームに分割
• 戦力が偏って不公平感が出ないように配慮 • チームごとの作業や知識の偏りは防ぎたい • 運用については同列。当番制で両チームが担当する • 各チームは「得意分野・デフォルト担当機能」を持つが、その 他の機能開発も実施する 18 ベテラン ベテラン 中堅 若手 若手 新卒 若手 新卒 ベテラン ベテラン 中堅 SM
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪分割の方針 • チーム名は自分たちで決めて貰った
• 自分達で名前を決めることでオーナー意識を持ってもらいたい • 〇〇さんチームや〇〇機能チーム名は避ける 19
©2021 RAKUS Co., Ltd. #RAKUSMeetup 1. 分割前の話 2. 大規模スクラム手法 Less
3. 分割してみる 4. 分割後の話 5. まとめ 20
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪分割後のチームの変化 • デイリースクラム(朝会)
• スプリントレトロスペクティブ(ふりかえり) • スプリントデモ • スプリントプランニング 21
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪スプリントのタイムスケジュール 22 AM
PM 月 火 水 木 金 朝 会 プラニング1 プラニング2 ふりかえり デモ 夕 会 AM PM 月 火 水 木 金 朝 会 プラニング1 プラニング2 ふりかえり デモ 夕 会 ふりかえり共有 分割前 分割後 →かなり変更は少ない 全員 チーム別 代表者 凡例:
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪デイリースクラム(朝会) • チーム別に実施している
• 内容は1チームスクラムと同じ • 15分間のタイムボックス • 昨日何をしたか/今日何をするか/困っていることは? 23
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪デイリースクラム(朝会) • 他チームの様子を知るために「偵察」を送り込むプラクティスを
紹介したが… • メンバーの意見を聞いた結果、全員参加することに • 全体共有→Aチーム朝会→Bチーム朝会の流れ • 最近はZOOMで実施していて物理的な制約がなく、短時間で済 んでいるので2チームの間はこのスタイルで良いと思っている • 他のチームの話に割って入ってもOK • 「気になったことはどんどん質問しよう」と明確に言っている • チーム間の認識齟齬などは早い段階で発見したい狙い 24
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪スプリントレトロスペクティブ(ふりかえり) • チームごとに実施する
• 翌日、話したサマリーを他チームに共有する • 横断的な課題が出たときはオーバーオールレトロスペクティブを実施する • 大きな機能開発単位でのふりかえりなども必要に応じて開催 25
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪スプリントレトロスペクティブ(ふりかえり) • 現在はMiroで実施している
• 1チームスクラム時代にある程度慣れているのでやり方は任せている • ファシリテーターは持ち回り • KPTなど、手法はファシリテータが決めている • 大抵は下記の流れでやっている 26 1. チェックイン(ルールの確認など) 2. スプリント期間内の事実確認 1. 運用や障害対応はどれぐらいあった? 2. 割り込みはどれぐらいあった? 3. (片方のチームは)感謝を伝える 3. 付箋に記入 4. 話し合うものを投票で決める 5. 話し合い 6. ふりかえりのふりかえり
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪スプリントデモ • ZOOMで週1時間で行っている
• 参加者は事業部長、サポート、PO 、SM 、UIデザイナー、開 発チーム全員 • デモする人は当番制 • 2チームになったが大きな変化はない 27
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪スプリントプランニング • スプリントプランニング1
• POと各チームの代表者が集 まって、どのPBIを担当するか を決める • スプリントプランニング2 • 各チームで個別にプランニン グする(複数チームで協力す る必要があれば複数チームで プランニングする) 28
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪運用 どちらかのチームに作業が依存しないように当番制で行う •
運用当番 • 他部署からの依頼や質問の対応 • リリース当番 • リリース準備と立ち合い、リリース後作業を担当 • アラート監視当番 • 週ごとに当番制 → 担当する人が偏らないようにチーム内でもローテーション 29
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪悩ましいところ • リーダを置くことのジレンマ
• スクラム的にはリーダーという役割はない • スクラムチームが9人までというのはリーダーなしの限界が 9人だから(らしい) • 元々ある問題だったが、2チームになり調整ごとが増え、より 顕著に • 経験年数、性格によってはリーダに頼りたい様子 • 今の自分達には、「リード役」がいないと難しいという事実を 受け止め一旦はリーダーありの状態を許容している • 壁打ち相手になって「いいじゃない」という感じにしたい • 「決めて下さい」のような会話が多くないかは注視する 30
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪悩ましいところ • PO
が実質Proxy 問題 • 現状はビジネス側のステークホルダーの意向をPOが確認していて一人の POという原則を守れていないのが課題 • プロダクトオーナーなのかプロジェクトマネージャなのか • POがプロジェクトマネージャ的な役割も一部担っている 現状はこれで前に進むしかないが、POの仕事に集中することでスピード感 アップしたい 31 事業 部長 製品 企画 PO 開発組織 ビジネス側 優先順位や要件を 確認
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪悩ましいところ • いつの間にか「作ること」目的になってしまっていないか?
• ちゃんと使ってもらいたい人に、使いやすいものを作れているの か? • 大きな機能開発ではユーザインタビューをするようにした • ユーザから直接意見を聞くことでの学びが多い 32
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪悩ましいところ • インフラがチームに入っていない
• 情報格差や受け渡しのコストが掛かりやすい • 現状は同じチームに入れることは難しいので情報共有を小まめ にやり、お互いの領域をカバーし合うしかない • デザイナーもチームに入っていない • プレゼンテーションナルなコンポーネントをStorybookに切り出 して作業分担しやすいようにトライ 33
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪リモートワークでどうなったか • チーム開発の進め方としては大きな影響はなかった。
• そのためには気軽に会話が始められる仕掛けが必要 • 固定のZOOMのURLを用意しておく • BチームはNeWorkを使用中 34
©2021 RAKUS Co., Ltd. #RAKUSMeetup 1. 分割前の話 2. 大規模スクラム手法 Less
3. 分割してみる 4. 分割後の話 5. まとめ 35
©2021 RAKUS Co., Ltd. #RAKUSMeetup あ ▪まとめ • 大きなギャップもなく2チーム制に移行できている
• 2チームになったことで情報の受け渡しなどのオーバーヘッドが 増えたことは間違いないが、必要なコストの範囲 • 3~4チームになると別の課題が出るとは思うが今の延長で行けそ うな感触 • スクラムが出来ていればLessはやりやすい • 他の大規模スクラムのフレームワークと比べてLessは導入しやす い(と思う) 36
©2021 RAKUS Co., Ltd. #RAKUSMeetup ご清聴ありがとうございました 37