フレームワーク活用ガイドひとことで言うと#
「スクラムをそのまま大きくする」がコンセプト。1人のプロダクトオーナー、1つのプロダクトバックログを複数チームで共有し、余計なプロセスを足さずにスケールする。SAFeと対照的に「足すのではなく引く」発想のフレームワーク。
押さえておきたい用語#
- フィーチャーチーム（Feature Team）
- 特定コンポーネントではなく顧客向け機能を端から端まで開発できるチームのこと。LeSSの前提となるチーム編成。
- プロダクトバックログ（Product Backlog）
- 全チームが共有する唯一の優先順位付き作業リストのこと。チーム別バックログは作らない。
- Overall Retrospective（オーバーオール レトロスペクティブ）
- チームごとの振り返りに加えて行う組織横断の振り返り会議のこと。チーム単独では解決できない課題を扱う。
- LeSS Huge（レス ヒュージ）
- 8チームを超える大規模向けのLeSS拡張版のこと。Requirement Areaという概念でプロダクトを分割する。
LeSSの全体像#
こんな悩みに効く#
- チームが増えたのにプロセスが複雑化して、スクラムの良さが失われている
- チームごとにバックログが分かれて、全体最適ができていない
- 大規模アジャイルを導入したいが、SAFeは重すぎると感じる
基本の使い方#
全チームが同じプロダクトバックログを共有する。
- プロダクトオーナーは1人（最大8チームまで）
- バックログアイテムはチームに固定せず、どのチームでも取れる
- 優先順位はプロダクトオーナーが決める
ポイント: チーム別バックログを作らない。全体最適のために1本化するのがLeSSの核心。
Part 1で全チームが集まり、Part 2で各チームが詳細計画を立てる。
- Part 1: プロダクトオーナーが優先アイテムを説明し、各チームがどのアイテムを取るか決める
- Part 2: 各チームに分かれ、通常のスプリントプランニングを行う
ポイント: Part 1でチーム間の依存関係と分担を直接調整できる。
全チームが合同でスプリントレビューを実施する。
- バザー形式（各チームがブースを構える）が推奨
- ステークホルダーが各ブースを回り、フィードバックを出す
- プロダクト全体として何が進んだかを全員が把握
ポイント: バザー形式にすることで大人数でも効率的にフィードバックが集まる。
チームごとのレトロスペクティブに加え、全体レトロスペクティブを行う。
- 参加者: プロダクトオーナー、各チームのスクラムマスター、マネジメント
- チーム横断の課題（プロセス、ツール、組織構造など）を扱う
ポイント: 個別チームでは解決できない組織レベルの障壁を取り除く場として機能させる。
具体例#
背景: ECサイトの開発で4チーム（各7〜8名）が稼働中。これまでチームごとに「検索チーム」「決済チーム」のように機能で分けていたが、チーム間の調整コストが膨大になっていた。週5回の調整ミーティングで年間約1,200時間を消費。
LeSS導入: チーム構成をコンポーネント型からフィーチャー型に変更。各チームが検索から決済まで1つの機能を通して開発できる体制に。バックログを1本化し、プロダクトオーナーが優先順位を一元管理。
スプリント運営:
| 項目 | 導入前 | LeSS導入後 |
|---|---|---|
| チーム間調整MTG | 週5回（計5時間） | 0回（Part 1で解決） |
| 1スプリントで届く機能数 | 平均4機能 | 平均6機能 |
| リリースまでのリードタイム | 3週間 | 2週間 |
| 開発者満足度（10点満点） | 5.2 | 7.8 |
結果: チーム間の調整コストが年間1,200時間削減され、1スプリントで届けられる機能数が1.5倍に増加。開発者の満足度も大幅に向上した。
背景: 地方銀行の勘定系システム刷新プロジェクト。6チーム・50名体制。当初SAFeの導入を検討したが、PIプランニングの運営コストやRTEの確保が困難で、よりシンプルなLeSSを選択。
導入プロセス: まず2チームでパイロットを3ヶ月実施。コンポーネントチーム（画面チーム・API チーム）からフィーチャーチームへの移行に2スプリントかけた。その後、残り4チームを段階的に合流させた。
運営の工夫:
| 課題 | 対処法 |
|---|---|
| POの負荷集中 | サポートPO（APO）2名を配置し、POの意思決定をアシスト |
| 金融規制対応のドキュメント | DoD にコンプライアンス文書の完成を含める |
| チーム間の技術力差 | ペアプログラミングとチーム間ローテーションを実施 |
結果: 統合テスト工数が従来比40%削減、リリースサイクルが四半期から月次に短縮。パイロットチームの成功体験が他チームの動機付けとなり、全チームの自律性が高まった。
背景: 県の防災情報システム刷新プロジェクト。3チーム・20名体制。ベンダー2社と自治体IT部門の混成チーム。各ベンダーが別々のバックログで作業していたため、情報連携の不整合が頻発。
LeSS導入: 自治体IT部門のリーダーが1人のPOとして全体の優先順位を管理。ベンダーの壁を越えてフィーチャーチームを再編成。Part 1プランニングで3チームが同じ部屋に集まり、情報共有を直接実施。
成果比較:
| 指標 | 導入前 | LeSS導入後 |
|---|---|---|
| データ連携の不整合件数 | 月平均12件 | 月平均2件 |
| 仕様確認の待ち時間 | 平均5営業日 | 平均1営業日 |
| スプリントゴール達成率 | 55% | 82% |
結果: ベンダー間の壁が解消され、データ連携の不整合が83%減少。POへの仕様確認も直接対話で即日解決できるようになり、プロジェクト全体の予測可能性が大幅に向上した。
やりがちな失敗パターン#
- コンポーネントチームのまま導入する — LeSSはフィーチャーチームが前提。チームが端から端まで1つの機能を完成できる体制にしないと効果が出ない
- プロダクトオーナーを複数置く — 「大変だから」とPOを増やすと、バックログが分裂し全体最適が崩れる。1人のPOを支えるサポート体制を整える
- SAFeとLeSSを混ぜる — 思想が異なるフレームワークを折衷すると矛盾が生じる。どちらかを選んで徹底するのが成功の鍵
- 段階的な移行をせず一気に全チームを切り替える — 全チームを同時にフィーチャーチーム化すると混乱が大きい。2〜3チームのパイロットで成功体験を作ってから拡大する
まとめ#
LeSSは「スクラムに何かを足す」のではなく、「スクラムをそのまま大きくする」アプローチ。1つのプロダクトバックログ、1人のプロダクトオーナー、フィーチャーチームというシンプルな構造で、大規模開発の複雑さに立ち向かう。プロセスを増やすのではなく減らすことで速くなるという逆転の発想が魅力。