LeSS: Large-Scale Scrumフレームワークを徹底解説

1つのScrumチームでは収まらなくなった組織は、遅かれ早かれ同じ問いに行き着きます。10チーム、30チーム、80チームを、Scrumがうまく機能していた本来の良さを失わずにどう調整するのか。SAFeは構造を足すことで答えます。役割を増やし、セレモニーを増やし、全員の足並みを揃えるための階層を増やします。Large-Scale Scrum(LeSS)は、その正反対のやり方で答えます。

LeSSは、多数のチームが1つのプロダクトを一緒に作るためのScrumであり、その上に新しい何かを重ねるのではなく、組織をデスケーリング(簡素化)することでそこに到達します。「アジャイルをどうスケールさせるか」を問う代わりに、より小さく、より難しい問いから出発します。本当にアジャイルであり続けながら、組織をどこまでシンプルにできるか、という問いです。

Key Facts

• Large-Scale Scrumは、2005年からScrumのスケーリングに共同で取り組んできたCraig LarmanとBas Voddeによって形づくられました。
• less.worksは2つのフレームワークを定義しています。2〜8チーム向けのLeSSと、8チーム超向けのLeSS Hugeです。8チームという線引きは厳格なルールではなく、「あくまで経験則に基づく上限の観察」と説明されています。
• less.worksが示すLeSSの原則は9つではなく10です。二次的な要約のいくつかはこの数を誤っています。
• LeSS Hugeでは、Requirement Areaは設計上4〜8チームで構成され、それより少なくなることはありません。

LeSS(Large-Scale Scrum)とは

Large-Scale Scrum(LeSS)は、複数のチームが1つのプロダクトを一緒に作るためのScrumであり、調整のレイヤーを上に足すのではなく、組織をデスケーリングすることでそこに到達します。多くのスケーリングフレームワークが「アジャイルをどうスケールさせるか」を問うのに対し、less.worksはLeSSの問いを別の形で表現しています。形だけをなぞるのではなく、組織をどうシンプルにして、アジャイルになれるか、という問いです。

Craig LarmanとBas Voddeは、2005年に始まったクライアント支援の仕事からこのフレームワークを築き上げました。実在する組織とともにScrumをスケールしてきた長年の経験が、現在公開されているLeSSのルールになりました。その成果から2つのフレームワークが生まれています。通常のLeSSは2〜8チームを対象とし、LeSS Hugeはそれを超える8チーム超を対象とします。less.worksは、8チームという線が厳格なルールではないことを率直に認めており、「あくまで経験則に基づく上限の観察」と呼んでいます。これは、小さな構造が支えを必要とし始めるのを彼らが見てきた地点であり、フレームワークのロジックに組み込まれた数字ではありません。

どちらのフレームワークも、同じ譲れない前提を保ちます。何チームが関わっていても、Product Backlogは1つ、Definition of Doneは1つ、Sprintは1つ、Product Ownerは1人、出荷可能なプロダクトIncrementも1つです。

LeSSの10の原則

less.worksは数を明確にしています。原則は9つではなく10です。二次的な要約のかなりの数が9つに丸めて、途中で1つ落としているため、人々がつまずきやすい点です。この違いは豆知識としてよりも、これらがLeSSのルールの実際の出どころであるという点で重要です。less.worksは、これらの原則が「LeSSを作る際の指針になった」と述べており、導入にあたっても同じように指針とすべきだとしています。ルールがカバーしていない状況が現れたときに立ち返る場所だからです。

最後の原則は、SAFeや、並列のワークストリームに依存する他のフレームワークに触れたことがある人なら、じっくり考える価値があります。待ち行列理論によれば、仕掛かり中の作業を増やすとすべてが遅くなります。並列の努力が増えれば速くなるように感じられるときでもです。LeSSはこの論理を、1チームのボードだけでなく組織全体に適用します。

LeSSとLeSS Huge: 8チームを超えると何が変わるのか

2〜8チームが通常のLeSSの領域であり、この範囲では調整の構造は何も変わりません。Product Backlogは1つ、すべてのチームと直接やり取りする1人のProduct Owner、Sprintは1つです。8チームを超えると、LeSS Hugeが、1人のProduct Ownerだけでは全チームの日々の作業を追いきれなくなったときにも、プロダクト全体の視点を保つために必要な仕組みを加えます。

Area Product Ownerは自分のエリアに特化し、エリア内のチームに対してProduct Ownerとして振る舞いますが、プロダクト全体のバックログとビジョンに関する最終判断は全体のProduct Ownerが保持します。両者は、特にSprint Planningの前に常に同期をとり、Area POのローカルな優先順位が、全体のProduct Ownerが実際に最も重要だと決めたことから大きくずれないようにします。LeSS Hugeが追加の複雑さに見合う価値を持つのはこの調整ポイントです。チーム数が1人で追える範囲を超えたときに、プロダクト全体へのフォーカスを守るために存在するのです。

LeSSのSprint: 1つのSprint、複数のチーム

概念的には、LeSSはチームごとに独自の時計で動く別々のSprintではなく、プロダクト全体で1つのプロダクトレベルのSprintを回します。すべてのチームが一緒に始まり、一緒に終わり、その結果として得られるのは、あとから誰かが突き合わせなければならないチームレベルのIncrementの山ではなく、統合された、出荷可能な1つのプロダクトIncrementです。全チームのSprint Planningは同時に行われ、Sprint Reviewとレトロスペクティブも同様です。揃える必要がないのはバックログリファインメントです。Sprint Planningの開始時に項目の準備ができていれば、チームは自分たちのスケジュールでリファインメントを行えます。

Sprint Planning自体は、1チームのレベルと同じように2つのパートに分かれますが、前半の部屋にはより多くの人が集まります。

リファインメントは、LeSSが最も規律を求める場面です。Sprint Planningのようにカレンダーへ強制的に組み込まれるわけではないため、ついおろそかになりがちだからです。less.worksは、複数チームのリファインメントを「おそらくLeSSで最も重要なイベント」と呼んでおり、チームは通常、Sprintのキャパシティの10分の1ほどをこれに充てます。これを省くと、Sprint Planning Oneが項目を選ぶ場ではなく明確化に費やす会議になってしまい、本来の目的と正反対になります。

Sprint Reviewは、単に参加者を増やした1チームのデモのように運営されがちなため、特筆する価値があります。LeSSはこれをProduct Ownerの承認ゲートではなく、プロダクト全体に対する本当の検査と適応の機会として扱います。これは聞こえるよりも微妙な違いです。実質的に承認のチェックポイントであるデモは、チームにPOのために演じることを覚えさせます。ステークホルダーが歩き回り、質問し、次に起こることを形づくれるバザーは、組織に、自分たちが作ったプロダクトを実際に見る習慣を身につけさせます。

プロダクト全体で1人のProduct Owner(誰もが疑う部分)

これは、多くの人が初めて聞いたときに言葉を失う点です。何チームあっても、プロダクト全体に対して、すべてのチームを通じて、Product Ownerは1人だけ。ボトルネックが生まれるのを待っているように聞こえます。実際には、LeSSはProduct Ownerが本当にやらなければならないことを厳密に絞り込むことで、この計算を成立させています。

これにより、Product OwnerはSprint Planning Two、デイリースクラム、チームレベルのレトロスペクティブには一切関わりません。これらの会議はPOではなくチームのものです。LeSSは、多くの組織が1つの役割にまとめてしまっている2つの仕事、つまり優先順位付けと明確化を分離することで、これを実現しています。Product Ownerが担うのは優先順位付けで、何が最も重要で、それはなぜかを決めます。明確化、つまりある項目が具体的にどう振る舞うべきかというやり取りは、チームと顧客またはステークホルダーの間で直接行われ、POは必要に応じて関われますが、仲介役として必須ではありません。less.worksは、意図された役割を「コネクターであって、仲介者ではない」と説明しており、チームのあらゆる質問が通らなければならない唯一の承認済みチャネルであることとは、意味のある違いがあります。

これは、多くの読者が最初に思い描く形とも異なります。複数のProduct Ownerの上にProduct Managerが座り、調整役のチームを調整する、という構図ではありません。ScrumにおけるProduct Ownerの仕事をプロダクトの規模でこなす1人の人であり、スケールしない部分の仕事はチームに任せるのです。

この分担は、見落とされがちな形でチームの自律性も守ります。すべての確認の質問が1人を通らなければならないなら、LeSSは批判者が想定しているボトルネックをまさに再現してしまうでしょう。そうではなく、顧客と直接話せるチームは細部をより速く進められ、Product Ownerは空いた時間を、プロダクト全体で1人にしかできないこと、つまり次に何を作るかを決めることに使います。この役割を、Scrum Masterがチームレベルで担う調整の仕事と比較しているなら、この分担は、1チームのScrumにすでに存在する分担と同じもので、1つのチームの内側ではなく、より多くのチームにわたって適用されているだけです。

LeSS vs SAFe: デスケーリングか、構造の追加か

この記事にたどり着く読者は、すでにSAFeについて読んでいることが多く、両者を公平に比べるには、それぞれが実際に何を最適化しているのかを述べるのが適切です。SAFeはチームをおおむねそのままにして、それらを調整するための階層、役割、スケールした計画のリズムを加えます。LeSSは逆方向に進みます。組織にフィーチャーチームを中心に再編成し、余分な役割を取り除き、積み重なった計画イベントではなく、1つのSprintと1つのBacklogで調整するよう求めます。

この表のどちらの側も間違いではなく、どちらのフレームワークも客観的な尺度でもう一方よりアジャイルというわけではありません。同じ調整の問題に、正反対の直感で取り組んでいるのです。SAFeは調整にはより多くの足場が必要だと考え、LeSSはその足場の大半こそ解決しようとしている問題だと考えます。SAFeが同期のイベントとしてPI Planningを使うのに対し、LeSSはSprint Planning Oneを使います。これは1チームがすでに行っているのと同じイベントで、全チームが同じ場にいるだけです。この比較に、思想の違いが凝縮されています。一方はスケールに対処するために新しいイベントを作り、もう一方はすでにあるイベントをスケールさせたのです。

LeSS vs Spotifyモデル vs 通常のマルチチームScrum

あと2つの比較は頻繁に出てくるため、簡単に触れておきます。どちらも、SAFeほどLeSSの競合ではなく、解決する問題が少し異なります。

Spotifyモデルは、丸ごとコピーすることを意図したものではなく、Spotify自身も何年も前に元の構造から先へ進んでいます。語彙(スクワッド、チャプター、ギルド)としてはよく通用しますが、ルールブックとしては通用しません。そもそもルールブックを公開していないからです。通常のマルチチームScrumは、共有のフレームワークを何も重ねずに、複数のチームがそれぞれ標準的なScrumを実行する形で、多くの組織が他の何かを導入する前にデフォルトで行っているものです。そして通常、最初に破綻するのもここです。2つのチームのProduct Ownerが正反対の方向に優先順位をつけることを止めるものはありません。そもそも彼らのバックログを結びつけるものがないからです。LeSSは、そのデフォルトの構成を取り上げ、それを壊す特定の部分を直したものだと言えます。バックログは1つ、オーナーは1人、Sprintは1つです。同じ問いに対する、知っておく価値のある古い答えもあります。Crystalは、1つのフレームワークを保って組織をそれに合わせて作り変えるのではなく、チームが大きくなるにつれて手法ファミリーのより重いメンバーに入れ替えることでスケールします。

導入の現実: LeSSの導入が実際に求めるもの

SAFeのほうが売りやすく、その理由は率直に述べる価値があります。SAFeの導入は足すものばかりです。新しい役割、研修カリキュラム、認定、カレンダー上の名前のついたイベント。まだ何も成果を出していなくても、組織図の上では前進して見えます。LeSSの導入は取り除くものばかりで、取り除くことは、自分の現在の仕事がなくなるものの1つかもしれないマネージャーたちの前で話すには、はるかに難しい話です。

これはどれも微妙な話ではありません。フィーチャーチームを中心に再編成すれば、通常、一部の人の仕事の形が変わります。そしてProduct Ownershipを1つの役割に統合すれば、通常、他の人の肩書がなくなるか再定義されます。これは、すでに存在する役割を取り除くのではなく、人を新しい役割へと訓練することが中心のSAFeとはまったく違う要求です。LeSSの導入が、SAFeの展開より小規模で、広がるのが遅い傾向にある理由の一端もそこにあります。デスケーリングの根拠が妥当だとしても、自社のマネジメント構造についてその議論をしようとする組織は多くありません。

LeSSが向いているのは、すでに1チームのScrumをうまく運営していて、その裏付けとなる実際のバックログがある組織です。SprintやDefinition of Doneが日々何を意味するかをまだ学んでいる段階の組織には向きません。また、プロダクト全体に対して実質的な権限を持つ1人のProduct Ownerを指名する意思があり、今あるコンポーネントチームの構造を守るのではなく、フィーチャーチームを中心に再編成する意思がある組織にも向いています。規制の厳しい環境や契約の多い環境が要求するレポートや役割の構造を必要とする組織や、そもそも1つのバックログを共有しない複数の本当に別々のプロダクトを管理している組織には向きません。そうしたケースは、通常、SAFeのポートフォリオレイヤーや別のモデルのほうがよく合います。

LeSSを使うべきでないとき

これらはどれも、LeSSが悪いフレームワークである理由ではありません。特定の組織が、特定の時点で、LeSSが求めることに対して準備ができていないかもしれない理由です。この文の率直な版は、SAFeやあらゆるスケーリングのアプローチにも当てはまります。難しいのはフレームワークではありません。組織が実際にどう構成されているかを変えることであり、それはフレームワークが足場を足すものでも取り除くものでも変わりません。

LeSSは売りやすいほうではなく、そうなろうともしていません。組織がすでに1チームのScrumをうまく運営していて、フィーチャーチームと1人のProduct Ownerを中心に再編成する意思があるなら、デスケーリングは単なる思想的な立場ではなく、現実的な選択肢です。まだその意思がないなら、SAFeや、より軽い手法のほうが、おそらく速く、より遠くへ進めます。それも正当な答えです。選ぶ基準は、どちらのフレームワークがよりアジャイルかではありません。組織が実際にどの方向の変化を起こせるか、です。