PMP試験の勉強で覚えた用語をかみ砕いて理解するための記事。

1. LeSSの概要と背景

LeSS(Large Scale Scrum)は、複数のチームが共同してスクラムを実施する際に活用されるフレームワークで、大規模なプロジェクトに適用するためのスクラムの拡張バージョン。PMPにおいて、アジャイルなプロジェクトマネジメント手法を活用する場面で登場することがある。LeSSは特に大規模なプロジェクトにおいてチーム間の調整を円滑にし、全体の効率を高めるために用いられる。

IT企業における製品開発など、数多くのチームが関与するような場面で、複数チーム間の一貫性を保ちながらアジャイルな開発プロセスを進行させることが求められる。このときLeSSが用いられることが多い。

2. LeSSとは?

LeSSは基本的に「1つのプロダクトバックログ、1人のプロダクトオーナー、複数のスクラムチーム」という構成で、シンプルさを追求している。具体的なプロセスとしては、各チームが共通のプロダクトバックログを利用し、それぞれスプリントを実行してプロダクトの開発を行う。プロダクトオーナーは、全体の優先順位付けを管理し、チーム間の調整を行う役割を担う。

LeSSは組織に対して、できる限り階層を減らしシンプルな構造を維持することを強調する。これにより、迅速な意思決定とチーム間のコミュニケーションを促進し、変化に対する柔軟性を確保する。PMBOKにおいても、LeSSはスケーリングが必要な状況でアジャイルを導入する手法として紹介され、アジャイルプロジェクトマネジメントの知識エリアで頻繁に登場する。

LeSSならではの特徴的な手法として、「全チーム合同でのスプリント計画ミーティング」と「相互チームレビュー」がある。

  • 全チーム合同でのスプリント計画ミーティング: 複数のチームが一堂に会し、プロダクトバックログのアイテムの優先順位を決定し、各チームに割り当てる。この手法により、全体のゴールに向かって各チームが一貫した理解を持つことができ、チーム間の作業の整合性を保つことができる。この合同の計画ミーティングでは、各チームが他のチームのタスクや目標を把握できるため、依存関係の管理が容易になる。また、各チームがどのように協力して全体の目標を達成するかについても議論される。これにより、チーム同士の協力体制が強化され、リソースの無駄遣いや重複作業を防ぐことができる。
  • 相互チームレビュー: スプリントの終了後、各チームが開発した成果物について他のチームからフィードバックを得る場として相互チームレビューが行われる。このレビューは、単なる品質チェックにとどまらず、異なるチームの視点から改善点を見つけ出すことが目的となる。例えば、あるチームが実装した機能が他のチームの機能にどのように影響するかを確認し、適切なフィードバックを提供することで、システム全体の整合性を保つことができる。また、レビューを通じて各チーム間で知識の共有が進み、プロジェクト全体のスキル向上が図られる。このようにして、全体としての品質の向上とスキルの均質化が実現される。

3. 実務での適用例

大手IT企業で、複数の開発チームが共同で大規模なERPシステムを開発するプロジェクトを例に挙げる。このプロジェクトには10以上の開発チームが関与しており、各チームはそれぞれ異なる機能モジュール(例えば財務、在庫管理、人事管理など)を担当していた。LeSSを導入することで、各チームは共通のプロダクトバックログを利用し、プロダクトオーナーが全体の優先順位を管理していた。その結果、各チームは自分たちのタスクが他のチームの作業とどのように関連しているかを正確に把握することができ、連携のミスや重複作業を防ぐことができた。

例えば、スプリント計画ミーティングでは、すべてのチームが一堂に会し、プロダクトバックログのアイテムについて議論し、それぞれのチームに適切に割り当てを行った。この際、財務チームが開発する機能が人事管理チームの機能に依存していることが発覚し、両チーム間でスプリントの順序や優先度を調整することができた。これにより、システム全体として整合性を保ちながら進捗をスムーズに進めることができた。

また、スプリント終了後の相互チームレビューでは、他のチームが開発した機能についてのフィードバックを積極的に行い、各チームの視点からの改善提案が行われた。たとえば、在庫管理チームが財務チームの機能に対して「在庫変動に伴うコスト計算のアルゴリズムが実務に適していない」と指摘し、改善のための具体的なアイデアを提供することで、システム全体の品質向上に寄与した。これにより、各チームは個別の開発にとどまらず、システム全体の価値向上を意識した開発が可能となった。(※筆者の体験ではなく、例です。)

4. アンチパターン – LeSSを使わなかった場合の問題点

LeSSのようなフレームワークを導入せず、各チームが独自にスクラムを行った場合、以下のような問題が生じた。

まず、各チームが独自のプロダクトバックログを持ち、それぞれのチームが独立して計画を立てていたため、全体としての優先順位が不明確となった。例えば、あるチームが機能Aを開発していたが、他のチームがそれに依存する機能Bをまだ開発していないことが後から判明し、プロジェクト全体の進行に大きな遅延が発生した。このように、チーム間の依存関係の管理が適切に行われず、全体の整合性が欠けることになった。

さらに、チームごとに開発のペースが異なり、あるチームが開発を完了したが、他のチームの遅れによりリリースができない状況が頻発した。このため、リソースが無駄に使われ、開発チームの士気が低下することにもつながった。例えば、財務チームが担当する機能は早期に完成していたが、在庫管理チームの遅れによって統合テストが遅れ、結果としてシステム全体のリリースが3ヶ月遅延した。

また、統一されたプロダクトバックログが存在しなかったため、異なるチームが重複した作業を行うケースも見られた。例えば、在庫管理チームと人事管理チームがそれぞれ似たようなデータ入力機能を開発しており、その後、二重にコストがかかっていることが判明した。この重複作業により、開発コストが大幅に増大し、プロジェクトの予算を圧迫する結果となった。

さらに、チーム間のフィードバックプロセスが欠如していたため、開発した機能が他のモジュールに与える影響を十分に考慮せずに進められてしまった。これにより、システム全体の品質が低下し、ユーザーからのフィードバックで多数の不具合が発見された。これらの不具合を修正するために、追加の開発リソースとコストが必要となり、プロジェクト全体のスケジュールと予算に深刻な影響を及ぼした。(※筆者の体験ではなく、例です。)

5. 学びと今後の展望

LeSSを導入することで、大規模プロジェクトにおいてもアジャイルの利点を最大限に生かすことができる。特にチーム間の一貫性を保ちつつ迅速な意思決定を可能にする点が強み。今後は、他のスケーリングフレームワーク(SAFeなど)と比較しながら、プロジェクトに最適な方法を選択することも重要になるだろう。また、LeSSに関する知識をさらに深めるためには、実際にケーススタディを学ぶことが有効。

6. まとめ

LeSSは大規模なアジャイルプロジェクトにおいて効果的なスケーリングフレームワーク。シンプルさを重視し、全体の効率と一貫性を向上させるために活用される。

7. PMP試験で出そうな問題例と解答

  • 問題例: LeSSの特徴として正しいものはどれか。
    1. 各チームが独自のプロダクトバックログを持つ
    2. 各チームが共通のプロダクトバックログを使用する
    3. プロダクトオーナーは各チームに一人ずつ存在する
  • 正解: 2. 各チームが共通のプロダクトバックログを使用する

LeSSの導入に関する問題は、特にチーム間の調整やプロダクトバックログの共有に関する内容が出題されることが多い。そのため、チーム間の関係性やプロセスのシンプルさを理解しておくと良い。

投稿者 kojiro777

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です