$30 off During Our Annual Pro Sale. View Details »

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

nako418
July 27, 2023
250

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

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

nako418

July 27, 2023
Tweet

Transcript

  1. @Chatwork AgileTeaParty
    ⼤⼈数でのスクラム
    中井菜⼦@nako418

    View Slide

  2. ⾃⼰紹介
    中井 菜⼦(@nako418)
    ヤフー株式会社
    2018年4⽉〜 プロダクトオーナーとしてスクラムに関わりはじめる
    2020年7⽉〜 とある社内プロダクトたちのプロダクトオーナー
    RSGTには2019年から参加
    フットサル、ボードゲーム
    ⾸と肩と背中がバキバキでやばい。

    View Slide

  3. 今⽇のお話
    • ⼤⼈数でスクラムをやるうえでのあれこれ
    • ⼈数が多いと、どういう課題が⽣じるのか
    • わたしのチームでこれまでやってきた⼯夫の紹介

    View Slide

  4. 今⽇お話しないこと
    • ⼤⼈数でスクラムをやるうえでのベストプラクティス
    • こうすればうまくいくよ︕という⼿法の紹介
    • ⼤⼈数でスクラムをやることを推進するようなこと

    View Slide

  5. もくじ
    1. はじめに
    2. いまいるところ
    3. ⼤⼈数でのスクラムだと何が違う︖
    4. どんな⼯夫をしたのか
    5. まとめ

    View Slide

  6. はじめに

    View Slide

  7. なぜ無名のわたしが登壇することになったのか
    • 声をかけてもらったから
    • 「うっ」となるのは成⻑のチャンスと⾔われたのを思い出して引き受けた
    • 参考︓https://speakerdeck.com/miholovesq/small-zaogao-is-a-chance-to-grow-ja
    ͏ͬ

    View Slide

  8. 「うっ」を分解する
    • 他社さまで変なこと喋れないという緊張感
    • 無名のわたしがお話したところでなにかの役にたつのだろうかという不安感
    • 無免許だし、登壇経験も多くないし、⼀般的なお話をできるほどのスクラムの経験もない
    • キーノートという⾔葉が重たいw
    ͏ͬ ΍Δ͔

    View Slide

  9. テーマを決めるにあたって
    • 登壇することにしたものの、なんのお話をするか悩んだ
    • テーマが⾃由で、話をすることだけ決まるって難しい

    View Slide

  10. テーマを決めるにあたって
    • わたしがお話できることをお話しよう
    • ⼀般化したような、抽象的なお話でなくても良さそう
    • 事例とかがあっても良さそう
    • プロダクトオーナー視点ってこともあってエンジニアに閉じない話にできそう
    ͳΜͱ͔ʹΌΓͦ͏

    View Slide

  11. 今⽇のお話
    • ⼤⼈数でスクラムをやるうえでのあれこれ
    • ⼈数が多いと、どういう課題が⽣じるのか
    • わたしのチームでこれまでやってきた⼯夫の紹介

    View Slide

  12. 今⽇お話しないこと
    • ⼤⼈数でスクラムをやるうえでのベストプラクティス
    • こうすればうまくいくよ︕という⼿法の紹介
    • ⼤⼈数でスクラムをやることを推進するようなこと

    View Slide

  13. いまいるところ
    ͔͜͜Βຊฤ

    View Slide

  14. わたしのこと
    • スクラム歴 6年⽬
    • プロダクトオーナー 6年⽬

    View Slide

  15. わたしのこと
    • スクラム歴 6年⽬
    • プロダクトオーナー 6年⽬
    ॳΊͯͷεΫϥϜ
    ॳΊͯͷ10
    ೥݄

    View Slide

  16. わたしのこと
    • スクラム歴 6年⽬
    • プロダクトオーナー 6年⽬
    εΫϥϜͬΆ͍ͳʹ͔
    10ͬΆ͍ͳʹ͔
    ೥݄

    View Slide

  17. わたしのこと
    • スクラム歴 6年⽬
    • プロダクトオーナー 6年⽬
    -F44ʹग़ձ͏
    -F44ͷ10
    ೥݄

    View Slide

  18. わたしのこと
    • スクラム歴 6年⽬
    • プロダクトオーナー 6年⽬
    εΫϥϜ೥໨
    ೥ؒͣͬͱ10
    ೥݄

    View Slide

  19. わたしのこと
    • スクラム歴 6年⽬
    • プロダクトオーナー 6年⽬
    εΫϥϜ೥໨
    ೥ؒͣͬͱ10
    ೥݄

    View Slide

  20. チームのこと
    • LeSSをやっている
    • 2つのチームが合体して1つのLeSSチームとして2つのプロダクトを担当
    • 詳しくはRSGT2022参照︓https://speakerdeck.com/nako418/less-is-also-scrum

    View Slide

  21. チームのこと
    • ⼈数構成
    • プロダクトオーナー 1⼈(わたし)
    • スクラムマスター 1⼈
    • 開発メンバー 21⼈
    • 期間
    • 2020/07〜
    • コロナで100%リモートになった頃から
    • 2023/07でちょうど3年

    View Slide

  22. チームのこと
    • 特徴
    • 開発チームは専⾨領域をつくらないフィーチャーチーム
    • 変化
    • スクラムチーム内でのチーム替えや、異動等によるメンバーの⼊れ替えはある
    • 扱うプロダクトと、プロダクトオーナー、スクラムマスター変わらず
    • 周辺事情
    • うまくいっているねと⾔われることが多い

    View Slide

  23. わたしとチーム
    • 約3年、⼤⼈数でのスクラムをLeSSチームのプロダクトオーナーとして経験

    View Slide

  24. ⼤⼈数でのスクラムは何が違う︖

    View Slide

  25. ⼤⼈数でのスクラムは何が違う︖

    View Slide

  26. ⼤⼈数でのスクラムは何が違う︖
    ਓ਺

    View Slide

  27. ⼤⼈数でのスクラムは何が違う︖
    ਓ਺
    େਓ਺ͷεΫϥϜνʔϜʢਓʣ
    Α͋͘ΔεΫϥϜνʔϜʢਓʣ

    View Slide

  28. ⼤⼈数でのスクラムは何が違う︖

    View Slide

  29. ⼤⼈数でのスクラムは何が違う︖

    View Slide

  30. ⼈数が違うと何が違う︖

    View Slide

  31. ⼈数が違うと何が違う︖
    ίϛϡχέʔγϣϯύε
    Ұ౓ʹͰ͖Δ͜ͱ

    View Slide

  32. ⼈数が違うと何が違う︖
    ίϛϡχέʔγϣϯύε
    Ұ౓ʹͰ͖Δ͜ͱ
    େਓ਺Ͱ΍Γ͍ͨཧ༝

    View Slide

  33. ⼈数が違うと何が違う︖
    ίϛϡχέʔγϣϯύε

    View Slide

  34. ⼈数が違うと何が違う︖
    ίϛϡχέʔγϣϯύε
    Α͋͘ΔεΫϥϜνʔϜʢਓʣ
    େਓ਺ͷεΫϥϜνʔϜʢਓʣ

    View Slide

  35. ⼈数が違うと何が違う︖

    ίϛϡχέʔγϣϯύε
    Α͋͘ΔεΫϥϜνʔϜʢਓʣ
    େਓ਺ͷεΫϥϜνʔϜʢਓʣ

    View Slide

  36. ⼈数が違うと何が違う︖


    ίϛϡχέʔγϣϯύε
    Α͋͘ΔεΫϥϜνʔϜʢਓʣ
    େਓ਺ͷεΫϥϜνʔϜʢਓʣ

    View Slide

  37. コミュニケーションパスが増えるとどうなる︖
    • コミュニケーションコストが増加
    • 全員に⼀次情報を伝えるコストが⼤きくなる
    • 意思疎通や認識合わせをするコストが⼤きくなる
    • コミュニケーションに階層が⽣まれる
    • 伝⾔ゲームになって情報が⽋落する
    • 全員が同じ情報を持てなくなる

    ͔͔Δ
    ؤுΕ͹

    ͰͰ͖Δ

    ͰͰ͖Δ

    View Slide

  38. ⼩さなチームのほうがコミュニケーションが上⼿く、⽣産性が⾼い
    スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完
    了するための⼗分な⼤きさがあり、通常は 10 ⼈以下である。⼀般的に⼩さなチームのほうがコ
    ミュニケーションがうまく、⽣産性が⾼いことがわかっている。スクラムチームが⼤きくなり
    すぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成す
    ることを検討する必要がある。したがって、同じプロダクトゴール、プロダクトバックログ、
    およびプロダクトオーナーを共有する必要がある。
    「スクラムガイド2020年度版」 Ken Schwaber&Jeff Sutherland著
    https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
    εΫϥϜΨΠυͰ΋ɺਓ਺Λ૿΍͢͜ͱ͸ਪ঑͞Ε͍ͯͳ͍ɻ
    ͦΕͰ΋Θͨͨͪ͠͸ਓ਺Λ૿΍ͯ͠Ұ౓ʹͰ͖Δ͜ͱΛ૿΍͍ͨ͠ɻ

    View Slide

  39. ⼤規模スクラムのフレームワークを使うとコミュニケーションパスが減る
    • LeSSにもScrum@Scaleにも、コミュニケーションパスを減らすプラクティスがある
    • LeSSでは開発チームを複数持つ
    • Scrum@ScaleはScrum of Scrumでスクラムチームを複数持つ
    • それぞれ、内部で定義されたチームごとに⾏うイベントと、その代表者が参加して⾏うイベント
    がある
    • 1つのイベントに参加する⼈数が⼤⼈数になりすぎない
    ී௨ͷεΫϥϜͱͷࠜຊతͳҧ͍͸ਓ਺͔ͩΒͦ͜ɺ
    ಛఆͷҰਓ͔Βݟͨͱ͖ͷύεΛԾ૝తʹݮΒ͢Α͏ͳϓϥΫςΟε
    ͕͋ΔͷͰ͸ʁ

    View Slide

  40. コミュニケーションパスの数
    • よくあるスクラムチーム(7⼈)
    ։ൃνʔϜΛ෼͚ͯߟ͑ͨ৔߹

    શମΛͭͷνʔϜͱߟ͑ͨ৔߹

    View Slide

  41. コミュニケーションパスの数
    • ⼤⼈数のスクラムチーム(開発者15⼈)
    ϑϨʔϜϫʔΫΛ࢖Θͳ͍େਓ਺ͷεΫϥϜ

    View Slide

  42. コミュニケーションパスの数
    • ⼤規模スクラムチーム(開発者15⼈)
    4DSVN!4DBMF

    View Slide

  43. コミュニケーションパスの数
    • ⼤規模スクラムチーム(開発者15⼈)
    Ұൠతͳ-F44
    ʢ֤νʔϜʹεΫϥϜϚελʔਓʣ

    Θͨ͠ͷνʔϜͷ-F44
    ʢνʔϜશମʹεΫϥϜϚελʔਓʣ

    View Slide

  44. フレームワークを使えばうまくいくわけではない
    • フレームワークはあくまでもフレームワーク。⼿段でしかない
    • ⼈数を増やして⼀度にできることを増やした副作⽤がなくなるわけではない

    View Slide

  45. ⼀度にできることが増えるとどうなる︖
    • 優先順位付けが難しくなる
    • 分業が進む
    • 知らない領域が増える
    • 全体が⾒えなくなる
    • 同じ⽅向を向きにくくなる
    • 部分最適が進みやすくなる
    いずれも、⼤⼈数でスクラムをやるうえでのトレードオフ(向き合わなければならない課題)

    View Slide

  46. ⼀度にできることは本当に増えるのか︖
    • チームの⽣産⼒
    (開発メンバーの⽣産⼒の合計) * (チームによる相乗効果)
    • 例
    Α͋͘ΔεΫϥϜνʔϜ େਓ਺ͷεΫϥϜνʔϜ
    ਓ෼ͷྗ νʔϜྗ
    ਓ෼ͷྗ νʔϜྗ


    ਓ෼ͷྗ νʔϜྗ
    ͷ࿨ εΫϥϜνʔϜͷνʔϜྗ
    -F44νʔϜ

    View Slide

  47. ⼀度にできることは本当に増えるのか︖
    • チームの⽣産⼒
    (開発メンバーの⽣産⼒の合計) * (チームによる相乗効果)
    • 例
    Α͋͘ΔεΫϥϜνʔϜ
    ਓ෼ͷྗ νʔϜྗ
    ਓ෼ͷྗ νʔϜྗ


    ਓ෼ͷྗ νʔϜྗ
    ͷ࿨ εΫϥϜνʔϜͷνʔϜྗ
    -F44νʔϜ


    େਓ਺ͷεΫϥϜνʔϜ

    View Slide

  48. ⼀度にできることは本当に増えるのか︖
    • チームの⽣産⼒
    (開発メンバーの⽣産⼒の合計) * (チームによる相乗効果)
    • 例
    Α͋͘ΔεΫϥϜνʔϜ
    ਓ෼ͷྗ νʔϜྗ
    ਓ෼ͷྗ νʔϜྗ


    ਓ෼ͷྗ νʔϜྗ
    ͷ࿨ εΫϥϜνʔϜͷνʔϜྗ
    -F44νʔϜ


    େਓ਺ͷεΫϥϜνʔϜ

    View Slide

  49. ⼀度にできることは本当に増えるのか︖
    • チームの⽣産⼒
    (開発メンバーの⽣産⼒の合計) * (チームによる相乗効果)
    • 例
    Α͋͘ΔεΫϥϜνʔϜ
    ਓ෼ͷྗ νʔϜྗ
    ਓ෼ͷྗ νʔϜྗ


    ਓ෼ͷྗ νʔϜྗ
    ͷ࿨ εΫϥϜνʔϜͷνʔϜྗ
    -F44νʔϜ




    େਓ਺ͷεΫϥϜνʔϜ

    View Slide

  50. ⼤⼈数でスクラムをやるということ
    • ⼈数が増えて⼀度にできることが増えることで起きる課題と向き合わなければならない
    • コミュニケーションにおける課題に向き合いチームの⽣産性を⾼めなければならない

    View Slide

  51. どんな⼯夫をしたのか

    View Slide

  52. なにをしたのか
    • 課題はたくさん
    • ⼈数が増えて⼀度にできることが増えることで起きる課題
    • コミュニケーションにおける課題
    • スクラムチームのメンバーがそれぞれの役割でアプローチした
    • プロダクトオーナー
    • スクラムマスター
    • 開発メンバー

    View Slide

  53. スクラムのロールごとの役割
    • プロダクトオーナーはチームが向く⽅向を決める
    • スクラムマスターは⾃⼰組織化されたチームになるための⽀援をする
    • 開発メンバーは専⾨家としてインクリメントを作ることに責任を持つ
    ⼤きな船に例えると・・・

    View Slide

  54. ロールごとの役割を⼤きな船に例えると、、、

    View Slide

  55. ロールごとの役割を⼤きな船に例えると、、、
    ΞΠΞΠαʔʂʂ
    10ˠ
    ֤νʔϜͷ୅දˠ
    ໨ࢦ͢͸͋ͷ͓ๅʂ

    View Slide

  56. ロールごとの役割を⼤きな船に例えると、、、
    ͋ͬͪʹ޲͔͏ͬͯʂ
    ͳΒɺ໘଩͍ͬͺʔ͍ʂ
    ଩औΓνʔϜ

    View Slide

  57. ロールごとの役割を⼤きな船に例えると、、、
    Θͨͨͪ͠͸
    ϖʔεΛཚͣ͞ʹ
    ૨͗ଓ͚ΒΕΕ͹0,Ͱ͢ʂ
    ಈ෺ಈྗνʔϜ
    ʢધटʣ

    View Slide

  58. ロールごとの役割を⼤きな船に例えると、、、
    νʔϜͷग़ྗΛ
    ্͛ΒΕΔΑ͏ΈΜͳͰؤுΖ͏
    ϥϯχϯάಈྗνʔϜ
    ʢࠨཌྷʣ

    View Slide

  59. ロールごとの役割を⼤きな船に例えると、、、
    Θ͕͕ͨ͠Μ͹Ε͹
    νʔϜͷग़ྗ্͕Δ͸ͣɾɾʂ
    ΤΞϩόΠΫಈྗνʔϜ
    ʢӈཌྷʣ

    View Slide

  60. ロールごとの役割を⼤きな船に例えると、、、
    ཛྷ͕͖ͦ͏ɾɾʂ
    νʔϜ͸Ͳ͏ಈ͘ʁ

    View Slide

  61. ロールごとの役割を⼤きな船に例えると、、、
    ͏ʔΜɺ
    ཛྷʹؾ͍͍ͮͯͳͦ͞͏ͩ͠ɺ
    ӈཌྷ͸όϥϯε่Ε͍ͯΔ͠ɺ
    ͜ͷ··ߦ͘ͱཛྷʹಥͬࠐΉͧɺɺ
    ધ௕ͱ֤νʔϜʹ࿈བྷ͠ͳ͍ͱʂ
    ˡ4.

    View Slide

  62. 起きていそうなこと
    • ⼈数が多ければ多いほど、みんなが同じ⽅向を向きにくい
    • 船⻑(PO)はこっち(どっち︖)って⾔っている
    • 各チームの代表者はそれを聞いているが、その場にいなかった⼈には伝わらないケースも
    • 各チームでは部分最適化が進む
    • 代表者は各チームに戻ると情報共有しつつも⾃分たちのやるべきことにフォーカスする
    • 天気(周囲の状況)が変わっていることに気づけないことも
    • 隣のチームの出⼒があがってバランスが崩れたことに気づけない
    • いろんな⽅向に⼒が働けば働くほど相殺されて前に進まない、進みが遅くなる
    • 全体の不調和にいち早く気づき共有する
    • 遠くから全体が⾒えている監視員(SM)が今の向き先にある課題を共有する
    • チーム間で連携を取る新たな動きがうまれ、安全な航海ができる

    View Slide

  63. なにをしたのか
    • 課題はたくさん
    • ⼈数が増えて⼀度にできることが増えることで起きる課題
    • コミュニケーションにおける課題
    • なにをしたのか
    • コミュニケーションをスムーズにするための⼯夫
    • 向く⽅向を揃えるための⼯夫
    εΫϥϜνʔϜͷϝϯόʔ͕ͦΕͧΕͷ෼໺ͰΞϓϩʔν

    View Slide

  64. コミュニケーションをスムーズにするための⼯夫
    • リファインメントは各開発チームから1名以上参加
    • アイテムの詳細を書き出す
    • レトロスペクティブでスクラムチームについて話す
    • Working Agreement の⾒直し
    • チームシャッフル
    • マネージャー間での情報共有とメンバーとの1on1
    • プロダクトオーナーとメンバーで1on1

    View Slide

  65. リファインメントは各チームから1名以上参加
    • ⽬的
    • スプリント中にチームメンバーが誰も知らない領域をつくらない
    • スクラムチーム全体で情報を共有
    • やったこと
    • リファインメントには各開発チームから最低1⼈は参加する
    • 実際にアイテムに着⼿するときにフォローする

    View Slide

  66. アイテムの詳細を書き出す
    • ⽬的
    • 情報共有を記憶に頼らない
    • 同じ⾔葉で情報を視覚的にも取得できるようにする
    • やったこと
    • プロダクトバックログアイテム⽤のテンプレートを作成
    • リファインメントでお話した内容をコメントにメモ
    チームで利⽤しているテンプレートの例

    View Slide

  67. レトロスペクティブでスクラムチームについて話す
    • ⽬的
    • スクラムチームの全体最適
    • やったこと
    • スクラムチーム全体を⾒ているスクラムマスターから課題を提⽰
    • チームの課題をスクラムチーム全体で取り上げる場合はスクラムチームとしての課題かの確認から
    • 課題だけでなく、理想像や良かった取り組みの共有もおこなう

    View Slide

  68. Working Agreement の⾒直し
    • ⽬的
    • チームの関係性の質をあげる
    • チームに対する期待値を可視化
    • やったこと
    • Working Agreementをルール(守らせたいもの)
    ではなく、チームに期待することと定義
    • チームとして⼤事にしたい価値観上位3つ
    • それぞれの価値観に沿った⾏動と
    反した⾏動を元に「⾏動指針」を作成
    Working Agreement 作成ワークショップ

    View Slide

  69. チームシャッフル
    • ⽬的
    • メンバーの⼊れ替わりにあわせて開発チームを再構築
    • 違うメンバーと関わることでお互いにいい影響を与え合う
    • やったこと
    • 毎期開発チームのメンバーをシャッフル
    KPJO
    PVU

    View Slide

  70. マネージャー間での情報共有とメンバーとの1on1
    • ⽬的
    • 個々のメンバーの成⻑に向けたフィードバックに活かす
    • マネージャー同⼠が向いている⽅向を揃える
    • やったこと
    • マネージャー陣で会話しまくる
    • メンバー個⼈の良い⾏動や課題、フィードバック
    • それぞれの視点から⾒える情報を共有する
    • ⾃分以外の視点も踏まえてメンバーと1on1
    Θ͍Θ͍

    View Slide

  71. プロダクトオーナーとメンバーで1on1
    • ⽬的
    • プロダクトオーナーと開発メンバーの距離感を近づける
    • わたしがメンバーのみんなと仲良くなる
    • やったこと
    • 定期的に1on1でお話する時間を設定
    • 雑談やプロダクトに関する相談、振り返り
    ࠷ۙͲ͏Αʁ
    ఱؾ͕ྑ͗ͯ͢ॵ͍͠ɺ
    ম͚ͯ͠·͏ͷ͕ؾʹͳͬͯɻɻ
    ͍͍೔ম͚ࢭΊ͋ΔΑʂ
    ڭ͍͑ͯͩ͘͞ʂ
    ࠷ۙͲ͏Αʁ
    ྑͦ͞͏ʂϓϩμΫτͰ΍ͬͯ
    ΈΑ͏ΑʂΞΠςϜ࡞ͬͯ΄͍͠ͳ
    ͥͻʂΞΠςϜ࡞Γ·͢ʂ
    ΍ͬͯΈ͍ͨ͜ͱ͕͋ΔΜ
    Ͱ͚͢Ͳɺɺ͜ΕͲ͏ࢥ͍·͢ʁ

    View Slide

  72. 向く⽅向を揃えるための⼯夫
    • 半期ごとのキックオフ
    • 半期ごとにインセプションデッキを作成/⾒直し
    • 四半期単位でのエピックリファインメント
    • 毎スプリント内でのリファインメント

    View Slide

  73. 半期ごとのキックオフ
    • ⽬的
    • 半期のプロダクトゴールを提案
    • チームがいまいる場所の認識を揃える
    • 今期もがんばろうという気持ちになる
    • やっていること
    • 前期のふりかえり
    • 前期できたことを確認
    • 今期の⽬標
    • 今期⼒を⼊れること
    2021H2キックオフ資料より↑→

    View Slide

  74. 半期ごとにインセプションデッキを作成/⾒直し
    • ⽬的
    • ⾃分たちが担当しているプロダクトに向き合う
    • チームメンバーがお互いに考えていることを知り、すり合わせる
    • やっていること
    • プロダクトのフェーズに合わせてスコープを提⽰
    • ⼀部の項⽬にフォーカスして議論
    • 事前のグループ分け&ワールドカフェ形式での議論
    • 参考
    • https://agile-monster.com/blog/5minutes-inception-deck/
    インセプションデッキのテンプレートより
    https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck

    View Slide

  75. 四半期単位でのエピックリファインメント
    • ⽬的
    • 四半期単位で向いている⽅向を調整
    • やっていること
    • やらないといけないこと、わたしたちがやりたいことから、優先順決め
    • 案件の進捗の確認
    • ざっくりなロードマップの作成
    ある四半期のざっくりなロードマップ

    View Slide

  76. 毎スプリント内でのリファインメント
    • ⽬的
    • アイテムだけでなくエピックレベルの情報にも⽬を向ける
    • ⾃分のチームが担当していないことの状況を知る
    • やっていること
    • リリース計画
    • 直近の周囲の情勢を共有
    • 情勢にあわせてロードマップを
    アップデート
    ある四半期のざっくりなロードマップ
    ある⽉のスケジュール

    View Slide

  77. 毎スプリント内でのリファインメント
    • ⽬的
    • アイテムだけでなくエピックレベルの情報にも⽬を向ける
    • ⾃分のチームが担当していないことの状況を知る
    • やっていること
    • リリース計画
    • 直近の周囲の情勢を共有
    • 情勢にあわせてロードマップを
    アップデート
    ऴΘͬͨ΋ͷʹ
    νΣοΫΛೖΕͨΓ
    ある四半期のざっくりなロードマップ
    ある⽉のスケジュール
    ௕Ҿ͘΋ͷ͸
    εϥΠυͤͨ͞Γ

    View Slide

  78. 向く⽅向を揃えるために

    View Slide

  79. 向く⽅向を揃えるために
    ΩοΫΦϑ
    ΠϯηϓγϣϯσοΩ࡞੒
    ΤϐοΫϦϑΝΠϯϝϯτ
    ϦϑΝΠϯϝϯτ
    ൒೥͓͖
    ൒೥͓͖
    ϲ݄͓͖
    ຖि
    Q4
    Q3
    Q2
    Q1

    View Slide

  80. まとめ

    View Slide

  81. ⼤⼈数でスクラムをやるということ
    • ⼈数が増えて⼀度にできることが増えることで起きる課題と向き合わなければならない
    • コミュニケーションにおける課題に向き合いチームの⽣産性を⾼めなければならない

    View Slide

  82. ⼈数が多いからこそロールに沿ったアプローチをする
    • 各チームは開発者としての責任を全うするためのアプローチを
    • ⾃分たちのチームの最適化
    • 周囲のチームとの連携
    • スクラムマスターはスクラムチーム全体を⾒たアプローチを
    • チーム単体では気づきにくい課題の提⽰
    • 先を⾒据えた提案
    • プロダクトオーナーはスクラムチームが向く⽅向を揃えるアプローチを
    • スクラムチームが向かう先を常に指し⽰す
    ⼀度取り組んだら終わりではなく、課題の解消/改善を続けていくのがだいじ
    ⼩さくても1つずつ確実に良くしていく

    View Slide

  83. ⼈数が多くてもスクラムはスクラムだし、アジャイル
    • ⼤規模スクラムでは役割などが⼀段階抽象化されるが、考え⽅はスクラムと変わらない
    • LeSSでも、Scrum@Scaleでも。
    • スクラムの基本原則である考え⽅に変わりはない
    • アジャイルマニフェストの原則に則るところも同じ
    • 戻るべきところはスクラムガイドであり、アジャイルマニフェスト
    だいじなのは、常によりよいものを提供し続けるために、模索し続けることができるチームである
    こと

    View Slide

  84. ありがとうございましたmm

    View Slide