これは 株式会社エス・エム・エス Advent Calendar 2025 の12月25日の記事です。 カイポケリニューアルプロジェクトでエンジニアリングマネージャーをしている荒巻（@hotpepsi）です。 今年の11月にLeSS' Yoaké 2025というカンファレンスに参加したり、認定LeSS実践者研修を受けてきました。これらのイベントや研修では、学習の重要性や、調整役を置かないことの意義が語られていて印象に残ったので、それについて書いてみます。
スクラムとLeSSの関係
以下の話の前提として、LeSSについて少し補足します。 LeSS (Large-Scale Scrum) は大規模スクラムを謳うフレームワークで、単一のバックログと一人のプロダクトオーナー、複数のチームからなります。LeSSはスクラムであると宣言しており、基本的にはスクラムの原則がそのまま適用されます。各チームは小さく、クロスファンクショナルなフィーチャーチームであることが望ましいです。
※ 用語について
- クロスファンクショナル
- 一般的には、チーム内に複数の職能の人たちがいる状態。LeSSの文脈では、チームに求められるスキルを持っているか、習得可能であること
- フィーチャーチーム
- 顧客中心の視点を持ち、価値のある機能（フィーチャー）を届けるための全ての工程に関わり、完成させることに責任を持つチーム。必然的にクロスファンクショナルであることが求められる。対義語は、特定領域を担当する「コンポーネントチーム」
LeSSでの学習とは
LeSSは、人は学習可能であるという前提に立ち、実験・学習・考察に振り切ったフレームワークとなっています。 研修では、繰り返し学習の重要性が語られました。ここでの学習は、チームの能力を高める全ての活動のことです。技術領域を広げたり業務ドメインを理解するなどの開発業務に関わる学習だけでなく、顧客インタビューや価値検証のような、要求分析の領域なども含まれます。すなわちLeSSが想定する組織学習とは、学習して影響範囲を広げていくことで、全体に対してオーナーシップを発揮して価値提供していくというものになります。
スクラムと全体最適
スクラムガイドではスクラムの外の世界についてあまり語られていません。一方、「大規模スクラム Large-Scale Scrum(LeSS) 」によると、LeSSでは「プロダクトが使われる現場」と「プロダクトが開発される現場」の2つの現場があるとしていて、チームの外側にも明確に意識が向いています。
一般に、プロダクトが成長して人が増えるとチームも増えていき、役割分担が生まれて境界ができます。そして次第に守備範囲が狭くなり、徐々に「プロダクトが使われる現場」から遠ざかり局所最適化されていきます。これに対してLeSSでは個人の学習能力に期待することで、自然な力学に逆らい、全体最適を目指します。ここで顧客価値とは「プロダクトが使われる現場」の価値であって、スクラムが注力することそのものです。なので全体最適に向かうというLeSSの原則は、スクラムと矛盾するものではなく、スクラムの明確化の一形態として解釈できるのかなと思いました。
LeSSそのものを学ぶ
開発者が学習の重要性を意識するためには、土台となる原則の理解が必要になります。研修ではいくつかのワークショップがあり、それを通じて、原則の理解や共感というのは、スクラムマスターがただ内容を紹介するだけで身につくものではなさそうだという感覚も得られました。 システム思考など実験・分析・改善活動などを通じて、開発者自身が議論し思考し、原則がどのように作用するのかを実感し記憶することで、原則とプラクティスが相互に結びつくと感じました。
調整役を置かないこと
LeSSではなるべく調整役を置かないことも推奨されています。ここでの調整役は、プロダクトオーナーやフィーチャーチーム以外の様々な役割のことです。例えば設計を専門的に行う人やチームが存在すると、調整コストや待ちの要因となります。そうした依存関係は仕事のパイプライン化を生み出し、スプリント内で作業を完結させることを困難にします。また、チームから見ると調整役が学習機会を奪っていることにもなります。そのためLeSSでは、チームの外部に存在する役割＝調整役がいないのが理想的です。
LeSSを導入してからの現在地
ここからは我々のLeSSの状況についてお伝えしたいと思います。カイポケリニューアルプロジェクトでは、チーム数が徐々に増え、複数のプロダクトオーナーと複数の職能別チームが存在する状況で、昨年LeSSを導入しました。
そこから徐々に、職能別チームからフィーチャーチームへ再編成し、少しずつLeSSの形に近づいている状況です。LeSS導入の少し前には、プロジェクトリードというチーム間のハブとなる役割を廃止したことがありましたが、これはまさに調整役を減らす活動だったのだと意義が再認識できました。
このあたりの導入による変化については、プロダクトオーナーやチームメンバーの声を座談会形式で記事化しています。
私自身はLeSSのマネージャーとしても活動しています。調整役にならないようにしたいなと思っています。
現在地としては、全体の半分くらいのチームがLeSSを実践しており、それ以外にも特定領域を担当するチームがいくつか存在します。またLeSS内部でも、プロダクトバックログ全体を管理するプロダクトオーナーの他に、特定ドメインのプロダクトバックログアイテムに責任を持つプロダクトマネージャーもいます。そうした状況で、このままLeSSを拡大していくのか、それともLeSS Hugeに向かうのか、などの議論も生まれたりしています。今後も、業務ドメインが複雑であるというプロダクトの特性を考慮しながら、どのようなLeSSに向かうのかを議論し実験していきたいと思っています。
LeSSの実践に興味のある方は、ぜひカジュアル面談でお話しましょう。以下のリンクからお気軽にお申し込みください。
