大規模スクラム [感想・レビュー!] LeSS (Large-Scale Scrum) はただのスクラムと考えれば良い

2019年1月30日に発売された大規模スクラム ーアジャイルとスクラムを大規模に実装する方法ー を読むことでLeSSの理解がかなり進みました。また、疑問に思っていたことにもきっちり答えてくれているので、LeSSをこれから学ぼうとする方には是非オススメしたい一冊です。

大規模スクラム

そもそもLeSSとは

スクラムをスケーリングする際のアプローチとしてSAFe、Nexus、DADとともに紹介されるフレームワークの1つ。Large-Scale Scrumを略してLeSSと呼ばれる。以下の図はLeSSを表すイメージ図です。

https://less.works より

LeSSについて疑問に思っていたこと

スクラムとしての理解はスクラムガイドエッセンシャルスクラムを読んで理解を深めていましたが、スクラムをスケーリングする際のフレームワークの1つであるLeSSについては、イマイチよく分かっていませんでした。というより、この本を読むまで全くと言って良いほど何も分かっておらず、なんとなく疑問に思っていたことは以下のようなハテナの連鎖でした。

  1. 大規模スクラムということだから、スクラムを階層構造にしたものではないか?
  2. プロダクトオーナーを階層化して組織化するのか?
  3. スクラムマスターは階層化できるのか?メインのスクラムマスターが必要なのか?
  4. チームはどのような単位に分割されるのか?
  5. マネージャーの役割は?

読んで最初に驚いたのは、この疑問のほとんどは本の前半で解消されたということ。また、作者の実験と経験から裏付けられた非常に説得力のある内容になっています。

1. 大規模スクラムということだから、スクラムを階層構造にしたものではないか?

まったく違いました。読み始めて8ページ目で理解できました。 LeSSは新しいスクラムでは無く、改善版でもない。「スクラムの原理・原則、ルールなどを大規模開発の文脈に可能な限りシンプルに適応したもの」とされています。 スクラムガイドラインの素晴らしいところがまさに現れているポイントだと思います。 ガイドラインは非常にシンプルかつ、理解しやすい内容になっています。それはつまり「抽象的」であるからだと思います。 抽象的だからこそ大規模開発にも適応できる、というのがLeSSを理解することで分かってきます。 つまり、LeSSを理解する前に、スクラムを理解しておくのが近道と言えるのでは無いでしょうか。 (エッセンシャルスクラムは必読だと個人的には感じています。)

2. プロダクトオーナーを階層化して組織化するのか?

これも違いました。9ページ目に説明されています。 1つのバックログ、1人のプロダクトオーナー、1つの出荷可能なプロダクト、1つのスプリントと定義されています。スクラムそのままですね。

3. スクラムマスターは階層化できるのか?メインのスクラムマスターが必要なのか?

当然、これも違うということがわかります。 LeSSはスクラムなので、階層はありません。全てフラットな関係性です。その中でスクラムマスターの責任も大きく変わりません。サーバントリーダーとして、スクラムプロセスの番人としての役割を担います。 通常のスクラムと異なる点として、1〜3チームに1人のスクラムマスターを配置するようです。また、大規模開発に導入するにあたり、時間の経過とともに重視するポイントが変わることも書かれており、なるほどと思わされます。
初期段階では

  1. プロダクトオーナー
  2. 開発チーム
  3. 組織
  4. 技術手法

の順番。
時間が経過してくると

  1. 組織
  2. 技術手法
  3. プロダクトオーナー
  4. 開発チーム

になります。 これは、スクラムチームが自己組織化されることでチームへの優先度が下がることを意味していますが、これをさらに加速するためには組織の構造、ポリシーを改善しない限りは頭打ちになるということのようです。 通常のスクラムと比べるとスクラムマスターの行動範囲はより大きくなるように思います。

4. チームはどのような単位に分割されるのか?

スクラムで開発チームは「クロスファンクショナル」、つまりプロダクト開発を進めるために必要なスキルを全て持ち合わせているチームであるべきとされています。 それを大規模開発に当てはめた場合、どのようにチーム分割するのでしょうか。 LeSSでは「顧客価値中心」でクロスファンクショナルなチームとされています。比較対象としてあげられているのが「コンポーネントチーム」です。コンポーネントチームは価値よりアウトプット量への注力であり、顧客価値に直結していません。これはスクラムの目的に反します。 顧客価値中心であるフィーチャーチームを優先することで、受け渡しの無駄を除去し、作業がより価値の高いものにできる。
これ以上綺麗な分け方はないですね。

5. マネージャーの役割は?

スクラムではコントロール型マネージャーの存在は良しとされていないように、LeSSでも同じです。ただ、マネージャーを不要とするのではなく、「任意」としています。もし今いないのであれば、無理に作る必要もないとのことです。 従来組織のマネージャーの役割、責任はプロダクトオーナーと開発チームに委譲されるべきで、そうすることにより自己組織化が促進されます。その状態でマネージャーが担うべき重要な役割は何になるのでしょうか。 それは「改善する能力の向上および必要となる組織変更の支援」となります。スクラムマスターやチームでは超えることのできない組織の壁をマネージャーが支援することで超えていきます。チームが一段上のパフォーマンスを出すためには組織の壁が重荷となることがあります。それを越えるために支援するのがマネージャーの役割となります。 では、そのためにマネージャーに求められるスキルとは何になるかが疑問となります。それに対しては「現地現物」であると答えてくれています。 現地現物とは、「習慣的に現場に行き、実際の問題を真に理解し、組織向上に生かす」ことです。現場で問題の分析は行わず、問題の原因に迫る偏見のない質問をすることが求められています。もしマネージャーの責任として問題解決が課せられている組織の場合、このスキルを発揮する難易度は高いかもしれません。

所管

LeSSの概念としてはスクラムとなんら変わらないと理解して問題なさそうですが、大規模開発に適合できるように「全体スプリント計画」と「全体振り返り」がスプリントの最初と最後で行うようになっています。個別チームとしてはスクラムを廻しつつ、複数チームでプロダクト全体の透明性、検証、適合を維持するための考え抜かれた工夫を感じ取ることができます。概念を理解すれば、あとは実践しながら、学びながら改善していくことで、自分の組織にあったフレームワークへと変化させていくのが良いと思います。

最後に

スクラムを理解することは簡単でも、実践するのが難しいのと同様で、LeSSの実践の難しさは計り知れないと感じています。それは、組織変更を行なうに等しいためです。そこで一番苦労することになるのがスクラムマスターだと思いますが、書籍の中ではスクラムマスターのサバイバルガイドの1つとして「正気を保つ」をあげています。「忍耐と低い期待」「永続性」「勇気」「ユーモアのセンス」「寛容と謙虚」がその構成要素です。言葉の意味するところの解釈は人それぞれかもしれませんが、書籍の説明を読み進め、解釈することで複雑な世界を生き抜くヒントとなるのかもしれません。