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

Transcript

1. © Stanby, Inc.
   どうするLeSS（スクラムのスケーリング）
   一度 LeSS を断念 〜 ふりかえり 〜 再挑戦の過程で
   チームトポロジーに向き合う現地からの中間報告
   1
   2023.9.16　 スクラムフェス三河
   

   View Slide

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

   View Slide

3. © Stanby, Inc.
   本日のセッションでお話しすること
   3
   持ち帰っていただくもの
   ● LeSS 導入時の超基本タスクリスト
   ○ 導入を検討するとき、導入計画を立てるときに押さえておくとよいと考えたことをお伝えします。
   

   View Slide

4. © 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
   

   View Slide

5. © Stanby, Inc.
   本日のセッションの流れ
   5
   1. 背景 & 前提
   ○ お話しする開発組織の概要
   ○ LeSS の概要（要点のみ）
   2. 第一次 LeSS 導入〜終了
   ○ 目指したこと、起こったこと、終了したこと
   3. 第二次 LeSS への再始動
   ○ 再導入の理由、議論したこと、議論の結果
   4. まとめ
   

   View Slide

6. © Stanby, Inc.
   本日のセッションの流れ
   6
   ちゃんと歩んで
   いらっしゃる方にとっ
   ては「当然」の話ば
   かりかも...
   1. 背景 & 前提
   ○ お話しする開発組織の概要
   ○ LeSS の概要（要点のみ）
   2. 第一次 LeSS 導入〜終了
   ○ 目指したこと、起こったこと、終了したこと
   3. 第二次 LeSS への再始動
   ○ 再導入の理由、議論したこと、議論の結果
   4. まとめ
   

   View Slide

7. © 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
   ● 人事
   その他
   

   View Slide

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

   View Slide

9. © Stanby, Inc.
   背景 & 前提
   9
   対象組織（スタンバイ-プロダクト部門）の概要
   

   View Slide

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

    View Slide

11. © Stanby, Inc.
    対象組織の概要 - 提供サービス（プロダクト）
    11
    求人検索エンジン「スタンバイ」
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

17. © Stanby, Inc.
    背景 & 前提
    17
    LeSSの基礎知識（要点のみ）
    

    View Slide

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

    View Slide

19. © Stanby, Inc.
    LeSSの基礎知識（要点のみ）
    LeSS = 1人のPO・1つのProduct Backlogを中心に、複数チームが並走するかたちでスクラムの規模を拡大する
    19
    引用元：https://less.works/jp/less/framework?setlang=japanese
    

    View Slide

20. © 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
    

    View Slide

21. © Stanby, Inc.
    LeSSの基礎知識（は以上です）
    ここからは、
    フレームワーク（PRINCIPLES, RULES, GUIDES）の話では
    なく、現場で進めている EXPERIMENTS の話をさせていただ
    きます。
    21
    引用元：Introduction to LeSS：https://less.works/less/framework/introduction
    

    View Slide

22. © Stanby, Inc.
    背景 & 前提
    22
    本日お話しする出来事のタイムライン
    

    View Slide

23. © Stanby, Inc.
    お話しする出来事のタイムライン
    23
    第一次LeSS 開始 第一次LeSS 終了
    　→コンポーネントチーム体制
    第二次LeSS 開始予定
    2018年
    （らしい）
    2021年
    4月
    2023年
    4月
    ? 年
    ? 月
    再び LeSS 導入へと
    リスタート
    イマココ
    

    View Slide

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

    View Slide

25. © Stanby, Inc.
    第一次 LeSS 導入〜終了
    25
    

    View Slide

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

    View Slide

27. © Stanby, Inc.
    第一次 LeSS 導入〜終了
    27
    開始
    

    View Slide

28. © Stanby, Inc.
    第一次LeSS時代 開始
    28
    当時の状況
    ● 既に複数の開発チームがあり（30人前後）、機能コンポーネントで開発チームを分けていた。
    ● 各チームではスクラムで開発していた（スクラムの土壌はあった）。
    ● 今後さらに人員増・チーム増が見込まれていた。
    

    View Slide

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

    View Slide

30. © Stanby, Inc.
    第一次 LeSS 導入〜終了
    30
    試行錯誤
    

    View Slide

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

    View Slide

32. © Stanby, Inc. 32
    発生した問題
    ● フィーチャーチーム化が進まない
    ○ 各チームが担えるドメインが偏ったままで、
    Product Backlog Item を取れない
    ×
    チーム 呉 が
    アイテム3を取れ
    ないまま・・
    第一次LeSS時代 試行錯誤 - その1
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

36. © Stanby, Inc.
    第一次LeSS時代 試行錯誤 - その2
    36
    発生した問題
    ● 各チームでアイテムがDoneにならない。
    ○ 毎スプリント、どのアイテムを進めるにも、調査
    から入らなければならない...
    

    View Slide

37. © Stanby, Inc. 37
    発生した問題
    ● 各チームでアイテムがDoneにならない。
    ○ 毎スプリント、どのアイテムを進めるにも、調査
    から入らなければならない...
    当時の要因分析
    ● チーム・個人ごとに得意なドメインが異なるため、ドメイ
    ン相互のキャッチアップにコストがかかる
    ○ ※いま思えば、要因の深掘りが足りない...
    第一次LeSS時代 試行錯誤 - その2
    

    View Slide

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

    View Slide

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

    View Slide

40. © Stanby, Inc.
    第一次LeSS時代 試行錯誤
    40
    などなど、いろいろありまして・・・
    

    View Slide

41. © Stanby, Inc.
    第一次 LeSS 導入〜終了
    41
    終了（その理由のふりかえり）
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

45. © Stanby, Inc.
    第一次LeSS時代 終了
    45
    と、いわゆる「無理筋」に気付き・・
    ● 2021年1月 現CTO明石が就任、開発組織の再編に着手
    ● 2021年4月 技術ドメインに基づいたチーム体制に移行
    かくして、第一次 LeSS 時代は終焉を迎えました。
    Photo by Matt Botsford on Unsplash
    

    View Slide

46. © Stanby, Inc.
    第一次 LeSS 時代 を追体験いただいて・・・
    【Q】もしご感想やコメントなどあれば教えてください！
    （フリーワード）
    46
    

    View Slide

47. © Stanby, Inc. 47
    第二次 LeSS への再始動
    

    View Slide

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

    View Slide

49. © Stanby, Inc.
    直近の状況
    ● good
    ○ （ねらいどおり）各技術ドメインの習得・共有は進み、深化した。
    そして、再び
    49
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

53. © Stanby, Inc. 53
    第二次 LeSS への再始動
    議論したこと
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

57. © Stanby, Inc. 57
    第二次 LeSS への再始動
    議論したこと
    その1：チーム構成の考え方
    

    View Slide

58. © Stanby, Inc.
    議論してきたこと - チーム構成の考え方
    58
    開発組織のチーム分界はどうあるべきか？を考えるなかで、次のような問いを立てました。
    ● 最高のパフォーマンスを出せるのはどんなチームか？
    ● 開発チームの再編を検討すべき条件は？
    

    View Slide

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

    View Slide

60. © Stanby, Inc.
    議論してきたこと - チーム構成の考え方
    たどり着いた結論。
    チーム分界は2つのドメイン距離を基準に考えるべき
    ● 技術ドメイン
    ○ 使用技術、使用言語、...
    ● ユーザードメイン
    ○ 提供価値、事業目標、...
    60
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

64. © Stanby, Inc.
    議論してきたこと - チーム構成の考え方
    64
    そして・・・
    開発チームの再編を検討すべき条件・タイミングについても次の
    ように整理できました。
    技術ドメイン観点
    ● 学習コストやスイッチングコストが大きくみえる場合
    ユーザードメイン観点
    ● 求められる体験(UX)が異なる場合
    ● 異なる目標を目指したほうがよい場合
    （KPI, Product Goal...etc）
    

    View Slide

65. © Stanby, Inc. 65
    第二次 LeSS への再始動
    議論したこと
    その2：開発チームのあるべき姿
    

    View Slide

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

    View Slide

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

    View Slide

68. © Stanby, Inc.
    議論してきたこと - 開発チームのあるべき姿
    68
    議論の結果、フィーチャーチームの社内定義を宣言して、認識
    を合わせることになりました。
    Photo by Austin Distel on Unsplash
    

    View Slide

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

    View Slide

70. © 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
    

    View Slide

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

    View Slide

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

    View Slide

73. © Stanby, Inc. 73
    第二次 LeSS への再始動
    議論したこと
    その3：やるべきこと
    

    View Slide

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

    View Slide

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

    View Slide

76. © 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 〜
    

    View Slide

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

    View Slide

78. © Stanby, Inc. 78
    第二次 LeSS への再始動
    そして、歩みを進めています
    

    View Slide

79. © 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 を導入
    

    View Slide

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

    View Slide

81. © Stanby, Inc.
    第二次 LeSS への再始動 を追体験いただいて・・・
    81
    【Q】もしご感想やコメントなどあれば教えてください！
    （フリーワード）
    

    View Slide

82. © Stanby, Inc.
    そして、歩みを進めます
    82
    これからずっと挑戦・検証を繰り返していくこと・・
    ● 人と組織のサステナブルな成長
    ≒ チームの対応範囲の拡張
    （次のページに少し書き添えます）
    ● 人と組織と事業の成長に適したシステムと組織のアー
    キテクチャの探求
    （もちろんゴールはないはずです）
    

    View Slide

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

    View Slide

84. © Stanby, Inc.
    付録　
    84
    

    View Slide

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

    View Slide

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

    View Slide

87. 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ページ ※使用許諾いただき済み
    

    View Slide

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

    View Slide

89. © Stanby, Inc.
    まとめ　
    89
    

    View Slide

90. © Stanby, Inc.
    まとめ - 本日お話しした出来事のタイムライン
    90
    第一次LeSS 開始 第一次LeSS 終了
    　→コンポーネントチーム体制
    第二次LeSS 開始予定
    2018年
    （らしい）
    2021年
    4月
    2023年
    4月
    ? 年
    ? 月
    再び LeSS 導入へと
    リスタート
    イマココ
    前半でこのあたりの
    お話をしました。
    後半でこのあたりの
    お話をしました。
    

    View Slide

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

    View Slide

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

    View Slide

93. © Stanby, Inc.
    結びに　
    93
    

    View Slide

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

    View Slide

95. © Stanby, Inc. 95
    ありがとうございました。
    Thank you !
    

    View Slide