LeSS(Large-Scale Scrum) 2025/2 ver.1.02 Keitaro Matsukura 〜組織観点で、LeSSについてを抜粋してみた〜

注意 当資料はLeSSの公式サイトや公式トレーニングプログラムをベースにしています （基本的にはほぼ引用） ただ、全てが正しい解釈ではないという前提での閲覧をお願いします。

おさらい

Agileとは（おさらい） アジャイルとは、変化に適応しながら価 値を最大化するための考え方や方法論の 総称です。2001年に「アジャイル宣言」 としてまとめられ、個人と対話、動くソ フトウェア、顧客との協調、変化への対 応を重視します。代表的な手法にScrum （スクラム）やKanban（カンバン）があ り、継続的なフィードバックと短い開発 サイクルで改善を繰り返します。これに より、顧客のニーズに素早く対応し、高 品質な成果を提供できるのがアジャイル の強みです。 https://agilemanifesto.org/iso/ja/manifesto.html

チーム単位 例：スクラム、Kanban Agile Frameworkとは（おさらい） アジャイルフレームワークとは、アジャイルの考え方を実践するための具体的な方法論のこと です。チーム単位と組織（エンタープライズ）単位のものがあります。 https://medium.com/leadership-and-agility/the-most-popular-agile-frameworks-today-b60d2597f897 組織単位 例：SAFe、LeSS

Agile Frameworkとは（おさらい） 世界でのフレームワーク利用率。 組織単位（エンタープライズ）のアジャイ ルフレームワークは、毎年利用率が変動し ており、最近では独自のフレームワークを 作っていく企業が増えています。 チーム単位に比べ、組織単位は難易度が高 く、多くの組織で試行錯誤している様子。 （2023年調べ） https://digital.ai/resource-center/analyst-reports/state-of-agile-report/

LeSSもその一つ Agile Frameworkとは（おさらい） 世界でのフレームワーク利用率。 組織単位（エンタープライズ）のアジャイ ルフレームワークは、毎年利用率が変動し ており、最近では独自のフレームワークを 作っていく企業が増えています。 チーム単位に比べ、組織単位は難易度が高 く、多くの組織で試行錯誤している様子。 （2023年調べ） https://digital.ai/resource-center/analyst-reports/state-of-agile-report/

LeSSの概要

LeSSとは LeSS フレームワークの要素は、1 チームの Scrum とほぼ同じです。 役割—プロダクト オーナー1 名、チーム2 ～ 8 個、スクラム マスター1 名(1 ～ 3 個)。重要なのは、これら のチームが機能チームであるということです。機能チームとは、共有コード環境で連携して作業し、完了項 目を作成するために各自が全力を尽くす、真の機能横断型およびコンポーネント横断型のフルスタック チー ムです。

原理・原則 大事にしていることはいっぱいあるよう です。 ここより一部抜粋して説明

「More with LeSS」 プロダクト開発をする組織の構造をよりシンプルにしていくことが重要 無駄と間接コストをなくす 役割を減らす 成果物（プロダクト数）を減らす コンポーネントチームをなくす（減らす） より少ないプロセス（作業の進め方、学び方、意思決定含む） 原理・原則（抜粋）

「Systems Thinking」 組織構造や課題点を単一の問題として捉えるのではなく、長期で俯瞰する必要がある 様々な問題は、連動して起きている 短期的な解決策が長期的な問題になることがある 何も問題がなさそうに見えて、長期で見ると問題になることがある 個人や1チームなどの部分的な効率化や生産性向上だけに集中することは避けたい 原理・原則（抜粋）

「Customer Centric」 顧客中心で考える プロダクトは部分ではなく、全体で価値に繋がる 価値を高めるために、価値を目指せるチームづくりを行う 原理・原則（抜粋）

「Lean Thinking」 人に対する尊重 顧客に迷惑をかけない 製品開発よりも人の育成 無駄な仕事をなくす チームや個人が自分たちでオーナーシップを持って仕事の仕方を改善する 製品開発 長期的な良いエンジニアの確保 チームと部屋の見える化 起業家マインドのあるチーフエンジニア・プロダクトマネージャー 継続的な改善 現地現物 完璧への挑戦 原理・原則（抜粋）

「Transparency」 スクラムと基本は同じ考えを組織でもします 透明性がなければ、方向転換や適応は困難です。 透明性があれば、適応的な制御と改善が可能になります。 例えば 人 グループ プロセス ツール 環境 サイト そして組織設計 原理・原則（抜粋）

「Teams」 チーム 共有された成果物 共同責任 チーム外の関係を管理する責任 分散型リーダーシップ チームベースの組織 多機能チーム 長続きするチーム チームが決定を下す 構造（抜粋）

「Feature Teams」 チームは顧客中心のプロダクトを完成させるために、必要な知識とスキルを持つ。持っ ていないのであれば、必要な知識とスキルを習得したり、獲得したりすることが期待さ れる。 構造（抜粋）

コンポーネントチーム フィーチャーチーム 最大行数のコードを提供するために最適化されている 最大の顧客価値を提供するために最適化 「簡単な」価値の低い機能を実装することで個人の生産性の向上に重点を置く 高価値機能とシステム生産性（価値スループット）に重点を置く 顧客中心の機能の一部のみを担当 完全な顧客中心の機能を担当 チームを編成する伝統的な方法 - コンウェイの法則に従う チームを編成する「現代的な」方法 — コンウェイの法則を回避する 「発明された」仕事と永続的に成長する組織につながる 顧客重視、可視性、小規模組織につながる チーム間の依存関係により追加の計画が必要になる チーム間の依存関係を最小限に抑えて柔軟性を高める 単一の専門分野に焦点を合わせる 複数の専門分野に焦点を当てる 個人/チームのコード所有権 製品コードの所有権の共有 明確な個人の責任 チームの責任を共有する 「ウォーターフォール」開発の結果 反復的な開発をサポート 既存の専門知識を活用し、新しいスキルの習得レベルが低い 柔軟性を活用し、継続的かつ幅広い学習を行う ずさんなエンジニアリング手法で動作し、影響は局所的である 熟練したエンジニアリングの実践が必要であり、その効果は広く目に見えている 信じがたいことに、コンポーネントのコード品質が低下することが多い コードの保守とテストを容易にする動機を与える 実装は簡単そうに見える 実装が難しそう

「Organizational Structure」 典型的な LeSS 組織図は次のようになります。 構造（抜粋） 「製品グループの責任者」は組織によって呼び方が異なりますが、こ こではすべてのチームの階層マネージャーを意味します。 機能チーム— 開発作業はここで行われます。各チームは、スクラム マスターを擁する、機能横断型の自己管理機能チームです。 プロダクト オーナー (チーム) — これは一般に「プロダクト マネジメ ント」とも呼ばれます。プロダクト オーナーは 1 人の場合もありま すが、大規模な LeSS 組織では、プロダクト オーナーは他のプロダク ト マネージャーのサポートを受ける場合があります。この組織構造 の重要な点は、チームとプロダクト オーナーが同等であることで す。これは、役割間の力のバランスを保つために重要です。 未完了部門— 理想的には、この部門は存在しません。しかし、残念 ながら、チームがスプリントごとに実際に出荷可能な増分を作成でき ない場合があります。テスト、QA、アーキテクチャ、ビジネス分析 グループなどの未完了部門は、最初からチームに統合される必要があ るため、小規模な LeSS フレームワーク グループに存在するべきでは ありません。

「Communities」 実践コミュニティとは、あるテーマに対する関心、一連の問題、情熱を共有し、継続的 に交流することでその分野における知識と専門知識を深める人々のグループです。 実践コミュニティ (CoP) は自己組織化に根ざしています。組織図には表示されません。 参加は任意です。人々は学びたい、貢献したいという情熱を持って参加します。 組織は、部門やプロジェクトを形成するのと同じように、CoP を形成したりまとめたり することはできません。しかし、組織は CoP を推進し、ファシリテーター、IT インフラ ストラクチャ、予算などのサポートを提供することはできます。 構造（抜粋）

「Scrum Master」 チーム プロダクトオーナー 組織 開発実践 これらの重点分野は、時間の経過によって重点を置く範疇を変えていく。 最初はプロダクトオーナーとチームの改善、時間が経つにつれて、開発プラクティスや 組織の改善へ移っていく。スクラムマスターがボトムアップの中心になる。 構造（抜粋）

「Role of Manager」 従来との違い（やらないこと） チームが何に取り組むかの決定は、もはやマネージ ャーの管理下にはなく、プロダクト オーナーによっ て決定されます チームがどのように働くべきかの決定はチームに委 任されます。チームは自己管理チームであり、何を すべきかを一緒に考え、それをどのように実行し、 どのように改善するかを決定する必要があります。 LeSSのマネージャー チームとスクラムマスターが障害を取り除き、改善 できるよう支援する チームの仕事の改善に最も役立つ方法を見つけるた めに現場に赴く マネージャー（抜粋）

「Go See」 実際に現場に行ってみるということは、組織内で何が起こっているかを実際に理解することです。レ ポートやプレゼンテーションなどの間接的な情報に基づいた決定は、最善の決定ではない可能性が高 いことを認識します。しかし、実際に現場に行って、目の前の現実の状況を見て理解することに基づ いた決定は、より多くの情報に基づいたものになる可能性があります。 Go See を実践するとはどういうことか。人々、特に管理職、上級管理職は、オフィスや会議室ですべ ての時間を過ごしたり、会議、レポート、メール、報告ツールですべての情報を得たりしないという ことである。むしろ、実際に何が起こっているのかを知り、改善に役立てるために (間接的な情報から 生じる歪みを排除することによって)、管理職は実際の作業現場に頻繁に出向き、そこに留まり、自ら 見て理解する。インタビューで、トヨタのチーフエンジニアは、管理職が現場で Go See を実践する ことを主張した大野耐一氏の言葉を引用している。 マネージャー（抜粋） 目で見るな、足で見ろ…数字ばかり見る奴が一番悪い。[Hayashi08]

「Self-Management」 マネージャー（抜粋） LeSS は少なくとも自己管 理チーム（Self-Managing teams）を意味し、つまり プロセスと進捗の監視と管 理はマネージャーではなく チームに属することを意味 します。

組織の構造についての補足 「組織構造が文化を作る」 これは　“Larmanの組織的行動法則” の第4項目です。 組織に所属する人は、一時的な改善をすることに長けており、根本的／長期的な改善をなにも実施しない という傾向があります。私たちはこれを何度も見てきました。なぜこんなことが起こるのでしょうか？ Larmanの組織的行動法則ではこう考察しています。 組織は、現状の中間管理職、トップレベルマネージャー、専任の専門家など、既存の地位や権力構造 を変更しないよう、暗黙的な最適化がなされています。 1. 1の結果として、どんな変革を行おうとしても、意味的には現状と同じ意味の新しい単語を再定義した り上書きしたりする程度の内容に無力化されてしまいます。 2. 1の結果として、どんな変革を行おうとしても、「純粋主義」や「理論倒れ」などと冷笑され、「我々 特有の問題には、実用的なカスタマイズが必要」と言われて、弱点克服やマネージャー/専門家の現状 にメスを入れる営みから逸らされます。 3. 組織構造が文化を作る 4.

LeSSを導入するにあたって あなたは、なぜLeSSを導入したいのか？ 今、何が問題なのか？ 何を変えたいのか？ そして、その影響範囲はどこまでなのか？ LeSSというのは、（少なくとも一部分の）組織を大きく変える判断に なります。

どういう組織にしたいのか？ LeSSに限らず、 アジリティの高い組織を作るということは、どういうことか。 個人、チーム、マネージャー、組織すべてに影響を与える。 完璧な組織とは何かを、想像してみるしかないかもしれません。 その完璧な組織を議論した一つの結果がLeSSというフレームワークの ようです。 以上

参考 https://less.works/