エンタープライズアジャイル勉強会でお話しさせて頂く内容です。 http://www.ogis-ri.co.jp/event/1247455_6738.html

1. 株式会社リクルートライフスタイル
塚越啓介・今井恵⼦
⼩さく始める⼤規模スクラム

2. ⼤規模スクラムってどういうこと？
PO
Team
SM
#000 はじめに

3. PO
Team
SM
Team
SM
Team
SM
Team
SM
⼤規模スクラムってこういうこと！
#000 はじめに

4. ⾃⼰紹介
#001 Airレジについて
AirREGI海外版
CSM / Engineer
Recruit LifeStyle
啓介
k t s u k a g o
塚越
AirREGI海外版
CSPO
Recruit LifeStyle
今井i k e k o
恵⼦

5. 本⽇のAgenda
Air REGIについて
なぜチャレンジしたのか？
⼤規模スクラムはじめました
運営ハードモード
チームと歩んだ半年
まとめ
#000 はじめに
# 001
# 006
# 002
# 003
# 004
# 005

6. チームの歩み
#000 はじめに
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ

7. AIR REGIについて
Agenda #001

8. AirREGIってどんなサービス？
飲⾷店、⼩売店の会計業務を⽀える
シンプルでカンタンな⾼性能POSレジアプリ
#001 Airレジについて

9. ↑
今回はこっちの話
今回のお話
Recruit LifeStyle
↑
前回こっちの話をしました
Air
REGI
Air
PAYMENT
Air
RESERVE
Air
WAIT
国内版
Air
REGI
海外版
#001 Airレジについて

10. 開発チームを取り巻く環境
Scrum Team
PO
SM
Team
Design
Group
Marketing
Group
Development
Group
Business Team
PRODUCER
Sales
Design Team
UX
UI
GM
GM
GM
#001 Airレジについて

11. なぜチャレンジしたのか
Agenda #002

12. スクラムって少⼈数のイメージ
スクラムって少⼈数のイメージ
⼤規模なスクラムってあまり聞かない
#002 なぜチャレンジしたのか

13. プロダクトもチームも、作って終わりではない
◯ プロダクト✕ プロジェクト
継続的な改善が⾏える組織にしたい
#002 なぜチャレンジしたのか
スカイツリー

14. What(何を作るか)を継続的に改善する
プロダクト
ユーザーが
求める物
Release
FB
Release
FB
Release
FB
Release
FB
#002 なぜチャレンジしたのか
→ マーケットニーズが⾒えづらい
海外という未知の領域でのプロダクト開発

15. How(どうやって作るか)を継続的に改善する
定期的に改善することで開発速度を⾼めていく
●コード量 ●複雑度
●コード量 ●複雑度
ソフトウェアは放っておくと⾃然と複雑になっていく
#002 なぜチャレンジしたのか

16. ⼤規模スクラムはじめました
Agenda #003

17. ⼤規模スクラムはじめました
導⼊ 構築 理解
#003 ⼤規模スクラムはじめました

18. ⼤規模スクラムはじめました
導⼊ 構築 理解
#003 ⼤規模スクラムはじめました

19. 垂直⽴ち上げもできますが
PO
Team
SM
Team
SM
Team
SM
Team
SM
失敗した時の影響範囲が⼤きい
#003 ⼤規模スクラムはじめました

20. １チームずつの導⼊がおすすめです！
PO
Team
SM
Team
SM
Team
SM
Team
SM
開発と同じく⼩さな成功体験の積み重ねが重要
#003 ⼤規模スクラムはじめました

21. ⼤規模スクラムはじめました
導⼊ 構築 理解
#003 ⼤規模スクラムはじめました

22. 複数スクラムチームで構成もできますが
PO
Team
SM
iOS Team
PO
Team
SM
Infra Team
PO
Team
SM
Android Team
PO
Team
SM
WEB Team
#003 ⼤規模スクラムはじめました

23. 複数開発チームでの構成がおすすめです！
PO
Team
SM
Dev Team
Team
SM
Dev Team
Team
SM
Dev Team
Team
SM
Dev Team
#003 ⼤規模スクラムはじめました

24. 決定スピードアップに繋がる
横断組織がない → ボトルネックがなくなる
POが1⼈ → ⼿戻りや持ち帰りの調整がなくなる
#003 ⼤規模スクラムはじめました

25. 職能別チームにもできますが
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 ⼤規模スクラムはじめました

26. 職能横断チームがおすすめです！
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 ⼤規模スクラムはじめました

27. Task Task Task Task
Task Task
And
roid
iOS Task Task
他の職能を⾃然と習得していく
#003 ⼤規模スクラムはじめました

28. 増員するとVelocityが安定しなくなる
ちなみに、増員する時は注意が必要
↓
リリース予測ができず、中⻑期計画が⽴てられない
#003 ⼤規模スクラムはじめました

29. 各チームに追加していくと全チームが不安定に
Team
SM
Dev Team
Team
SM
Dev Team
Team
SM
Dev Team
Team
SM
Dev Team
#003 ⼤規模スクラムはじめました

30. 新規メンバー受け⼊れ専⽤チームを作る
Team
SM
Dev Team
Team
SM
Dev Team
SM
Dev Team
SM
Dev Team
Mentor
#003 ⼤規模スクラムはじめました

31. ⼤規模スクラムはじめました
導⼊ 構築 理解
#003 ⼤規模スクラムはじめました

32. １番やっちゃダメなのは全⾯導⼊！
各所でハレーションが起こりやすい
全員が初⼼者なので、問題があった時混乱が⽣じる
失敗した時の影響範囲が⼤きい
#003 ⼤規模スクラムはじめました

33. 周囲の協⼒が必要です
#003 ⼤規模スクラムはじめました

34. 周囲を巻き込む時気をつけるべきこと
#003 ⼤規模スクラムはじめました
今までのやり⽅を否定しない
⼀⼈で推し進めてはいけない
協⼒者が⼀⼈もいない状態でやるべきではない

35. 運営ハードモード
Agenda #004

36. 運営ハードモード
#004 運営ハードモード
当事者
意識の
⽋如
外野
対応
PO
⼤変

37. 運営ハードモード
#004 運営ハードモード
当事者
意識の
⽋如
外野
対応
PO
⼤変

38. １チームの時と同じやり⽅では上⼿くいかない！
ひとりひとりの当事者意識が⽋如する
⼤⼈数だとディスカッションにならない
#004 運営ハードモード

39. ⼤⼈数に適したアレンジ⽅法を⾒つけていく
セレモニー⾃体を振り返ろう
PO/SMでセレモニーのやり⽅を振り返り、
継続的に改善していく
#004 運営ハードモード

40. 振り返りから⽣まれたTRYの例
⼤⼈数だとディスカッションにならない
→ 振り返りなどで代表者制を導⼊
スプリントレビューが⼤量＆無意味なものに
→ スプリント中に都度PO確認
チーム間の連携が上⼿くいかない
→ デイリースクラムを偵察に⾏く
#004 運営ハードモード

41. 運営ハードモード
#004 運営ハードモード
当事者
意識の
⽋如
外野
対応
PO
⼤変

42. 組織の中で何かと⽬⽴ってしまう
なんか
変わったこと
やってる
本当に成果
でてるの？
今までのやり⽅で
いいんじゃない？
#004 運営ハードモード

43. 共通⾔語で話そう
レトロスペクティブ
ベロシティ
ストーリーポイント
セレモニー
スプリント
スクラム
アクセプタンスクライテリア
デイリースクラム
プロダクトバックログ リファインメント
スクラムマスター
プロダクトオーナー
スプリントレビュー
ワーキングアグリーメント
Done/Undone
#004 運営ハードモード

44. 透明性を上げよう
Scrum Team
PO
SM
Team
Business Team
PRODUCER
Sales
GM
Marketing
Group
GM
Development
Group
PO SM PM
#004 運営ハードモード

45. 運営ハードモード
#004 運営ハードモード
当事者
意識の
⽋如
外野
対応
PO
⼤変

46. POの負荷が膨⼤になる
／ステークホルダー調整／etc…
1週間100を超えるチケット ／膨⼤な要件定義
／チームメンバーからの質疑応答 ／様々な決め事
#004 運営ハードモード

47. チームの成⻑が求められる
具体例は次のセクションで
チームへの権限委譲、当事者意識の醸成が重要
#004 運営ハードモード

48. チームと歩んだ半年
Agenda #005

49. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

50. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

51. 過保護なPO、受け⾝なチーム
#005 チームと歩んだ半年
https://www.flickr.com/photos/dirigentens/4592361218/
POがチームにチケットを割り当てる
POがチーム間、部署間の調整を⾏う
POが仕様を細かく決めないと開発できない

52. 効率の良い作業分担をチームで決める
⼦離れ、親離れ
#005 チームと歩んだ半年
https://www.flickr.com/photos/tambako/8601484790/
仕様の細かい部分はチームが考える
チーム間や他部署間調整をチーム⾃⾝で⾏う

53. リーダーが欲しい
#005 チームと歩んだ半年
リーダーが欲しいです
Team
スクラムではメンバーひとりひとりが⾃律的であり
全員が圧倒的当事者意識をもっていてつまり…
PO
そうだ、リーダーじゃなくメンターを置こう
PO
とはいえ困ったときに相談したり、
開発の⼤⽅針を決める⼈が必要です
Team

54. コンポーネントメンター制度
#005 チームと歩んだ半年
✕ 責任者／管理者 ◯ 先⽣／相談役
承認者になってはいけない
コンポーネント毎にボランティアで構成
教育したり、相談に乗ったりする

55. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

56. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

57. 誰のために何を作っているのかわからない
#005 チームと歩んだ半年
ターゲットが海外、かつtoBなので⾝近ではなく
誰にどう使われるのかピンとこない
↓
要件通りに作ればいいんでしょ

58. ユーザーに会いに⾏こう
#005 チームと歩んだ半年
現地調査で業務を観察＆インタビュー
業務フローを整理し
ユーザーストーリーマッピングで⾒える化

59. ユーザーになりきることで使いにくさや
改善ポイントが⾒えてくる
ロールプレイでユーザーの気持ちを体感
#005 チームと歩んだ半年
Sprint Reviewの時間でお店屋さんごっこ

60. チームが顧客視点を持つということ
#005 チームと歩んだ半年
決定／合意プロセスが早くなる
業界の「当たり前」を知る
POやビジネスサイドと⽬線が揃う

61. 技術知識とドメイン知識のバランス
#005 チームと歩んだ半年
ドメイン知識
技
術
的
専
⾨
知
識
このあた
りを⽬指
そう
こっちを
⽬指しが
ちですが

62. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

63. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

64. クロスファンクショナルなチームへ
#005 チームと歩んだ半年
上のチケットはアプリの⼈しかできないんで、
下の⽅のチケットからやります
Team
優先順位の⾼いチケットから開発してね
PO
誰がどのチケットでもとれればもっと早く
ユーザーに価値を提供できるのに…
PO

65. クロスファンクショナルなチームへ
#005 チームと歩んだ半年
なんとかして！スクラムマスター！
PO
⾊々必要なんだな…
PO
SM
まず、まとまった期間が必要ですね
教えてあげる先⽣も必要です
そんなにカンタンにできないっすよ

66. メンバーのスキルを⾒える化する
#005 チームと歩んだ半年
誰が何を得意としているかがわかる
誰がメンターになり得るかわかる
Name iOS Android WEB インフラ Design
⾚⽊ ◯ ✕ ◎ ◯ ◯
⽮代 ◯ ✕ ◎ ◯ △
張 ◎ ◯ △ ◯ △
島村 ◎ ✕ △ △ △

67. 五⼗六式に教える
#005 チームと歩んだ半年

68. それ以外のチケットを作らない
#005 チームと歩んだ半年
APP キャッシャーとして注⽂をとりたい
APP キャッシャーとして現⾦会計したい
APP キャッシャーとしてクレジット会計したい
APP キャッシャーとしてレシートを印字したい
ユーザーにとって開発チームのスキルは関係ない
優先順位を強烈に意識づける

69. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

70. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

71. 無駄をなくそう
#005 チームと歩んだ半年
事前に調査しないと開発できません
Team
じゃあ調査してください
PO
開発以外のところに無駄な時間が
かかっている気がする…
PO
こちら調査結果です
Team
1週間後

72. 無駄を⾒える化する
#005 チームと歩んだ半年
無駄は悪いものだと認識させる
無駄を⽇常的に削る意識をつける
結果、開発にかけられる時間が増える

73. 要件定義から開発完了までを早く
#005 チームと歩んだ半年
要件定義
PO
ワイヤー作成
UX Designer
デザイン作成
UI Designer
input
input
開発
Team
input
要件定義
ワイヤー作成
PO
UX Designer
UI Designer
開発
Team
Team

74. リファインメントで⼀気にやる
#005 チームと歩んだ半年
Engineer/Designer/PO間で共通認識が作りやすい
コスト安/ユーザビリティのバランスが取りやすい
cost
cost
デザイナーだけで
考えたUIUX
チームで考えた
UIUX

75. チームの歩み
受け⾝ ⾃発
顧客
視点
多能⼯
スピード
アップ
#005 チームと歩んだ半年

76. まとめ
Agenda #006

77. スプリント計画
１週間の流れ
⽉ ⽕⽔ ⽊ ⾦ ⽔
リファインメント
ロールプレイ
SHへエスカレ
チーム毎振り返り
全体振り返り
デイリースクラム
開発
#006 まとめ
セレモニー振返り

78. まとめ
#006 まとめ
導⼊
運営
成⻑
⼩さく始めて横展する
細かく振り返り、継続的に改善する
チームの⾃律性を育てていく
関係者対して透明性を上げる