大規模スクラムの失敗から学んだこと #AgileJapan2015

1. 大規模スクラムの失敗から学んだこと ∼急成長をとげるAirレジの組織拡大の取り組み∼ ㈱リクルートライフスタイル塚越啓介・佐橘一旗

2. 自己紹介 • Itsuki Sakitsu - エンジニア • 初期からのスクラム導入推進役 • Keisuke Tsukagoshi - エンジニア • スクラム支援、コーチング

3. 大規模スクラムって？

4. 普通のスクラム Product Owner Scrum Master Team Product

5. 大規模スクラム？ Product Owner Scrum Master Team Product

6. 大規模スクラム？ Product Owner Scrum Master Team Product

7. 大規模スクラム PO Lead Company Board UX Specialist Portofolio Architect PO Lead Architect Releaser Architect Releaser Product Product Scrum Support

8. 本日お伝えしたいことスケールアップしてもスクラムの原理原則はかわらないスクラムの導入に最も重要なのは「Why」「検証と適応と透明性」

9. アジェンダ 1. Airレジとは？ 2. なぜスクラムに取り組んだのか？ 3. 大規模アジャイル開発、検証と適応からの学び 4. 今後、挑戦したい課題 5. まとめ

10. 1. Airレジとは？ About AirREGI

11. 無料で簡単に使えるPOSレジアプリ

12. Aサービス Bサービス

13. 2.なぜスクラムに取り組んだのか？ Why SCRUM?

14. 我々は何故、 • スクラムを行うのか？ • 未経験の事業領域、試行錯誤の必要性 • スケールする必要があったのか？ • 相互に連携する複数のサービスを、全体整合性を保ちつつも並行して立ち上げたい

15. ぶっちゃけた話

16. 当たり前を当たり前にやりたいから

17. 当時の状況要件決まってないから開発できない

18. 当時の状況要件決まってないから開発できないこれ、全然イケテナイ言われたから作るか

19. 当時の状況そんな話きいてないけど

20. 当時の状況こんなスケジュール無理にきまってるじゃん

21. 当時の状況こんなスケジュール無理にきまってるじゃん

22. 目指したもの • 率直な意見を言い合える文化 • チームが協力してものづくりを行える文化 • 常に成長を続けられる文化

23. なぜスクラムをはじめたのか当たり前を当たり前にやりたいから

24. 3. 大規模アジャイル開発、検証と適応からの学び How we learned, tried and adopted

25. 組織拡大の歴史 2014/03 現在2014/06 さらに拡大 Scrum 試験導入既存体制 Product / Component 機能組織全面適用 WF体制 2013/11 組織拡大

26. 組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入既存体制 Product / Component 機能組織全面適用 WF体制 2013/11 組織拡大 Phase1. Scrum試験導入

27. 組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入既存体制 Product / Component 機能組織全面適用 WF体制 2013/11 組織拡大 Phase2. Scrum全面適応

28. 組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入既存体制 Product / Component 機能組織全面適用 WF体制 2013/11 組織拡大 Phase3. 組織の拡大

29. 2.1. WFからスクラムへ How we started SCRUM

30. 組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入既存体制 Product / Component 機能組織全面適用 WF体制 2013/11 組織拡大 Phase1. Scrum試験導入

31. はじまり • 「今のプロセスを改善したい」 • Scrum Boot Campを購入 • まずはカタチから

32. WF開発 Product

33. WF開発 + スクラムチーム ProductProduct

34. 当初導入できたこと • アーティファクト • プロダクトバックログ、スプリントバックログ(KANBAN) • セレモニー • 計画ミーティング、朝会、振り返り、スプリントレビュー

35. やってみた結果 • 開発タスクが漏れなくなった • 他メンバーが何をしているか見えるようになった • 案件や進め方に対して意見が出せるように

36. スクラムよかった！ • 知見者がいない状態でも導入効果はある • 形だけの導入でも効果はでる

37. スゲーうまくいった

38. スクラムうまくいったから他のチームも全部スクラムでやろう！

39. 2.2. スクラムの全面適応 How we adapted

40. 組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入既存体制 Product / Component 機能組織全面適用 WF体制 2013/11 組織拡大 Phase2. Scrum全面適応

41. スクラム＋WFチーム Product

42. 全面スクラム化 Product Product

43. 何が起こったか

44. SMってタスクの管理する人でしょ！スクラムだから納期はコミットしないでしょ？ユーザーストーリー作ったからあとよろしく！

45. あれ？

46. なんか違う

47. スクラムよかった！ • 知見者がいない状態でも導入効果はある • 形だけの導入でも効果はある

48. 正しくは

49. スクラムよかった • 知見者がいない状態でも導入効果はある • 形だけの導入でも効果はあるただし、チームメンバーの多くが能動的かつ課題感を共有している場合に限る

50. 落とし穴 • トップダウン導入による、やらされスクラム • 形だけの導入によるスクラムの誤解の顕在化 • 不安感からくる手段の目的化

51. Whyの有無で効果は全然ちがう

52. 形だけの導入による成果と障害 • 成果 • プロセス自体の定期的改善 (振り返り) • コミュニケーションの改善 (チーム、KANBAN） • スコープをきることでリリースサイクルを向上 (プロダクトバックログ) • 障害物 • スクラムのバズワード化 • POのコミット力低下 • メンバーの自発性がなかなか育たない

53. 事例1.スクラムのバズワード化 • 「スクラム」だから○○やらないとダメ • 「スクラム」をやることが目的になってしまう原因 Whyの欠如不安からプロセスに縛られる対策 Whyを考えるワークショップの実施相互に聞ける環境づくり /やってみせる成果プロセスではなくゴールを意識できるようになった

54. 事例2.POのコミット力低下 • 案件の投げっぱなし、情報共有不足 • POとチームの関係性悪化原因お互いの状況が見えていないわからないことをすぐに聞けない対策先ずは物理的な距離を近づける成果すぐに聞ける状況と、不満を口にしにくい環境

55. 事例3.メンバーの自発性がなかなか育たない • SMがタスクを作成、アサイン • 振り返りがお通夜原因 SMが自分で仕切ってしまう対策自己評価/他者評価のフィードバック実施成果自分が無意識でやっていたことへの気づき

56. 取り組みまとめ • 組織的にスクラムに対する理解を深める • ワークショップ、コーチング、相互相談 • 席替え実施 • POと開発チームを近くに • 自己評価/他者評価 • SMチェックシート実施

57. 2.2. スクラムから大規模アジャイル開発へ How we scaled

58. 大規模アジャイル開発

59. 全面スクラム化 Product

60. POの意思を統一する人 PO Lead Product

61. アーキテクト整合性 PO Lead Product Architect

62. リリース案件、リリース前QA PO Lead Architect Releaser Product

63. プロダクトが増える PO Lead PO Lead Architect Releaser Architect Releaser Product Product

64. 全体の意思を統一する人 PO Lead Company Board PO Lead Architect Releaser Architect Releaser Product Product

65. 全体のUI/UXを統一する人 PO Lead Company Board PO Lead Architect Releaser Architect Releaser Product Product UX Specialist

66. 全体のアーキテクト PO Lead Company Board PO Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect

67. 全体のスクラム支援 PO Lead Company Board PO Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect Scrum Support

68. PO Lead Company Board PO Lead Architect Releaser Architect Releaser Product Product UX Specialist Portofolio Architect Scrum Support

69. Portfolio Backlog Release Train SysQA RTE Release Train SysQA RTE PB PB PB Company Board Architects UX Specialist Scrum Support

70. スクラムの儀式 Sprint 計画MTG リファインメントスプリントレビュー朝会 DemoDay SM, PO ナレッジ共有会開発アーキ別共有会 Scrum of Scrum 振り返り

71. 組織拡大 2014/03 現在2014/06 さらに拡大 Scrum 試験導入既存体制 Product / Component 機能組織全面適用 WF体制 2013/11 組織拡大 Phase3. 組織の拡大

72. 我々は何故、 • スクラムを行うのか？ • 未経験の事業領域、イテレーション開発の必要性 • スケールを志すのか？ • 相互に連携する複数のサービスを、全体整合性を保ちつつも並行して立ち上げたい

73. スクラムから大規模スクラムへ • 成果 • 開発できる案件が増えた • ナレッジ蓄積スピードの加速 • 障害 • 組織的課題が見えづらい • リーダーTに対する依存 • 組織にアーキテクチャが  おいつかない

74. 事例1. 組織的課題が見えづらい • 全体の可視化が忘れられやすい • 各チームだけでなく、全体最適はとれてる？原因チームのことにフォーカスしてしまう対策全体像の可視化、各立場での情報共有成果大規模アジャイル開発体制自体の改善

79. 事例2.リーダーTに対する依存 • リーダーチームの意思決定待ち • チーム間でのコミュニケーション不足原因 PM : メンバー = リーダーT : チーム対策リーダーTの解散 ※サポート型のリーダーチーム成果各チーム間連携の向上

80. 事例3. 組織とアーキテクチャ • 技術的負債の顕在化 • 人が増えてもなかなか開発速度があがらない原因コンウェイの法則組織の大きさとアークテクチャの乖離対策アーキテクチャの見直しプラクティス(TDD, CI/CD)の導入成果挑戦中バグ発生率は低下中

81. スケールアップにより発生した問題 • チームで発生したことは抽象度があがって再発する • 急成長するプロダクトにあわせて、組織だけでなくアーキテクチャもスケールする

82. 4. 今後挑戦したい課題 Our current impediment list

84. 改めて、検証と適応と透明性

85. 組織拡大と可視化の重要性 • 組織拡大 = 意思を持つ人の増加 • 可視化は「事実」を顕在化させる • 意見は受け入れづらいが、事実は受け入れやすい • 目的が共有できていれば、課題を解決する意思を共有できる

86. 改めて、検証と適応と透明性プロセス、スループットの更なる可視化

87. プロセス、スループットの更なる可視化 • 大規模化に伴って登場人物が増えたが、アジャイルさの阻害要因になっていないか？ • 個別のレビューも塵が積もれば山となる

89. 大規模のプロセスをどう可視化するのか？案件リリースプロセスプロセスプロセスプロセス・どれだけのプロセスを実践している？・各プロセスにどれだけコストがかかっているのか？・そのプロセスの意味と目的は？権限移譲出来ない？・全体のスループットを明らかにし、更なるROI改善を

90. 5. まとめ Summary

91. スクラムから学んだこと • Whyを理解/共有をすること • 物理的な距離を近づけること • PMをそのままSMにしないこと (SMは我慢すること)

92. 大規模化から学んだこと • 全体の可視化を改めて行うこと • リーダーチームもサポート型に • 組織構造にあわせたアーキテクトを作ること

93. まとめスケールアップしてもスクラムの原理原則はかわらないスクラムの導入に最も重要なのは「Why」「検証と適応と透明性」

94. 失敗から学んだことをお伝えしてきましたが

95. 結局やってよかった？

96. YES!

97. Scale Upしてよかったこと • 仲間が増える • できることが増える • 学ぶことが増える

98. 出来る、大規模アジャイル開発失敗から学ぶことが出来れば大丈夫！そのためのWhyと透明性

99. 出来る、大規模アジャイル開発失敗から学ぶことが出来れば大丈夫！そのためのWhyと透明性一つでも皆様のお役に立てるものがあれば幸いです

100. 課題を解決する仲間絶賛募集中！ • http://www.career.recruit-lifestyle.co.jp/

大規模スクラムの失敗から学んだこと #AgileJapan2015

Itsuki Sakitsu

Transcript