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

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

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