どうするLeSS - スクラムフェス三河2023.9.16

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© Stanby, Inc. 本日のセッションでお話しすること 2 私のいるプロダクト部門では、数年間 LeSS（Large Scale Scrum）を運用した後、いちど解体しました。それから2年が経った今、再び LeSS の導入に向けて歩み始めています。この間に私たちが気付いたことや、次の成功に向けて議論してきたことを共有させていただきたいと思います。 ● 第一次 LeSS をなぜ解体することになったか ● 第二次 LeSS 導入への再始動にあたって議論し整理してきたこと

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© Stanby, Inc. 本日のセッションでお話ししないこと 4 ● LeSS フレームワークの詳しい話 ● LeSS とスクラムをスケーリングする他のフレームワークとの比較 ● LeSS におけるスクラムイベントなどでのプラクティス本発表は、スクラムチーム内の活動というより、開発組織を俯瞰してチーム構成やアーキテクチャについてみている話が主体になっています。＜フレームワークやプラクティスの参照先＞ LeSS公式サイト：https://less.works または、書籍：大規模スクラム Large-Scale Scrum(LeSS) 〜アジャイルとスクラムを大規模に実装する方法〜 / 榎本明仁監訳、荒瀬中人・木村卓央・高江洲睦訳 https://www.maruzen-publishing.co.jp/item/?book_no=295180 原著：Craig Larman, Bas Vodde / LARGE-SCALE SCRUM: More with LeSS

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© Stanby, Inc. ● ConfengineやSNSごとにプロフィール画像がバラバラだったことを後悔中 ... 発表者 ▶ piro. takahara（Takahara Hiroshi）@piro12vortis 7 経験業種・業界 ● 自社ソフトウェア ● Webソリューション（受託系） ● コンサルティング、 SES ● モバイルゲーム ● 映像配信 ● Webサービス、など好きな○○ 経験職種 ( role ) ● BEER ▶ サッポロCLASSIC ● CURRY ▶ 南インド〜スリランカ系 ● COFFEE ▶ Guatemala ● TEAM ▶ 徳島ヴォルティス ● SLOPE ▶ ニセコひらふ ● EVENT ▶ ふりかえり、読書会（輪読会） ● ソフトウェアエンジニア ● SE、PM/PMO ● PO ● SM、社内アジャイルコーチ ● EM ● 人事その他

Slide 8

Slide 8 text

© Stanby, Inc. 発表者 ▶ 今日お話しする内容に関連する前置き 8 私は（エンジニアリング経験はあるものの）組織マネジメント・組織開発まわりの、＝『アジャイルのレフトウィング』＝「チーム環境」に向き合う領域を主戦場にしています。引用元：アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ / 平鍋さん inspired by 常松さんのスクラムフェス大阪 2023ご登壇資料、本日ご発表の Satoshi Harada / Akira Kubo - アジャイルのライトウィングとレフトウィングはひとりで両方できなくてもいいんじゃない？「ひとりでできるもん！」から「みんなでできるもん！」への道のり

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© Stanby, Inc. 株式会社スタンバイは、Zホールディングス株式会社と株式会社ビジョナルによる合弁事業会社です。社名株式会社スタンバイ事業内容求人検索エンジン「スタンバイ」の運営住所東京都渋谷区設立 2019年11月12日資本金 1億円株式保有割合 Zホールディングス60%、ビジョナル40% Yahoo! JAPAN LINE ZOZOTOWN PayPay etc BIZREACH HRMOS M&Aサクシードトラボックス etc 10 会社概要

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© Stanby, Inc. 対象組織の概要 - 提供サービス（プロダクト） 12 求人検索エンジン「スタンバイ」は、Web上に点在するあらゆる求人情報を一括で検索できるサービスです。ネット上の求人を一括で検索ユーザー(求職者) 求人メディア企業ページ直接スタンバイに登録された求人採用管理システム求人情報取得クローリング等・雇用形態・給与形態・掲載開始日・こだわり条件・自宅や最寄り駅からの距離求人票検索応募ユーザー(求職者)

Slide 13

Slide 13 text

MISSION 配布厳禁世の中は変わり、あたらしい価値観が次々と生まれている。だからこそ「はたらく」は、もっと自由で多彩であるべきだ。私たちは、ひとりひとりの選択肢と可能性を広げていき、人々の「はたらく」をアップデートしていく。情報技術の力で、新しい仕組みを生み出し、本気で実現したい未来へと加速させていく。あたらしい働き方、スタンバイから。 MISSION 13

Slide 14

Slide 14 text

14 VISION 一番大きな、仕事の交差点へ世の中の求人を収集・整理し、仕事を探す人と、人材を探す企業のマッチングがもっとも生まれる場所になる。まず、スタンバイは、そこを目指す。人と企業のマッチングを通して、世の中の選択肢と可能性をひろげ、人と社会を元気にする。 14

Slide 15

Slide 15 text

© Stanby, Inc. 対象組織の概要 - プロダクトを構成する機能群 15 「スタンバイ」は、他の様々な検索サービスと同じく大きく3つの機能群で構成されています。 ● 求職者（個人ユーザー）向け機能群 ○ 検索意図の的確な把握 ○ 検索結果を分かりやすい提示 ● 求人出稿者（法人ユーザー）向け機能群 ○ 求人データ収集 ○ 求人データ解析 ○ インデクシング ● マッチング・ランキング機能群 ○ 検索エンジンの様々な内部機能引用元：プロダクト開発体制のこれまでとこれから：StanBy Tech Blog 2022-11-22 エントリ https://techblog.stanby.co.jp/entry/organization

Slide 16

Slide 16 text

© Stanby, Inc. 対象組織の概要 - プロダクトを構成する機能群 16 「スタンバイ」は、他の様々な検索サービスと同じく大きく3つの機能群で構成されています。 ● 求職者（個人ユーザー）向け機能群 ○ 検索意図の的確な把握 ○ 検索結果を分かりやすい提示 ● 求人出稿者（法人ユーザー）向け機能群 ○ 求人データ収集 ○ 求人データ解析 ○ インデクシング ● マッチング・ランキング機能群 ○ 検索エンジンの様々な内部機能引用元：プロダクト開発体制のこれまでとこれから：StanBy Tech Blog 2022-11-22 エントリ https://techblog.stanby.co.jp/entry/organization 以降のお話と関連します

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© Stanby, Inc. LeSSの基礎知識（要点のみ）・・・に行く前にこのセッションにご参加いただいている有り難いみなさんに質問させてください。【Q】LeSS との親しみ具合はどれくらいですか？ A. 指導している/指導できる B. 何年も実践してる C. 1年未満だが実践中 D. 実践できていないが、勉強している E. 名前を聞いたくらいで、細かいことはあまり・・・ F. LeSS 以外のフレームワークでスクラムをスケールしている Yo! その他（フリーワードでも okです！） 18

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© Stanby, Inc. LeSSの基礎知識（要点のみ）「LeSS」は、1人のPOと 1つのProduct Backlogを中心に、複数のチームが並走するかたちでスクラムをスケーリングするフレームワークです。※発表者オリジナル ● イベントは、全チーム共同のものと、チーム個別のものとを連携して行います。 ● スクラムマスターは専任フルタイム、チームのメンバーに含まれず、1〜3チームを支援します。 20 LeSSの全チームが共同で実施するイベント ● Sprint Planning 1 ● Sprint Review ● Overall Retrospective ● Multi-Team Product Backlog Refinement 各チームで個別に実施するイベント ● Sprint Planning 2 ● Daily Scrum ● (Team) Retrospective ● Single-Team Product Backlog Refinement Although LeSS is strongly influenced by Scrum, it is definitively not the same. ・Backlog Refinement is not an activity but an event.　・Scrum Master is a fulltime role, not a member of a Team. 引用元：https://less.works/less/framework/differences-with-scrum

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© Stanby, Inc. お話しする出来事のタイムライン 24 ▶SM ▶SM・アジャイル推進 ➔ 再びほぼアジャイル専任に【イマココ】 ▶EM ➔ 社内アジャイルコーチ的なムーブを継続 2020年7月〜 Joinした発表者の役割の変遷第一次LeSS 開始第一次LeSS 終了　→コンポーネントチーム体制第二次LeSS 開始予定 2018年（らしい） 2021年 4月 2023年 4月 ? 年 ? 月再び LeSS 導入へとリスタート

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© Stanby, Inc. お話しする出来事のタイムライン【再掲】 26 第一次LeSS 開始第一次LeSS 終了　→コンポーネントチーム体制第二次LeSS 開始予定 2018年（らしい） 2021年 4月 2023年 4月 ? 年 ? 月再び LeSS 導入へとリスタートこのあたりの話をします ▶SM ▶SM・アジャイル推進 ➔ 再びほぼアジャイル専任に【イマココ】 ▶EM ➔ 社内アジャイルコーチ的なムーブを継続

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© Stanby, Inc. 第一次LeSS時代開始 29 LeSS を始めた理由 ● 全体最適に開発を進めたい ○ 開発チームごとの優先順位で機能のリリースやアップデートが進んでいるが、サービスとしては一つなので... いまいま優先する=注力したい開発にリソースを集中して、より速く進めたい ※ ○ お互いのコンポーネントを触れるメンバーを増やして、属人化を解消したい・・・と、かなり典型的な状況と導入理由だったように思います。 ※各チームでバックログの優先順どおり開発を進めても、プロダクト全体では最適に開発が進まないという「あるある」な状況参考：スクラム導入後にアジリティが減少してしまう理由：https://scrummaster.jp/why-scrum-isnt-making-your-company-very-agile/

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© Stanby, Inc. 第一次LeSS時代試行錯誤 - その1 31 発生した問題 ● フィーチャーチーム化が進まない ○ 各チームが担えるドメインが偏ったままで、 Product Backlog Item を取れないこの状態から抜け出せていないこの状態になりたいのに・・・引用元：Feature Teams - Large Scale Scrum (LeSS) ：https://less.works/less/structure/feature-teams?preferred_lang=jp

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© Stanby, Inc. 33 発生した問題 ● フィーチャーチーム化が進まない ○ 各チームが担えるドメインが偏ったままで、 Product Backlog Item を取れない当時の要因分析 ● チームを跨いだ連携が円滑に進んでいない ○ ※いま思えば、要因の深掘りが足りない... × プロダクトバックログの並び順に開発できないチーム呉がアイテム3を取れないまま・・第一次LeSS時代試行錯誤 - その1

Slide 34

Slide 34 text

© Stanby, Inc. 34 当時の要因分析 ● チームを跨いだ連携が円滑に進んでいない当時の対策 ● メンバーをシャッフルしてチーム再編 ○ （考え方の筋は悪くなかったと思うが）全チームが全てのアイテムを取れるようにと、各チームにできるだけ全てのコンポーネントを触れる人を配分しようとした。 × プロダクトバックログの並び順に開発できないチーム呉がアイテム3を取れないまま・・第一次LeSS時代試行錯誤 - その1

Slide 35

Slide 35 text

© Stanby, Inc. 35 当時の要因分析 ● チームを跨いだ連携が円滑に進んでいない当時の対策 ● メンバーをシャッフルしてチーム再編 ○ （考え方の筋は悪くなかったと思うが）全チームが全てのアイテムを取れるようにと、各チームにできるだけ全てのコンポーネントを触れる人を配分しようとしたその結果 ● 依然フィーチャーチーム化が進まない ○ チームメンバーのドメイン経験が多様化し、ほとんどのバックログアイテムの相互理解コストが増大（学習コストではあるものの...） ○ 当座の開発対応において連携必要なドメイン経験が近いメンバーの所属チームが分散し、チーム間の連携・調整コストが増大 × プロダクトバックログの並び順に開発できないチーム呉がアイテム3を取れないまま・・第一次LeSS時代試行錯誤 - その1

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© Stanby, Inc. 38 当時の要因分析 ● チーム・個人ごとに得意なドメインが異なるため、ドメイン相互のキャッチアップにコストがかかる当時の対策 ● エリアPOを設けて、LeSS Huge に移行 ○ エリアPOにドメインのエバンジェリストとして広く布教する役割を期待した。引用元：LeSS Huge - Large Scale Scrum (LeSS) ：https://less.works/less/less-huge 第一次LeSS時代試行錯誤 - その2

Slide 39

Slide 39 text

© Stanby, Inc. 39 当時の対策 ● エリアPOを設けて、LeSS Huge に移行 ○ エリアPOにドメインのエバンジェリストとして広く布教する役割を期待した。 ○ LeSS Huge の思想・条件に合っていない ○ （軽くやりすぎ）その結果 ● 各エリアの専門家は育ってきた。しかし・・・ ● エリアPOごとに独立して動くことが多くなり、お抱えチームが生まれ、サイロ化へと向かった。（→コンポーネントチームと変わらない状態に） ● エリア横断で進める課題の調整コストが更に増大・・・😢 引用元：LeSS Huge - Large Scale Scrum (LeSS) ：https://less.works/less/less-huge 第一次LeSS時代試行錯誤 - その2

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© Stanby, Inc. 第一次LeSS時代終了 42 引用元：プロダクト開発体制のこれまでとこれから：StanBy Tech Blog 2022-11-22 エントリ https://techblog.stanby.co.jp/entry/organization ユーザードメインが異なる技術ドメインも異なる終了理由 ● フィーチャーチーム化が進まない ● それほどスピードも上がらない要因分析 ● ドメインが広すぎた。

Slide 43

Slide 43 text

© Stanby, Inc. 第一次LeSS時代終了 43 引用元：プロダクト開発体制のこれまでとこれから：StanBy Tech Blog 2022-11-22 エントリ https://techblog.stanby.co.jp/entry/organization ユーザードメインが異なる技術ドメインも異なる学習コストが高い終了理由 ● フィーチャーチーム化が進まない ● それほどスピードも上がらない要因分析 ● ドメインが広すぎた。サービス全体のドメインをカバーするフィーチャーチームを目指すのは簡単ではなかった。

Slide 44

Slide 44 text

© Stanby, Inc. 第一次LeSS時代終了 44 引用元：プロダクト開発体制のこれまでとこれから：StanBy Tech Blog 2022-11-22 エントリ https://techblog.stanby.co.jp/entry/organization ユーザードメインが異なる技術ドメインも異なるイマドキの言葉を使うと認知負荷が高い要因分析 ● ドメインが広すぎた（結局これに尽きる）サービス全体のドメインをカバーするフィーチャーチームを目指すのは簡単ではなかった。 “チームトポロジー”で指摘された「認知負荷」が相当高い開発体制を目指していたと言えます。

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© Stanby, Inc. お話しする出来事のタイムライン【再掲】 48 第一次LeSS 開始第一次LeSS 終了　→コンポーネントチーム体制第二次LeSS 開始予定 2018年（らしい） 2021年 4月 2023年 4月 ? 年 ? 月再び LeSS 導入へとリスタートこのあたりの話をします ▶SM ▶SM・アジャイル推進 ➔ 再びほぼアジャイル専任に【イマココ】 ▶EM ➔ 社内アジャイルコーチ的なムーブを継続

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© Stanby, Inc. 直近の状況 ● good ○ （ねらいどおり）各技術ドメインの習得・共有は進み、深化した。 ● motto ○ 重要課題があっても開発メンバーのパワーを集結できない。 ■ 担当外ドメインでは要件定義も設計も実装も運用も助けることが難しい・・・ ○ チーム横断で取り組む開発のスピードが出ない。 ■ 異なる優先度、異なるサイクルで開発するチーム間でなにかと調整が難しい・・・そして、再び 50

Slide 51

Slide 51 text

© Stanby, Inc. そして、再び 51 この状況は、以前「全体最適に開発を進めたい」と言ってたのと変わっていない。 ● なぜ、いちど問題が潜んでいたのか？ ○ LeSSを止めてコンポーネントチーム体制に移行した当時は、同時期に更新したプロダクトロードマップに沿ったかたちでチームも組まれ、そのとき優先すべき開発課題に注力できる状態だった。 👉当時分けたチームなので当時のプロダクトゴールとシンクロしていた

Slide 52

Slide 52 text

© Stanby, Inc. そして、再び 52 この状況は、以前「全体最適に開発を進めたい」と言ってたのと変わっていない。 ● なぜ、いちど問題が潜んでいたのか？ ○ LeSSを止めてコンポーネントチーム体制に移行した当時は、同時期に更新したプロダクトロードマップに沿ったかたちでチームも組まれ、そのとき優先すべき開発課題に注力できる状態だった。 👉当時分けたチームなので当時のプロダクトゴールとシンクロしていた ○ それから、1年、2年と経ち・・プロダクト全体で注力したい新たな課題が出てくると・・・ ○ 自チームを一歩踏み出せば未経験領域となるコンポーネントチームの宿命により、開発リソースを柔軟に集中させることが難しいという問題が再浮上。もう一度、しっかり向き合おう！

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© Stanby, Inc. 議論してきたこと 54 これから向かうべき開発体制について、議論を重ねました。 ● チーム構成の考え方 ○ チームの分界はどうあるべきか？ ○ チームを再編する条件・タイミングは？ ● 開発チームのあるべき姿 ○ 理想のフィーチャーチームとは？そして、我々が実現すべきフィーチャーチームとは？ ○ 理想のコンポーネントチームとは？そして、我々が実現すべきコンポーネントチームとは？ ● やるべきこと ○ これから目指すべき開発体制に辿り着くために必要なことは？

Slide 55

Slide 55 text

© Stanby, Inc. 議論してきたこと 55 ちゃんと考えて歩んでいる方にとっては「当然」の話ばかりかも.. これから向かうべき開発体制について、議論を重ねました。 ● チーム構成の考え方 ○ チームの分界はどうあるべきか？ ○ チームを再編する条件・タイミングは？ ● 開発チームのあるべき姿 ○ 理想のフィーチャーチームとは？そして、我々が実現すべきフィーチャーチームとは？ ○ 理想のコンポーネントチームとは？そして、我々が実現すべきコンポーネントチームとは？ ● やるべきこと ○ これから目指すべき開発体制に辿り着くために必要なことは？

Slide 56

Slide 56 text

© Stanby, Inc. 議論してきたことこれから向かうべき開発体制について、議論を重ねました。 ● チーム構成の考え方 ○ チームの分界はどうあるべきか？ ○ チームを再編する条件・タイミングは？ ● 開発チームのあるべき姿 ○ 理想のフィーチャーチームとは？そして、我々が実現すべきフィーチャーチームとは？ ○ 理想のコンポーネントチームとは？そして、我々が実現すべきコンポーネントチームとは？ ● やるべきこと ○ これから目指すべき開発体制に辿り着くために必要なことは？ 56 ちゃんと考えて歩んでいる方にとっては「当然」の話ばかりかも.. けど、こういう議論をまともにやりきることが意外に...

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

© Stanby, Inc. 議論してきたこと - チーム構成の考え方開発組織のチーム分界はどうあるべきか？を考えるなかで、次のような問いを立てました。 ● 最高のパフォーマンスを出せるのはどんなチームか？ ● 開発チームの再編を検討すべき条件は？議論のなかで交わされた意見 ● 他チームへの依存度が小さいとチームが独力で Delivery できる。 ● やみくもにフィーチャーチームを目指すと、コストばかり高まって Delivery が滞ってしまう。 ● 担当する開発のための学習コストが大きすぎない。 ● とはいえ、学習コストは小さければ良いというわけでもない。成長がないと今度はモチベーションが上がらない。 59

Slide 60

Slide 60 text

Slide 61

Slide 61 text

© Stanby, Inc. 議論してきたこと - チーム構成の考え方たどり着いた結論。チーム分界は2つのドメイン距離を基準に考えるべき ● 技術ドメイン ○ 使用技術、使用言語、... ● ユーザードメイン ○ 提供価値、事業目標、... いずれのドメインも、距離が遠くなると学習コストやスイッチングコストが嵩むためと考えました。逆説すると、ドメインの近さを適正な範囲に収めることで、コストを掛け過ぎず、速く前進できると言えそうです。 61

Slide 62

Slide 62 text

© Stanby, Inc. 議論してきたこと - チーム構成の考え方たどり着いた結論。チーム分界は2つのドメイン距離を基準に考えるべき ● 技術ドメイン ○ 使用技術、使用言語、... ● ユーザードメイン ○ 提供価値、事業目標、... どこかで聞いた話と似ていませんか？そうなんです、これは、チームトポロジーで指摘されている「適切な境界が認知負荷を下げる」ことへの認識が合ってきたと言い換えることができます。 62

Slide 63

Slide 63 text

© Stanby, Inc. 議論してきたこと - チーム構成の考え方引用：書籍「チームトポロジー」 Chapter3 - チームファースト思考 - 「まとめ」セクションより ※太字と文字色は発表者が付加チームの認知負荷を制限し、チームインタラクションを促進することで、速く進めるようにする 63 チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計 / マシュー・スケルトン、マニュエル・パイス著 / 原田騎郎、永瀬美穂、吉羽龍太郎訳 https://pub.jmam.co.jp/book/b593881.html 　変化が激しくチャレンジングな状況では、個人の集まりよりもチームのほうがより効果的に働ける。（略）　重要なのは、チームのサイズには制限（ダンバー数）があり、単一のチームが取り扱える認知負荷には実質的な限界があることだ。このことから、単一のチームが扱うべきソフトウェアシステムとドメインの複雑度には制限があることが強く示唆される。チームは扱うシステムやサブシステムにオーナーシップを持つ必要がある。チームが複数のコードベースを扱うとオーナーシップを失うだけでなく、システムを理解し健全に保つための心理的な余裕も失ってしまう。（後略）

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

© Stanby, Inc. 議論してきたこと - 開発チームのあるべき姿次に「やみくもにフィーチャーチームを目指すと、コストばかり高まって Delivery が滞ってしまう」について次のような問いを立てました。 ● 良いフィーチャーチームとは？ ● 良いフィーチャーチームとコンポーネントチームの連携は？これもまた、チームトポロジーや、unFIX モデルなどと通じる議論になりました。 67 Photo by Annie Spratt on Unsplash

Slide 68

Slide 68 text

Slide 69

Slide 69 text

© Stanby, Inc. 議論してきたこと - 開発チームのあるべき姿 69 LeSSを組んだ直後のイメージ議論の結果、フィーチャーチームの社内定義を宣言して、認識を合わせることになりました。（参考）フィーチャーチームの定義フィーチャーチームは担当するプロダクト*バックログのアイテムを並んでいる順に開発していくチームである。 ● 但し、1チームで全ての技術を取り扱う必要はない* ● また、チームが取り扱う技術をチームメンバー全員が等しく習得する必要はない * これらを実現するために、プロダクトのスコープは適切に分割され、低い依存度で LeSS 外のチームが提供するサービスを利用できるようにする。

Slide 70

Slide 70 text

© Stanby, Inc. 実は LeSS.works でも同じことが明記されていました。 A common misunderstanding: every member of a feature team needs to know the whole system. Not so, because ● The team as a whole—not each individual member—requires the skills to implement the entire customer-centric feature. These include component knowledge and functional skills such as test, interaction design, or programming. But within the team, people still specialize… preferably in multiple areas. ● Features are not randomly distributed over the feature teams. The current knowledge and skills of a team are factored into the decision of which team works on which features. Within a feature team organization, when specialization becomes a constraint…learning happens. 議論してきたこと - 開発チームのあるべき姿 70 引用元：Feature Teams - Large Scale Scrum (LeSS) ：https://less.works/less/structure/feature-teams?preferred_lang=jp

Slide 71

Slide 71 text

© Stanby, Inc. 議論してきたこと - 開発チームのあるべき姿 71 学習機会と捉えるチーム間で支援する（し合う） ● 1チームで全ての技術を取り扱う必要はない* ● チームが取り扱う技術をチームメンバー全員が等しく習得する必要はない * なお、これらを実現するために、プロダクトのスコープを適切に分割され、（後略）・・と注釈を添えていますが、そもそも・・ LeSS では、チームが協働によって学習してスキルを拡張していくことが期待されていて、学習機会を提供する仕掛けが組み込まれていますし、プロダクトのスコープも今より拡張していくという思想も組み込まれています。

Slide 72

Slide 72 text

© Stanby, Inc. 議論してきたこと - 開発チームのあるべき姿 72 学習機会と捉えるチーム間で支援する（し合う） ● 1チームで全ての技術を取り扱う必要はない* ● チームが取り扱う技術をチームメンバー全員が等しく習得する必要はない * なお、これらを実現するために、プロダクトのスコープを適切に分割され、（後略）・・と注釈を添えていますが、そもそも・・ LeSS では、チームが協働によって学習してスキルを拡張していくことが期待されていて、学習機会を提供する仕掛けが組み込まれていますし、プロダクトのスコープも今より拡張していくという思想も組み込まれています。最初から完全なフィーチャーチームじゃなくてよく、育っていければよい

Slide 73

Slide 73 text

Slide 74

Slide 74 text

© Stanby, Inc. 議論してきたこと - やるべきこと 74 これから目指すべき開発体制を構築するために・・ ● プロダクトロードマップにおいて、技術ドメインとユーザードメインの認知負荷が高くなる境目でプロダクトを再定義する ● 各プロダクトに開発チームを割り当てる（逆コンウェイ戦略） ● 2チーム以上がプロダクトバックログを共同所有するべき状況になれば、LeSS を導入するユーザードメインが異なる技術ドメインも異なる toC 領域のプロダクト toB 領域のプロダクト

Slide 75

Slide 75 text

© Stanby, Inc. 議論してきたこと - やるべきこと 75 そこに辿り着くために・・・ ● 複数のプロダクトを跨ぐサブシステム間の依存関係を解消できるよう、リアーキテクチャを進める ○ 節理面の境界を疎結合化して、以降は、 X-as-a-Service モードのインタラクション*で済むようにする ○ リアーキ初期から LeSS に移行して協働を開始することも学習機会 ● 技術的妥当性の観点でのプロダクト分界や移行タイミングに対するフィードバックにも耳を傾ける *チームトポロジーで示されているインタラクションモードの類型プロダクトバックログを跨ぐ依存関係を解消できるようリアーキテクチャ toC 領域のプロダクト toB 領域のプロダクト

Slide 76

Slide 76 text

© Stanby, Inc. 76 ● 複数のプロダクトバックログを跨ぐサブシステム間の依存関係を解消できるよう、リアーキを進める ○ 節理面の境界を疎結合化して、以降は、X-as-a-Service モードのインタラクションで済むようにする ○ 技術的妥当性の観点でのプロダクト分界や移行タイミングに対するフィードバックにも耳を傾ける 👉 day1 - Joe Justice さん keynote の「11 eXtreme Manufacturing principles」と符号しそうな部分 ● 4. One team waiting on another（あるチームが別のチームを待つ状態） ● 2. Dpendency Order（依存関係のある受注）議論してきたこと - やるべきこと　〜 refrain 〜

Slide 77

Slide 77 text

© Stanby, Inc. 議論してきたこと - やるべきこと（まとめ）現時点の、我々の「スクラムをスケーリングする進め方」を、あらためて整理します。 1. プロダクトのスコープを、現状〜近い将来のロードマップに照らして設定する ○ 2つの観点でチームの認知負荷が高くなり過ぎない境界を見定める、伸び代を考慮すること。 ■ 技術ドメイン＝Doneの定義の拡張レベル ■ ユーザードメイン＝プロダクトの拡張レベル 2. プロダクトバックログを進める際に外部依存が生じる部分のリアーキテクチャを計画する 3. プロダクトにチームを割り当てる 4. 現地現物をみて導入タイミングをみきわめ、チームと伴走する 77

Slide 78

Slide 78 text

Slide 79

Slide 79 text

© Stanby, Inc. いま、LeSS 導入の第一段階を進めようとしている中で、次のようなアクションアイテムがあります。 ● LeSS 内の具体的な運営方法の合意 ○ スプリントサイクルの決定 ○ プロダクトバックログとスプリントバックログの持ち方（ツール選定）、PoC ○ 共通のDoD作成 ○ 見積り基準のすり合わせ ● LeSS 内のフィーチャーチームと、LeSS 外のコンポーネントチームが円滑に連携する仕組みの構築（そして）その次の LeSS 導入へそして、歩み始めています 79 引用元：Feature Teams - Large Scale Scrum (LeSS) ：https://less.works/less/structure/feature-teams?preferred_lang=jp この図に近いイメージで段階的に LeSS を導入

Slide 80

Slide 80 text

© Stanby, Inc. いくつかの歩みを始めています。 ● 対象チームのバックログでリアーキを優先課題化 ● LeSS に移行したいドメインを公言 ● LeSS の Sprint Review 的なイベントの開催 ● Overall Impediment List の運用開始 ● Multi-Team Reﬁnement の時間枠を出社日のプロダクト全体の共通予定として設定 → 既に課題も出て・・見直しつつ、進めています。そして、歩み始めています 80 ※Bing Image Creator にて生成

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

© Stanby, Inc. そして、歩みを進めます 83 引用元： https://less.works/less/adoption/feature-team-adoption_map 人と組織のサステナブルな成長 ≒ チームの対象範囲の拡大 ● チームからみたプロダクトの拡張 ※右図のY軸 ● 完結できる作業の拡大（DoDの拡張） ※右図のX軸これ「フィーチャーチーム道」とでも呼びましょうか??

Slide 84

Slide 84 text

Slide 85

Slide 85 text

85 参考：https://www.odd-e.jp/training/course-detail/241 認定LeSS実践者研修（CLP）2023/9/6−8 資料の中で気に入った 3ページ ※使用許諾いただき済み次のページとリンクします

Slide 86

Slide 86 text

86 参考：https://www.odd-e.jp/training/course-detail/241 認定LeSS実践者研修（CLP）2023/9/6−8 資料の中で気に入った 3ページ ※使用許諾いただき済み

Slide 87

Slide 87 text

87 参考：https://www.odd-e.jp/training/course-detail/241 Just Talk !!! のほうが日本人にもニュアンス伝わるかも https://www.slideshare.net/ramvasan/large-scale-sc rum-more-with-less 認定LeSS実践者研修（CLP）2023/9/6−8 資料の中で気に入った 3ページ ※使用許諾いただき済み

Slide 88

Slide 88 text

LeSS 雑学：ロゴの “L” は不等号を模して『より小さく』と語っている 88 チームメンバーが（フレームワークに頼らず）自分たちの意志でコラボレーションし、学習・改善を行い、成長できる環境を提供するために必要最小限のフレームワークにするという理念を表現しているそうです。引用元：https://less.works/resources/graphics/LeSS-logos

Slide 89

Slide 89 text

Slide 90

Slide 90 text

Slide 91

Slide 91 text

© Stanby, Inc. まとめ LeSS を一度断念したことをふりかえり、LeSS に再挑戦することになった今、次のようなアクションに取り組んでいます。 ● 今から我々が目指す状態とプロダクトの再定義を行い、準備や進め方の認識合わせを進めた。 ○ 全体で1つのバックログを持つのは認知負荷が高すぎると判断し、ドメインによってプロダクトを再定義 ○ 分割したプロダクトバックログにチームを割り当てる（逆コンウェイ戦略の実行） ● 当面のプロダクトを跨ぐサブシステム間の依存関係をいったん最小化できるよう、リアーキを進める。 ○ 再定義したプロダクトの境界（節理面）にまたがるサブシステム・APIの再構築 91 チームトポロジーで言うところの X-as-a-Service インタラクションが成り立つように

Slide 92

Slide 92 text

© Stanby, Inc. ● プロダクトの定義 ○ 技術ドメインとユーザードメインの認知負荷を考慮してプロダクトのスコープを決める ○ 現実をみて、将来プロダクトを拡張することも考慮してフィーチャーチームの登り方の絵を描き、共有する ● 依存関係の最小化 ○ プロダクト（LeSS）の内と外との境界をまたぐコンポーネント間の依存関係を確認する ○ 依存関係がある場合、依存関係を最小化するためのリアーキテクチャを計画する ● チームの割り当て ○ プロダクトにチームを割り当てる、またはチーム再編をデザインする（逆コンウェイ戦略） ● 導入計画の合意 ○ 当事者と話し、チーム状況やリアーキのマイルストーンなどを考慮して、移行タイミングを合意するまとめ - LeSS 導入時の超基本タスクリスト 92

Slide 93

Slide 93 text

Slide 94

Slide 94 text

© Stanby, Inc. poem? 94 先週、Bas Vodde さん直々の『認定LeSS実践者研修』を受けさせていただいて・・・ ● LeSS には『アジャイルソフトウェア開発宣言』を強く意識させる思想・理念が息づているように感じました。 → 私も「人は学習し成長する」という信念を持って、よりよい仕事と学習の機会を提供できるようTRYし続けたいという思いを新たにしています。 ● LeSS で向かうべきは「相互依存度を高めて協業機会を生み出す」方向であることを再確認。 → 我々がいま進めている『プロダクト境界をリアーキテクチャして疎結合化する』は逆行する戦術と言えそうですが、別の観点で大切な “Go See” を重視して、現地現物をみながら、自分たちの実態に即した階段を設計して上っていけるようにしたいと考えています。またどこかで経過報告させてください！