３人から、３年間で３０人６チームまでのスケールした時の課題と、 Scrum@Scale及びLeSSのプラクティス適用 フルリモートワークでのスクラムのスケール 守田憲司 Preferred Networks, Inc.

守田 憲司 2 共訳 1991～2018 Canon Inc. 2018～ Preferred Networks, Inc 社内Agile Coach Scrum X Scale Hardware Research AI

最新の研究成果を、早く、高い品質で 研究成果を早く高品質に届けたい 3 Research/AI/Hardwareを含めたScrum 複数チームのScrum

Matlantis （対象プロダクト） バーチャル実験 汎用原子レベルシミュレータ 高速に材料探索 ～1万回オーダ 有望な 材料 結果・考察 フィードバック 次の バーチャル実験 リアル実験 触媒 潤滑油 吸着材 合成燃料の触媒探索 添加剤の鉄表面への作用 MOFへの水吸着 新たな研究開発サイクルによる開発期間短縮 適用事例 高い 成功確率 4

Matlantisの特徴 5 ブラウザ上で すぐに使用可能 従来手法の 10,000倍以上 高速 72元素の 組み合わせに 対応

LeSSとScrum@Scale 6 ----- ----- ----- ---- 9チームまで１チームのように CPO PO PO PO PO PO LeSS Scrum@Scale

● 成功するか分からない ● リソース不足 ● 激しいスキルと知識の乖離 スタート時(3年前)の状況 研究者 コア技術 サービス開発 ？

● 成功するか分からない ● リソース不足 ● 激しいスキルと知識の乖離 スタート時(3年前)のRetrospective 研究者 コア技術 サービス開発 Daily 無駄では？

● １チームをキープ ● クロスファンクショナルチームで共通言語を作る ● MVPしか作れない ⇨ Jupiter notebookのシミュレーション環境 １チームをキープ（３年前のスタート時） 研究者 コア技術 サービス開発

Problem-Solution Fit の感触 ● 少しずつ顧客が増えていく ● チームも徐々に成長 Problem-Solution Fit 10

● どうやっても全体は1チームに収まらない。 １年後の状況 研究者 コア技術 サービス開発 ？

● どうやっても全体は1チームに収まらない。 １年後のRetrospective 研究者 コア技術 サービス開発 Daily 無駄でしょ！

LeSSとScrum@Scale 13 ----- ----- ----- ---- 9チームまで１チームのように CPO PO PO PO LeSS Scrum@Scale 依存関係を少なく分割する

● Backlog, Meeting(Sprint Review以外) 分割 ● 研究者チームはScrum離脱、Product Backlogだけ共有 ● Scrum@Hardwareでエンジンと胴体作ったらこんな感じかも？ 専門性で分割（スタートから１年後） 研究者 コア技術 サービス開発 数ヶ月での 技術革新 研究成果を仕上げる のに時間がかかる 日～週単位でリリース 最先端 独自性 精度評価、確認 過去との互換性担保 車輪の再発明しない OSS活用して効率よく リズムの違い 価値観の違い ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----

● サービス開発チームが成長 ○ 多すぎるよな～ ○ 不満がでるまで待ってみよう スタートから2年後の状況 研究者 コア技術 サービス開発 ？ ？ ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----

スタートから2年後のRetrospective 研究者 コア技術 サービス開発 Dailyの共有はSlackで、、 ちょっと待って ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ---- 起きていたこと ● ミーティングが長く感じる ● チーム内の事を把握しきれない

LeSSとScrum@Scale 17 ----- ----- ----- ---- 9チームまで１チームのように CPO PO PO PO LeSS Scrum@Scale 依存関係を少なく分割する

● サービス開発をLess的に分割 ● １、２週間で当たり前になって、皆楽そう（ふりかえり難しい） ● チーム名はBlueとOrange、責任の分割無し ○ PO、Product Backlogは共通 ○ Muralのポストイットの色に対応させた（一つのKanban） ○ 結果としては、インフラよりとUXよりのチームができた スタートから2年後の分割結果 研究者 コア技術 サービス開発 ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----

● サービス開発は２チームでも厳しい感じに ● コア技術のチーム人数多め ● 研究者チームとは、少し疎な良い関係 さらに成長(半年前くらいの状況) 研究者 コア技術 サービス開発 ？ ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----

● チームの意味を理解 ● チーム分割を理解 半年前くらいのRetrospective 研究者 コア技術 分けてみよっか？ サービス開発 LeSS的にいきますか。 ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----

● サービス開発は３チームへ分割 ● コア技術のチームも試しに分割 現在の状態 研究者 コア技術 サービス開発 ● 3つのProduct Backlog ● 1つのSprint Review ● 5つのDaily Scrum ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----

スケールと役割の分離 22 PdM EM PO PdM EM CPO PO PO PO EM PO PdM EM CPO PO PO EM PO PO EM EM PO PdM CPO 少人数 チーム毎のPO EM 追加 EM分離 PdM, CPO 分離 全体 Green Team Orange Team Blue Team Purple Team 1人

現在のミーティング (1週間Sprint) 研究者 コア技術 サービス開発 Daily Daily Daily Daily Daily Planning Part 1,2 Planning Part 1,2 Review準備 Review準備 Sprint Review Planning 3 Planning 3 Planning 3 Planning 3 Planning 3 Retrospective Retrospective Retrospective Retrospective Retrospective 全体Retrospective 全体 Backlog Refinement Refinement Refinement Refinement Refinement Refinement

● 人数が多すぎる ○ Dailyが長くて退屈 ○ Daily Slackで済ませたい ○ ミーティングがムダ ○ 全部理解しきれない ○ Kanbanが縦に長い チーム分割まとめ 24 ● リズムが合わない ○ Deploy頻度 ○ Reviewの反応 ● 価値観が合わない ○ 車輪の再発明は避けたい ○ 最先端技術を創りたい LeSS的に分割 Scrum@Scale的に分割

非言語コミュニケーション 困ったときの相談 偶発的な会話 リモートワークで失われたこと 25 常に課題に上がる事 ● ミーティング時間のムダ ● コミュニケーション不足

偶発的な会話を増やすために考えたこと 26 リモートワークの有利な点 ● 会議への移動のロスが少ない。 起こりがちな事 ● ミーティングの参加者が増える ● 会議の数を減らす 意識した事 ● ミーティングの数を増やす ● 参加者を絞る

ミーティングの数と参加人数 27 多くの参加者 少ないミーティング 多くのミーティング 少ない参加者 2倍の発言量 一人当たり同じミーティング時 こうなりがち

様々な場を通じて、豊かな会話を 28 経営陣 PO & 経営陣 PdM POs Biz Biz & Service 開発 研究 コア 技術 研究& コア技 術 サービ ス 開発 ステー クホル ダー PO & ス テークホ ルダー サービス 開発 & ス テークホ ルダー 場をたくさん作る ● チーム内と代表者 ○ 参加者は絞って

リモートワークとスケールまとめ 研究者 コア技術 サービス開発 リズムと価値観で大きく分割 (Scrum@Scale) 8～10人になったら責任分担なく分割(LeSS) リモートワークの特性を活かし 会議を増やして、人数を絞る ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----

Making the real world computable