atama plusのLearge-Scale Scrum

Transcript

1. a t a m a p l u s の

   L a r g e - S c a l e S c r u m 松 村 ⾼ 朗 2022.10.26

2. ⾃⼰紹介 2016. 4 - 2021.3 株式会社⽇本総合研究所 PO/Dev/ScM 2021. 4 -

   atama plus株式会社 ScM 松 村 ⾼ 朗 @ A l o e o o o 2

3. 教育に、⼈に、社会に、 次の可能性を。 教育を新しくすること。それは、社会のまんなかを新しくする こと。私たちは学びのあり⽅を進化させます。 学習を⼀⼈ひとり最適化し、「基礎学⼒」を最短で⾝につける。 そのぶん増える時間で、「社会でいきる⼒」を伸ばす。 それが私たちの⽬指すもの。⾃分の⼈⽣を⽣きる⼈を増やし、 これからの社会をつくっていきます。 Mission atama

   plus株式会社

4. ⓒ 2022 atama plus Inc. 4 全国の塾・予備校に AI教材「atama＋」を提供。 ⼀⼈ひとりの 「得意」「苦⼿」を分析し、

   学習をパーソナライズします。

5. なぜLeSSを導⼊したのか？

6. ⓒ 2022 atama plus Inc. 〜2020年5⽉（3つのスクラムチーム） なぜLeSSを導⼊したのか？ 6 ※POはプロダクトオーナー、QAはQuality Assurance

   、SMはスクラムマスターの略です。 SM デザイナー エンジニア QA PO ペルソナ

7. ⓒ 2022 atama plus Inc. ペルソナ別のスクラムチームでの課題 • プロダクトバックログ間の優先順位が異なる • 各ペルソナごとに最適化されたバックログに各チームが取り組むため、

   開発チーム全体としての提供価値が最⼤化されない • スクラムチームのサイロ化 • 異なるバックログ間の関係性や他チームの状況が⾒えづらくなり、 スクラムチーム間で協働しづらい なぜLeSSを導⼊したのか？ 7

8. ⓒ 2022 atama plus Inc. LeSSの導⼊、1⼈のPOと複数の開発チーム(2020年~2021年) なぜLeSSを導⼊したのか？ 8 SM デザイナー

   エンジニア QA PO ペルソナ 2020年9⽉に追加 2021年1⽉に追加

9. 現在の開発体制

10. ⓒ 2022 atama plus Inc. LeSS Hugeに近い形へ 現在の開発体制 10 SM

    PO メンバー/チーム増加で コミュニケーションコストや POの負担が限界に SM エンジニア デザイナー QA PO エンジニア デザイナー QA 実験としてLeSS Hugeに 近い体制へ移⾏

11. ⓒ 2022 atama plus Inc. LeSS Hugeに近い形へ 現在の開発体制 11 技術的課題の投資判断の難しさ

    開発効率向上等の技術的課題と 他の開発テーマでの優先度づけが難しい 特定のチームを設置 他にもコミュニティや会議体を ⽤意するなど試⾏錯誤中 SM PO SM エンジニア デザイナー QA PO エンジニア デザイナー QA 開発基盤チーム

12. LeSS運⽤での⼯夫

13. ⓒ 2022 atama plus Inc. LeSSにおいて⼯夫していること（1/2） • スクラムイベントのやり⽅は各チームに任せる • メンバー構成/チーム状況によって、最適なやり⽅は異なる

    • 各チームのやり⽅はオーバーオールレトロスペクティブ等で共有 • 開発内容の検討をPOからチームに委譲する • POが忙しくなりやすく時間を取りづらい • POは戦略までを検討し、開発内容はチームで検討する LeSSの運⽤での⼯夫 13

14. ⓒ 2022 atama plus Inc. LeSSにおいて⼯夫していること（2/2） • 複数チームでの開発をしやすくするための進め⽅やコミュニケーション設計 • 課題整理~仕様策定フェーズは、リードチームを設けて効率化を図る

    • 複数チームで同じテーマを開発する際には、通常のスクラムイベント以外 にも同期するタイミングを設ける • 属チーム化した内容は、共有会の実施や、学習⽤のPBIを⽤意するなどして、 知識を共有する LeSSの運⽤での⼯夫 14 SM エンジニア デザイナー QA PO

15. ⓒ 2022 atama plus Inc. まとめ atama plusのLeSS 15 LeSSは1チームスクラムとは

    異なる観点での運営・⽀援が必要 • ⼀⽅、チームが増えるについて、POの 負荷が増え、チームとしても全体感の把 握やコミュニケーションが難しくなる • 適切なタイミングでAreaに分けるのが良 さそう • PO-チーム間や各チーム間の関係性 • 各チームがすべてのドメイン/コード ベースに平等に詳しくない状況 • ⼀時的に許容し、部分的に効率化。 のちに平準化。 開発チーム全体で 最適な優先順位での開発が可能に

16. プロダクト開発について情報発信中！ @atamaplus_dev