LeSSIntroduction

LeSS Study勉強会

2016.5.13、6.6

やっとむ

Introduction to LeSS

• こちらのまとめ・一部訳・物語の台本

• https://less.works/less/framework/introduction.html

Introduction to LeSS

• Large-Scale Scrum: More with LeSSの第2章

2人のエコノミストが道を歩いていた。

1人が道ばたに紙が落ちているのを見つけた。

「あれは100ドル紙幣じゃないか？」

「違うさ」もう1人が答えた。「100ドル紙幣だったら、もう誰かが拾っているよ」

One-Team Scrum

• スクラムは経験的プロセス制御開発フレームワークであり、機能横断チームが自己組織化して製品をイテレーティブかつインクリメンタルに開発する

• スクラムガイドやスクラムプライマーでは、1チームのスクラムしか語っていない

LeSS

LeSS

• ラージスケールスクラム(LeSS)はスクラムを複数チームで1つのプロダクトを開発する状況に当てはめたもの。なぜLeSS？1チームのスクラムと同じように……

• 大規模なグループにおいて、LeSSは必須要素と経験的プロセス制御とのあいだのいいバランスを取れる

• また1チームスクラムと同様、LeSSは (1)軽量 (2)理解がシンプル (3)修得は難しい―本質的複雑さが原因。

Background

2002年、Craigが「Agile & Iterative Development」を書いたころ、誰でもアジャイル開発は小規模グループ向けだと「知って」いた。だが我々はスクラムを非常に大きく複数サイトにまたがるプロダクト開発に当てはめることに興味を持ち、またリクエストも受けるようになっていた。

そこで2005年からCraigとBasはタッグを組んで、クライアントに向けてスクラムのスケールアップに取り組んだ。現在、2つのLeSSフレームワーク(基本のLeSSと、LeSS Huge)を、大規模プロダクトを世界をまたいで開発している、さまざまなドメインにおいて適用している。

• Ericsson や Nokia Networksなどの通信機器開発

• JPMorganやBAMLなどの投資銀行、個人向け銀行

• ION Tradingなどのトレーディングシステム開発

• bwinなどのゲームサイト開発

• Valtech Indiaなどのオフショアアウトソーシング

Background

「大規模」とは、いま書いている時点の最大でLeSSHugeを適用しているプロダクトグループは2500名、10開発サイト、数千万ステップのC++コード、カスタムハードウェアを擁する。

業界で真ん中くらいのLeSSプロダクトグループサイズは、1～2箇所のサイトに3～5チームがいるというものだ。

経験をもとにこれまで2冊本を出しており、本書は3冊目に当たる。プリクエルであり、入門書でもある。なのでLeSSの詳細については前の2冊を読んでね。

LeSS Principles and Themes

キュー理論

ラージスケールスクラムもスクラムだ

透明性

より少なくでもっと多く

プロダクト全体にフォーカス

顧客中心

継続的改善で完璧を目指す

リーン思考

システム思考

経験的プロセス制御

LeSS Principles and Themes

• ラージスケールスクラムもスクラムだ—LeSSは「新しい、よりよいスクラム」ではない。LeSSはスクラムそのものの原則、要素、目的を大規模なコンテキストにどうやって適応するかという話だ。

• 経験的プロセス制御—検査と適応をプロダクト、目的、組織デザイン、プラクティスにあてはめ、状況に適した組織をスクラムに沿って作り上げる。あらかじめ決まった法則に従うわけではない。経験的プロセス制御によってできるのが……

• 透明性—さわれる「完成」アイテム、短いサイクル、共同作業、共通の定義、作業場所から恐怖を追い払う。

• より少なくでもっと多く—(1) 経験的プロセス制御の意味合いでは、少ないプロセスの定義から多くの学びを得る。 (2) リーン思考の文脈では、ムダとオーバーヘッドを少なくし、価値を多くする。 (3) スケーリングの観点では、役割、作成物、スペシャルグループを少なくする。

• プロダクト全体にフォーカス—プロダクトバックログは1つ、プロダクトオーナーは1人、出荷判断可能なプロダクトインクリメントを1つ、1スプリントで ―― チームが3つでも33つでも変わらない。顧客がほしいのはプロダクトであり、部分ではない。

LeSS Principles and Themes

• 顧客中心—価値もムダも、お金を払う顧客の立場で考える。彼らから見えるサイクルタイムを短くする。本当の顧客とのフィードバックループを増やす。全員が、自分の今日の仕事がお金を払う顧客にどう関わり、どう利益をもたらすのか、理解している。

• 継続的改善で完璧を目指す—いつもプロダクトを作って提供する。そこにはコストも欠陥もない。プロダクトはいつも顧客を喜ばせ、環境を改善し、生活をより良いものにする。スプリントのたびに謙虚かつ大胆に改善して、そこを目指す。

• システム思考—見て、理解して、最適化するのはシステム全体だ。部分ではない。因果ループモデリングでシステムダイナミクスを探索する。局所最適や不十分な最適化を避け、「効率」や「生産性」を個人や個々のチームで考えない。顧客は全体的な「アイデアから現金まで」のサイクルタイムとフローに興味があり、個々の手順ではない。

• リーン思考—組織的なシステムを作る。その基礎はマネージャーが教師としてシステム思考とリーン思考を適用し、教え、改善をマネジメントし、現場現物を実践するところにある。2つの柱、人びとへの敬意と継続的改善を置く。すべては完璧を目指す。

• キュー理論—キューを含むシステムがどう働くかR&D分野で理解し、得た洞察をキューサイズ、WIP制限、マルチタスク、ワークパッケージ、変動に適用する。

Two Frameworks: LeSS & LeSS Huge• ラージスケールスクラムには2つのフレームワークがある。

• LeSS : チーム数が2～8

• LeSS Huge : 9チーム以上、1プロダクト数千名まで

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に(＝大きく)考えてはいけない。

LeSS Framework Elements

LeSS Framework Elements

• (小さい)LeSSの要素は1チームScrumと同じ• 役割

• 作成物

• イベント

• 上記に加え、LeSSでは以下も追加• ルール

• ガイド

LeSS Framework Elements

• ルール― グループが守り、やるべきこと。スプリントプランニング1と2や、単一のプロダクトバックログと出荷判断可能なプロダクトなど。LeSSルールには、役割、成果物、イベントそれぞれに対応するものがある。

• シンプルで数少ないLeSSルールは、わずかな「事前に定めた」感をバランスよく、経験的プロセス制御に交える。とりわけ新たに始めるグループにとって、最初に「なにをどう」したらいいか、正しい方向に向ける効果がある。そしてLeSSにおける透明性を実現することができる。

• 「最初はきっちりと」というアプローチは、数多くの学習モデルに見られる初学者のニーズに応えるものだ。ジャズのトランペット奏者であり教師でもあるClark Terryは、学びを次のようにまとめている。真似、適応、改革。これはまた合気道の守破離(従う、分かれる、昇華する)としても知られる。

• ガイド― 試してみるべきアドバイス。LeSS導入の経験者から与えられる。例えばスプリント中にチームどうしがどう調整するかなど。適当かも不適当かもしれず、継続的改善の実験の範疇になる。

LeSS Story: Flow of Teams & Events• この物語では人とチームがLeSSのスプリントを経験す

るフローを説明する。

• 登場人物:• デイブ: トレードチーム• デヴィ: トレードチーム• ドン: マージンチーム• ダコタ: マージンチーム• パオロ: プロダクトオーナー• サム: スクラムマスター(トレードチーム、マージンチーム)

• 演出の都合により省略、変更、追加などがあります

LeSS Story: Flow of Teams & Events• ロンドンで珍しく晴れた朝、ロンドンの金融街である

シティにあるビルに、デイブは出勤しました。オフィスに着くと、もうデヴィが来ていました。2人はトレードチームに所属し、全5チームからなる債券取引・ポジションリスク管理システムの開発をしています。

• デヴィ「おはようデイブ！ このスプリントはうちが代表チームよ。プランニング１(いち)があと10分で始まるわ」

• デイブ「オーケー。コーヒーを淹れてくるよ。大部屋で会おう」

Sprint Planning One (1/7)

• デイブが大部屋に入ると、もう人が集まっていました。5チームから各2名の代表者。トレード・マージンチームのスクラムマスターのサムもいます。プロダクトオーナー件プロダクトマネージャのパオロに加え、2名のプロダクトマネージャもいます。

• これから、4回目の2週間スプリントのスプリントプランニング1が始まります。時間は2時間です。

Sprint Planning One (2/7)

• パオロ「やあ。このスプリント用に22枚カードを用意しました。ブラジル市場向けのフィーチャーに加え、USAの債券デリバティブの監査用レポートもある」

• サム「1チームだけで優先順位の高いやつを取らないようにね。全チームにいきわたるよう分配して」

Sprint Planning One (3/7)

• 各チームの代表者は、カードが並べてあるテーブルの周りに集まりました。デイブとデヴィも一緒にカードを選び始めます。

• デイブ「このヨーロッパ債のカードは、今までのプロダクトバックログリファインメントで詳しく見てきたから、やりたいな」

• デヴィ「こっちもそうね。それとこのオーダーシステムの機能は単純だから、誰でもわかりそう」

Sprint Planning One (4/7)

• そうしていると、マージンチームのダコタが2人のカードを見て、提案してきました。

• ダコタ「そのオーダーシステムのカード、うちにもらえないかしら？ 前のスプリントで関連するのをやったのよ。こっちの単純なレポート機能と交換でどう？」

• デヴィ「そうね、ちょっと見せて。良さそうね」

Sprint Planning One (5/7)

• 5分ほどたって、各チームが自分のカードを3枚か4枚ずつ選びました。テーブルには優先度の低いものが4枚残っており、パオロはそれを見て困った顔をしました。

• パオロ「残り4枚なんだけど、この1枚をちょっと見てください。これだけは重要で、このスプリントに入れたいんですよ。なんとか、選んだカードと入れ替えられないかな？」

Sprint Planning One (6/7)

• パオロの最後の1枚も片付いたので、次は各チームがスプリントゴールを決め、残った疑問を解決する時間になりました。プロダクトバックログリファインメントで話をしてきていても、やはり疑問は残るようです。各チームはそれぞれ、疑問をフリップチャートに書き出していきます。

• デイブ＆デヴィ「(フリップチャートに書く)」

• パオロ「あ、それはこうですよ」

• パオロを含めた3名のプロダクトマネージャは、手分けをして各チームの疑問に答えて回ります。45分ほどで、すべての疑問に回答がつきました。

Sprint Planning One (7/7)

• サム「最後に、調整の相談をしてくれ」

• デイブ「ヨーロッパ債の機能は、マージンチームのカードと共通の作業があるね。スプリントプランニング2のミーティングを一緒にやらないか」

• マージンチームのドンが合意したので、スプリントプランニング1は終了になりました。

Sprint Planning Two

• その後休憩を挟んで、こんどはチームごとにスプリントプランニング2を始めます。これは1チームのスクラムとほぼ同じですが、この物語でどうなるか見てみましょう。

• トレードチームとマージンチームは共同でスプリントプランニング2を始めました。関連するカードについて、大きな設計上の疑問を見つけ、大半はその場で議論して解決しました。いくつかは後回しにし、チームをまたいだデザインワークショップをすることにしました。

• 当初の計画見込みが変わりそうだったので、スプリントプランニングが終わったとき、各チームが共通のプロダクトバックログ(Googleスプレッドシート)上でチームの予想を書き換えました。

Multiteam Design Workshop

• ふたたび休憩を取ってから、トレードチームとマージンチームでデザインワークショップを開きます。トレードチームからはデイブとデヴィが、マージンチームからは3名が参加しました。

• デイブ「(ホワイトボードにモデリングしながら)こうでこうでこうで」

• ドン「いいね」

• ダコタ「作業分担もできそうね。計画にも影響なさそう」

• デヴィ「よかった。でも、これならもっと早く気がついて、先に解決できたはずね」

Overall Retrospective

• 翌日、スプリントの2日目に、サムと他のスクラムマスター、プロダクトオーナーのパオロ、サイトマネージャのメアリー、各チームからの代表1名ずつが、全員集まって90分の全体レトロスペクティブを開催しました。前スプリントがチームごとのレトロスペクティブで終わってしまったので、全体でできなかったためです。

• システム全体の課題や改善にフォーカスし、調整、情報共有、問題解決について離しました。

• 以前、スクラムオブスクラムを試したもののあまり上手くいかなかったので、サムがオープンスペースという手法を紹介し、このスプリントで試すことになりました。

Day4 Coordination (1/3)

• LeSSのある日の調整の様子を見てみましょう。各チームはそれぞれでデイリースクラムをやりますが、トレードとマージンの調整のため、デヴィがマージンチームのデイリースクラムに参加します。同様にドンはトレードチームに参加します。

• デヴィ「(マージンチームのところにいく)」

• ドン「(トレードチームのところにいく)」

Day4 Coordination (2/3)

• デイリースクラム後、45分のオープンスペースセッションに、各チームの代表が集まります。デイブとデヴィも参加します。サムがファシリテータになり、チーム間の調整をします。

• ドン「僕は今年のテスト仲間(community of practice=CoP)の調整役だ。ダコタ、来てくれ」

• ダコタ「自動受け入れテストを導入したいの。賛成なら、インフラをうちのチームで作るわ」

• デイブ「(別の場所で独り言をいう)アーキテクチャ仲間(CoP)は、今日はいないな。このスプリントでミーティングはないけれど、スパイクしたいことがあるから、CoPコミュニケーションツールに書き込んでおこう」

• デヴィ「CIシステムがおかしいわね。今スプリントはうちのチームが担当だから、見てみなきゃ。(デイブに向かって)デイブ、ペアで調べたいんだけど、あとで時間もらえる？」

• デイブ「いいとも」

• サム「全体レトロスペクティブはこれで終わりだ。おつかれさま」

Day4 Coordination (3/3)

• デヴィ「(パオロのところに行く)うちのチームの最初のアイテムが終わったんだけど、見てもらえる？」

• パオロ「喜んで！ なるほど、いいですね。こことことは、ちょっと直したいな」

• デヴィ「わかったわ、チームに伝えるわ」

• その日の午後、デイブは2番目のアイテムをチームと一緒に開発しました。TDDで開発し、10分ごとにTrunkにコミットし、他チームのコードと統合しました。CIは全チームのプロダクト全体をビルド、テストし、グリーンの結果を表示していました。

Overall PBR

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

• デイブ＆デヴィ＆ドン＆ダコタ＆パオロ「(PBRに参加するふり)」

Team PBR

• スプリント6日目、各チームでプロダクトバックログリファインメントを開きます。通常はチームごとに別々ですが、この物語ではどうでしょうか。

• デイブ「昨日の全体PBRで、チームPBRのテーマがUSAのレギュレーションに決まったけれど、他のチームも関係しているらしいんだ」

• デヴィ「じゃあチームPBRを合同でやりましょう」

• 結局チームPBRは3チーム合同でやることになりました。そこには会社の法務部門から専門家も参加し、ワークショップをおこないました。ローテション分析や、分散と集合スタイルのワークをやりました。

Sprint Review (1/2)

• スプリント最終日になり、2時間のスプリントレビューの時間になりました。プロダクト全体のレベルで、一緒におこなうレビューです。

• チームが5つあるので、まず1時間のバザールスタイルレビューをおこないます。プロダクトオーナー、プロダクトマネージャ、またセールス担当者も参加して、並行して個々のアイテムを見ていきます。

• チームメンバーの一部はPCのところにいてフィードバックを受け取り、後の人は興味あるアイテムを見に行きます。

• 全員「(やってみよう！)」

Sprint Review (2/2)

• 後半1時間では、ふたたびグループ全体が集まります。パオロはプロジェクタでプロダクトバックログを表示します。

• パオロ「これとこれは、プランニングの予想通り完成ですね。おつかれさまでした」

• 次にパオロとほかのプロダクトマネージャ、セールス担当者はそれぞれ順に、自分からのフィードバックをまとめて発表します。そして重要な3つのアイテムを表示し、チームと議論しました。

• パオロ「最後に、今回のスプリントの成果はリリースしようと思います。ベータテストに参加してくれるトレーダーに使ってもらいます。それから、次スプリントのテーマはUSA向けレギュレーション対応にしようと考えてるんだ」

Team Retrospectives

• 休憩後、トレードチームはチームレトロスペクティブを開きました。

• デヴィ「スプリントプランニングの後でチームまたぎデザインワークショップをやるのは、よくなかったわね」

• デイブ「複雑で関連の強いアイテムは、プランニングの前にデザインワークショップをやるとよさそうだ」

• トレードチームは全体でそれに合意しました。そして次の全体レトロスペクティブで、PBR中に関係するアイテムを見つけるよう提案することにしました。

The End

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

LeSS Story: Flow of Teams & Events

おわり

前回までのあらすじ(ストーリー部分)

• デイブ、デヴィたちは全5チームある開発部隊でトレーディング関連のシステムを開発している

• 2週間スプリントの初日はスプリントプランニングで、USAの監査関連機能がホットなテーマ

• チームをまたいで関係するストーリーについては、関わるチームが集まってデザインワークショップをする

• 全体レトロは、次のスプリントの始め(プランニングの後)

• リファインメントは、チームごとやチーム合同で、ビジネス側専門家(専門分野のプロダクトマネージャ)も参加

• スプリントレビューはバザールスタイルで、最後にステークホルダーがフィードバックする

• チームごとのレトロスペクティブでスプリント終了

LeSS Story: Flow of Features & Events• この物語では顧客のフィーチャがLeSSのスプリントを経験

するフローを説明する。

• 登場人物:• アリエル: プロダクトマネージャ(監査の専門家)

• パオロ: プロダクトオーナー

• ピーター: プロダクトマネージャ

• サム: スクラムマスター

• 演出の都合により省略、変更、追加などがあります

LeSS Story: Flow of Features & Events• アリエルはUSAへの出張が終わり、ロンドンに帰るところです。

この出張では金融監査担当者とミーティングし、法律の改正について情報を仕入れてきました。

• ロンドンに戻って週末ゆっくり休んだアリエルは、月曜日にプロダクトオーナーのパオロと会いました。

• アリエル「USAでの監査に関して、私たちの顧客が最初に必要になる機能を考えてきたの。カードにまとめたわ」

• パオロ「ありがとう。カードは5枚ですね、これで監査にはすべて対応できるのかな？」

• アリエル「パオロ、これは監査なの。どうせまた変わるし、曖昧さもなくならないのよ」

• パオロ「そうですね。この5枚、プロダクトバックログの末尾に、順序は気にせず追加しておいてくれるかな」

LeSS Story: Flow of Features & Events• 1週間後、パオロはアリエルに声をかけます。

• パオロ「監査の機能にそろそろ手をつけようと思う。まずは債券取引からになるんですけど、次のスプリントのPBRワークショップで取り上げるよう、チームに伝えたんですよ。あなたは専門家だから、全体PBRとチームPBRに参加してもらえないかな？」

• アリエル「いいわ。どのチームPBRに出るかは、チームに聞けばいいのね」

• パオロ「そうですね。PBRは今月の24日と25日だ。Wikiにドキュメントも用意しておいてくださいね」

Overall PBR (1/3)

• 24日、アリエルは全体PBRワークショップに参加しまいした。パオロ、プロダクトマネージャのピーター、それに5チームから代表が2名ずつ参加しています。

• パオロ「では始めます。USAの監査とデリバティブについてやることがたくさんあります。会計年度の監査に間に合わせるため、これから3スプリントでリリースしたいな。リファインメントと見積もり次第だけれど、3チームくらいが掛かり切りになるかもしれないと思ってます」

• アリエル「じゃあ私から説明するわ。みんな、ホワイトボードの周りにあつまってくれる」

Overall PBR (2/3)

• アリエルはホワイトボードに「USA債券デリバティブの監査」と書き、説明しながら細分化し、質問に回答しました。30分ほどして、最終的に16個のアイテムができました。

• 少し休憩してから、16個のアイテムをカードに書き起こしました。その中から7枚、優先度が高く、まだ疑問点が残っているものを選びました。

• サム「Specification by Exampleの手法を使おうか。具体例を書いてみるんだ」

• さらに90分かけて具体例を作り、7枚のカードも理解できました。

Overall PBR (3/3)

• 参加者は全体で、16枚のカードをすべて見積もりました。バックログ上の見積り済みアイテムと比較して、相対ポイントで見積もりを出しました。

• 16枚中8枚は、1チームがスプリントの3分の1で完成できるサイズでした。これがグループで決めたガイドラインでは最大の大きさです。それ以上のものは、さらに次回のPBRワークショップで分割する必要があります。

• パオロ「16枚あるけれど、優先度の低いものは今は外しておきます。あとは、できるだけ早く完成したいな。この優先度が高いアイテムをレディにできるよう、集中してください」

• PBRの最後に、チーム代表は相談して、5チームのうち3チームが監査を担当することにしました。2チームはUSA債券の経験があります。またトレードチームは今後ヨーロッパでの監査を担当する予定でした。

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分ごとに繰り返す。

Multiteam PBR & Team PBR(2/2)• その日をかけて、12アイテムを順次リファインして

いきます。1枚が解決したら(あるいは要調査で終わったら)、次の1枚に着手します。その場で、大きなアイテムを分割することもあります。

• また途中で2回、見積りもします。見積りはチームごとですが、既存アイテムを使ってベースラインをそろえます。

The Next Day

• PBRの翌日、ピーターはPOのパオロに代わっていくつか作業をします。• プロダクトバックログに、分割して新たにできたアイテムを加え、分割元のア

イテムは消す

• 昨日のPBR中につくったWiki上のドキュメントに、アイテムからリンクを張る

• 最新の見積りを記録し、どのアイテムがレディになったか記入する

• 後でアリエルとピーターはパオロと一緒に、プロダクトバックログの変更内容をレビューし、パオロの質問に答え、並び替えをします。

• パオロは監査レポートのアイテムを、バックログの先頭部分に移動しました。これだけリリースできれば、プレッシャーが軽くなると判断したためです。そのうえで、重要性が低いと思えるアイテムをいくつか、ずっと下の方に移動しました。着手するのは何ヶ月か先かもしれません。

Sprint Planning One

LeSS Story: Flow of Features & Events

おわり

LeSS Huge

LeSS Huge: Requirement Areas• 1つのプロダクトに関わる人が1000人となると、あるいは100人であって

も、分割統治は避けられない。従来型の大規模開発では、以下のような分割をする。

• 単一職能グループ(分析グループ、テストグループ、……)

• アーキテクチャ上のコンポーネントグループ(UI層グループ、サーバーサイドグループ、データアクセスコンポーネントグループ、……)

• こうした組織はスピードが遅く、柔軟性に欠ける。理由は、(1)ムダが多い(在庫、仕掛かり、引き継ぎ、情報の分散、……)、(2)ROIの回収に時間がかかる、(3)計画と調整が複雑になる、(4)マネジメントのオーバーヘッドが多い、(5)フィードバックや学びが貧弱である、などだ。

• また組織が単一のスキルやアーキテクチャへ「内向き」になり、顧客価値へ「外向き」にならない。

LeSS Huge: Requirement Areas• だがLeSS Hugeフレームワークでは、8チームより大きい場

合、職能やアーキテクチャでは分割しない。分割は顧客の関心事の主要なエリアでおこなう。これを要求エリアと呼ぶ。LeSSの原則である顧客中心を反映した分割だ。

LeSS Huge: Requirement Areas• たとえば、証券取引のプロダクトを考えよう(証券のトレードや

管理をする)。顧客の要求の主要なエリア――要求エリア――は、以下のようになる。• トレードの処理(取引の開始から完了まで)

• 資産のサービス(株式分割、配当など)

• 新興市場への対応(ブラジルなど)

LeSS Huge: Requirement Areas• 概念的には、単一のプロダクトバックログに「要求エリア」属性を追加し、

アイテムにそれぞれ要求エリアを必ず1つだけ持たせる。

• そうして、エリアプロダクトバックログに集中できるようになる。概念的には、単一のプロダクトバックログを参照するビューと考えられる。新市場対応のエリアプロダクトバックログは次のようになる。

順序 アイテム 要求エリア ……

1 B 新市場対応

2 C トレード処理

3 D 資産サービス

4 F 新市場対応

順序 アイテム 要求エリア ……

1 B 新市場対応

4 F 新市場対応

Area Product Owner and Teams• LeSS Hugeでは新しいロールが1つ増える。要求エリアにはそれぞれ1人エリアプロダクトオーナーがつき、そのエリアの専門家として、エリアプロダクトバックログを管理する。また複数の――けっして1つではない――フィーチャーチームがエリアプロダクトオーナー1人につき、そのエリアの専門チームとなる。

• したがって、たとえば証券プロダクトには、以下が存在することになる。• 全体のプロダクトオーナーが1人、エリアプロダクトオーナーが2人、3人をサポートす

るプロダクトマネージャーたち

• (一番大きな)*証券トレード*要求エリアには6つのチーム

• あとの2つの要求エリアには、4チームずつ

• 要求エリアを担当するチームは固定だろうか？そうではない。時間とともにゆっくり、エリアの重要性が変化するのに合わせて、チームも増えたり減ったりする――他のエリアと行き来するのが一般的だ。

LeSS Huge Framework Elements• 簡単に言ってしまうと、要求エリアそれぞれは(小さい方

の)LeSSを導入して、全体で統一したスプリントで並行して動く。巨大な組織への導入時期のいろいろなやり方について、顧客価値による導入と組織の章で議論する。

• 役割―― LeSSと同じだが、以下が変更点だ。2人以上のエリアプロダクトオーナーと、要求エリアごとに「4～8」チーム。1人のプロダクトオーナー(プロダクト全体の最適化にフォーカスする)、複数のエリアプロダクトオーナーが、プロダクトオーナーチームを構成する。非常に大きなプロダクトグループでは、サポート役のプロダクトマネージャもいることが多い。

LeSS Huge Framework Elements• 1つの要求エリアには最低4チームいる。例外はあるだろう

か？• 導入・移行の初期で、グループが少しずつ新しいエリアに広げていくタイミ

ング。最終的に4チーム以上になると確信があるときは、小さくシンプルに1チームから始めてよい。

• エリアの需要が増えたり減ったりして、バランスを取るためチームを入れ替えているタイミング。1エリアのチームが4つから3つに減ってもいい。最終的には、縮小したエリアを2つくっつけて1つの大きいエリアにする。

• なぜ最低「4」チームなのか？エリアが小さいとなにが問題なのか？

• 小さいエリアが多数あると、プロダクトバックログ全体の優先順位の見通しが悪くなるし、調整も複雑になる。またチームの専門領域が狭くなりすぎて、柔軟性(アジリティ)が失われ、価値最大のアイテムに発見的に対応しにくくなる。

LeSS Huge Framework Elements• 作成物―― LeSSと同じだが、以下が変更点だ。要求エリア

列をプロダクトバックログに追加し、ビューとしてのエリアプロダクトバックログが要求エリアごとにできる。

• イベント―― スプリントはプロダクト全体で共通と、ここでも変わらない。すべてのチームが同じスプリントで動き、スプリント終了時には共通の出荷判断可能なプロダクトインクリメントが1つできる。単一のエリアを担当するチームの観点では、LeSS HugeのイベントはLeSSと変わらない。イベントについて詳しくは、続く物語の中で見ていく。

• LeSSと同様、ルールとガイドはLeSS Hugeにもあり、こちらも物語で紹介する。また後の章で解説する。

LeSS Huge Story

登場人物

• ピーター 証券取引事業部のマネージャで、全体プロダクトオーナー、POチームの責任者

• アリエル 新任のプロダクトオーナー、監査に詳しい

• ロブ マーケット担当エリアプロダクトオーナー

• クリシュナ 取引処理エリアのスクラムマスター

• リーマンショック以来、監査に関する要求が厳しくなっている

• その分野の専門家として、アリエルは雇われた

要約

A Big Surprise

• ピーター、アリエル、ロブ、クリシュナが集まって相談している

• Dodd-Frank保護法の対応が今年度中に必須となったが、影響は非常に大きい• でもDodd-Frankの詳細について、まだ誰も知らない(監査官すらま

だ勉強中)

• アリエルは監査に詳しいが、この会社のシステムを知らない

• まずは影響の大きさを把握するのが急務

• ロブが言った。「ゾンビチームはどうだろう」

要約

Dyslexic Zombie Team

• ゾンビチームはLeSS導入に抵抗し続けたチームだった

• 非常に経験豊富でシステムを熟知したベテランで、アーキテクチャも知悉している

• LeSSに反対していたものの、いざ導入すると、難易度の高い開発をこなせるチームになった

• 他のチームにアーキテクチャを教えたりもする

• トム(元PowerPointアーキテクチャチーム)は、現在のアーキテクチャ仲間(CoP)のリーダー

• ロブ「アリエルと一緒にシステムへの影響を調査するなら、ゾンビチームが最適じゃないかな」

要約

Dyslexic Zombie Team

要約

Refining with Zombies

• 次の日のゾンビチームのリファインメントに、アリエルが参加して全体像を説明した

• ゾンビのトム「これを今年度中？ 無茶だ！」

要約

Refining with Zombies

• 今度はトムがシステムの全体像をホワイトボードで説明しながら、監査の影響を検討した

• 時間がないので、直ちに開発に着手することに• 明確になっている部分を見つけて「ひとくち食べる」

• 学ぶための開発で、影響の大きさをつかむ

• 大小の部分を見つけてエリアプロダクトバックログに追加していく

要約

Creating a New Requirement Area• 翌日、プロダクトオーナーチームが集まった

• ピーター「監査官が満足するだけのものを今年度中に出せなかったら、取引停止だ」

• 新しいエリアを作ることになり、アリエルがエリアプロダクトオーナーを務める

• 現在ロブのエリアバックログにあるアイテム(「Dodd-Frankに着手」)をアリエルのエリアバックログに移して、分割する

• 次スプリントはゾンビチームが新エリアを担当する。数スプリント以内に他のチームも参加する見込み

要約

Sprint Planning in the New Requirement Area• スプリントプランニングはエリアごとに分かれて並行して実

施

• アリエルのプランニングには、さらに2人監査に詳しい専門家が参加(PBRやスプリント中の問い合わせにも対応する)

• アリエル「続く2スプリントでやりたいことが3つあります」1. Dodd-Frankについて学び、分割する

2. ひとくち分の開発をして、システムへの影響を探る

3. 他のチームが参加できるよう準備する

• 後から3チーム、順次エリアに参加してくる見込みで、ゾンビチームは開発と同時に、後続チームをリードし、全体像を維持する責任がある• サイモン「アーキテクチャ・プロダクトマネジメントチームみたいだねｗ」

• トム「Dodd-Frankのビジョンを維持するけど、調整は各チームの責任だよ」要約

The First Sprint in the New Requirement Area• 最初のスプリントでは、全体の時間の半分をリファインメント

にあてて、Dodd-Frankの理解に取り組んだ

• 半分の時間は開発に使い、小さなアイテムではあるものの全体的な設計の議論に時間を費やしながら進めた

要約

Sprint Review in the New Requirement Area• 全エリアは同じスプリントで進み単一の出荷可能なプロダク

トインクリメントを作っているものの、スプリントレビューはエリアごとでおこなう

• ゾンビチームは1アイテム完成できた

• アリエル「予定では2アイテムだったけれど、でも1アイテム完成できただけですごいわ」

要約

The Second Sprint

• 前よりも進めるようにはなったが、このスプリントでもやはり半分くらいの時間はリファインメントにかけた

• このエリアに参加してくる予定のチームと、マルチチームのPBRを実施したり、デザインワークショップを開催したりして、Dodd-Frankの内容と設計について共有した

• Dodd-Frankの規模感とヤバさは、ゾンビチーム自身がいちばんよくわかっていた

要約

Product Owner Team Meeting• 数週間後、プロダクトオーナーチームが集まった

• 各エリアのPOが状況を説明し、直近のゴールを共有する

• アリエル「進捗はわずかですが、ベロシティが上がり始めました。霧が晴れ始めて、ゾンビチームと一緒に理解が進んでいます。手伝ってくれている2人の専門家も素晴らしいです」

• 別のエリアPOが、自分のエリアとアリエルのエリアの関連が強いのに気づき、チームと一緒に打ち合わせをすることにした

要約

Adding a Third Team

• また数スプリント後の、プロダクトオーナーチームミーティングにて

• ピーター「アリエルには2チームしかいない。今年度の最重要事項として、チームを増やしたいと思う。ラビ、君が4チーム必要だというのもわかるが、全体の状況を考えて、君のところから1チームアリエルのところに回すのが最善だ。立候補するチームを募ってくれ」

要約

LeSS Huge Story

おわり

要約

Multisite

• 分散 vs. 複数拠点 (Dispersed versus Multisite Teams)

• 開発グループが8人だけの小さなもので、それが3カ国にわかれていたら、分散「チーム」が1つあることになる(薦めているわけではない。言葉を定義しているだけだ)。

• 1プロダクトのグループが50人、あるいは500人であれば、分散チームは必要ない。チームはそれぞれ同じ場所、文字通り1つのテーブルを囲んで働ける。だが他の拠点にいるチームも出てくる。この場合、プロダクトグループは複数拠点チームとなる。

LeSS Huge Story when Multisite• アリエルは証券取引システムの新しい要求エリアのPOで、

今は立ち上げのため1チームしかいない

• 全体POのピーターは4チーム必要と考えている

• 最初の2チームはロンドンだが、3番目のチームはルーマニアのクルジュにいるドラキュラチームになった

• ピーター「アリエル、複数拠点のアドバイスをしよう」• SMのサイタが複数拠点を長くやってるので相談するといい

• ゾンビチーム全員、できるだけ早くクルジュに行かせて、向こうの作業場所で一緒に働いてもらう

• アリエル自身もクルジュに頻繁に行くべき

要約

Multisite Sprint Planning Part One• 数スプリント後のスプリントプランニング

• Google Hangoutでクルジュの作業スペースが見える。クルジュのメンバーのうち2名は、ロンドンに来ている

• アイテムはGoogle Spreadsheetで共有

• 質問タイムで、ロンドンは付箋に、クルジュはスプレッドシートに質問を書き込む。回答はスプレッドシートも、ビデオチャットも使う

要約

Multisite Overall PBR

• ロンドンとクルジュをビデオチャットでつなぎ、アイテムをさらに分割する

• ブラウザベースのマインドマッピングツールで議論しながらブランチを増やしていく

• 分割したものは、スプレッドシート上に実例(Example)を書き込んで理解を確認

• 見積りは全体で、カメラに写るくらい巨大なプランニングポーカーを使っておこなう

要約

LeSS Huge Story when Multisite

おわり

要約

Onwards (1/3)

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

Onwards (2/3)

• 組織とニセスクラム―― もうひとつ重要なのが、こうしたことを実現するための組織設計だ。

スケールしたスクラムと、特別なスケールフレームワークで「チームだけスクラム」というものを、混同してはならない。

スケールしたスクラムは、スクラムをスケールさせたものだ。

Onwards (3/3)

• 「ニセの大規模スクラム」を作るのは簡単だ。グループが一見スクラムの動きをしているように見えるが、表面をちょっと剥いてみると、今までやってきたことと何も変わらないという状況だ。スクラムやアジャイルっぽい用語をちょっと飾り付けただけだ。そうなると、大規模なグループはこうなる。

• 「分析スクラムチーム」がユーザーストーリーを書く

• 「UXスクラムチーム」がワイヤフレームでUXのストーリーのを描く

• 「アーキテクチャスクラムチーム」パワーポイントのストーリーを作る

• 「プログラミングスクラムチーム」はチームごとの「プロダクトバックログ」を持っている

• 「テストスクラムチーム」

• ……こうした人びとが、「プロジェクトを納期までに納品せよ。できたら教えろ」という命令の下で、スクラムマスターの皮をかぶったプロジェクトマネージャの指揮で働いている。

• こりゃひどい。

• さて、本当のラージスケールスクラムは組織を変える、スクラムは変えないというところから始まるので、続く章ではLeSSの組織設計と移行について見ていこう。

Introduction to LeSS

おわり