SlideShare a Scribd company logo
株式会社リクルートライフスタイル
塚越啓介・今井恵⼦
⼩さく始める⼤規模スクラム
⼤規模スクラムってどういうこと?
PO
Team
SM
#000 はじめに
PO
Team
SM
Team
SM
Team
SM
Team
SM
⼤規模スクラムってこういうこと!
#000 はじめに
⾃⼰紹介
#001 Airレジについて
AirREGI海外版
CSM / Engineer
Recruit LifeStyle
啓介
k t s u k a g o
塚越
AirREGI海外版
CSPO
Recruit LifeStyle
今井i k e k o
恵⼦
本⽇のAgenda
Air REGIについて
なぜチャレンジしたのか?
⼤規模スクラムはじめました
運営ハードモード
チームと歩んだ半年
まとめ
#000 はじめに
# 001
# 006
# 002
# 003
# 004
# 005
チームの歩み
#000 はじめに
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
AIR REGIについて
Agenda #001
AirREGIってどんなサービス?
飲⾷店、⼩売店の会計業務を⽀える
シンプルでカンタンな⾼性能POSレジアプリ
#001 Airレジについて
↑
今回はこっちの話
今回のお話
Recruit LifeStyle
↑
前回こっちの話をしました
Air
REGI
Air
PAYMENT
Air
RESERVE
Air
WAIT
国内版
Air
REGI
海外版
#001 Airレジについて
開発チームを取り巻く環境
Scrum Team
PO
SM
Team
Design
Group
Marketing
Group
Development
Group
Business Team
PRODUCER
Sales
Design Team
UX
UI
GM
GM
GM
#001 Airレジについて
なぜチャレンジしたのか
Agenda #002
スクラムって少⼈数のイメージ
スクラムって少⼈数のイメージ
⼤規模なスクラムってあまり聞かない
#002 なぜチャレンジしたのか
プロダクトもチームも、作って終わりではない
◯ プロダクト✕ プロジェクト
継続的な改善が⾏える組織にしたい
#002 なぜチャレンジしたのか
スカイツリー
What(何を作るか)を継続的に改善する
プロダクト
ユーザーが
求める物
Release
FB
Release
FB
Release
FB
Release
FB
#002 なぜチャレンジしたのか
→ マーケットニーズが⾒えづらい
海外という未知の領域でのプロダクト開発
How(どうやって作るか)を継続的に改善する
定期的に改善することで開発速度を⾼めていく
●コード量 ●複雑度
●コード量 ●複雑度
ソフトウェアは放っておくと⾃然と複雑になっていく
#002 なぜチャレンジしたのか
⼤規模スクラムはじめました
Agenda #003
⼤規模スクラムはじめました
導⼊ 構築 理解
#003 ⼤規模スクラムはじめました
⼤規模スクラムはじめました
導⼊ 構築 理解
#003 ⼤規模スクラムはじめました
垂直⽴ち上げもできますが
PO
Team
SM
Team
SM
Team
SM
Team
SM
失敗した時の影響範囲が⼤きい
#003 ⼤規模スクラムはじめました
1チームずつの導⼊がおすすめです!
PO
Team
SM
Team
SM
Team
SM
Team
SM
開発と同じく⼩さな成功体験の積み重ねが重要
#003 ⼤規模スクラムはじめました
⼤規模スクラムはじめました
導⼊ 構築 理解
#003 ⼤規模スクラムはじめました
複数スクラムチームで構成もできますが
PO
Team
SM
iOS Team
PO
Team
SM
Infra Team
PO
Team
SM
Android Team
PO
Team
SM
WEB Team
#003 ⼤規模スクラムはじめました
複数開発チームでの構成がおすすめです!
PO
Team
SM
Dev Team
Team
SM
Dev Team
Team
SM
Dev Team
Team
SM
Dev Team
#003 ⼤規模スクラムはじめました
決定スピードアップに繋がる
横断組織がない → ボトルネックがなくなる
POが1⼈ → ⼿戻りや持ち帰りの調整がなくなる
#003 ⼤規模スクラムはじめました
職能別チームにもできますが
iOS
iOS
iOS Team
iOS
iOS
WEB
WEB
Web Team
WEB
WEB
Infra
Infra
Infra Team
Infra
Infra
Android
Android
Android Team
Android
Android
#003 ⼤規模スクラムはじめました
職能横断チームがおすすめです!
Infra
Android
WEB
iOS
A Team
Infra
Android
WEB
iOS
D Team
Infra
Android
WEB
iOS
B Team
Infra
Android
WEB
iOS
C Team
#003 ⼤規模スクラムはじめました
Task Task Task Task
Task Task
And
roid
iOS Task Task
他の職能を⾃然と習得していく
#003 ⼤規模スクラムはじめました
増員するとVelocityが安定しなくなる
ちなみに、増員する時は注意が必要
↓
リリース予測ができず、中⻑期計画が⽴てられない
#003 ⼤規模スクラムはじめました
各チームに追加していくと全チームが不安定に
Team
SM
Dev Team
Team
SM
Dev Team
Team
SM
Dev Team
Team
SM
Dev Team
#003 ⼤規模スクラムはじめました
新規メンバー受け⼊れ専⽤チームを作る
Team
SM
Dev Team
Team
SM
Dev Team
SM
Dev Team
SM
Dev Team
Mentor
#003 ⼤規模スクラムはじめました
⼤規模スクラムはじめました
導⼊ 構築 理解
#003 ⼤規模スクラムはじめました
1番やっちゃダメなのは全⾯導⼊!
各所でハレーションが起こりやすい
全員が初⼼者なので、問題があった時混乱が⽣じる
失敗した時の影響範囲が⼤きい
#003 ⼤規模スクラムはじめました
周囲の協⼒が必要です
#003 ⼤規模スクラムはじめました
周囲を巻き込む時気をつけるべきこと
#003 ⼤規模スクラムはじめました
今までのやり⽅を否定しない
⼀⼈で推し進めてはいけない
協⼒者が⼀⼈もいない状態でやるべきではない
運営ハードモード
Agenda #004
運営ハードモード
#004 運営ハードモード
当事者
意識の
⽋如
外野
対応
PO
⼤変
運営ハードモード
#004 運営ハードモード
当事者
意識の
⽋如
外野
対応
PO
⼤変
1チームの時と同じやり⽅では上⼿くいかない!
ひとりひとりの当事者意識が⽋如する
⼤⼈数だとディスカッションにならない
#004 運営ハードモード
⼤⼈数に適したアレンジ⽅法を⾒つけていく
セレモニー⾃体を振り返ろう
PO/SMでセレモニーのやり⽅を振り返り、
継続的に改善していく
#004 運営ハードモード
振り返りから⽣まれたTRYの例
⼤⼈数だとディスカッションにならない
→ 振り返りなどで代表者制を導⼊
スプリントレビューが⼤量&無意味なものに
→ スプリント中に都度PO確認
チーム間の連携が上⼿くいかない
→ デイリースクラムを偵察に⾏く
#004 運営ハードモード
運営ハードモード
#004 運営ハードモード
当事者
意識の
⽋如
外野
対応
PO
⼤変
組織の中で何かと⽬⽴ってしまう
なんか
変わったこと
やってる
本当に成果
でてるの?
今までのやり⽅で
いいんじゃない?
#004 運営ハードモード
共通⾔語で話そう
レトロスペクティブ
ベロシティ
ストーリーポイント
セレモニー
スプリント
スクラム
アクセプタンスクライテリア
デイリースクラム
プロダクトバックログ リファインメント
スクラムマスター
プロダクトオーナー
スプリントレビュー
ワーキングアグリーメント
Done/Undone
#004 運営ハードモード
透明性を上げよう
Scrum Team
PO
SM
Team
Business Team
PRODUCER
Sales
GM
Marketing
Group
GM
Development
Group
PO SM PM
#004 運営ハードモード
運営ハードモード
#004 運営ハードモード
当事者
意識の
⽋如
外野
対応
PO
⼤変
POの負荷が膨⼤になる
/ステークホルダー調整/etc…
1週間100を超えるチケット /膨⼤な要件定義
/チームメンバーからの質疑応答 /様々な決め事
#004 運営ハードモード
チームの成⻑が求められる
具体例は次のセクションで
チームへの権限委譲、当事者意識の醸成が重要
#004 運営ハードモード
チームと歩んだ半年
Agenda #005
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
過保護なPO、受け⾝なチーム
#005 チームと歩んだ半年
https://www.flickr.com/photos/dirigentens/4592361218/
POがチームにチケットを割り当てる
POがチーム間、部署間の調整を⾏う
POが仕様を細かく決めないと開発できない
効率の良い作業分担をチームで決める
⼦離れ、親離れ
#005 チームと歩んだ半年
https://www.flickr.com/photos/tambako/8601484790/
仕様の細かい部分はチームが考える
チーム間や他部署間調整をチーム⾃⾝で⾏う
リーダーが欲しい
#005 チームと歩んだ半年
リーダーが欲しいです
Team
スクラムではメンバーひとりひとりが⾃律的であり
全員が圧倒的当事者意識をもっていてつまり…
PO
そうだ、リーダーじゃなくメンターを置こう
PO
とはいえ困ったときに相談したり、
開発の⼤⽅針を決める⼈が必要です
Team
コンポーネントメンター制度
#005 チームと歩んだ半年
✕ 責任者/管理者 ◯ 先⽣/相談役
承認者になってはいけない
コンポーネント毎にボランティアで構成
教育したり、相談に乗ったりする
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
誰のために何を作っているのかわからない
#005 チームと歩んだ半年
ターゲットが海外、かつtoBなので⾝近ではなく
誰にどう使われるのかピンとこない
↓
要件通りに作ればいいんでしょ
ユーザーに会いに⾏こう
#005 チームと歩んだ半年
現地調査で業務を観察&インタビュー
業務フローを整理し
ユーザーストーリーマッピングで⾒える化
ユーザーになりきることで使いにくさや
改善ポイントが⾒えてくる
ロールプレイでユーザーの気持ちを体感
#005 チームと歩んだ半年
Sprint Reviewの時間でお店屋さんごっこ
チームが顧客視点を持つということ
#005 チームと歩んだ半年
決定/合意プロセスが早くなる
業界の「当たり前」を知る
POやビジネスサイドと⽬線が揃う
技術知識とドメイン知識のバランス
#005 チームと歩んだ半年
ドメイン知識
技
術
的
専
⾨
知
識
このあた
りを⽬指
そう
こっちを
⽬指しが
ちですが
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
クロスファンクショナルなチームへ
#005 チームと歩んだ半年
上のチケットはアプリの⼈しかできないんで、
下の⽅のチケットからやります
Team
優先順位の⾼いチケットから開発してね
PO
誰がどのチケットでもとれればもっと早く
ユーザーに価値を提供できるのに…
PO
クロスファンクショナルなチームへ
#005 チームと歩んだ半年
なんとかして!スクラムマスター!
PO
⾊々必要なんだな…
PO
SM
まず、まとまった期間が必要ですね
教えてあげる先⽣も必要です
そんなにカンタンにできないっすよ
メンバーのスキルを⾒える化する
#005 チームと歩んだ半年
誰が何を得意としているかがわかる
誰がメンターになり得るかわかる
Name iOS Android WEB インフラ Design
⾚⽊ ◯ ✕ ◎ ◯ ◯
⽮代 ◯ ✕ ◎ ◯ △
張 ◎ ◯ △ ◯ △
島村 ◎ ✕ △ △ △
五⼗六式に教える
#005 チームと歩んだ半年
それ以外のチケットを作らない
#005 チームと歩んだ半年
APP キャッシャーとして注⽂をとりたい
APP キャッシャーとして現⾦会計したい
APP キャッシャーとしてクレジット会計したい
APP キャッシャーとしてレシートを印字したい
ユーザーにとって開発チームのスキルは関係ない
優先順位を強烈に意識づける
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
無駄をなくそう
#005 チームと歩んだ半年
事前に調査しないと開発できません
Team
じゃあ調査してください
PO
開発以外のところに無駄な時間が
かかっている気がする…
PO
こちら調査結果です
Team
1週間後
無駄を⾒える化する
#005 チームと歩んだ半年
無駄は悪いものだと認識させる
無駄を⽇常的に削る意識をつける
結果、開発にかけられる時間が増える
要件定義から開発完了までを早く
#005 チームと歩んだ半年
要件定義
PO
ワイヤー作成
UX Designer
デザイン作成
UI Designer
input
input
開発
Team
input
要件定義
ワイヤー作成
PO
UX Designer
UI Designer
開発
Team
Team
リファインメントで⼀気にやる
#005 チームと歩んだ半年
Engineer/Designer/PO間で共通認識が作りやすい
コスト安/ユーザビリティのバランスが取りやすい
cost
cost
デザイナーだけで
考えたUIUX
チームで考えた
UIUX
チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年
まとめ
Agenda #006
スプリント計画
1週間の流れ
⽉ ⽕⽔ ⽊ ⾦ ⽔
リファインメント
ロールプレイ
SHへエスカレ
チーム毎振り返り
全体振り返り
デイリースクラム
開発
#006 まとめ
セレモニー振返り
まとめ
#006 まとめ
導⼊
運営
成⻑
⼩さく始めて横展する
細かく振り返り、継続的に改善する
チームの⾃律性を育てていく
関係者対して透明性を上げる

More Related Content

小さく始める大規模スクラム