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.1k
スクラム開発チームをLessでスケールさせた話/Scaling Scrum team with Less
開発チームをLessを導入してスケールさせた事例の紹介になります。
A1
August 04, 2021
Tweet
Share
More Decks by A1
See All by A1
短納期でローンチした新サービスをJavaで開発した話/launched new service using Java
eichisanden
6
3.7k
トラブルゼロで乗り切ったTypeScript移行/trouble-free TypeScript migration
eichisanden
3
3.1k
息の長いサービスのフロントエンドを少し改善する営み/frontend-improvement
eichisanden
3
2.6k
実はGitLabで使えるmermaid.js/gitlab-mermaid.js
eichisanden
1
490
既存 Web アプリケーションへの React.js 適用/react for web application
eichisanden
0
1.6k
楽楽明細でやってるChatOps/Development with ChatOps
eichisanden
0
1.1k
jshell概要
eichisanden
0
84
楽楽明細の開発を支える技術
eichisanden
0
570
内部構造から学ぶGit
eichisanden
2
280
Other Decks in Programming
See All in Programming
Kubernetes上でOracle_Databaseの運用を楽にするOraOperatorの紹介
nnaka2992
0
150
Kotlin Multiplatform at Stable and Beyond (Kotlin Vienna, October 2024)
zsmb
2
360
実践Dash - 手を抜きながら本気で作るデータApplicationの基本と応用 / Dash for Python and Baseball
shinyorke
2
470
ROS 2のZenoh対応とZenohのROS 2対応
takasehideki
2
300
Serverless renderování Webových komponent
rarous
PRO
0
100
RemixとCloudflare Stack におけるFile Upload
ossamoon
1
130
Cloud Adoption Framework にみる組織とクラウド導入戦略
tomokusaba
2
510
CSC509 Lecture 03
javiergs
PRO
0
140
Removing Corepack
yosuke_furukawa
PRO
9
1.2k
DevFest Android in Korea 2024 - 안드로이드의 문단속 : 앱을 지키는 암호화 이야기
mdb1217
1
160
PHPを書く理由、PHPを書いていて良い理由 / Reasons to write PHP and why it is good to write PHP
seike460
PRO
5
460
What is TDD?
urakawa_jinsei
1
220
Featured
See All Featured
Scaling GitHub
holman
458
140k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
10
1.4k
Writing Fast Ruby
sferik
626
60k
Become a Pro
speakerdeck
PRO
24
4.9k
Adopting Sorbet at Scale
ufuk
73
9k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
[RailsConf 2023] Rails as a piece of cake
palkan
49
4.7k
Statistics for Hackers
jakevdp
796
220k
A better future with KSS
kneath
237
17k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
228
52k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
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