# 何故 LeSSなのか? LeSS Complete Picture, 3-minute introduction to Large Scale Scrum - YouTube Tap to unmute [LeSS Complete Picture, 3-minute introduction to Large Scale Scrum](https://www.youtube.com/watch?v=cvz4364pC0g) [Michael James](https://www.youtube.com/channel/UClZWfQtgi5d5pvwEq5v9XTw) Michael James1.77K subscribers 従来のシーケンシャルなライフサイクルの開発はうまく行きません。これらは小さいプロダクトにも、大きなプロダクトにも、あまり効果的ではありません。 2001年、アジャイル開発、特にスクラムは、ソフトウェア開発に革命を起こしてきました。 しかし、大規模なグループにアジャイル開発を適用する方法について尋ねると、「知らない」、「小さいチームにしか使うな」、「スクラムはチームレベルで行え」のような答えしか返ってきません。 どの解答も有用とは言えません。開発に人員を追加することを避けられればベストであるのは事実ですが、大規模なプロダクト開発がなくならないのもまた事実です。 そのため、我々はなんとかうまくやる方法を見つけないといけません。 私たち（Craig と Bas) は 長年さまざまなソフトウェア開発にあらゆる役割で関わってきました。 従来のシーケンシャルなライフサイクル、Unified Process、CMMi などなど。 **これだ** とは思えるようなものはありませんでしたが。 スクラムは、その一方で、単一チーム開発に関する適切な方法に感じられました。そのため、疑問は「スクラムの強みを **失わず** にスケールするにはどうしたらいいか」となりました。 ## LeSSは大規模スクラム スクラムの強みは何でしょうか？ それは簡単に答えられる質問ではありません。もちろん、スクラムのコンセプトと理論（ [透明性](/content/jp/less/principles/transparency/index.html)、 [経験的プロセス管理](/content/jp/less/principles/empirical-process-control/index.html)、繰り返し開発、 [自己組織化チーム](/content/jp/less/management/self_managing_teams/index.html) ）は必須です。しかしながら、これらの理論はかなり昔から存在しているので、スクラムの成功を説明しきれません。 たくさんの議論を重ね、我々は結論づけました。 スクラムは抽象的な理論と、具体的な実践の間にある、絶妙なスイートスポットを打ったのです。 つまり、 [大規模なスクラムをスクラムたらしめる](/content/jp/less/principles/large_scale_scrum_is_scrum/index.html) には、同じように絶妙なバランスを見つける必要があるのです。 言い換えるとこうなります。 大規模なグループのために、LeSSは 定義された具体的な要素と、経験的プロセス管理の間にある、絶妙なバランスを保つスイートスポットを狙います。 これらから以下のような決断が必要になります。 - LeSSはシンプルであるべき スケーリングにあたっては、役割や成果物やプロセスなどを追加する傾向にありますが、これらは避けるべきです。プロセスは、プロダクトグループにより経験的に作られるのですから。多くの他のスケーリングフレームワークは、この「定義されたプロセスを用意する」という罠に落ちています。LeSSにおいて我々は、この罠を避けたいです。 - LeSSはスクラムの規模拡大 スクラムをスケールしたフレームワークの部品として使うより、スクラムそのものに目を向け、一つ一つの要素について、「何故それがあるのか」、「もし私たちが複数チームを擁するとき、どうやって同じ目的を大規模なスケールで達成できるか」という問いかけをするべきです。 - 仕立てるより拡大する プロセス開発に共通するコンセプトは、普遍的で包括的なフレームワークを定義し、状況に合わせて仕立て上げることです。しかし、人々は自分たちの状況には全部必要と仮定してしまうので、このやり方はうまく行きません。この仮定はしばしば、肥大化したプロセスを生み出します。LeSSは最小の状態を保つべきです。我々は、スケーリングに「もっと」が必要なことは認めたうえで、付加要素で LeSSを「汚染」することなく、異なるフレームワークに分離しました。それが [LeSS Huge](/content/jp/less/less-huge/index/index.html) です。 ## LeSSの概要 LeSSを理解するには以下の図による説明が役立ちます。 [ Download PDF ](/content/img/framework/less-complete-picture.jp.pdf) [ Download PNG ](/content/img/framework/less-complete-picture.jp.png) ## LeSSは経験を用いる 我々が執筆した最初の2冊の本、 [Scaling Agile and Lean Development](http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961) と [Practices for Scaling Agile and Lean Development](http://www.amazon.com/Practices-Scaling-Lean-Agile-Development/dp/0321636406) において、我々は大規模スクラムを 理論に基づく経験の集合と規定しました。 ベストプラクティスなんてものは存在しません。 あるのは、特定の状況において有用なプラクティスだけです。{: .box_top_bottom .text_centered_bold } よって、これらの本は我々の経験が詰まっています。 あるものは取り組む事を推奨し、あるものは避けることを推奨し、残りは特定の状況で役立ち、それ以外の状況で悪手になります。このアプローチはうまく行き、多くのポジティブなフィードバックを得ることが出来ました。 私たちはまた、やや困惑していた人たちからもフィードバックを得ました。 彼らは、状況にあまり依存しないルールをもっと必要としていました。 このフィードバックに基づき、私たちは　守、破、離　の学習モデルに反映しました。 このモデルは新たなことを学ぶときに学習者が通過する過程を示しています。 - 守 \- ルールを守り、基本を学ぶ - 破 \- ルールを破り、状況の適不適を見つける - 離 \- 熟練し、自らの道を見つける 私たちは、我々の過去のスケーリング手法が「守」にあたる内容を提供できていないことに気づきました。そして、大規模なプロダクト開発でアジャイルを始めようとした人々を混乱に陥れることになりました。このことは、他の、より予測的なスケーリングアプローチが基本レベルのアドバイスをし始めたとき、より明白になりました。 ## フレームワークとしてのLeSS LeSSは、単なる理論と経験の集合以上のモノです。LeSSはフレームワークとルールも提供します。 [LeSSのルール](/content/jp/less/rules/index/index.html) は、何がLeSSか（何がLeSSではないか）を定義し、LeSSを適用するための具体的なフレームワークを提供します。LeSSのフレームワークでは、プロダクトグループは実験を適用し、その状況下でどんなやり方が最適かを見つけることが出来ます。 これは3つめのLeSS本（ [Large-Scale Scrum](http://www.amazon.com/Large-Scale-Scrum-More-Craig-Larman/dp/0321985710)）の基本でもあります。 本書では、LeSSは以下のように定義されています - LeSSのフレームワークを提供するルール（より大規模なプロダクトには、LeSS Huge フレームワークも） - LeSSを適用するためのガイド - はじめの2冊の本で得た実験的要素 これらのやり方は、LeSSがシンプルでスクラムの性質に忠実であることを保証します。 そして、スクラムと同様に、LeSSは開始するための十分な具体的なプラクティスと、 スケールするための十分な柔軟性と力を提供します.