アジャイル チームは、プロダクト所有者、スクラム マスター、ソフトウェア開発者、その他のメンバーで構成され、有益な製品を創造的に提供することで、複雑な問題の対処に協力して取り組んでいます。スクラムは、チームが複雑な製品の開発、提供、維持に使用する一般的なアジャイル手法の 1 つです。しかし、Large-Scale Scrum (LeSS) のような大規模なアジャイル プロセスのフレームワークを使用して、企業における大規模スクラムに効果的に対処するようになったのは、ほんの最近のことです。
LeSS フレームワークとは
LeSS は、1 つの製品に対して一緒に作業をする複数のチームにスクラムを拡張するためのフレームワークです。スクラム ガイドで Ken Schwaber 氏と Jeff Sutherland 氏が定義したように、1 つのスクラム チームの設立から始まり、1 つの製品に対して一緒に作業をする複数のチームに適用されます。
このフレームワークは、Craig Larman 氏と Bas Vodde 氏の著書『Large-Scale Scrum: More with LeSS』により、さらに磨きがかけられます。2 人の著者は長年の経験を凝縮して、複雑さと無駄を減らしながら価値を提供するフレームワークとして LeSS を定義しました。
LeSS フレームワークでは、定義済みルールとガイドを通じて可能な限りシンプルに、大規模な企業環境にスクラムの原則と理想を適用することを目指しています。そのシンプルさにより、LeSS は「かろうじて十分な」フレームワークであるというレッテルを貼られましたが、これはフレームワークを否定するものではありません。
LeSS フレームワークの構造
LeSS は、スクラムの実践を拡大することを含む 600 以上の実験を通じて作成されました。スクラムは、当時、同じ場所に配置された小さなグループのみをサポートすると考えられていました。LeSS の実験、ガイド、フレームワーク、および原則は、より多くのチームのニーズをサポートするために作成されました。さらに、LeSS ルールがその後、リリースされ、LeSS の実装と実行の方法に関するガイダンスをより適切に定義および提供し、導入のためのガイドとなりました。
原則、フレームワーク、ガイド、実験
原則
LeSS では、企業全体にスクラムの価値、要素、および全体的な目的を適用するために 10 の原則を定義します。これらの原則は、顧客にさらに集中して優れたコラボレーションを行う、より責任あるチームの設立に役立ちます。チームは、製品組織が競争力と即応性を維持するために必要な学習、透明性、顧客中心の価値の提供に重点を置きます。10 の原則は次の通りです。
- Large-Scale Scrum はスクラムである
- 経験的プロセス管理
- 透明性
- より小さな努力でより多くを達成する
- 製品全体の焦点
- 顧客中心
- 完璧を目指した継続的な改善
- システム思考
- リーン思考
- 待ち行列理論
フレームワーク
LeSS では、2 - 8 チーム (10 - 50 人) 用の Basic LeSS と 8 チーム以上 (50 - 6000 人以上) 用の LeSS Huge の 2 つの構成を提供しています。
LeSS Huge では、Basic LeSS の基盤を築くことから始まり、重要な役割であるエリア プロダクト所有者 (APO)、追加のアーティファクトおよび会議の変更を追加します。LeSS Huge にすぐに取り組む前に、Basic LeSS から開始して、組織で実験、経験、フィードバックを得ることをお勧めします。LeSS Huge を導入するにあたり、おすすめの取り組み方法が2 つあります。
- 一度に 1 つの要件領域に集中し、より大きな製品の中の要件領域に焦点を当てる
- チームの作業範囲、完了の定義、製品定義を徐々に拡大する
これにより、組織全体に LeSS を拡張する前に、LeSS を使ったチーム エクスペリエンスを築き、製品領域全体に拡張し、マネジメントのサポートを得ることができます。
ガイド
LeSS ガイドは、著者の Craig Larman 氏と Bas Vodde 氏が LeSS で行った実験に基づいて作成された推奨事項を記載したものです。ガイドは彼らの 3 冊目の著書『Large-Scale Scrum: More with LeSS』の予想外の副産物でしたが、LeSS の採用方法、関係者の役割と責任、チーム間の調整と統合の方法などを理解する際に非常に役立ちます。LeSS フレームワークの適用において、ガイドはオプションであることに注意してください。
実験
LeSS には、一部の組織が試みるべき実験、他の組織は避けるべき実験、成功失敗相半ばする結果となった実験といった、著者たちの提案する実験が含まれています。これらの実験の結果は、LeSS フレームワークを形成する基礎となりました。
Craig Larman 氏と Bas Vodde 氏の最初の 2 冊の著書『Scaling Lean & Agile Development』と『Practices for Scaling Lean & Agile Development』では、ベスト プラクティスは常に環境に依存するため「ベスト プラクティス」というようなものは存在しないという原則に基づいた一連の実験として Large-Scale Scrum が構成されました。
3 冊目の著書『Large-Scale Scrum: More with LeSS』では、LeSS を採用するためのガイド、最初の 2 冊の著書からの実験、LeSS における役割の明確化、チーム間の調整と統合の方法などを紹介しています。
3 冊の本はすべて段階的にフレームワークを構築しているため、LeSS の基礎をよりよく理解するためにお読みいただくことをお勧めします。
LeSS における役割と計画
Basic LeSS は、チームと重要なスクラムの役割に重点を置いています。製品のビジョンと方向性を担当するスクラムのプロダクト所有者、製品の作成とデリバリーを担当するスクラム開発チーム、継続的な改善とコーチングでチームを支援するスクラム マスターです。LeSS が展開される領域の 1 つは、マネージャーの役割と、継続的な改善と自律を目的に障壁を取り除くことでマネージャーがチームを支援する方法です。
前述したように、LeSS Huge のエリア プロダクト所有者は、プロダクト所有者をあらゆる点で支援および調整し、ビジネス ニーズと技術チームの橋渡しをするために重要です。エリア プロダクト所有者の作業はプロダクト所有者と同じですが、エリア プロダクト所有者はサポート対象のチームにより集中し、限定的な範囲に対処します。エリア プロダクト所有者は、顧客重視のタスクを専門とし、製品を重視する機能チームのプロダクト所有者としての役割を担います。
スクラムで説明され、LeSS でさらに詳細化される重要なセレモニーの 1 つは、プロダクト バックログ リファインメント (PBR) ミーティングです。PBR ミーティングは、一連の並行 LeSS スプリント実行を通じて、重点分野全体にスプリント計画を拡大します。これらのミーティングが継続的に行われる期間は、将来のスプリントに備えるためにアイテムを理解し、議論し、磨きをかけるために、各スプリント内で必要なものです。PBR ミーティングの主な活動は、1) 大きなアイテムの分割、2) 未解決の問題の明確化と回答、3) ストーリーのサイズ、リスク、依存関係、および価値の推定です。
スプリント計画セレモニーの重要性は別として、スプリント レビューとふりかえりは、チームが構築し、提供したものを検証するだけでなく、変更や改善、新しいアイデアについて話し合うための重要なセレモニーです。また、チームが提供した顧客価値を称賛するための機会でもあります。ふりかえりによる検査と適応の機会は各チーム内にあり、また、チームがどのように調整とコラボレーションを実施したかを取り上げるふりかえりも行われます。
LeSS の違いとは
LeSS は、アジャイルを拡張するその他のフレームワークに類似した 5 つの主要なコンポーネントを共有しています。アジャイル マニフェストから得られるインスピレーションとその 12 の原則、スプリント / イテレーションを通じた期間、組織全体の同期、スクラム内のそ、DevOps、CI/CD、テスト主導型開発 (TDD) などの品質開発の実践です。しかし、LeSS を他から際立たせているのは、その他の顕著な特性です。
LeSS とスクラムの比較
LeSS とスクラムのどちらが優れているかを比べることはよくあることです。しかし、これは正しい見方ではありません。LeSS はスクラムの「より良い」バージョンではありません。どちらを持つべきか、またはどちらが優れているかの比較ではないのです。LeSS はスクラムに基づき構築されており、より大規模な環境での使用と、より大規模な組織全体で 1 つのチームを超えてスクラムを拡張する方法をサポートします。
Basic LeSS は 1 つのスクラム チームにとてもよく似ています。LeSS には 1 つのプロダクト バックログ、1 人のプロダクト所有者、完了の定義があります。また、1 つ以上のチームで構成されていますが、各スプリントの終了時に共通のリリース可能な製品を提供するために、すべてのチームはスクラム チームのように連携します。1 つのプロダクト バックログを所有する 1 人のプロダクト所有者がいるにも関わらず、LeSS では、結果としての作業は 1 つ以上のチームによって達成される場合があります。特に、LeSS Huge では、プロダクト所有者の役割が拡張され、多くのチーム間で調整およびコラボレーションを行うエリア プロダクト所有者の役割が含まれるようになります。これらの取り組みをサポートするために、プロダクト所有者は、単独チームのプロダクト バックログ リファインメント ミーティングを推進します。これは、一緒に作業をするすべてのチーム間での作業のデリバリーの調整に役立ちます。
ここから先は、LeSS でのスプリント計画は、1) すべてのチームが集まり製品のバックログ アイテムの最適な分割法を決定し、2) チームがプロダクト バックログ アイテムのデリバリーのために、他のチームと協力しコミュニケーションをとりながらスプリントを計画するという、2 つの部分に分かれます。
これらの点とは別に、デイリー スクラム、スプリント レビュー、全体的なふりかえりなどの他のセレモニーには、LeSS において独自のニュアンスがあります。
LeSS と SAFe の比較
LeSS は、大規模なソフトウェア開発チームを持つ企業全般に人気が高まっていますが、Scrum of Scrums や Scrum@Scale などの他の拡張アジャイル フレームワークも注目を集めています。主要なフレームワークの 1 つに、Scaled Agile Framework® (SAFe) があります。
LeSS と SAFe には多くの類似点があります。たとえば、どちらもスクラム チームを拡張し、リーン思考、継続的な改善、顧客中心主義などの原則を組み込むことから始まります。ただし、LeSS は、柔軟性と適応性を維持することによって、組織構造の簡素化に重点を置いているという点で異なります。
LeSS とは異なり、SAFe には、リリース トレイン エンジニア (RTE)、ソリューション トレイン エンジニア (STE)、エピック所有者などの追加の役割が必要です。これには、スクラムを正常に実行しているアジャイル チームと同等の基盤から始める場合でも、組織によっては引き受ける準備が整っていない可能性があるプロセス、アーティファクト、組織の変更も含まれています。LeSS Huge はいくつかの点で Basic LeSS とは異なりますが、それ以外は他のフレームワークほど複雑ではありません。
LeSS フレームワークのメリット
LeSS の基本的な焦点は、異なるフレームワークを構築することではなく、完全にエンドツーエンドで顧客重視のソリューションまたは製品を提供するために協力する多くのチームに、スクラムの原則を適用することです。
LeSS で達成できるメリットには、次のようなメリットがあります。
- チームがすでにスクラムで使用しているプラクティスを実装することで、実装コストを削減します
- 1 人のプロダクト所有者がフレームワークと原則を理解し、ビジネス チームと技術チームの間のギャップを埋めます
- 製品のデリバリーに必要な人数を削減します。LeSS によって、役割とオーバーヘッドが急激に増加することはありません
- 重点分野内の製品全体のビューを提供します
- チームは顧客およびビジネスの関係者と直接コンタクトします
- アジャイル マニフェストの基本的なプロセスである頻繁なふりかえりやその他のミーティングを通じて、継続的な改善が可能になります
多くの組織にとって、スクラム チームを拡張するための LeSS アプローチは、アジャイルを拡張するジャーニーにおける次の論理的なステップである可能性があります。
次のステップ
LeSS のようなフレームワークは、企業が組織内でアジャイルを効果的に拡張し、目標とするビジネス成果の達成をための実行可能な方法を提供します。現行のプラクティスを拡大し、そうしたプラクティスのメリットを完全に実現できるツールを選択することも同様に重要です。Atlassian の Jira Align はエンタープライズ アジャイル計画プラットフォームです。Jira Align を使用すれば、可視性、戦略的整合性、企業の適応性を向上してデジタル変革を加速できます。Jira Align が今日どのように LeSS をサポートするかご覧ください。
Related resources
