---
title: LeSS概要
tags:  #agile #scrum #scale #less  
author: [木村　卓央](https://convert.docswell.com/user/TakaoKimura)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4V7PVRZZ78.jpg?width=480
description: 大規模スクラムとはどういったものなのかを LeSS の構成をベースに紹介しています
published: March 18, 22
canonical: https://convert.docswell.com/s/TakaoKimura/ZPRXX5-2022-03-18-112114
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4V7PVRZZ78.jpg)

⼤規模スクラム（Large Scale Scrum)概要
エンタープライズアジャイル勉強会
Copyright© Kanataku,LLC Takao Kimura.


# Page. 2

![Page Image](https://bcdn.docswell.com/page/L2JVZRWMEQ.jpg)

アジャイル コーチ
KIMURA
Takao
木村 卓央
Certiﬁed Scrum Professional® – ScrumMaster™ and Product Owner ™ and Scrum Developer®
Advanced Certiﬁed ScrumMaster℠ / Certiﬁed Agile Leadership I
PROFESSIONAL SCRUM MASTER™ I / Ⅱ and SCRUM PRODUCT OWNER™ I
PROFESSIONAL AGILE LEADERSHIP™ / EVIDENCE-BASED MANAGEMENT
Project Management Professional (PMP)® / PMI Agile Certiﬁed Practitioner (PMI-ACP)®
PMI⽇本⽀部 アジャイルプロジェクトマネジメント研究会 会員
LeSS Study主催
Agile Discussion!主催
Fearless Changeアジャイルに効くアイデアを広めるための48のパターン 共訳
⼤規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを⼤規模に実装する⽅法 共訳
https://www.kanataku.com/
Copyright© Kanataku,LLC Takao Kimura.
info@kanataku.com


# Page. 3

![Page Image](https://bcdn.docswell.com/page/Z5EG4MDXJL.jpg)

LeSS Study
n ⼤規模アジャイル開発のフレームワークである
LeSS Learge-Scale Scrum の勉強会です。
n LeSSのサイトである less.worksを翻訳しながら学び合う場と
して2015年から開催
n 『⼤規模スクラム Learge-Scale Scrum(LeSS)』
が丸善出版より出版されたことを期に
読書会として進めることに。
LeSS Study doorkeeper
https://less-study.doorkeeper.jp/
Copyright© Kanataku,LLC Takao Kimura.


# Page. 4

![Page Image](https://bcdn.docswell.com/page/V4JQGR157P.jpg)

⼤規模スクラムはスクラムである
Large-Scale Scrum is Scrum
Copyright© Kanataku,LLC Takao Kimura.


# Page. 5

![Page Image](https://bcdn.docswell.com/page/DK7458RVJ1.jpg)

⼤規模スクラムはスクラムである
はスクラムと同様にバランスを取っている
l 抽象的な原理・原則
l 具体的なプラクティス
n LeSS
n ⾃分たちの仕事の仕⽅を継続的に改善できるように
l 徹底的な透明性の維持
l 検査と適応のサイクルを重視
l スクラムに具体的な構造を追加
Copyright© Kanataku,LLC Takao Kimura.


# Page. 6

![Page Image](https://bcdn.docswell.com/page/PLJ1W2Q47G.jpg)

基本は1チームのスクラムと同じ
スクラムのプラクティスとアイデアを保持
n 1つのプロダクトバックログ
n 1⼈の(全体の)プロダクトオーナー
n 1つのDoneの定義
n 各スプリントの終わりに出荷可能なインクリメント
n クロスファンクショナルなチーム
n スプリント
l LeSSでは、全てのチームが共通のスプリントで
共通の出荷可能なインクリメントをデリバリーする
Copyright© Kanataku,LLC Takao Kimura.


# Page. 7

![Page Image](https://bcdn.docswell.com/page/8GJW6RMZJ2.jpg)

LeSSの⽅向性
n 少なくすることでもっと多く(More
with LeSS)
シンプルであるべき
Ø 余計な役割/成果物/プロセスを追加してしまう罠にはまらないよう
にする
n ⼤規模スクラムはスクラムである(Large-Scale Scrum is Scrum)
l スケールしたスクラム
Ø スクラムを理解した上で、同様の効果を⼤規模開発において実現す
る⽅法を模索する
n 削ぎ落しではなくスケールアップ(LeSS→LeSS Huge)
l 汎⽤的なフレームワークからスタートして削ぎ落としていく⽅法で
は、メタボなプロセスになる
Ø 常に「最⼩限」から始めて必要最低限のものをビルドアップ
l
Copyright© Kanataku,LLC Takao Kimura.
10


# Page. 8

![Page Image](https://bcdn.docswell.com/page/W4EZYRQLJ3.jpg)

LeSSはスクラムではない(LeSS is not Scrum)
このページは現在作成中です。
LeSS はスクラムの影響を強く受けていますが、まったく同じではありません。
LeSS とスクラム(2017)との主な違いをいくつか挙げます。
n
n
n
n
n
n
n
n
スクラムチームという概念は、LeSS には存在しない
スクラムでは開発チームと呼ばれているものは、LeSS では単にチームと呼ばれる
⾃⼰組織化チームは、⾃⼰管理チームと呼ばれる
スプリントプランニングは、スプリントプランニング1と2に分かれている
バックログリファインメントは、アクティビティではなくイベントである
スプリントゴールは LeSS の⼀部ではないが、LeSS と併⽤すると役に⽴つプラクティスと考えられている
スクラムマスターはフルタイムの役割であり、チームのメンバーではない
プロダクトオーナーは、チームのデイリースクラムやレトロスペクティブの参加者として期待されてはいな
い
今のところ、スクラム(2020)は無視している。
Copyright© Kanataku,LLC Takao Kimura.
https://less.works/less/framework/differences-with-scrum


# Page. 9

![Page Image](https://bcdn.docswell.com/page/KY76DR6MEV.jpg)

LeSS complete picture
LeSSは原理・原則をコアにして、複数
チームのコンテキストにスクラムを適⽤す
るためのルールとガイドのセットからなる
Copyright© Kanataku,LLC Takao Kimura.
n
原理・原則
l LeSSのコア
n
フレームワーク
l ルールで定義している
n
ガイド
l ルールを効率的に適応するためのもの
l 試す価値がある実験の集まり(経験知)
n
実験
l 限定的な環境で機能する


# Page. 10

![Page Image](https://bcdn.docswell.com/page/5G75386QJ4.jpg)

原理・原則 - LeSSのコア
⼤規模スクラムは
スクラムである
透明性
待ち⾏列理論
少なくすることで
もっと多く
経験的プロセス
制御
プロダクト全体
思考
システム思考
顧客中⼼
リーン思考
完璧を⽬指しての
継続的改善
Copyright© Kanataku,LLC Takao Kimura.
出典: https://less.works/less/principles/index.html


# Page. 11

![Page Image](https://bcdn.docswell.com/page/V9J2ZKMWER.jpg)

LeSS complete picture
LeSSは原理・原則をコアにして、複数
チームのコンテキストにスクラムを適⽤す
るためのルールとガイドのセットからなる
Copyright© Kanataku,LLC Takao Kimura.
n
原理・原則
l LeSSのコア
n
フレームワーク
l ルールで定義している
n
ガイド
l ルールを効率的に適応するためのもの
l 試す価値がある実験の集まり(経験知)
n
実験
l 限定的な環境で機能する


# Page. 12

![Page Image](https://bcdn.docswell.com/page/5DEYRNX9JM.jpg)

2つのフレームワーク
LeSSフレームワーク
２~８チームで開発するプロダクトに適⽤
LeSS Hugeフレームワーク
９チーム以上で開発するプロダクトに適⽤
Copyright© Kanataku,LLC Takao Kimura.


# Page. 13

![Page Image](https://bcdn.docswell.com/page/2VJNDX1D78.jpg)

LeSS ルール(2020 12⽉)
n フレームワークはルールによって定義されている
n シンプルなルールである
l 意図的に不完全になっている
l スケールするために必要な部分のみが定義されている
n フレームワークごとに以下の構成で書かれている
l 構造
l プロダクト
l スプリント
https://less.works/less/rules
Copyright© Kanataku,LLC Takao Kimura.


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GYE9G858J3.jpg)

LeSS フレームワーク
2〜”8”チームで開発するプロダクトに適⽤します。
Copyright© Kanataku,LLC Takao Kimura.
h/ps://less.works/jp/less/framework/index.html


# Page. 15

![Page Image](https://bcdn.docswell.com/page/5GE8V8YZED.jpg)

LeSS ルール︓LeSS の構造
n
n
n
n
n
n
n
n
n
n
実際のチームを組織の基本構成要素として組織を構成します。
それぞれのチームは、（１）⾃⼰管理、（２）クロスファンクショナル、（３）同⼀ロケーション、（４）
⻑期間存続です。
チームの⼤半は顧客中⼼のフィーチャーチームです。
スクラムマスターは LeSS の導⼊が問題なく⾏われることに責任を持ちます。注⼒する対象は、チーム、プ
ロダクトオーナー、組織、技術的⼿法であり、１チームだけの改善に留まることなく、組織全体の改善を⾏
う必要があります。
スクラムマスターは専任でフルタイムのロールです。
１⼈のスクラムマスターが１〜３チームを担当することができます。
LeSS ではマネージャーは必須ではありません。もしマネージャーがいる場合でも多くの場合、その役割は
おそらく変わります。マネージャーがフォーカスすべきことは、⽇々の作業の管理からプロダクトを開発す
るシステム全体の価値提供能⼒の向上に移ります。
マネージャーの役割はプロダクト開発の仕組みの改善を促進することです。「現地現物」の実践、「⽌めて
直す」の推奨、「適合するよりも実験をする」ことを通じて改善を促進します。
プロダクトグループは、「最初から」完全な LeSS の構造を適⽤します。これは LeSS を導⼊する際の肝と
なることです。
プロダクトグループを越える、より⼤きな組織には、「現地現物」の考え⽅を使い、実験や改善があたりま
えとなる環境を作っていくことで段階的に LeSS 導⼊を進めます。
Copyright© Kanataku,LLC Takao Kimura.


# Page. 16

![Page Image](https://bcdn.docswell.com/page/MLEL5R417R.jpg)

LeSS のスクラムマスター
n 基本的に１チームのスクラムと同じ
組織に対してスクラムを教え、コーチし、それが終わることはない
l スクラムチームが成功するための環境を作る
nチームにプロダクト全体を意識するよう働きかける
l ⼤きなプロダクトグループの⼈々の相互作⽤、遅延、原因、ポテン
シャル（潜在リスク）などの各個⼈の考えの範囲を超えてサポート
l プロダクト全体の狙いをチームに意識付けをおこなう
n 透明性を保つよう働きかける
n フルタイムで専任、場合によっては３チームまで兼務は可能
n 組織の完璧なビジョンに向かっていくために、レトロスペクティブと
改善を助け、⽀援する
l
Copyright© Kanataku,LLC Takao Kimura.


# Page. 17

![Page Image](https://bcdn.docswell.com/page/54JM3RK5EW.jpg)

フィーチャーチーム
⻑期間存続する
l チームはより⾼いパフォーマンス
を発揮するために、⼀緒に居続け
る。そして時間を掛けて新しい
フィーチャーを引き受ける
n クロスファンクショナルでクロスコ
ンポーネント
n 理想的には同じ場所にいる
n 全てのコンポーネントや領域(分析、
プログラミング、テスト)を超え、
完全なる顧客中⼼のフィーチャーで
作業する
n 専⾨家で構成される
n スクラムでは、通常は7±2⼈
n
『大規模スクラム Large-Scale Scrum(LeSS)』 P.77 より
Copyright© Kanataku,LLC Takao Kimura.


# Page. 18

![Page Image](https://bcdn.docswell.com/page/ZPJRQRXZ79.jpg)

コンポーネントチーム vs フィーチャーチーム
Copyright© Kanataku,LLC Takao Kimura.


# Page. 19

![Page Image](https://bcdn.docswell.com/page/NPEX5R617X.jpg)

LeSS の組織構造
n よく⾒られる組織構造
LeSS ではマネージャーは必須ではあり
ません。もしマネージャーがいる場合
でも多くの場合、その役割はおそらく
変わります。マネージャーがフォーカ
スすべきことは、⽇々の作業の管理か
らプロダクトを開発するシステム全体
の価値提供能⼒の向上に移ります。マ
ネージャーの役割はプロダクト開発の
仕組みの改善を促進することです。
「現地現物」の実践、「⽌めて直す」
の推奨、「適合するよりも実験をす
る」ことを通じて改善を促進します。
『 LeSSルール(2020 12月) LeSSの構造』より
プロダクトグループ
の責任者
ほとんどの LeSS 組織ではマネージャーが存在する
現地現物によってチームを⽀援。障害を取り除く
Undone 部⾨
理想的には存在しない部⾨
システム保証などの名前で存在することがある
Copyright© Kanataku,LLC Takao Kimura.
https://less.works/jp/less/structure/organizational-structure.html


# Page. 20

![Page Image](https://bcdn.docswell.com/page/63EK6R1MED.jpg)

LeSS ルール︓LeSS のプロダクト
n
n
n
n
n
n
n
１⼈のプロダクトオーナーと１つのプロダクトバックログがあり、出荷可能なプロダクト全体を
運⽤します。
プロダクトオーナーだけでプロダクトバックログリファインメントをするべきではありません。
複数のチームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダク
トオーナーをサポートします。
全ての優先順位付けはプロダクトオーナーが⾏います。が、要求や仕様を明確にするのは出来る
限りチームと、顧客やユーザーそしてステークホルダーとの間で直接⾏います。
プロダクトの定義は現実的な範囲で、エンドユーザーまたは顧客中⼼でなければなりません。プ
ロダクトの定義は広い⽅が好ましく、時間の経過とともに拡張する可能性があります。
プロダクト全体で全チーム共通の１つの Done の定義を持ちます。
各チームは共通の Done の定義を拡張してより厳しい独⾃のものを定めても構いません。
究極のゴールは Done の定義を拡張し、毎スプリント（あるいはより⾼い頻度で）出荷可能なプ
ロダクトを作れるようになることです。
Copyright© Kanataku,LLC Takao Kimura.


# Page. 21

![Page Image](https://bcdn.docswell.com/page/4L7368Q275.jpg)

LeSS のプロダクトオーナー
n 基本的に１チームのスクラムと同じ
n プロダクトオーナーが内側（チーム）と外側（ステークホルダー、顧
客・ユーザー）と同じように時間を費やす
l 新しいビジネスの戦略的な機会の模索
l スケールという観点では、プロダクトへの投資収益率( ROI )を最⼤
化してリターンを確保するためにわずかに異なる点がある
n 明確化より優先順位付け
l 優先順位付けはプロダクトオーナー
l 明確化はチームで協業する
Ø ユーザー・顧客とチームの直接会話する事を奨励する
Ø コネクターとしてのプロダクトオーナー
Copyright© Kanataku,LLC Takao Kimura.


# Page. 22

![Page Image](https://bcdn.docswell.com/page/V87DVM967G.jpg)

ガイド︓はじめに
LeSS 導⼊の成功率を⾼めるには
1
全員を教育する
LeSS を理解する
LeSS の導⼊の⽬的を理解する
2
「プロダクト」を定義する
プロダクトを定義することによって、導⼊範囲、プロダクトバックログの
内容、適切なプロダクトオーナーが決まる
3
「Done」を定義する
Doneの定義により、組織変更の規模が変わる
4
正しい構造を有したチーム
をつくる
専任、安定、⻑期間存続、クロスファンクショナル、同⼀ロケーション
機能部⾨から離れたフィーチャーチームを組織する
5
プロダクトオーナーのみが
チームに仕事を与える
最初のチームは将来のチームの⾜場となる基盤を築くため、通常よりもさ
らにチームは集中する必要がある
6
プロジェクトマネージャー
をチームに近づけない
LeSS では、プロジェクトマネージャーの役割がなくなる
Copyright© Kanataku,LLC Takao Kimura.


# Page. 23

![Page Image](https://bcdn.docswell.com/page/4VJPVR9ZJ8.jpg)

ガイド︓あなたのプロダクトを定義する
では広いプロダクトの定義が好ましいが現実的な範囲でなけれ
ばならない
n LeSS
https://www.amazon.co.jp/
Copyright© Kanataku,LLC Takao Kimura.
画像: NEWS PICKS アマゾン、倉庫の完全⾃動化の可能性排除「あと10年かかる」 2019年


# Page. 24

![Page Image](https://bcdn.docswell.com/page/L2EVZRMM7Q.jpg)

Done の定義
n Done
の定義は全チーム共通
l 可能な限り強い Done の定義を設定する
l 弱い Done の定義
Ø リスクと透明性の⽋如
Ø 遅延と柔軟性の⽋如
n チーム単位で、強い Done の定義に拡張できる
l チームは⾃分たちで改善をコントロールできる
Ø 少しずつ、他のチームにも共有していく
n Done の定義を拡張に、組織変更が必要なものもある
l 例えば、Undone 部⾨を各チームに⼊れる
Copyright© Kanataku,LLC Takao Kimura.


# Page. 25

![Page Image](https://bcdn.docswell.com/page/Z57G4MGXEL.jpg)

LeSS ルール︓LeSS のスプリント
n
n
n
n
１つのプロダクトに関わる全てのチームは同じスプリントで作業します。スプリントの開始も終了も全チーム共通です。スプリントの終わ
りにはプロダクト全体が１つに統合されている状態にします。
スプリントプランニングは２つのパートで構成されています。スプリントプランニング１は全てのチームが合同で実施します。それに対し
てスプリントプランニング２は通常、各チームごとに個別で⾏われます。ただし、関連性が強いアイテムがある場合は共有スペースで、マ
ルチチーム・スプリントプランニング２を⾏います。
スプリントプランニング１にはプロダクトオーナーとチーム全員またはチームの代表者が参加します。参加者は⼀緒に、各チームがこのス
プリントで作業するアイテムを暫定的に選択します。チームは協働する部分を特定し、質問を明確にします。
各チームにはチームごとのスプリントバックログがあります。
n
スプリントプランニング２は各チームがどのようにアイテムを実現させるかを考える場であり、設計やスプリントバックログの作成を⾏い
ます。
n
デイリースクラムはチームごとに⾏います。
チームどうしの調整はチームに委ねられています。中央集権的な調整ではなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。
重要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである「コードでのコミュニケーション」、チームをまたいだミーティン
グ、「コンポーネントメンター」、「トラベラー」、「偵察」、そして「オープンスペース」を活⽤することです。
プロダクトバックログリファインメント（PBR）は、シェアード・ラーニング（訳注:学習したものをシェアする）を増やし、調整の機会と
して活⽤できるため、複数チームで⾏うのが望ましいです。
n
n
n
スプリントレビューは全てのチームが共同で⾏います。検査と適応を⾏うのに適切な情報を得られるよう、必要なステークホルダーが参加
するようにします。
n
スプリントレトロスペクティブは各チームで⾏います。
オーバーオール・レトロスペクティブは各チームのレトロスペクティブの後に⾏われます。ここでは複数チームやシステム全体にまたがる
課題を扱い、改善に向けての実験を議論します。この場にはプロダクトオーナー、全スクラムマスター、チーム代表者と、（いるなら）マ
ネージャーが参加します。
n
Copyright© Kanataku,LLC Takao Kimura.


# Page. 26

![Page Image](https://bcdn.docswell.com/page/V4EQGRX5JP.jpg)

LeSS のスプリント
１つのプロダクトに関わる全てのチームは同じスプリントで作業します。
スプリントの開始も終了も全チーム共通です。スプリントの終わりには
プロダクト全体が１つに統合されている状態にします。
Copyright© Kanataku,LLC Takao Kimura.
『LeSSルール(2020 12月)』より


# Page. 27

![Page Image](https://bcdn.docswell.com/page/DKJ4586VE1.jpg)

スプリントプランニング
!&quot;#$%&amp;&#039;(
)*+,!&quot;#$%
&amp;&#039;()*&#039;+),)-.
Copyright© Kanataku,LLC Takao Kimura.
スプリントプランニングは２つの
パートで構成されています。スプ
リントプランニング１は全ての
チームが合同で実施します。それ
に対してスプリントプランニング
２は通常、各チームごとに個別で
⾏われます。ただし、関連性が強
いアイテムがある場合は共有ス
ペースで、複数チームスプリント
プランニング２を⾏います。
『LeSSルール(2020 12月)』より
『大規模スクラム Large-Scale Scrum(LeSS)』 P.254
より


# Page. 28

![Page Image](https://bcdn.docswell.com/page/PLE1W2V4JG.jpg)

スプリントプランニング１
n プロダクトオーナーはカードをテーブルに広げる
n チームがどのアイテムを持っていくか決める
ディスカッションする
n チームが取ったアイテムの優先順位が全体最適になっているか確認す
る
n 共通でやらなければならない作業
の明確化
l 複数チーム
スプリントプランニング２
l
Copyright© Kanataku,LLC Takao Kimura.


# Page. 29

![Page Image](https://bcdn.docswell.com/page/8GEW6RLZE2.jpg)

複数チームスプリントプランニング２
n １つの部屋で、複数チームで⾏う
n 設計した内容をシェアする
ホワイトボードにモデルを書く
l ツールは使わない（視野が狭まる）
n 各チームが個別にタスクを作る
l コミュニケーションを取りながら
l
Copyright© Kanataku,LLC Takao Kimura.


# Page. 30

![Page Image](https://bcdn.docswell.com/page/W47ZYRMLE3.jpg)

プロダクトバックログリファインメント( PBR )
./01232*4567
89:;5&lt;1=%
!&quot;#$%
&amp;&#039;()*+,)&#039;-./01232*
Copyright© Kanataku,LLC Takao Kimura.
プロダクトバックログリファイン
メント（ PBR ）は、シェアード・
ラーニング(訳注:学習したものを
共有する)を増やし、調整の機会と
して活⽤できるため、複数チーム
で⾏うのが望ましいです。
『LeSSルール(2020 12月)』より
『大規模スクラム Large-Scale Scrum(LeSS)』 P.229 より


# Page. 31

![Page Image](https://bcdn.docswell.com/page/KYJ6DRNM7V.jpg)

プロダクトバックログリファインメント( PBR )
n
n
n
実施する内容は、基本的にスクラムと同じ
３チーム未満の場合は、オーバーオールと複数チームPBRを組み合わせたものを
１回だけ⾏う、３チーム以上の場合は、オーバーオールPBRの後に、複数チーム、
単⼀チームPBRを組み合わせて⾏うことが多い
特定のチームにアイテムを事前に割り当てることは基本的には⾏わない
l ⾃分たちが⾏わないと知っていると関⼼を持たなくなる(プロダクト全体思考)
最初のPBR
導⼊する際に１度だけ⾏われる
最初のスプリントを始めるのに⼗分なアイテムをリファインメントする
オーバーオール
PBR
複数チームや単⼀チームPBRに先だって⾏われるプロダクト全体に注⽬したPBR
どのチームがそのアイテムをリファインメントするのかを模索する
複数チームPBR
２つ以上のチームが⾃分たちが実装しそうなアイテムをリファインメントする
単⼀チームPBR
１つのチームが⾃分たちが実装しそうなアイテムをリファインメントする
このチームが特定のアイテムを実装することが確実な場合のみ実施
Copyright© Kanataku,LLC Takao Kimura.
『大規模スクラム Large-Scale Scrum(LeSS)』 より


# Page. 32

![Page Image](https://bcdn.docswell.com/page/5GJ5385QE4.jpg)

スプリントレビュー・レトロスペクティブ
スプリントレビューは全てのチームが共同
で⾏います。検査と適応を⾏うのに適切な
情報を得られるよう、必要なステークホル
ダーが参加するようにします。
スプリントレトロスペクティブは各チーム
で⾏います。
オーバーオール・レトロスペクティブは各
チームのレトロスペクティブの後に⾏われ
ます。ここでは複数チームやシステム全体
にまたがる課題を扱い、改善に向けての実
験を議論します。この場にはプロダクト
オーナー、全スクラムマスター、チーム代
表者と、（いるなら）マネージャーが参加
します。
『LeSSルール(2020 12月)』より
Copyright© Kanataku,LLC Takao Kimura.
『大規模スクラム Large-Scale Scrum(LeSS)』 P.288 より


# Page. 33

![Page Image](https://bcdn.docswell.com/page/4LE368NZE5.jpg)

スプリントレビュー
n デモではなく、ディスカッションに重きを置く
n 報告ではなく学びの共有
n バザール形式（ガイド︓レビュー・バザール）
l 広い部屋に複数のブースを作成
Ø 各ブースには担当者がいて、質問などに答える
Ø プロダクトオーナー、ステークホルダー、他のチームメンバーなど
が、実際に動くソフトウェアを触る
Ø メモ(フィードバックや質問)を書くのが⼤事
l 全員が集まって、プロダクトオーナーを中⼼にメモについて議論す
る
Ø 市場や顧客、今後のビジネスやプロダクトに対する市場のフィード
バック、次のスプリントの⽅向性などを議論する
Copyright© Kanataku,LLC Takao Kimura.
『大規模スクラム Large-Scale Scrum(LeSS)』 P.288 より


# Page. 34

![Page Image](https://bcdn.docswell.com/page/V8EDVMW4EG.jpg)

レトロスペクティブ
n チームレトロスペクティブ
スクラムと同じ
n オーバーオールレトロスペクティヴ
l 次のプランニングの最初の⽅に⾏う(理想は前に⾏う)
l システム思考
Ø システム全体を改善することを考える場
l LeSS の原理・原則の1つは、完璧を⽬指しての継続的改善
l 2つの重要なステップ
Ø システム全体を分析する
Ø システム全体を改善するための実験案を設計する
新しい実験を1つだけ集中して取り組む
l
•
Copyright© Kanataku,LLC Takao Kimura.
『大規模スクラム Large-Scale Scrum(LeSS)』 P.290 より


# Page. 35

![Page Image](https://bcdn.docswell.com/page/4V7PVR9V78.jpg)

調整と統合
チームどうしの調整はチームに委ねられています。中央集権的な調整で
はなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。重
要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである
「コードでのコミュニケーション」、チームをまたいだミーティング、
「コンポーネントメンター」、「トラベラー」、「偵察」、そして
「オープンスペース」を活⽤することです。
『LeSSルール(2020 12月)』より
n
n
n
n
n
n
n
n
ただ話す
コードでのコミュニケーション
ブランチは使わない
コミュニティ
オープンスペース
トラベラー
コンポーネントメンター
偵察
Copyright© Kanataku,LLC Takao Kimura.
『大規模スクラム Large-Scale Scrum(LeSS)』 P.284
より


# Page. 36

![Page Image](https://bcdn.docswell.com/page/L2JVZRMREQ.jpg)

LeSS Huge フレームワーク
「9チーム以上」で作る場合に適⽤します。
これよりも⼩さな規模で LeSS Huge を適⽤することは推奨しません。不必要なオーバーヘッドや
部分最適の原因となります。
特に明記しない限り、すべての LeSS のルールは LeSS Huge にも適⽤されます。各要求エリアは、
基本的な LeSS のフレームワークのようにふるまいます。
Copyright© Kanataku,LLC Takao Kimura.
https://less.works/jp/less/less-huge/index.html


# Page. 37

![Page Image](https://bcdn.docswell.com/page/Z5EG4MG6JL.jpg)

LeSS ルール︓LeSS Huge の構造
顧客視点で関連の強い顧客の要求は、要求エリアにまとめられます。
n 各チームは１つの要求エリアを専⾨的に対応します。チームはエリアに⻑期間固
定するものです。ただし、他のエリアの価値がより⾼くなった場合、そちらに移
動することがあります。
n 各要求エリアにはエリアプロダクトオーナーが１⼈ずついます。
n 各エリアは「４〜８」チームで構成されます。このチーム数の範囲を守るように
します。
n LeSS Huge の導⼊は、構造上の変更も含め、進化させながらインクリメンタル
なアプローチで進めます。
n 毎⽇思い出して下さい。LeSS Huge の導⼊は数ヶ⽉〜数年を要します。無限の
忍耐とユーモアのセンスを持って進めてください。
n
Copyright© Kanataku,LLC Takao Kimura.


# Page. 38

![Page Image](https://bcdn.docswell.com/page/V4JQGRX27P.jpg)

LeSS ルール︓LeSS Huge のプロダクト
全体の（オーバーオール）プロダクトオーナーの役割はプロダクト全体の優先順
位決めと、どのチームがどのエリアを対応するかを決めることです。エリアプロ
ダクトオーナーとは密にコミュニケーションを取る必要があります。
n エリアプロダクトオーナーは当該エリアのチームに対してプロダクトオーナーと
してふるまいます。
n プロダクトバックログは１つです。そして全てのアイテムはどこか必ず１つの要
求エリアに属します。
n 要求エリアごとに１つのエリアプロダクトバックログが存在します。このバック
ログは概念的には、プロダクトバックログをより詳細な視点で記述しているもの
です。
n
Copyright© Kanataku,LLC Takao Kimura.


# Page. 39

![Page Image](https://bcdn.docswell.com/page/DK74586PJ1.jpg)

LeSS ルール︓LeSS Huge のスプリント
プロダクト単位でスプリント期間は共通です。各要求エリアで別々のスプリント
期間にすることはありません。スプリントの終わりには統合された１つのプロダ
クトになっている必要があります。
n プロダクトオーナーとエリアプロダクトオーナーは頻繁に会話し、スプリントプ
ランニング時にチームが最も価値の⾼いアイテムに着⼿できるように準備する必
要があります。また、スプリントレビュー後にはプロダクト規模の適応がより⼀
層可能となります。
n
Copyright© Kanataku,LLC Takao Kimura.


# Page. 40

![Page Image](https://bcdn.docswell.com/page/PLJ1W2VX7G.jpg)

LeSS complete picture
LeSSは原理・原則をコアにして、複数
チームのコンテキストにスクラムを適⽤す
るためのルールとガイドのセットからなる
Copyright© Kanataku,LLC Takao Kimura.
n
原理・原則
l LeSSのコア
n
フレームワーク
l ルールで定義している
n
ガイド
l ルールを効率的に適応するためのもの
l 試す価値がある実験の集まり(経験知)
n
実験
l 限定的な環境で機能する


# Page. 41

![Page Image](https://bcdn.docswell.com/page/8GJW6RLKJ2.jpg)

ガイド︓⼤規模スクラム
ルールを効率的に適応するためのガイドであり、何年にも及ぶ
LeSS の経験の中で試す価値があるとされた実験の集まり。
ガイドはヒントであり、改善の余地がある部分でもある。
Copyright© Kanataku,LLC Takao Kimura.
⼤規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを⼤規模に実装する⽅法 丸善出版 2019年
著:Craig Larman, Bas Vodde 監修:榎本 明仁 翻訳:⽊村 卓央, ⾼江洲 睦, 荒瀬 中⼈, ⽔野 正隆, 守⽥ 憲司


# Page. 42

![Page Image](https://bcdn.docswell.com/page/W4EZYRMNJ3.jpg)

ガイド
3. 導⼊ 51
少ない⽬標とLeSSのメトリクス 121
Undoneワークに負けるな 177
マネジメントに関する推奨書籍リスト 122
LeSSのミーティング 177
はじめに 57
6. スクラムマスター 124
LeSS Hugeのプロダクトオーナー 179
⽂化は構造に従う 62
スクラムマスターが重視すること 126
役割は守らないが雇⽤は守る 64
スクラムマスターの5つのツール 129
完璧を⽬指しての組織ビジョン 64
巨⼤なグループのファシリテーション 131
9. プロダクトバックログ 182
継続的改善 67
学習と複数のスキル習得を促進する 132
「依存関係の管理」ではなく，制約の最⼩化 183
導⼊の拡⼤ 69
コミュニティ活動 132
少しかじる 187
進化させながらインクリメンタルな導⼊ 71
スクラムマスターサバイバルガイド 134
親の対処 189
要求エリアを1つずつ 71
スクラムマスターへの推奨書籍 137
特別なアイテムの取扱い 192
並列組織 72
特に注意を払う領域 138
⼤規模プロダクトバックログ⽤のツール 195
4. 顧客価値による組織化 73
要求エリアのサイロ化を避ける 139
アウトカムを多く，アウトプットを少なく 197
チームベースの組織を構築する 74
7. プロダクト 143
エリアバックログ 200
フィーチャーチームを理解する 76
あなたのプロダクトは何ですか? 145
フィーチャーチーム導⼊マップ 84
あなたのプロダクトを定義する 150
顧客ドメインでの専⾨化を優先 90
プロダクトの定義を広げる 154
LeSSの組織構造 92
プロジェクトやプログラムよりもプロダクト 155
複数拠点でのLeSS
8. プロダクトオーナー 157
3つの導⼊原則
要求エリア 96
流動的な要求エリア 96
フィーチャーチームへの移⾏ 100
LeSS Hugeの組織 102
5. マネジメント 106
テイラーとファヨールを理解する 108
Y理論によるマネジメント 110
マネージャーは任意 112
LeSSの組織 113
現地現物 117
教師および学習者としてのマネージャー 119
ドメインと技術⼒の両⽅ 120
Copyright© Kanataku,LLC Takao Kimura.
誰がプロダクトオーナーになるべきか? 158
⼀時的な仮のプロダクトオーナーと早めに、または適
当に始める 161
ユーザー/顧客は誰? 162
明確化より優先順位付け 163
やってはいけないこと 164
プロダクトオーナーのヘルパー 165
5つの関係 166
何よりも顧客との協調を 173
少なくともスプリントごとに出荷する 174
良い⼈になるな 175
放棄しよう 176
エリアプロダクトオーナー 180
スクラムマスターの助けを借りるPOチーム 181
最⼤3レベルまで 204
巨⼤な要求のための新しいエリア 205
巨⼤な要求を扱う 206
10. Doneの定義 210
Doneの定義を作成する 211
12. スプリントプランニング 250
スプリントプランニング1 251
複数チームスプリントプランニング2 255
スプリントバックログにソフトウェアのツールは使わ
ない 256
プロダクトオーナーのチームミーティング 258
13. 調整と統合 259
ただ話す 260
調整しやすい環境 262
コードでのコミュニケーション 265
継続的にインテグレーションする 267
コミュニティ 269
クロスチームミーティング 272
複数チームの設計ワークショップ 274
現在のアーキテクチャーワークショップ 276
コンポーネントメンター 277
オープンスペース 279
トラベラー 280
Doneの定義を育てる 220
偵察 282
11. プロダクトバックログリファインメント
225
リーディングチーム 282
プロダクトバックログリファインメントの種類 227
オーバーオールPBR 228
複数チームPBR 230
複数拠点でのPBR 231
最初のPBR 232
分割 238
⼤規模での⾒積り 246
スクラムオブスクラムズをしない⽅がいいかも 282
テクニックを混ぜ合わせる 284
14. レビューとレトロスペクティブ 286
早く頻繁にプロダクトを適応させる 287
レビュー・バザール 288
オーバーオールレトロスペクティブ 290
システムを改善する 292
複数エリアでのレビューとレトロスペクティブ 297


# Page. 43

![Page Image](https://bcdn.docswell.com/page/KY76DRN9EV.jpg)

LeSS complete picture
LeSSは原理・原則をコアにして、複数
チームのコンテキストにスクラムを適⽤す
るためのルールとガイドのセットからなる
Copyright© Kanataku,LLC Takao Kimura.
n
原理・原則
l LeSSのコア
n
フレームワーク
l ルールで定義している
n
ガイド
l ルールを効率的に適応するためのもの
l 試す価値がある実験の集まり(経験知)
n
実験
l 限定的な環境で機能する


# Page. 44

![Page Image](https://bcdn.docswell.com/page/5G75385DJ4.jpg)

実験︓LeSSに関する本
Practices for
Scaling Lean &amp; Agile
Development
Scaling Lean &amp; Agile
Development
Practices for Scaling Lean &amp; Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum (English Edition) Addison-Wesley Professional 2010年
著: Craig Larman, Bas Vodde
Scaling Lean &amp; Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (English Edition) Addison-Wesley Professional 2008年 著: Craig Larman, Bas Vodde
Copyright© Kanataku,LLC Takao Kimura.


# Page. 45

![Page Image](https://bcdn.docswell.com/page/V9J2ZKGMER.jpg)

おまけ
Copyright© Kanataku,LLC Takao Kimura.


# Page. 46

![Page Image](https://bcdn.docswell.com/page/5DEYRNVPJM.jpg)

ロール
n プロダクトオーナー︓1⼈
全てのアイテムの詳細を把握することは不可能
l 優先順位は、プロダクトの⽅向性により決定する
l 規模、難易度などは、POにとって必要な情報
n スクラムマスター︓専任、1~3チームを担当
l 組織に対する働きかけが多くなる
n チーム︓スクラムで⾔う開発チーム（同じ）
l 各チームは同じ場所で働く
l チームの⼤半は顧客中⼼のフィーチャーチーム
n LeSSでは、プロダクトグループ（明確には定義していない）
l スクラムチームでは無い
l
Copyright© Kanataku,LLC Takao Kimura.


# Page. 47

![Page Image](https://bcdn.docswell.com/page/2VJNDXMM78.jpg)

作成物
n プロダクトバックログ
l LeSSでは、あまり粒度を⼩さくしない
Ø 各チームが、１スプリントで4アイテムくらい
n スプリントバックログ
l スクラムと同じ
n 出荷可能なプロダクトのインクリメント
l Potentially
Shippable Product Increment
l LeSSでは、あえて古い⽤語を使う
Copyright© Kanataku,LLC Takao Kimura.


# Page. 48

![Page Image](https://bcdn.docswell.com/page/GYE9G8NWJ3.jpg)

イベント
n スプリントプランニング１
どのチームがどのアイテムをやるのかを決める
Ø 均等に優先順位を振り分ける
l 複数チームの代表者
n スプリントプランニング２
l 各チームがチームごとに⾏う
Ø 実施するアイテムに関連がある場合は、複数チームで⾏う
l アイテムの詳細な確認はリファインメントで⾏う
n スプリント
l 1~4週間
l 全てのチームは、同じスプリント
l
Copyright© Kanataku,LLC Takao Kimura.


# Page. 49

![Page Image](https://bcdn.docswell.com/page/5GE8V8KRED.jpg)

イベント
n スプリントレビュー
全てのチームで共有
l 今後のプロダクトの⽅向性をフィードバックしてもらう
l プロダクトの種類によっては、レビューが難しいものもある
n レトロスペクティブ
l 各チームで⾏う
Ø ごくたまに、複数チームで⾏う
n オーバーオールレトロスペクティブ
l 組織、システム全体、複数チームで起きた問題を取り上げる
l 組織の課題を洗い出す
Ø 次のスプリントで改善出来るようなものではない
l 次のスプリントの⽕曜⽇に⾏うことが多い
l
Copyright© Kanataku,LLC Takao Kimura.


# Page. 50

![Page Image](https://bcdn.docswell.com/page/MLEL5RZ27R.jpg)

イベント
n プロダクトバックログリファインメント
l アイテムの明確化と⾒積もりを⾏う
l どのチームでやるのかを検討する
Ø 最終決定はスプリントプランニング
l POは任意
Copyright© Kanataku,LLC Takao Kimura.


