Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

21,841 views

Published on

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

Published in: Technology

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

  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. 1チームずつの導⼊がおすすめです! 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. 1番やっちゃダメなのは全⾯導⼊! 各所でハレーションが起こりやすい 全員が初⼼者なので、問題があった時混乱が⽣じる 失敗した時の影響範囲が⼤きい #003 ⼤規模スクラムはじめました
  33. 33. 周囲の協⼒が必要です #003 ⼤規模スクラムはじめました
  34. 34. 周囲を巻き込む時気をつけるべきこと #003 ⼤規模スクラムはじめました 今までのやり⽅を否定しない ⼀⼈で推し進めてはいけない 協⼒者が⼀⼈もいない状態でやるべきではない
  35. 35. 運営ハードモード Agenda #004
  36. 36. 運営ハードモード #004 運営ハードモード 当事者 意識の ⽋如 外野 対応 PO ⼤変
  37. 37. 運営ハードモード #004 運営ハードモード 当事者 意識の ⽋如 外野 対応 PO ⼤変
  38. 38. 1チームの時と同じやり⽅では上⼿くいかない! ひとりひとりの当事者意識が⽋如する ⼤⼈数だとディスカッションにならない #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. スプリント計画 1週間の流れ ⽉ ⽕⽔ ⽊ ⾦ ⽔ リファインメント ロールプレイ SHへエスカレ チーム毎振り返り 全体振り返り デイリースクラム 開発 #006 まとめ セレモニー振返り
  78. 78. まとめ #006 まとめ 導⼊ 運営 成⻑ ⼩さく始めて横展する 細かく振り返り、継続的に改善する チームの⾃律性を育てていく 関係者対して透明性を上げる

×