LeSSフレームワーク入門

素晴らしいプロダクトはどのように作られるのでしょうか？

小さな素晴らしいプロダクトを作る時はチームと顧客が集まり数分毎に新しいバージョンに更新しながら、顧客の課題をテクノロジーによって解決していきます。

みなさんは既にこの方法が小さなプロダクトを作る際にもっとも良い方法だとご存知だと思います。

しかし、大規模な開発になると何が異なるのでしょうか？ 通常は、つまならない仕様書を他の部署から受け取り別の内部部門に仕事を引き渡します。 本当の顧客との接点はなく、マネージャーとだけ話しをし、プロセスに関しては口を出さず。プロダクト全体に対しての影響力は無く 目的を見失います。

一見、スクラムやアジャイルな手法を取り入れているように見えるかもしれませんが学習と適応ができない現実に打ちのめされる事になります。

小規模な開発の何が良かったのでしょうか？ 我々は顧客中心なアプローチを取れており。 プロダクト全体を把握していました。 最小限のプロセス、効率的なプロダクトと働き方の現状確認ができていました。それは自然なことでした。

小規模な開発の時に自然と行なっていた事を大規模にも適応する事はできるのでしょうか？ この問いに対する答えを数十年に渡りクレイグとバスは探求してきました。これが数百に及び実験とLeSSを作り上げる事につながったのです。

LeSSはアジャイルな開発などの理念を維持しながら作られたシンプルなフレームワークです

LeSSは12名のグループにも、数百名でも、数千人の規模でも使われてきました。 銀行、通信、ゲームからレーダーシステムの開発などにも使われています。

さて、LeSSはどのように機能するのでしょうか？ LeSSは複数チームのスクラムです。 1名のプロダクトオーナーがビジョンを提示し、顧客視点で作られたアイテムが入ったプロダクトバックログの優先順位を変えていきます。 1−４週間のスプリントサイクルで出荷可能な統合されたプロダクト作ります。 複数チームが共通のスプリントでこのプロダクトを開発します。開発は反復しながら、インクリメンタルに進められます。

各スプリントは、短い共通のスプリントプランニング1から始まります。 各チームはスプリントで実装するフィーチャーを選びます。 続くスプリントプランニング２では各チームはどう実装すのかの戦略を決める事になります。

スプリント中は自己管理するチームが自分たちが選んだフィーチャーを実装し他のチームと協働しながら出荷可能なプロダクトインクリメントを継続的に統合しながら作り上げます。 他チームとの調整はチームの責任となり、調整役は必要ありません。

スプリントの途中でチームは開発を一時的に止めてプロダクトバックログリファインメントを行います顧客やエンドユーザーと協働しながら将来のスプリントで行う事を明確にしていきます。 顧客とチームを繋げ、プロダクトオナーのビジョンや優先順位付けに関する負担を軽減します。

スプリントの終わりに共通のスプリントレビューを開催し、チームと顧客がスプリントでの成果物を探求します。そして、何を今後開発して行くのが良いのかを明確にしていきます。

各チームは検証と適応を行い、より良い働き方を適応していきます。 チームが自分たちの開発方法やプロセスに借り物では無く、オーナーシップを持つ事を望みますます。 オーナーシップが無いと継続的な改善には繋がりません。

LeSSではレトロスペクティブはチーム単位だけでは終わりません。チーム、プロダクトオーナー、スクラムマスターおよびマネージャーによってオーバーオールレトロスペクティブが行われシステムや組織全体の視点で高い価値を提供する上での課題を探求します。 LeSSを使って組織全体の検証と適応を行うわけです。

そして、このサイクルを繰り返します。実験と失敗を繰り返すことでより良い状態を目指します。

８チーム以上になった時には同じようなフレームワークではありますが、LeSS Hugeを使います。 しかし、毎スプリント１つの出荷可能なプロダクトを作る事に変わりはありません。

これがLeSSのフレームワークになります。数分でわかる、いくつかのルールがあるだけです

しかし、そのまま導入しようとしても、あなたの組織ではうまくいきません！ 現状の組織構造では・・・ 組織を変えて導入がうまく行く状態を作る必要があります。 これには近道も簡単なやり方もありません。あなたの組織構造はアジリティに向かう上で多くの障害がある状態になっている事でしょう。 LeSSのルールは多くありませんが、組織に対する影響は少なくありません。

LeSSの導入には数年かかるでしょう。既存組織のルール、プロセス、構造、習慣を変えて行く必要があるからです。

LeSS導入は単にプロセスを変えてルールを既存の組織構造に追加して終わりではありません。 現状を変えずに単に名前をアジャイルに変えているだけの組織が多くあります。 LeSS導入では表面的な変化では無く、従来のプロジェクト、プロダクト、役割、開発技法そしてマネージメント手法を変えて行く事になります

アジリティを実現して行くために、体制やポリシーを変えて行く必要があります。 例えば、チームはクロスファンクショナルになる必要があります。これは、ただコードを書いてテストをすれば良いという事ではりません。 ソフトウェアの設計、アーキテクチャ、ビジネス理解、UX/UIの設計スキルなども含まれます。 チームは顧客やエンドユーザーと要求の明確化をしていく事にも責任を持ちます。 また、チームはフィーチャーチームである必要があり、エンドツーエンドでの開発が可能である必要がありますフィーチャーとは単に内部コンポーネントだけの話しではありません。 LeSSのチームは幅広いコンポーネントに関わり、コードの共有所有をする環境の中で仕事をします。

多くの組織は問題を短略的に解決しようとして、複雑性を増す解決策を導入してしまいます。たとえば、チームのテスト不足によりプロダクション環境で問題が発生したとします。このような場合、マネージャーの典型的な対応としてはチームの誰かに新たな役割を命じたり、新しい部署を立ち上げたりして同じ問題が発生しないようにしたりします しかし、このような対応は非常に短略的な対応で。チームに責任を取らなくて良いと言っているようなものです。

プロセス、専門の役割、部署を作るなど他に責任をとってもらう事によりチームから責任を取り上げている事になるのです。 このようなアプローチをとると、従業員が心を持たないゾンビと化していきます。

私たちは複雑性を取り除く事で、多くの事を得られると考えます。 少なくする事でもっと多くを（More with Less） はハンドオフ、スプリントの準備、安定させる為のスプリントいわゆる「依存関係」、分析グループ、アーキテクトグループや様々なチーム外の仕事を減らしたり、無くしたりする事をおすすめします。

LeSSではスクラムマスターやマネージメントはチームの学習を支援します。 マネージメントは指示をするのでは無く、システム開発をする上での能力を上げる支援をするように変わる必要があります。

我々の経験では、LeSSフレームワークは必要最低限の構造を提供するものです製品開発を行うみなさんには製品の全体像を把握し、組織を価値提供と柔軟性を持つことにオーナーシップを持って頂くことが必要です。

また、実験的マインドセットを学ぶことになります。そして、（500以上の）既に行われた実験についてもフレームワークの中で、特におすすめするガイドとどのように導入するのか、10の原則について触れています。 そして、多くの実践者やコーチによるコミュニティーが生まれてきています。

みなさんには工業化時代の機械的な仕事を楽しめない組織から人間的で目的思考の組織になり、仕事を楽しめる組織へ招待したいと思います。しかし、その道のりは簡単ではありません。難しく、長く、苦痛を伴う道のりです。しかし、もしみなさんが、諦めずに、進めて行けば、組織はシンプルになりビジネス環境に応じて変化に対応でき、無駄を省き、もともと持っていた組織の可能性を解き放つことができます。