LeSS Study勉強会(2016.5.13、6.6)の資料です。

1. LeSS
Introduction
LeSS Study勉強会
2016.5.13、6.6
やっとむ

2. Introduction to LeSS
• こちらのまとめ・一部訳・物語の台本
• https://less.works/less/framework/introductio
n.html

3. Introduction to LeSS
• Large-Scale Scrum: More with LeSSの第2章
2人のエコノミストが道を歩いていた。
1人が道ばたに紙が落ちているのを見つけた。
「あれは100ドル紙幣じゃないか？」
「違うさ」もう1人が答えた。「100ドル紙幣だったら、
もう誰かが拾っているよ」

4. One-Team Scrum
• スクラムは経験的プロセス制御開発フレームワーク
であり、機能横断チームが自己組織化して製品をイ
テレーティブかつインクリメンタルに開発する
• スクラムガイドやスクラムプライマーでは、1チーム
のスクラムしか語っていない

5. LeSS

6. LeSS
• ラージスケールスクラム(LeSS)はスクラムを複数
チームで1つのプロダクトを開発する状況に当ては
めたもの。なぜLeSS？1チームのスクラムと同じよう
に……
• 大規模なグループにおいて、LeSSは必須要素と経
験的プロセス制御とのあいだのいいバランスを取れ
る
• また1チームスクラムと同様、LeSSは (1)軽量 (2)理
解がシンプル (3)修得は難しい―本質的複雑さが
原因。

7. Background
2002年、Craigが「Agile & Iterative Development」を書いたころ、誰でもアジャイ
ル開発は小規模グループ向けだと「知って」いた。だが我々はスクラムを非常に大
きく複数サイトにまたがるプロダクト開発に当てはめることに興味を持ち、またリクエ
ストも受けるようになっていた。
そこで2005年からCraigとBasはタッグを組んで、クライアントに向けてスクラムの
スケールアップに取り組んだ。現在、2つのLeSSフレームワーク(基本のLeSSと、
LeSS Huge)を、大規模プロダクトを世界をまたいで開発している、さまざまなドメイ
ンにおいて適用している。
• Ericsson や Nokia Networksなどの通信機器開発
• JPMorganやBAMLなどの投資銀行、個人向け銀行
• ION Tradingなどのトレーディングシステム開発
• bwinなどのゲームサイト開発
• Valtech Indiaなどのオフショアアウトソーシング

8. Background
「大規模」とは、いま書いている時点の最大でLeSS
Hugeを適用しているプロダクトグループは2500名、
10開発サイト、数千万ステップのC++コード、カスタム
ハードウェアを擁する。
業界で真ん中くらいのLeSSプロダクトグループサイ
ズは、1～2箇所のサイトに3～5チームがいるというも
のだ。
経験をもとにこれまで2冊本を出しており、本書は3冊
目に当たる。プリクエルであり、入門書でもある。なの
でLeSSの詳細については前の2冊を読んでね。

9. LeSS Principles and Themes

10. キュー理論
ラージスケールスクラム
もスクラムだ
透明性
より少なくでもっと多く
プロダクト
全体にフォーカス
顧客中心
継続的改善で完璧を目指す
リーン思考
システム思考
経験的プロセス制御

11. LeSS Principles and Themes
• ラージスケールスクラムもスクラムだ—LeSSは「新しい、よりよいスクラム」で
はない。LeSSはスクラムそのものの原則、要素、目的を大規模なコンテキストに
どうやって適応するかという話だ。
• 経験的プロセス制御—検査と適応をプロダクト、目的、組織デザイン、プラク
ティスにあてはめ、状況に適した組織をスクラムに沿って作り上げる。あらかじめ
決まった法則に従うわけではない。経験的プロセス制御によってできるのが……
• 透明性—さわれる「完成」アイテム、短いサイクル、共同作業、共通の定義、作業
場所から恐怖を追い払う。
• より少なくでもっと多く—(1) 経験的プロセス制御の意味合いでは、少ないプロ
セスの定義から多くの学びを得る。 (2) リーン思考の文脈では、ムダとオーバー
ヘッドを少なくし、価値を多くする。 (3) スケーリングの観点では、役割、作成物、ス
ペシャルグループを少なくする。
• プロダクト全体にフォーカス—プロダクトバックログは1つ、プロダクトオーナー
は1人、出荷判断可能なプロダクトインクリメントを1つ、1スプリントで ―― チー
ムが3つでも33つでも変わらない。顧客がほしいのはプロダクトであり、部分では
ない。

12. LeSS Principles and Themes
• 顧客中心—価値もムダも、お金を払う顧客の立場で考える。彼らから見えるサイ
クルタイムを短くする。本当の顧客とのフィードバックループを増やす。全員が、
自分の今日の仕事がお金を払う顧客にどう関わり、どう利益をもたらすのか、理
解している。
• 継続的改善で完璧を目指す—いつもプロダクトを作って提供する。そこにはコス
トも欠陥もない。プロダクトはいつも顧客を喜ばせ、環境を改善し、生活をより良
いものにする。スプリントのたびに謙虚かつ大胆に改善して、そこを目指す。
• システム思考—見て、理解して、最適化するのはシステム全体だ。部分ではない。
因果ループモデリングでシステムダイナミクスを探索する。局所最適や不十分
な最適化を避け、「効率」や「生産性」を個人や個々のチームで考えない。顧客は
全体的な「アイデアから現金まで」のサイクルタイムとフローに興味があり、個々
の手順ではない。
• リーン思考—組織的なシステムを作る。その基礎はマネージャーが教師としてシ
ステム思考とリーン思考を適用し、教え、改善をマネジメントし、現場現物を実践
するところにある。2つの柱、人びとへの敬意と継続的改善を置く。すべては完璧
を目指す。
• キュー理論—キューを含むシステムがどう働くかR&D分野で理解し、得た洞察を
キューサイズ、WIP制限、マルチタスク、ワークパッケージ、変動に適用する。

13. Two Frameworks: LeSS &
LeSS Huge
• ラージスケールスクラムには2つのフレームワークがある。
• LeSS : チーム数が2～8
• LeSS Huge : 9チーム以上、1プロダクト数千名まで

14. Two Frameworks: LeSS &
LeSS Huge
• LeSSフレームワーク ― (基本の)LeSSフレームワークは1人のプロダク
トオーナー(PO)と、2～8のチームから成る。1人のPOは総合的な本当の
プロダクトオーナーで(真にプロダクトをオウン＝背負っている)、1つの本
当の出荷可能なプロダクトを見て、単一のプロダクトバックログを管理し、
そのプロダクトバックログをもとに全チームが1つのスプリントで働き、プ
ロダクト全体を最適化する。
• LeSSとLeSS Hugeを分ける「8チーム」はマジックナンバーではない。
ティッピングポイントは状況による。ある時点で、(1)POが1人だけではプ
ロダクト全体観を維持できなくなる、(2)POが外部と内部のフォーカスの
バランスを取れなくなる、(3)プロダクトバックログが巨大すぎて1人では
維持できなくなる。
• グループがティッピングポイントを超えたら、変えるべきタイミングだ。
LeSS Hugeに移行すべきかもしれないが、まずは小さくシンプルにする。
Hugeに(＝大きく)考えてはいけない。

15. LeSS Framework Elements

16. LeSS Framework Elements
• (小さい)LeSSの要素は1チームScrumと同じ
• 役割
• 作成物
• イベント
• 上記に加え、LeSSでは以下も追加
• ルール
• ガイド

17. LeSS Framework Elements
• ルール ― グループが守り、やるべきこと。スプリントプランニング1と2や、
単一のプロダクトバックログと出荷判断可能なプロダクトなど。LeSSルー
ルには、役割、成果物、イベントそれぞれに対応するものがある。
• シンプルで数少ないLeSSルールは、わずかな「事前に定めた」感をバラ
ンスよく、経験的プロセス制御に交える。とりわけ新たに始めるグループ
にとって、最初に「なにをどう」したらいいか、正しい方向に向ける効果が
ある。そしてLeSSにおける透明性を実現することができる。
• 「最初はきっちりと」というアプローチは、数多くの学習モデルに見られる
初学者のニーズに応えるものだ。ジャズのトランペット奏者であり教師で
もあるClark Terryは、学びを次のようにまとめている。真似、適応、改革。
これはまた合気道の守破離(従う、分かれる、昇華する)としても知られる。
• ガイド ― 試してみるべきアドバイス。LeSS導入の経験者から与えられ
る。例えばスプリント中にチームどうしがどう調整するかなど。適当かも不
適当かもしれず、継続的改善の実験の範疇になる。

18. LeSS Story:
Flow of Teams & Events
• この物語では人とチームがLeSSのスプリントを経験す
るフローを説明する。
• 登場人物:
• デイブ: トレードチーム
• デヴィ: トレードチーム
• ドン: マージンチーム
• ダコタ: マージンチーム
• パオロ: プロダクトオーナー
• サム: スクラムマスター(トレードチーム、マージンチーム)
• 演出の都合により省略、変更、追加などがあります

19. LeSS Story:
Flow of Teams & Events
• ロンドンで珍しく晴れた朝、ロンドンの金融街である
シティにあるビルに、デイブは出勤しました。オフィ
スに着くと、もうデヴィが来ていました。2人はトレード
チームに所属し、全5チームからなる債券取引・ポジ
ションリスク管理システムの開発をしています。
• デヴィ「おはようデイブ！ このスプリントはうちが代
表チームよ。プランニング１(いち)があと10分で始ま
るわ」
• デイブ「オーケー。コーヒーを淹れてくるよ。大部屋
で会おう」

20. Sprint Planning One (1/7)
• デイブが大部屋に入ると、もう人が集まっていまし
た。5チームから各2名の代表者。トレード・マージン
チームのスクラムマスターのサムもいます。プロダ
クトオーナー件プロダクトマネージャのパオロに加
え、2名のプロダクトマネージャもいます。
• これから、4回目の2週間スプリントのスプリントプラ
ンニング1が始まります。時間は2時間です。

21. Sprint Planning One (2/7)
• パオロ「やあ。このスプリント
用に22枚カードを用意しまし
た。ブラジル市場向けの
フィーチャーに加え、USAの
債券デリバティブの監査用
レポートもある」
• サム「1チームだけで優先順
位の高いやつを取らないよ
うにね。全チームにいきわた
るよう分配して」

22. Sprint Planning One (3/7)
• 各チームの代表者は、カードが並べてあるテーブル
の周りに集まりました。デイブとデヴィも一緒にカー
ドを選び始めます。
• デイブ「このヨーロッパ債のカードは、今までのプロ
ダクトバックログリファインメントで詳しく見てきた
から、やりたいな」
• デヴィ「こっちもそうね。それとこのオーダーシステ
ムの機能は単純だから、誰でもわかりそう」

23. Sprint Planning One (4/7)
• そうしていると、マージンチームのダコタが2人の
カードを見て、提案してきました。
• ダコタ「そのオーダーシステムのカード、うちにもらえ
ないかしら？ 前のスプリントで関連するのをやったの
よ。こっちの単純なレポート機能と交換でどう？」
• デヴィ「そうね、ちょっと見せて。良さそうね」

24. Sprint Planning One (5/7)
• 5分ほどたって、各チームが自分のカードを3枚か4
枚ずつ選びました。テーブルには優先度の低いもの
が4枚残っており、パオロはそれを見て困った顔をし
ました。
• パオロ「残り4枚なんだけど、この1枚をちょっと見て
ください。これだけは重要で、このスプリントに入れ
たいんですよ。なんとか、選んだカードと入れ替えら
れないかな？」

25. Sprint Planning One (6/7)
• パオロの最後の1枚も片付いたので、次は各チーム
がスプリントゴールを決め、残った疑問を解決する
時間になりました。プロダクトバックログリファインメ
ントで話をしてきていても、やはり疑問は残るようで
す。各チームはそれぞれ、疑問をフリップチャートに
書き出していきます。
• デイブ＆デヴィ「(フリップチャートに書く)」
• パオロ「あ、それはこうですよ」
• パオロを含めた3名のプロダクトマネージャは、手分
けをして各チームの疑問に答えて回ります。45分ほ
どで、すべての疑問に回答がつきました。

26. Sprint Planning One (7/7)
• サム「最後に、調整の相談をしてくれ」
• デイブ「ヨーロッパ債の機能は、マージンチームの
カードと共通の作業があるね。スプリントプランニン
グ2のミーティングを一緒にやらないか」
• マージンチームのドンが合意したので、スプリントプ
ランニング1は終了になりました。

27. Sprint Planning Two
• その後休憩を挟んで、こんどはチームごとにスプリントプ
ランニング2を始めます。これは1チームのスクラムとほ
ぼ同じですが、この物語でどうなるか見てみましょう。
• トレードチームとマージンチームは共同でスプリントプラ
ンニング2を始めました。関連するカードについて、大き
な設計上の疑問を見つけ、大半はその場で議論して解
決しました。いくつかは後回しにし、チームをまたいだデ
ザインワークショップをすることにしました。
• 当初の計画見込みが変わりそうだったので、スプリント
プランニングが終わったとき、各チームが共通のプロダ
クトバックログ(Googleスプレッドシート)上でチームの予
想を書き換えました。

28. Multiteam Design Workshop
• ふたたび休憩を取ってから、トレードチームとマージン
チームでデザインワークショップを開きます。トレード
チームからはデイブとデヴィが、マージンチームからは
3名が参加しました。
• デイブ「(ホワイトボードにモデリングしながら)こうでこう
でこうで」
• ドン「いいね」
• ダコタ「作業分担もできそうね。計画にも影響なさそう」
• デヴィ「よかった。でも、これならもっと早く気がついて、
先に解決できたはずね」

29. Overall Retrospective
• 翌日、スプリントの2日目に、サムと他のスクラムマス
ター、プロダクトオーナーのパオロ、サイトマネージャの
メアリー、各チームからの代表1名ずつが、全員集まって
90分の全体レトロスペクティブを開催しました。前スプリ
ントがチームごとのレトロスペクティブで終わってしまっ
たので、全体でできなかったためです。
• システム全体の課題や改善にフォーカスし、調整、情報
共有、問題解決について離しました。
• 以前、スクラムオブスクラムを試したもののあまり上手く
いかなかったので、サムがオープンスペースという手法
を紹介し、このスプリントで試すことになりました。

30. Day4 Coordination (1/3)
• LeSSのある日の調整の様子を見てみましょう。各
チームはそれぞれでデイリースクラムをやりますが、
トレードとマージンの調整のため、デヴィがマージン
チームのデイリースクラムに参加します。同様にドン
はトレードチームに参加します。
• デヴィ「(マージンチームのところにいく)」
• ドン「(トレードチームのところにいく)」

31. Day4 Coordination (2/3)
• デイリースクラム後、45分のオープンスペースセッションに、各チームの
代表が集まります。デイブとデヴィも参加します。サムがファシリテータに
なり、チーム間の調整をします。
• ドン「僕は今年のテスト仲間(community of practice=CoP)の調整役だ。
ダコタ、来てくれ」
• ダコタ「自動受け入れテストを導入したいの。賛成なら、インフラをうちの
チームで作るわ」
• デイブ「(別の場所で独り言をいう)アーキテクチャ仲間(CoP)は、今日は
いないな。このスプリントでミーティングはないけれど、スパイクしたいこ
とがあるから、CoPコミュニケーションツールに書き込んでおこう」
• デヴィ「CIシステムがおかしいわね。今スプリントはうちのチームが担当
だから、見てみなきゃ。(デイブに向かって)デイブ、ペアで調べたいんだ
けど、あとで時間もらえる？」
• デイブ「いいとも」
• サム「全体レトロスペクティブはこれで終わりだ。おつかれさま」

32. Day4 Coordination (3/3)
• デヴィ「(パオロのところに行く)うちのチームの最初
のアイテムが終わったんだけど、見てもらえる？」
• パオロ「喜んで！ なるほど、いいですね。こことことは、
ちょっと直したいな」
• デヴィ「わかったわ、チームに伝えるわ」
• その日の午後、デイブは2番目のアイテムをチーム
と一緒に開発しました。TDDで開発し、10分ごとに
Trunkにコミットし、他チームのコードと統合しました。
CIは全チームのプロダクト全体をビルド、テストし、グ
リーンの結果を表示していました。

33. Overall PBR
• スプリント5日目、デイブとデヴィは全体プロダクト
バックログリファインメント(PBR)に参加します。各
チームの代表と、プロダクトオーナーとプロダクトマ
ネージャも参加します。
• デイブ＆デヴィ＆ドン＆ダコタ＆パオロ「(PBRに参加
するふり)」

34. Team PBR
• スプリント6日目、各チームでプロダクトバックログリ
ファインメントを開きます。通常はチームごとに別々
ですが、この物語ではどうでしょうか。
• デイブ「昨日の全体PBRで、チームPBRのテーマが
USAのレギュレーションに決まったけれど、他のチー
ムも関係しているらしいんだ」
• デヴィ「じゃあチームPBRを合同でやりましょう」
• 結局チームPBRは3チーム合同でやることになりま
した。そこには会社の法務部門から専門家も参加し、
ワークショップをおこないました。ローテション分析
や、分散と集合スタイルのワークをやりました。

35. Sprint Review (1/2)
• スプリント最終日になり、2時間のスプリントレビュー
の時間になりました。プロダクト全体のレベルで、一
緒におこなうレビューです。
• チームが5つあるので、まず1時間のバザールスタイ
ルレビューをおこないます。プロダクトオーナー、プロ
ダクトマネージャ、またセールス担当者も参加して、
並行して個々のアイテムを見ていきます。
• チームメンバーの一部はPCのところにいてフィード
バックを受け取り、後の人は興味あるアイテムを見
に行きます。
• 全員「(やってみよう！)」

36. Sprint Review (2/2)
• 後半1時間では、ふたたびグループ全体が集まります。パオ
ロはプロジェクタでプロダクトバックログを表示します。
• パオロ「これとこれは、プランニングの予想通り完成ですね。
おつかれさまでした」
• 次にパオロとほかのプロダクトマネージャ、セールス担当者
はそれぞれ順に、自分からのフィードバックをまとめて発表し
ます。そして重要な3つのアイテムを表示し、チームと議論し
ました。
• パオロ「最後に、今回のスプリントの成果はリリースしようと思
います。ベータテストに参加してくれるトレーダーに使っても
らいます。それから、次スプリントのテーマはUSA向けレギュ
レーション対応にしようと考えてるんだ」

37. Team Retrospectives
• 休憩後、トレードチームはチームレトロスペクティブ
を開きました。
• デヴィ「スプリントプランニングの後でチームまたぎ
デザインワークショップをやるのは、よくなかったわ
ね」
• デイブ「複雑で関連の強いアイテムは、プランニン
グの前にデザインワークショップをやるとよさそう
だ」
• トレードチームは全体でそれに合意しました。そして
次の全体レトロスペクティブで、PBR中に関係する
アイテムを見つけるよう提案することにしました。

38. The End
• サム「第4スプリントおつかれさま！ トレードチームの
みんな、今日がデイブの誕生日だって知ってたか
い？ みんなでベルギービールの店でお祝いしよう
ぜ！」

39. LeSS Story:
Flow of Teams & Events
おわり

40. 前回までのあらすじ(ストーリー部分)
• デイブ、デヴィたちは全5チームある開発部隊でトレーディン
グ関連のシステムを開発している
• 2週間スプリントの初日はスプリントプランニングで、USAの
監査関連機能がホットなテーマ
• チームをまたいで関係するストーリーについては、関わるチー
ムが集まってデザインワークショップをする
• 全体レトロは、次のスプリントの始め(プランニングの後)
• リファインメントは、チームごとやチーム合同で、ビジネス側
専門家(専門分野のプロダクトマネージャ)も参加
• スプリントレビューはバザールスタイルで、最後にステークホ
ルダーがフィードバックする
• チームごとのレトロスペクティブでスプリント終了

41. LeSS Story:
Flow of Features & Events
• この物語では顧客のフィーチャがLeSSのスプリントを経験
するフローを説明する。
• 登場人物:
• アリエル: プロダクトマネージャ(監査の専門家)
• パオロ: プロダクトオーナー
• ピーター: プロダクトマネージャ
• サム: スクラムマスター
• 演出の都合により省略、変更、追加などがあります

42. LeSS Story:
Flow of Features & Events
• アリエルはUSAへの出張が終わり、ロンドンに帰るところです。
この出張では金融監査担当者とミーティングし、法律の改正
について情報を仕入れてきました。
• ロンドンに戻って週末ゆっくり休んだアリエルは、月曜日にプ
ロダクトオーナーのパオロと会いました。
• アリエル「USAでの監査に関して、私たちの顧客が最初に必
要になる機能を考えてきたの。カードにまとめたわ」
• パオロ「ありがとう。カードは5枚ですね、これで監査にはすべ
て対応できるのかな？」
• アリエル「パオロ、これは監査なの。どうせまた変わるし、曖昧
さもなくならないのよ」
• パオロ「そうですね。この5枚、プロダクトバックログの末尾に、
順序は気にせず追加しておいてくれるかな」

43. LeSS Story:
Flow of Features & Events
• 1週間後、パオロはアリエルに声をかけます。
• パオロ「監査の機能にそろそろ手をつけようと思う。
まずは債券取引からになるんですけど、次のスプリ
ントのPBRワークショップで取り上げるよう、チーム
に伝えたんですよ。あなたは専門家だから、全体
PBRとチームPBRに参加してもらえないかな？」
• アリエル「いいわ。どのチームPBRに出るかは、チー
ムに聞けばいいのね」
• パオロ「そうですね。PBRは今月の24日と25日だ。
Wikiにドキュメントも用意しておいてくださいね」

44. Overall PBR (1/3)
• 24日、アリエルは全体PBRワークショップに参加しま
いした。パオロ、プロダクトマネージャのピーター、そ
れに5チームから代表が2名ずつ参加しています。
• パオロ「では始めます。USAの監査とデリバティブに
ついてやることがたくさんあります。会計年度の監査
に間に合わせるため、これから3スプリントでリリース
したいな。リファインメントと見積もり次第だけれど、
3チームくらいが掛かり切りになるかもしれないと
思ってます」
• アリエル「じゃあ私から説明するわ。みんな、ホワイ
トボードの周りにあつまってくれる」

45. Overall PBR (2/3)
• アリエルはホワイトボードに「USA債券デリバティブの監査」
と書き、説明しながら細分化し、質問に回答しました。30分ほ
どして、最終的に16個のアイテムができました。
• 少し休憩してから、16個のアイテムをカードに書き起こしまし
た。その中から7枚、優先度が高く、まだ疑問点が残っている
ものを選びました。
• サム「Specification by Exampleの手法を使おうか。具体例
を書いてみるんだ」
• さらに90分かけて具体例を作り、7枚のカードも理解できまし
た。

46. Overall PBR (3/3)
• 参加者は全体で、16枚のカードをすべて見積もりました。バッ
クログ上の見積り済みアイテムと比較して、相対ポイントで
見積もりを出しました。
• 16枚中8枚は、1チームがスプリントの3分の1で完成できるサ
イズでした。これがグループで決めたガイドラインでは最大
の大きさです。それ以上のものは、さらに次回のPBRワーク
ショップで分割する必要があります。
• パオロ「16枚あるけれど、優先度の低いものは今は外してお
きます。あとは、できるだけ早く完成したいな。この優先度が
高いアイテムをレディにできるよう、集中してください」
• PBRの最後に、チーム代表は相談して、5チームのうち3チー
ムが監査を担当することにしました。2チームはUSA債券の
経験があります。またトレードチームは今後ヨーロッパでの監
査を担当する予定でした。

47. Multiteam PBR & Team PBR
(1/2)
• 翌25日、トレードチームとUSAの2チームは丸1日かけてチームPBRワー
クショップを開きました。監査の12アイテムを、できるだけ早くレディにす
るためです。12アイテムは相互に関連しているので、チームをまたいだ
PBRにしました。アリエルとピーターも参加しましたが、パオロはいません。
• グループはローテーション方式でリファインメントを進めます。以下のよう
な手順です。
1. 3チーム、それぞれアイテムを選ぶ。各チームにプロダクトマネージャ(ア
リエルとピーター)が加わります。3チーム目はプロダクトマネージャなし。
2. 30分間、リファインメントを進める。
3. 30分後、鐘が鳴って、チームは場所をローテーションする。アイテムとプロ
ダクトマネージャは動かない。3チーム目は(プロダクトマネージャがいな
いので)、誰か1人動かずに残る。
4. 残った人がこれまでの状況を共有し、またリファインメントを進める。
5. 30分ごとに繰り返す。

48. Multiteam PBR & Team PBR
(2/2)
• その日をかけて、12アイテムを順次リファインして
いきます。1枚が解決したら(あるいは要調査で終
わったら)、次の1枚に着手します。その場で、大きな
アイテムを分割することもあります。
• また途中で2回、見積りもします。見積りはチームご
とですが、既存アイテムを使ってベースラインをそ
ろえます。

49. The Next Day
• PBRの翌日、ピーターはPOのパオロに代わっていくつか作業をします。
• プロダクトバックログに、分割して新たにできたアイテムを加え、分割元のア
イテムは消す
• 昨日のPBR中につくったWiki上のドキュメントに、アイテムからリンクを張る
• 最新の見積りを記録し、どのアイテムがレディになったか記入する
• 後でアリエルとピーターはパオロと一緒に、プロダクトバックログの変更
内容をレビューし、パオロの質問に答え、並び替えをします。
• パオロは監査レポートのアイテムを、バックログの先頭部分に移動しまし
た。これだけリリースできれば、プレッシャーが軽くなると判断したためで
す。そのうえで、重要性が低いと思えるアイテムをいくつか、ずっと下の方
に移動しました。着手するのは何ヶ月か先かもしれません。

50. Sprint Planning One

51. LeSS Story:
Flow of Features & Events
おわり

52. LeSS Huge

53. LeSS Huge:
Requirement Areas
• 1つのプロダクトに関わる人が1000人となると、あるいは100人であって
も、分割統治は避けられない。従来型の大規模開発では、以下のような
分割をする。
• 単一職能グループ(分析グループ、テストグループ、……)
• アーキテクチャ上のコンポーネントグループ(UI層グループ、サーバーサイドグループ、
データアクセスコンポーネントグループ、……)
• こうした組織はスピードが遅く、柔軟性に欠ける。理由は、(1)ムダが多い
(在庫、仕掛かり、引き継ぎ、情報の分散、……)、(2)ROIの回収に時間が
かかる、(3)計画と調整が複雑になる、(4)マネジメントのオーバーヘッド
が多い、(5)フィードバックや学びが貧弱である、などだ。
• また組織が単一のスキルやアーキテクチャへ「内向き」になり、顧客価値
へ「外向き」にならない。

54. LeSS Huge:
Requirement Areas
• だがLeSS Hugeフレームワークでは、8チームより大きい場
合、職能やアーキテクチャでは分割しない。分割は顧客の関
心事の主要なエリアでおこなう。これを要求エリアと呼ぶ。
LeSSの原則である顧客中心を反映した分割だ。

55. LeSS Huge:
Requirement Areas
• たとえば、証券取引のプロダクトを考えよう(証券のトレードや
管理をする)。顧客の要求の主要なエリア――要求エリア
――は、以下のようになる。
• トレードの処理(取引の開始から完了まで)
• 資産のサービス(株式分割、配当など)
• 新興市場への対応(ブラジルなど)

56. LeSS Huge:
Requirement Areas
• 概念的には、単一のプロダクトバックログに「要求エリア」属性を追加し、
アイテムにそれぞれ要求エリアを必ず1つだけ持たせる。
• そうして、エリアプロダクトバックログに集中できるようになる。概念的
には、単一のプロダクトバックログを参照するビューと考えられる。新市
場対応のエリアプロダクトバックログは次のようになる。
順序 アイテム 要求エリア ……
1 B 新市場対応
2 C トレード処理
3 D 資産サービス
4 F 新市場対応
順序 アイテム 要求エリア ……
1 B 新市場対応
4 F 新市場対応

57. Area Product Owner and
Teams
• LeSS Hugeでは新しいロールが1つ増える。要求エリアにはそれぞれ1人
エリアプロダクトオーナーがつき、そのエリアの専門家として、エリアプ
ロダクトバックログを管理する。また複数の――けっして1つではない
――フィーチャーチームがエリアプロダクトオーナー1人につき、そのエリ
アの専門チームとなる。
• したがって、たとえば証券プロダクトには、以下が存在することになる。
• 全体のプロダクトオーナーが1人、エリアプロダクトオーナーが2人、3人をサポートす
るプロダクトマネージャーたち
• (一番大きな)*証券トレード*要求エリアには6つのチーム
• あとの2つの要求エリアには、4チームずつ
• 要求エリアを担当するチームは固定だろうか？そうではない。時間ととも
にゆっくり、エリアの重要性が変化するのに合わせて、チームも増えたり
減ったりする――他のエリアと行き来するのが一般的だ。

58. LeSS Huge
Framework Elements
• 簡単に言ってしまうと、要求エリアそれぞれは(小さい方
の)LeSSを導入して、全体で統一したスプリントで並行して動
く。巨大な組織への導入時期のいろいろなやり方について、
顧客価値による導入と組織の章で議論する。
• 役割 ―― LeSSと同じだが、以下が変更点だ。2人以上のエ
リアプロダクトオーナーと、要求エリアごとに「4～8」チーム。
1人のプロダクトオーナー(プロダクト全体の最適化にフォー
カスする)、複数のエリアプロダクトオーナーが、プロダクト
オーナーチームを構成する。非常に大きなプロダクトグルー
プでは、サポート役のプロダクトマネージャもいることが多い。

59. LeSS Huge
Framework Elements
• 1つの要求エリアには最低4チームいる。例外はあるだろう
か？
• 導入・移行の初期で、グループが少しずつ新しいエリアに広げていくタイミ
ング。最終的に4チーム以上になると確信があるときは、小さくシンプルに1
チームから始めてよい。
• エリアの需要が増えたり減ったりして、バランスを取るためチームを入れ替
えているタイミング。1エリアのチームが4つから3つに減ってもいい。最終的
には、縮小したエリアを2つくっつけて1つの大きいエリアにする。
• なぜ最低「4」チームなのか？エリアが小さいとなにが問題な
のか？
• 小さいエリアが多数あると、プロダクトバックログ全体の優先
順位の見通しが悪くなるし、調整も複雑になる。またチーム
の専門領域が狭くなりすぎて、柔軟性(アジリティ)が失われ、
価値最大のアイテムに発見的に対応しにくくなる。

60. LeSS Huge
Framework Elements
• 作成物 ―― LeSSと同じだが、以下が変更点だ。要求エリア
列をプロダクトバックログに追加し、ビューとしてのエリアプ
ロダクトバックログが要求エリアごとにできる。
• イベント ―― スプリントはプロダクト全体で共通と、ここでも
変わらない。すべてのチームが同じスプリントで動き、スプリ
ント終了時には共通の出荷判断可能なプロダクトインクリメ
ントが1つできる。単一のエリアを担当するチームの観点で
は、LeSS HugeのイベントはLeSSと変わらない。イベントにつ
いて詳しくは、続く物語の中で見ていく。
• LeSSと同様、ルールとガイドはLeSS Hugeにもあり、こちら
も物語で紹介する。また後の章で解説する。

61. LeSS Huge Story
登場人物
• ピーター 証券取引事業部のマネージャで、全体プロダクト
オーナー、POチームの責任者
• アリエル 新任のプロダクトオーナー、監査に詳しい
• ロブ マーケット担当エリアプロダクトオーナー
• クリシュナ 取引処理エリアのスクラムマスター
• リーマンショック以来、監査に関する要求が厳しくなっている
• その分野の専門家として、アリエルは雇われた
要約

62. A Big Surprise
• ピーター、アリエル、ロブ、クリシュナが集まって相談している
• Dodd-Frank保護法の対応が今年度中に必須となったが、
影響は非常に大きい
• でもDodd-Frankの詳細について、まだ誰も知らない(監査官すらま
だ勉強中)
• アリエルは監査に詳しいが、この会社のシステムを知らない
• まずは影響の大きさを把握するのが急務
• ロブが言った。「ゾンビチームはどうだろう」
要約

63. Dyslexic Zombie Team
• ゾンビチームはLeSS導入に抵抗し続けたチームだった
• 非常に経験豊富でシステムを熟知したベテランで、アーキ
テクチャも知悉している
• LeSSに反対していたものの、いざ導入すると、難易度の高い
開発をこなせるチームになった
• 他のチームにアーキテクチャを教えたりもする
• トム(元PowerPointアーキテクチャチーム)は、現在のアーキ
テクチャ仲間(CoP)のリーダー
• ロブ「アリエルと一緒にシステムへの影響を調査するなら、ゾ
ンビチームが最適じゃないかな」
要約

64. Dyslexic Zombie Team
要約

65. Refining with Zombies
• 次の日のゾンビチームのリファインメントに、アリエルが参加
して全体像を説明した
• ゾンビのトム「これを今年度中？ 無茶だ！」
要約

66. Refining with Zombies
• 今度はトムがシステムの全体像をホワイトボードで説明しな
がら、監査の影響を検討した
• 時間がないので、直ちに開発に着手することに
• 明確になっている部分を見つけて「ひとくち食べる」
• 学ぶための開発で、影響の大きさをつかむ
• 大小の部分を見つけてエリアプロダクトバックログに追加していく
要約

67. Creating a New Requirement
Area
• 翌日、プロダクトオーナーチームが集まった
• ピーター「監査官が満足するだけのものを今年度中に出せ
なかったら、取引停止だ」
• 新しいエリアを作ることになり、アリエルがエリアプロダクト
オーナーを務める
• 現在ロブのエリアバックログにあるアイテム(「Dodd-Frank
に着手」)をアリエルのエリアバックログに移して、分割する
• 次スプリントはゾンビチームが新エリアを担当する。数スプリ
ント以内に他のチームも参加する見込み
要約

68. Sprint Planning in the New
Requirement Area
• スプリントプランニングはエリアごとに分かれて並行して実
施
• アリエルのプランニングには、さらに2人監査に詳しい専門家
が参加(PBRやスプリント中の問い合わせにも対応する)
• アリエル「続く2スプリントでやりたいことが3つあります」
1. Dodd-Frankについて学び、分割する
2. ひとくち分の開発をして、システムへの影響を探る
3. 他のチームが参加できるよう準備する
• 後から3チーム、順次エリアに参加してくる見込みで、ゾンビ
チームは開発と同時に、後続チームをリードし、全体像を維
持する責任がある
• サイモン「アーキテクチャ・プロダクトマネジメントチームみたいだねｗ」
• トム「Dodd-Frankのビジョンを維持するけど、調整は各チームの責任だよ」
要約

69. The First Sprint in the New
Requirement Area
• 最初のスプリントでは、全体の時間の半分をリファインメント
にあてて、Dodd-Frankの理解に取り組んだ
• 半分の時間は開発に使い、小さなアイテムではあるものの
全体的な設計の議論に時間を費やしながら進めた
要約

70. Sprint Review in the New
Requirement Area
• 全エリアは同じスプリントで進み単一の出荷可能なプロダク
トインクリメントを作っているものの、スプリントレビューはエリ
アごとでおこなう
• ゾンビチームは1アイテム完成できた
• アリエル「予定では2アイテムだったけれど、でも1アイテム
完成できただけですごいわ」
要約

71. The Second Sprint
• 前よりも進めるようにはなったが、このスプリントでもやはり半
分くらいの時間はリファインメントにかけた
• このエリアに参加してくる予定のチームと、マルチチームの
PBRを実施したり、デザインワークショップを開催したりして、
Dodd-Frankの内容と設計について共有した
• Dodd-Frankの規模感とヤバさは、ゾンビチーム自身がいち
ばんよくわかっていた
要約

72. Product Owner Team
Meeting
• 数週間後、プロダクトオーナーチームが集まった
• 各エリアのPOが状況を説明し、直近のゴールを共有する
• アリエル「進捗はわずかですが、ベロシティが上がり始めま
した。霧が晴れ始めて、ゾンビチームと一緒に理解が進んで
います。手伝ってくれている2人の専門家も素晴らしいです」
• 別のエリアPOが、自分のエリアとアリエルのエリアの関連が
強いのに気づき、チームと一緒に打ち合わせをすることにし
た
要約

73. Adding a Third Team
• また数スプリント後の、プロダクトオーナーチームミーティン
グにて
• ピーター「アリエルには2チームしかいない。今年度の最重要
事項として、チームを増やしたいと思う。ラビ、君が4チーム必
要だというのもわかるが、全体の状況を考えて、君のところ
から1チームアリエルのところに回すのが最善だ。立候補す
るチームを募ってくれ」
要約

74. LeSS Huge Story
おわり
要約

75. Multisite
• 分散 vs. 複数拠点 (Dispersed versus Multisite Teams)
• 開発グループが8人だけの小さなもので、それが3カ国にわ
かれていたら、分散「チーム」が1つあることになる(薦めてい
るわけではない。言葉を定義しているだけだ)。
• 1プロダクトのグループが50人、あるいは500人であれば、分
散チームは必要ない。チームはそれぞれ同じ場所、文字通り
1つのテーブルを囲んで働ける。だが他の拠点にいるチーム
も出てくる。この場合、プロダクトグループは複数拠点チーム
となる。

76. LeSS Huge Story
when Multisite
• アリエルは証券取引システムの新しい要求エリアのPOで、
今は立ち上げのため1チームしかいない
• 全体POのピーターは4チーム必要と考えている
• 最初の2チームはロンドンだが、3番目のチームはルーマニ
アのクルジュにいるドラキュラチームになった
• ピーター「アリエル、複数拠点のアドバイスをしよう」
• SMのサイタが複数拠点を長くやってるので相談するといい
• ゾンビチーム全員、できるだけ早くクルジュに行かせて、向こうの作
業場所で一緒に働いてもらう
• アリエル自身もクルジュに頻繁に行くべき
要約

77. Multisite Sprint Planning
Part One
• 数スプリント後のスプリントプランニング
• Google Hangoutでクルジュの作業スペースが見える。クル
ジュのメンバーのうち2名は、ロンドンに来ている
• アイテムはGoogle Spreadsheetで共有
• 質問タイムで、ロンドンは付箋に、クルジュはスプレッドシート
に質問を書き込む。回答はスプレッドシートも、ビデオチャット
も使う
要約

78. Multisite Overall PBR
• ロンドンとクルジュをビデオチャットでつなぎ、アイテムをさ
らに分割する
• ブラウザベースのマインドマッピングツールで議論しながら
ブランチを増やしていく
• 分割したものは、スプレッドシート上に実例(Example)を書き
込んで理解を確認
• 見積りは全体で、カメラに写るくらい巨大なプランニングポー
カーを使っておこなう
要約

79. LeSS Huge Story
when Multisite
おわり
要約

80. Onwards (1/3)
• プロダクト全体にフォーカス ―― ここで紹介した物語は、
LeSSを実際に実践したときの、スプリントとイベントについて
理解するためのものだ。あえて強調していないが、すべての
ストーリーの中心には、プロダクト全体にフォーカスという
LeSSの原則がある。すべてのチームが一緒になって、共通
する1つの出荷判断可能なプロダクトインクリメントを、共通
するスプリントの最後に提供する。この点は非常に重要だ。

81. Onwards (2/3)
• 組織とニセスクラム ―― もうひとつ重要なのが、こうしたこ
とを実現するための組織設計だ。
スケールしたスクラムと、特別なスケール
フレームワークで「チームだけスクラム」
というものを、混同してはならない。
スケールしたスクラムは、スクラムをスケールさ
せたものだ。

82. Onwards (3/3)
• 「ニセの大規模スクラム」を作るのは簡単だ。グループが一見スクラムの動きを
しているように見えるが、表面をちょっと剥いてみると、今までやってきたことと何
も変わらないという状況だ。スクラムやアジャイルっぽい用語をちょっと飾り付け
ただけだ。そうなると、大規模なグループはこうなる。
• 「分析スクラムチーム」がユーザーストーリーを書く
• 「UXスクラムチーム」がワイヤフレームでUXのストーリーのを描く
• 「アーキテクチャスクラムチーム」パワーポイントのストーリーを作る
• 「プログラミングスクラムチーム」はチームごとの「プロダクトバックログ」を持っている
• 「テストスクラムチーム」
• ……こうした人びとが、「プロジェクトを納期までに納品せよ。できたら教えろ」とい
う命令の下で、スクラムマスターの皮をかぶったプロジェクトマネージャの指揮
で働いている。
• こりゃひどい。
• さて、本当のラージスケールスクラムは組織を変える、スクラムは変えないという
ところから始まるので、続く章ではLeSSの組織設計と移行について見ていこう。

83. Introduction to LeSS
おわり