LeSS(Large Scale Scrum)の実践手引
Scrumは、基本的に１チームを前提に定義されています。Scrumを組織や会社全体(数十名～数千名規模）にスケールするには、ちょっとした工夫が必要です。私自身は、それぞれ６０名、１２０名の組織でしか、LeSSを実践したことがありませんが、それでも「経験したことがある」ことは強みになると思います。ここではLeSSを実践するためのポイントと注意点をまとめました。
LeSS is Scrum !!
LeSSはScrumの上に成り立つフレームワークです。まずは１チームのScrumが適切に運用できている必要があります。以下の問いに全力で答えてください。
・チームは、インクリメントをスプリント毎に出せていますか？
・完了の定義はありますか、チーム（PO、開発チーム、SM）が完了の定義を絶えず意識していますか？バリューストリームを意識していない開発チームではLeSSへの移行は難しく、メリットを享受できないかもしれません。
・リファインメントは適切に運用されていますか？プロダクトの中長期計画は、チームの皆が把握できていますか？
・プロダクトオーナーはいますか？一人でしょうか？ほかのロールと兼任していないですよね？
・開発チームは、スクラムマスターが声をかけなくても、スクラムのイベントを自主的に行なっていますか？イベント内のファシリテーターも開発チームの中から自発的に出てきていますでしょうか？
いずれもYESなら、良い傾向だと思いますので、LeSSに挑戦する土台があるかもしれません。
LeSSには、2から8チーム向けの”LeSS”と、9チーム以上の場合の”LeSS Huge”があります。このあたりも説明します。
LeSS is More !!
LeSSは、Scrumを基本として、いくつかのイベントが足されたものです。ただそれだけです。LeSSの本には色々な手法が載っていますが、過度に複雑にする必要はありません。Scrumと一緒で、理論は簡単だが、実践は困難です。
誤解を恐れずに言いますと、LeSSは、Scrumに以下のイベント（セレモニー）を足したものです。
LeSS ＝ Scrum ➕
全体リファインメント( Overall Product Backlog Refinement )、
全体振り返り(Overall Retrospective)、
スプリントプランニング1、2（Sprint Plannning1,2)
全体振り返りは、必要なときのみ実施すれば良いことになっていますが、おそらく必ず実施することになります。組織課題・会社課題を議論する場となるからです。これらの課題がなくなることは想像・・・できませんよね？
全体リファインメント、全体振り返り、スプリントプランニング1は、開発チームの代表者が出席すれば良いのですが、慣れてくるまでは開発チーム全員で出席しても良いと思います。
イベントが増える分、開発にかける時間が少し減ります。1週間スプリントなら、1週間に2〜4時間は減ると思います。しかしこれは、大規模で開発するためには必要な投資です。複数チームでScrumを実施する場合、いわずもがな、情報共有が非常に重要になります。情報共有というのは、単にメールやSlackで一方的に通知を送って終わりというものではなく、アジャイル宣言にあるように、対話が非常に重要になります。LeSSはアジャイルになるための手段を、最低限提供してくれます。LeSSでは、チーム同士やプロダクトオーナー、ステークホルダーと、より顔を合わせる機会が増えます。開発チームは、直接ステークホルダーや顧客と顔を合わせ、自分たち自身でビジネスを分析・実装・シップして、顧客からのフィードバックを直に受けるようになっていきます。よりユーザの価値にフォーカスしていきます。それがLeSSなのです。
LeSS のサイクル（Scrumとの比較)
LeSSは、Scrumにいくつかのイベントを足したものだと書きました。それぞれのイベントの詳細を記載します。
Overall Product Backlog Refinement(全体リファインメント)
全体リファインメントでは、開発チームの代表者（各チーム1～2名)、PO、SM、ステークホルダー、（できればユーザーも）が集まり、プロダクトの中長期計画を練ります。アウトプットは優先順位のついたプロダクトバックログです。直近２～３スプリントで開発チームが動ける程度の粒度にまで、プロダクトバックログアイテムを細かくします。１週間スプリントで、約２～３時間かけます。スクラムマスターはファシリテーターとなります。POとステークホルダーがメインで会話するのではなく、開発チームとステークホルダー、（できればユーザー）が会話をします。POはあくまでプロダクトバックログの優先順位の最終決定を行うだけであって、プロダクトバックログアイテムの作成・更新は、開発チームがメインで行います。プロダクトバックログアイテムの更新だけを行う時間ではありませんので、POはプロダクトのビジョンを語っても良いと思います。（いきなり語りだすと困りますが）。スクラムマスターは、対話に参加できていない人がいないか、何か発言したそうだけどできていない人がいないかなどを俯瞰し、場をファシリテートします。人数が多すぎる場合は、場が混乱しないように（フィッシュボウル等を使う）します。タイムボックスも非常に重要なので、あらかじめアジェンダとゴールを作っておくと良いと思います。プランニングポーカー等で見積もりを行う際も、なるべく時間が短くできるように色々な手法を使います。
Overall Retrospective(全体振り返り)
Overall Retrospectiveでは、組織や会社全体の改善に向けての話し合いをします。このネーミングに注目してください。Sprint Retrospectiveではありません。スプリントの振り返りではない、ということです。各開発チームの振り返りは別にあります。各開発チームで解決できない課題を持ち寄ってもいいですが、課題があったら、全体振り返りを待たずして解決に向けて動き出した方がよりアジャイルだと思います。参加者は、プロダクトオーナー、各開発チームの代表者、スクラムマスターです。スクラムマスターは、最初のうちはファシリテーターをします。
Sprint Planning 1, 2
１チームのScrumでは、スプリントプランニング１，２を分けて運用しているチームもあれば、分けてないチームもあると思います。LeSSでは明確に分けます。
Sprint Planning1では、これから始まるスプリントにおいて、どのチームがどのプロダクトバックログアイテムを取っていくかを決めます。理想的には、これだけを行います。15分程度で終わります。この場でアイテムの分割や見積もりが始まると混乱します。
Sprint Planning2は、１チームのScrumのSprint Planningと同様です。開発チームが主導で、このスプリントの計画を建てます。１週間スプリントでは所要時間はおよそ４時間～８時間かけます。
LeSSのスクラムマスター
LeSSのスクラムマスターは、より組織やチームに力点が移ります。チーム間の協調はスクラムマスターの仕事ではありませんが、LeSSをはじめた最初のうちはそのようなことも必要です。継続して開発チームにScrumやLeSSのあるべき姿、Agile Mindsetを伝え続ける必要があります。
以下のような仕事があると思います。
・ScrumやLeSSの情報を伝え続ける。
・開発チームに入る妨害から、開発チームを守る
・チームを良く観察し、チームが楽しく働けているか気にかける。
・プロダクトのバリューストリームを明確（見える化）にし、完了の定義を拡張できるように施策を検討し、チームに伝える。一緒に考える。
・プロダクト、会社の課題をシステム思考で検討し、局所最適ではなく、全体最適になるように検討する。
・プロダクトオーナーが、プロダクトバックログの優先順位の最終決定のみ行えるようにするにはどうすれば良いか考え、施策を実行する。
・チームがチーム同士で協調できるように支援する、なんらかの壁がある場合、なぜそれがあるのか考え、本質的に取り除く。
・必要であれば全体振り返りのファシリテートを行う。（事前準備も含め）
・必要であれば全体リファインメントのファシリテートを行う。（事前準備も含め）
・HR(Human Resource Department)と協力し、組織や会社をアジャイルな状態にするにはどうするか検討し、施策を実行する。
・アジャイルマインドセットを耐えず伝え続ける。
・よりよい状態はどのような状態か伝え続け、そのためのGapを分析し、施策を実行する。
・良きコーチとして、積極的に何もしないこともある。
LeSSのスクラムマスターは、非常に大変です。兼務は、まずできないと思います。
POはただ一人、よりチームに権限を委譲しよう
LeSSにおいても、依然変わりなくPOは一人です。よりLeSS全体のROIを考えるようになります。そのため、プロダクトバックログの作成に割ける時間は減っていきます。プロダクトバックログの作成・更新はほとんどチームに任せるようします。もし考え方についてチームにトランスファーが必要であれば、トランスファーします。POのディシジョンツリーをチーム代表者とともに作ってみて、POの決定はどのような指針で行われるのかを皆でシェアして、それを壁に貼っておいても良いと思います。トレードオフスライダーで優先順位の決め方を示しても良いと思います。そのためにはPOはより密にチームと顔を合わせて対話する必要があります。より雑談が増えるかもしれません。特定の人物と密に相談をするというよりも、LeSS全体と相談するような形です。よりコミュニケーション能力が必要になります。全体リファインメントでは、対話の中心はステークホルダー・ユーザーと開発チームに委譲していきます。
POは、LeSS全体を観て、ROIを最大化するようにプロダクトバックログの優先順位を最終的に決定することです。
既存組織へのLeSSの適用
強力なボトムアップとトップダウン、中間管理職の深い理解が必要となります。全方位から攻める必要があります。いずれも、どれか一つだけだと、長続きしません。LeSSの導入は、数ヶ月はカオスになりますがあらかじめそれを伝えておくと良いと思います。ただ、安定を求めていると革新もありません。
変化に抵抗するのは人間ですから、当たり前のことです。ただ変化しないことが最も危険であるということをご理解いただく必要があります。このあたりは、昨今、マネージャー層は実感として出てき始めていると思いますが、メンバー層ではまだ浸透してない企業もあるかもしれません。
実際に、管理職などの役職は、LeSSの文脈ではでてきませんが、管理職があってもLeSSを導入することはもちろんできますが、理想を言えば、階層組織を無くすことが良いと思いますが、ある程度成熟した組織じゃないと難しいかと思います。この辺はまだ試行錯誤段階です。
LeSS Huge
LeSSは、２～８チームを想定されており、LeSS Hugeは9チーム以上を想定されています。LeSS Hugeでも、LeSSのときのままスケールできればそのままでも良いのですが、LeSSにより、権限委譲の進んだプロダクトオーナーでさえボトルネックになってきます。ここで、はじめて、Area Product Ownerという概念が生まれます。LeSS HugeとLeSSの主な違いは、Area Product Ownerだけです。Areaが分かれると、全体リファインメントとスプリントプランニング１は、Area毎に行うようになります。スプリントレビュー、全体振り返りは複数Areaをまたいでやることもあります。
Product Backlogにエリア属性をつける
Product Backlogをエリア毎に分けます。エリアは、技術視点ではなく、顧客視点でプロダクトバックログアイテムに属性をつけて、グルーピングしたものです。エリア内で優先順位をつけます。各エリアは、開発チームが４チーム以上存在することが推奨されています。
Area Product Owner
各エリアの優先順位の最終決定権をもつ、Area Product Ownerを１人つけます。ここで大切なのは、Area Product Ownerの決定が絶対です。そのエリアに関しては、Area Product OwnerがProduct Ownerです。決定の齟齬を恐れるのであれば、Areaを作らないほうがいいと思います。
Agile Mindset
Agileとは何か、私は現時点(2019/9)で、こう考えます。
みんなが、会社に行くのが楽しみすぎて、わくわくして夜眠れないぐらい仕事が楽しい状態。（実際に眠れないと困るのですが）
LeSSやScrumはそれを実現するひとつの手段であると思っています。
まとめ
LeSSは、Scrumにいくつかのイベントを足したもの、LeSS HugeはLeSSにAreaを追加したものになります。ルールは非常にシンプルですが、実現は困難を伴います。それでもやる価値はあり、よりアジャイルになり、毎日が喜びに変わる・・・かも知れません。
この記事が気に入ったらサポートをしてみませんか？