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