大人数でのスクラム / Scrum with many people

Chatwork社の社内イベントにてゲストとして登壇させてもらったときの資料です。

Transcript

1. @Chatwork AgileTeaParty ⼤⼈数でのスクラム 中井菜⼦@nako418
2. ⾃⼰紹介 中井 菜⼦（@nako418） ヤフー株式会社 2018年4⽉〜 プロダクトオーナーとしてスクラムに関わりはじめる 2020年7⽉〜 とある社内プロダクトたちのプロダクトオーナー RSGTには2019年から参加 フットサル、ボードゲーム ⾸と肩と背中がバキバキでやばい。
3. 今⽇のお話 • ⼤⼈数でスクラムをやるうえでのあれこれ • ⼈数が多いと、どういう課題が⽣じるのか • わたしのチームでこれまでやってきた⼯夫の紹介
4. 今⽇お話しないこと • ⼤⼈数でスクラムをやるうえでのベストプラクティス • こうすればうまくいくよ︕という⼿法の紹介 • ⼤⼈数でスクラムをやることを推進するようなこと
5. もくじ 1. はじめに 2. いまいるところ 3. ⼤⼈数でのスクラムだと何が違う︖ 4. どんな⼯夫をしたのか 5. まとめ
6. はじめに
7. なぜ無名のわたしが登壇することになったのか • 声をかけてもらったから • 「うっ」となるのは成⻑のチャンスと⾔われたのを思い出して引き受けた • 参考︓https://speakerdeck.com/miholovesq/small-zaogao-is-a-chance-to-grow-ja ͏ͬ
8. 「うっ」を分解する • 他社さまで変なこと喋れないという緊張感 • 無名のわたしがお話したところでなにかの役にたつのだろうかという不安感 • 無免許だし、登壇経験も多くないし、⼀般的なお話をできるほどのスクラムの経験もない • キーノートという⾔葉が重たいw ͏ͬ ΍Δ͔
9. テーマを決めるにあたって • 登壇することにしたものの、なんのお話をするか悩んだ • テーマが⾃由で、話をすることだけ決まるって難しい
10. テーマを決めるにあたって • わたしがお話できることをお話しよう • ⼀般化したような、抽象的なお話でなくても良さそう • 事例とかがあっても良さそう • プロダクトオーナー視点ってこともあってエンジニアに閉じない話にできそう ͳΜͱ͔ʹΌΓͦ͏
11. 今⽇のお話 • ⼤⼈数でスクラムをやるうえでのあれこれ • ⼈数が多いと、どういう課題が⽣じるのか • わたしのチームでこれまでやってきた⼯夫の紹介
12. 今⽇お話しないこと • ⼤⼈数でスクラムをやるうえでのベストプラクティス • こうすればうまくいくよ︕という⼿法の紹介 • ⼤⼈数でスクラムをやることを推進するようなこと
13. いまいるところ ͔͜͜Βຊฤ
14. わたしのこと • スクラム歴 6年⽬ • プロダクトオーナー 6年⽬
15. わたしのこと • スクラム歴 6年⽬ • プロダクトオーナー 6年⽬ ॳΊͯͷεΫϥϜ ॳΊͯͷ10 ೥݄
16. わたしのこと • スクラム歴 6年⽬ • プロダクトオーナー 6年⽬ εΫϥϜͬΆ͍ͳʹ͔ 10ͬΆ͍ͳʹ͔ ೥݄
17. わたしのこと • スクラム歴 6年⽬ • プロダクトオーナー 6年⽬ -F44ʹग़ձ͏ -F44ͷ10 ೥݄
18. わたしのこと • スクラム歴 6年⽬ • プロダクトオーナー 6年⽬ εΫϥϜ೥໨ ೥ؒͣͬͱ10 ೥݄
19. わたしのこと • スクラム歴 6年⽬ • プロダクトオーナー 6年⽬ εΫϥϜ೥໨ ೥ؒͣͬͱ10 ೥݄
20. チームのこと • LeSSをやっている • 2つのチームが合体して1つのLeSSチームとして2つのプロダクトを担当 • 詳しくはRSGT2022参照︓https://speakerdeck.com/nako418/less-is-also-scrum
21. チームのこと • ⼈数構成 • プロダクトオーナー 1⼈（わたし） • スクラムマスター 1⼈ • 開発メンバー 21⼈ • 期間 • 2020/07〜 • コロナで100%リモートになった頃から • 2023/07でちょうど3年
22. チームのこと • 特徴 • 開発チームは専⾨領域をつくらないフィーチャーチーム • 変化 • スクラムチーム内でのチーム替えや、異動等によるメンバーの⼊れ替えはある • 扱うプロダクトと、プロダクトオーナー、スクラムマスター変わらず • 周辺事情 • うまくいっているねと⾔われることが多い
23. わたしとチーム • 約3年、⼤⼈数でのスクラムをLeSSチームのプロダクトオーナーとして経験
24. ⼤⼈数でのスクラムは何が違う︖
25. ⼤⼈数でのスクラムは何が違う︖
26. ⼤⼈数でのスクラムは何が違う︖ ਓ਺
27. ⼤⼈数でのスクラムは何が違う︖ ਓ਺ େਓ਺ͷεΫϥϜνʔϜʢਓʣ Α͋͘ΔεΫϥϜνʔϜʢਓʣ
28. ⼤⼈数でのスクラムは何が違う︖
29. ⼤⼈数でのスクラムは何が違う︖
30. ⼈数が違うと何が違う︖
31. ⼈数が違うと何が違う︖ ίϛϡχέʔγϣϯύε Ұ౓ʹͰ͖Δ͜ͱ
32. ⼈数が違うと何が違う︖ ίϛϡχέʔγϣϯύε Ұ౓ʹͰ͖Δ͜ͱ େਓ਺Ͱ΍Γ͍ͨཧ༝
33. ⼈数が違うと何が違う︖ ίϛϡχέʔγϣϯύε
34. ⼈数が違うと何が違う︖ ίϛϡχέʔγϣϯύε Α͋͘ΔεΫϥϜνʔϜʢਓʣ େਓ਺ͷεΫϥϜνʔϜʢਓʣ
35. ⼈数が違うと何が違う︖ ຊ ίϛϡχέʔγϣϯύε Α͋͘ΔεΫϥϜνʔϜʢਓʣ େਓ਺ͷεΫϥϜνʔϜʢਓʣ
36. ⼈数が違うと何が違う︖ ຊ ຊ ίϛϡχέʔγϣϯύε Α͋͘ΔεΫϥϜνʔϜʢਓʣ େਓ਺ͷεΫϥϜνʔϜʢਓʣ
37. コミュニケーションパスが増えるとどうなる︖ • コミュニケーションコストが増加 • 全員に⼀次情報を伝えるコストが⼤きくなる • 意思疎通や認識合わせをするコストが⼤きくなる • コミュニケーションに階層が⽣まれる • 伝⾔ゲームになって情報が⽋落する • 全員が同じ情報を持てなくなる ೔ ͔͔Δ ؤுΕ͹ ೔ ͰͰ͖Δ ೔ ͰͰ͖Δ
38. ⼩さなチームのほうがコミュニケーションが上⼿く、⽣産性が⾼い スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完 了するための⼗分な⼤きさがあり、通常は 10 ⼈以下である。⼀般的に⼩さなチームのほうがコ ミュニケーションがうまく、⽣産性が⾼いことがわかっている。スクラムチームが⼤きくなり すぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成す ることを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、 およびプロダクトオーナーを共有する必要がある。 「スクラムガイド2020年度版」 Ken Schwaber＆Jeff Sutherland著 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf εΫϥϜΨΠυͰ΋ɺਓ਺Λ૿΍͢͜ͱ͸ਪ঑͞Ε͍ͯͳ͍ɻ ͦΕͰ΋Θͨͨͪ͠͸ਓ਺Λ૿΍ͯ͠Ұ౓ʹͰ͖Δ͜ͱΛ૿΍͍ͨ͠ɻ
39. ⼤規模スクラムのフレームワークを使うとコミュニケーションパスが減る • LeSSにもScrum@Scaleにも、コミュニケーションパスを減らすプラクティスがある • LeSSでは開発チームを複数持つ • Scrum@ScaleはScrum of Scrumでスクラムチームを複数持つ • それぞれ、内部で定義されたチームごとに⾏うイベントと、その代表者が参加して⾏うイベント がある • １つのイベントに参加する⼈数が⼤⼈数になりすぎない ී௨ͷεΫϥϜͱͷࠜຊతͳҧ͍͸ਓ਺͔ͩΒͦ͜ɺ ಛఆͷҰਓ͔Βݟͨͱ͖ͷύεΛԾ૝తʹݮΒ͢Α͏ͳϓϥΫςΟε ͕͋ΔͷͰ͸ʁ
40. コミュニケーションパスの数 • よくあるスクラムチーム（7⼈） ։ൃνʔϜΛ෼͚ͯߟ͑ͨ৔߹ ຊ શମΛͭͷνʔϜͱߟ͑ͨ৔߹ ຊ
41. コミュニケーションパスの数 • ⼤⼈数のスクラムチーム（開発者15⼈） ϑϨʔϜϫʔΫΛ࢖Θͳ͍େਓ਺ͷεΫϥϜ ຊ
42. コミュニケーションパスの数 • ⼤規模スクラムチーム（開発者15⼈） 4DSVN!4DBMF ຊ
43. コミュニケーションパスの数 • ⼤規模スクラムチーム（開発者15⼈） Ұൠతͳ-F44 ʢ֤νʔϜʹεΫϥϜϚελʔਓʣ ຊ Θͨ͠ͷνʔϜͷ-F44 ʢνʔϜશମʹεΫϥϜϚελʔਓʣ ຊ
44. フレームワークを使えばうまくいくわけではない • フレームワークはあくまでもフレームワーク。⼿段でしかない • ⼈数を増やして⼀度にできることを増やした副作⽤がなくなるわけではない
45. ⼀度にできることが増えるとどうなる︖ • 優先順位付けが難しくなる • 分業が進む • 知らない領域が増える • 全体が⾒えなくなる • 同じ⽅向を向きにくくなる • 部分最適が進みやすくなる いずれも、⼤⼈数でスクラムをやるうえでのトレードオフ（向き合わなければならない課題）
46. ⼀度にできることは本当に増えるのか︖ • チームの⽣産⼒ （開発メンバーの⽣産⼒の合計） * （チームによる相乗効果） • 例 Α͋͘ΔεΫϥϜνʔϜ େਓ਺ͷεΫϥϜνʔϜ ਓ෼ͷྗ
    νʔϜྗ ਓ෼ͷྗ
    νʔϜྗ 
    
    
     
    
    
    
      
    
     
    
     
    
    
    
     ਓ෼ͷྗ
    νʔϜྗ ͷ࿨
    εΫϥϜνʔϜͷνʔϜྗ -F44νʔϜ
47. ⼀度にできることは本当に増えるのか︖ • チームの⽣産⼒ （開発メンバーの⽣産⼒の合計） * （チームによる相乗効果） • 例 Α͋͘ΔεΫϥϜνʔϜ ਓ෼ͷྗ
    νʔϜྗ ਓ෼ͷྗ
    νʔϜྗ 
    
    
     
    
    
    
      
    
     
    
     
    
    
    
     ਓ෼ͷྗ
    νʔϜྗ ͷ࿨
    εΫϥϜνʔϜͷνʔϜྗ -F44νʔϜ ഒ ഒ େਓ਺ͷεΫϥϜνʔϜ
48. ⼀度にできることは本当に増えるのか︖ • チームの⽣産⼒ （開発メンバーの⽣産⼒の合計） * （チームによる相乗効果） • 例 Α͋͘ΔεΫϥϜνʔϜ ਓ෼ͷྗ
    νʔϜྗ ਓ෼ͷྗ
    νʔϜྗ 
    
    
     
    
    
    
      
    
     
    
     
    
    
    
     ਓ෼ͷྗ
    νʔϜྗ ͷ࿨
    εΫϥϜνʔϜͷνʔϜྗ -F44νʔϜ ഒ ഒ େਓ਺ͷεΫϥϜνʔϜ
49. ⼀度にできることは本当に増えるのか︖ • チームの⽣産⼒ （開発メンバーの⽣産⼒の合計） * （チームによる相乗効果） • 例 Α͋͘ΔεΫϥϜνʔϜ ਓ෼ͷྗ
    νʔϜྗ ਓ෼ͷྗ
    νʔϜྗ 
    
    
     
    
    
    
      
    
     
    
     
    
    
    
     ਓ෼ͷྗ
    νʔϜྗ ͷ࿨
    εΫϥϜνʔϜͷνʔϜྗ -F44νʔϜ ഒ ഒ ഒ ഒ େਓ਺ͷεΫϥϜνʔϜ
50. ⼤⼈数でスクラムをやるということ • ⼈数が増えて⼀度にできることが増えることで起きる課題と向き合わなければならない • コミュニケーションにおける課題に向き合いチームの⽣産性を⾼めなければならない
51. どんな⼯夫をしたのか
52. なにをしたのか • 課題はたくさん • ⼈数が増えて⼀度にできることが増えることで起きる課題 • コミュニケーションにおける課題 • スクラムチームのメンバーがそれぞれの役割でアプローチした • プロダクトオーナー • スクラムマスター • 開発メンバー
53. スクラムのロールごとの役割 • プロダクトオーナーはチームが向く⽅向を決める • スクラムマスターは⾃⼰組織化されたチームになるための⽀援をする • 開発メンバーは専⾨家としてインクリメントを作ることに責任を持つ ⼤きな船に例えると・・・
54. ロールごとの役割を⼤きな船に例えると、、、
55. ロールごとの役割を⼤きな船に例えると、、、 ΞΠΞΠαʔʂʂ 10ˠ ֤νʔϜͷ୅දˠ ໨ࢦ͢͸͋ͷ͓ๅʂ
56. ロールごとの役割を⼤きな船に例えると、、、 ͋ͬͪʹ޲͔͏ͬͯʂ ͳΒɺ໘଩͍ͬͺʔ͍ʂ ଩औΓνʔϜ
57. ロールごとの役割を⼤きな船に例えると、、、 Θͨͨͪ͠͸ ϖʔεΛཚͣ͞ʹ ૨͗ଓ͚ΒΕΕ͹0,Ͱ͢ʂ ಈ෺ಈྗνʔϜ ʢધटʣ
58. ロールごとの役割を⼤きな船に例えると、、、 νʔϜͷग़ྗΛ ্͛ΒΕΔΑ͏ΈΜͳͰؤுΖ͏ ϥϯχϯάಈྗνʔϜ ʢࠨཌྷʣ
59. ロールごとの役割を⼤きな船に例えると、、、 Θ͕͕ͨ͠Μ͹Ε͹ νʔϜͷग़ྗ্͕Δ͸ͣɾɾʂ ΤΞϩόΠΫಈྗνʔϜ ʢӈཌྷʣ
60. ロールごとの役割を⼤きな船に例えると、、、 ཛྷ͕͖ͦ͏ɾɾʂ νʔϜ͸Ͳ͏ಈ͘ʁ
61. ロールごとの役割を⼤きな船に例えると、、、 ͏ʔΜɺ ཛྷʹؾ͍͍ͮͯͳͦ͞͏ͩ͠ɺ ӈཌྷ͸όϥϯε่Ε͍ͯΔ͠ɺ ͜ͷ··ߦ͘ͱཛྷʹಥͬࠐΉͧɺɺ ધ௕ͱ֤νʔϜʹ࿈བྷ͠ͳ͍ͱʂ ˡ4.
62. 起きていそうなこと • ⼈数が多ければ多いほど、みんなが同じ⽅向を向きにくい • 船⻑（PO）はこっち（どっち︖）って⾔っている • 各チームの代表者はそれを聞いているが、その場にいなかった⼈には伝わらないケースも • 各チームでは部分最適化が進む • 代表者は各チームに戻ると情報共有しつつも⾃分たちのやるべきことにフォーカスする • 天気（周囲の状況）が変わっていることに気づけないことも • 隣のチームの出⼒があがってバランスが崩れたことに気づけない • いろんな⽅向に⼒が働けば働くほど相殺されて前に進まない、進みが遅くなる • 全体の不調和にいち早く気づき共有する • 遠くから全体が⾒えている監視員（SM）が今の向き先にある課題を共有する • チーム間で連携を取る新たな動きがうまれ、安全な航海ができる
63. なにをしたのか • 課題はたくさん • ⼈数が増えて⼀度にできることが増えることで起きる課題 • コミュニケーションにおける課題 • なにをしたのか • コミュニケーションをスムーズにするための⼯夫 • 向く⽅向を揃えるための⼯夫 εΫϥϜνʔϜͷϝϯόʔ͕ͦΕͧΕͷ෼໺ͰΞϓϩʔν
64. コミュニケーションをスムーズにするための⼯夫 • リファインメントは各開発チームから1名以上参加 • アイテムの詳細を書き出す • レトロスペクティブでスクラムチームについて話す • Working Agreement の⾒直し • チームシャッフル • マネージャー間での情報共有とメンバーとの1on1 • プロダクトオーナーとメンバーで1on1
65. リファインメントは各チームから1名以上参加 • ⽬的 • スプリント中にチームメンバーが誰も知らない領域をつくらない • スクラムチーム全体で情報を共有 • やったこと • リファインメントには各開発チームから最低１⼈は参加する • 実際にアイテムに着⼿するときにフォローする
66. アイテムの詳細を書き出す • ⽬的 • 情報共有を記憶に頼らない • 同じ⾔葉で情報を視覚的にも取得できるようにする • やったこと • プロダクトバックログアイテム⽤のテンプレートを作成 • リファインメントでお話した内容をコメントにメモ チームで利⽤しているテンプレートの例
67. レトロスペクティブでスクラムチームについて話す • ⽬的 • スクラムチームの全体最適 • やったこと • スクラムチーム全体を⾒ているスクラムマスターから課題を提⽰ • チームの課題をスクラムチーム全体で取り上げる場合はスクラムチームとしての課題かの確認から • 課題だけでなく、理想像や良かった取り組みの共有もおこなう
68. Working Agreement の⾒直し • ⽬的 • チームの関係性の質をあげる • チームに対する期待値を可視化 • やったこと • Working Agreementをルール（守らせたいもの） ではなく、チームに期待することと定義 • チームとして⼤事にしたい価値観上位3つ • それぞれの価値観に沿った⾏動と 反した⾏動を元に「⾏動指針」を作成 Working Agreement 作成ワークショップ
69. チームシャッフル • ⽬的 • メンバーの⼊れ替わりにあわせて開発チームを再構築 • 違うメンバーと関わることでお互いにいい影響を与え合う • やったこと • 毎期開発チームのメンバーをシャッフル KPJO PVU
70. マネージャー間での情報共有とメンバーとの1on1 • ⽬的 • 個々のメンバーの成⻑に向けたフィードバックに活かす • マネージャー同⼠が向いている⽅向を揃える • やったこと • マネージャー陣で会話しまくる • メンバー個⼈の良い⾏動や課題、フィードバック • それぞれの視点から⾒える情報を共有する • ⾃分以外の視点も踏まえてメンバーと1on1 Θ͍Θ͍
71. プロダクトオーナーとメンバーで1on1 • ⽬的 • プロダクトオーナーと開発メンバーの距離感を近づける • わたしがメンバーのみんなと仲良くなる • やったこと • 定期的に1on1でお話する時間を設定 • 雑談やプロダクトに関する相談、振り返り ࠷ۙͲ͏Αʁ ఱؾ͕ྑ͗ͯ͢ॵ͍͠ɺ ম͚ͯ͠·͏ͷ͕ؾʹͳͬͯɻɻ ͍͍೔ম͚ࢭΊ͋ΔΑʂ ڭ͍͑ͯͩ͘͞ʂ ࠷ۙͲ͏Αʁ ྑͦ͞͏ʂϓϩμΫτͰ΍ͬͯ ΈΑ͏ΑʂΞΠςϜ࡞ͬͯ΄͍͠ͳ ͥͻʂΞΠςϜ࡞Γ·͢ʂ ΍ͬͯΈ͍ͨ͜ͱ͕͋ΔΜ Ͱ͚͢Ͳɺɺ͜ΕͲ͏ࢥ͍·͢ʁ
72. 向く⽅向を揃えるための⼯夫 • 半期ごとのキックオフ • 半期ごとにインセプションデッキを作成/⾒直し • 四半期単位でのエピックリファインメント • 毎スプリント内でのリファインメント
73. 半期ごとのキックオフ • ⽬的 • 半期のプロダクトゴールを提案 • チームがいまいる場所の認識を揃える • 今期もがんばろうという気持ちになる • やっていること • 前期のふりかえり • 前期できたことを確認 • 今期の⽬標 • 今期⼒を⼊れること 2021H2キックオフ資料より↑→
74. 半期ごとにインセプションデッキを作成/⾒直し • ⽬的 • ⾃分たちが担当しているプロダクトに向き合う • チームメンバーがお互いに考えていることを知り、すり合わせる • やっていること • プロダクトのフェーズに合わせてスコープを提⽰ • ⼀部の項⽬にフォーカスして議論 • 事前のグループ分け＆ワールドカフェ形式での議論 • 参考 • https://agile-monster.com/blog/5minutes-inception-deck/ インセプションデッキのテンプレートより https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck
75. 四半期単位でのエピックリファインメント • ⽬的 • 四半期単位で向いている⽅向を調整 • やっていること • やらないといけないこと、わたしたちがやりたいことから、優先順決め • 案件の進捗の確認 • ざっくりなロードマップの作成 ある四半期のざっくりなロードマップ
76. 毎スプリント内でのリファインメント • ⽬的 • アイテムだけでなくエピックレベルの情報にも⽬を向ける • ⾃分のチームが担当していないことの状況を知る • やっていること • リリース計画 • 直近の周囲の情勢を共有 • 情勢にあわせてロードマップを アップデート ある四半期のざっくりなロードマップ ある⽉のスケジュール
77. 毎スプリント内でのリファインメント • ⽬的 • アイテムだけでなくエピックレベルの情報にも⽬を向ける • ⾃分のチームが担当していないことの状況を知る • やっていること • リリース計画 • 直近の周囲の情勢を共有 • 情勢にあわせてロードマップを アップデート ऴΘͬͨ΋ͷʹ νΣοΫΛೖΕͨΓ ある四半期のざっくりなロードマップ ある⽉のスケジュール ௕Ҿ͘΋ͷ͸ εϥΠυͤͨ͞Γ
78. 向く⽅向を揃えるために
79. 向く⽅向を揃えるために ΩοΫΦϑ ΠϯηϓγϣϯσοΩ࡞੒ ΤϐοΫϦϑΝΠϯϝϯτ ϦϑΝΠϯϝϯτ ൒೥͓͖ ൒೥͓͖ ϲ݄͓͖ ຖि Q4 Q3 Q2 Q1
80. まとめ
81. ⼤⼈数でスクラムをやるということ • ⼈数が増えて⼀度にできることが増えることで起きる課題と向き合わなければならない • コミュニケーションにおける課題に向き合いチームの⽣産性を⾼めなければならない
82. ⼈数が多いからこそロールに沿ったアプローチをする • 各チームは開発者としての責任を全うするためのアプローチを • ⾃分たちのチームの最適化 • 周囲のチームとの連携 • スクラムマスターはスクラムチーム全体を⾒たアプローチを • チーム単体では気づきにくい課題の提⽰ • 先を⾒据えた提案 • プロダクトオーナーはスクラムチームが向く⽅向を揃えるアプローチを • スクラムチームが向かう先を常に指し⽰す ⼀度取り組んだら終わりではなく、課題の解消/改善を続けていくのがだいじ ⼩さくても１つずつ確実に良くしていく
83. ⼈数が多くてもスクラムはスクラムだし、アジャイル • ⼤規模スクラムでは役割などが⼀段階抽象化されるが、考え⽅はスクラムと変わらない • LeSSでも、Scrum@Scaleでも。 • スクラムの基本原則である考え⽅に変わりはない • アジャイルマニフェストの原則に則るところも同じ • 戻るべきところはスクラムガイドであり、アジャイルマニフェスト だいじなのは、常によりよいものを提供し続けるために、模索し続けることができるチームである こと
84. ありがとうございましたmm