どうも皆さんこんにちは。
鞍馬ぽめると申します、よろしくお願いいたします。

はじめに

今回は 大規模スクラム Large-Scale Scrum(LeSS) - アジャイルとスクラムを大規模に実装する方法 という本を読了したので、その感想を書いていこうと思います

なんの本？

スクラム開発を大規模なプロダクト開発で実践するためのフレームワークである LeSS について解説してくれている書籍です
LeSS については LeSS のサイトでもその内容についてまとめられています

「スクラム開発は大規模なプロジェクトには向かないのかもしれない、、、」
大規模なプロダクト開発にスクラムを導入しようとして挫折した人であれば、
誰しもがこんな悲しい思いを抱いたことがあると思います

実際にぼく自身も同じ経験をしたことがあります

LeSS はそんなぼくらにとってひとつの回答です
スクラムの強みを失わずにスケールするにはどうしたらいいか を考えて編み出された、大規模プロダクト開発にスクラム開発を活かすためのフレームワークになります

※ 今回学んだ LeSS の内容については、かなり長くなってしまうので、今後の記事で何回かに分けて書いていこうと思います

個人的にはぜひとも試してみたいと思いました
ぼくは本当に本を読むのが苦手で、まだまだ内容の把握が曖昧な状態ではありますが、、笑

というのも、 LeSS のフレームワーク自体は基本的なスクラムとほとんど変わらず、
非常にシンプルでイメージしやすかったからです

スクラムのプロセスとの目立った違いは

の 2 つくらいで、あとはひたすらに それ、そもそも基本的なスクラムでも気をつけないといけないことだよね ということが、より強調して述べられていたように感じました

また、頻繁に ガイド が出てきますが、
これは実践してこそ、その有用性に気付かされるものではないかと感じました

LeSS は（著者の経験上）最大で 8 つのスクラムチームまでスケールすることが可能ですが、
それを超える超大規模な場合は LeSS Huge という方法に切り替えることを推奨してました

一般的にスクラムチームにおける開発チームメンバーの人数は 3 ~ 9 人が良いと言われているので、
8 チームを超えるとなると、場合によっては 72 人以上が関わっているプロダクト開発ということですね、かなり大規模だと思います

個人的な所感ではありますが、この導入はなかなか難しいものかもしれないと感じました

LeSS Huge は エリア と呼ばれる単位で対応領域を分けることで大規模なプロダクトに立ち向かう形ですが、
どうしても隣のエリアが見えにくくなってしまったり、中央集権的な構造になってしまったり、そんな懸念が浮かびます

LeSS Huge を導入している企業さんもいくつかあるようなので、
どうやって実践しているのか実際に見てみたいですね

LeSS や LeSS Huge をすでに導入し成功している企業さんが、スライドや記事を上げてくださっているようなので、
そういうものから書籍じゃわからない実際の部分を学んでみようと思います

また、自身の関わっているプロダクト開発でも導入できるタイミングを伺って、試せそうであればぜひ提案していこうと思います

本書で学んだ LeSS の具体的な内容については、このブログで少しずつ共有していきたいと考えています

今回も最後まで読んでいただきありがとうございました