この記事は「株式会社エス・エム・エス Advent Calendar 2025」24日目の記事です。
昨日の記事は、@_atsushisakaiの「意思決定と学習をスケールさせるエンジニアの採用」でした。
はじめに：認定LeSS実践者研修に参加した
先日、「認定LeSS実践者研修（CLP）」を受講してきました*1。講師はLeSS（Large-Scale Scrum）の考案者の1人であるBas Voddeさんでした。
現職ではLeSSを一部で取り入れており、自分自身もLeSSを実践するなかでの疑問や悩みを多く持った状態で参加しました。また、同じプロダクトの開発に携わっているプロダクトマネージャー、エンジニアリングマネージャー、開発者、QA、デザイナーも一緒に参加したので、研修中に自分たちのプロダクトや組織の実際に即してディスカッションをしたり、講師に質問をしたりすることもできました。
今回の記事では、研修を通じて学んだことの中でも、「学習」と「チームの担当範囲」の関係について、学んだことや現時点での自分の考えを書いてみようと思います。なお、LeSSについての一般的知識については公式Webサイトや（やや公式Webサイトに比べると内容が古いですが）以下の書籍を参照してください。
そもそもLeSSは何を目指しているのか？
LeSSはいわゆる「大規模スクラム」のフレームワークとして知られています。スクラムやアジャイルを複数チームやより大きな組織の中でやろうとするフレームワークには色々ありますが、そのなかでもLeSSは、
- 価値提供と柔軟性を最大化しようとしている
- 効率や生産性を最大化しようしているのではない
ものだとBasさんは言います。その上で、LeSSは複数のアプローチで「価値提供」「柔軟性」という目的に向かおうとします。それらのアプローチには、リーンから大きな影響を受けているものなどがありますが、中でも一番特徴的なのは、LeSSが学習による個人/チームのスキルの拡張を非常に重視している点だと筆者は理解しています。
なぜ学習による個人/チームのスキルの拡張が重要か？
Basさんによると、LeSSが依拠している一つの洞察は、
- 価値提供や柔軟性の最大の制約は人のスキルである
というものです。人のスキルが広ければ広いほど、ビジネス上の優先順位に正しく準拠してプロダクト開発を進められるし、プロダクト全体の視点をもって開発ができるということです。この洞察に基づいて、LeSSは、「学習によってスキルの制約を打破することで、価値提供や柔軟性を最大化する」ことを目指しています。もちろん、「全ての人が全てを学べるわけではない（特に大きな企業では）」（Bas Vodde）という留保もありながら、可能な限り学習によってスキルを広げていくことを推奨しています。
「チームの担当範囲をより広くする」という考え方
学習によってスキルを広げていくという観点から、LeSSは、「チームの担当範囲をより広くする」ことを推奨します。
LeSSにおいては、1つのプロダクトバックログを全てのチームが共有し、アイテムをどのチームが取るかはスプリントプランニング1まで（原則としては）決まりません。各チームはプロダクト内の特定のコンポーネントやサブシステムを「担当」することはせず、スプリントプランニング1において取ることになったアイテムの実装に必要な修正をすべて行うことが理想です。
この考え方は、ソフトウェア開発の世界においてはやや異色に感じられるかもしれません。たとえば、『チームトポロジー』では、チームの認知負荷を高めすぎないように、担当する範囲を限定せよという主張が展開されます。『チームトポロジー』におけるストリームアラインドチームの設計においては、なるべく独立してデリバリーまでを行えるように設計することを推奨されてはいるものの、基本的には担当範囲をなるべく狭くしようというのが『チームトポロジー』の発想であり、LeSSとは発想が逆であると言うことができると思います。
認知負荷理論とLeSS
認知負荷理論とLeSSとの関係については元々気になっていたため、研修に先んじて参加したLeSS' Yoaké ASIA 2025において、LeSSトレーナーのViktor Grgicさんに質問をしていました。そこでは、「認知負荷というのは動作記憶（ワーキングメモリー）についての概念で、新しいことを学習するときの制約に認知負荷の限界がなることはあっても、学習して長期記憶に入るものの限界があるというわけではない」という回答がありました。
※なお、Viktorさんの認知負荷についての見解は、「Rethinking Cognitive Load in Large-Scale Software Development」と題する過去のイベントで使用されたスライドや、その中で紹介されている書籍『Navigating Complexity of Cognitive Load in Software Product Development』で詳しく知ることができます。
※認知負荷理論についてはkangetsu_121さんの「認知負荷および認知負荷理論 (Cognitive Load Theory) をもう少し正確に理解するための心理学研究・知見の紹介」がソフトウェア開発者向けでおすすめです。
自分の理解するところによると、認知負荷理論は確かに学習やコンテキストスイッチについての示唆を与えてくれるものの、それを理由にチームの担当範囲を狭く限定し固定する必要まではなく、チームの担当範囲の設計としてはなるべく広く持たせた上で、実際のスキルとのギャップは少しずつ学習によって埋めていくことがLeSSのアプローチだということかと思います（Viktorさんの書籍では、コンテキストスイッチのコストの観点からも、むしろコンポーネントチームは避けるべきだという議論がなされています）。
担当範囲を限定するチーム設計の困難
前述のように、『チームトポロジー』におけるストリームアラインドチームの設計においても、極力他のチームに依存せずにデリバリーができるようにすることが求められています。
ストリームアラインドチームとは、価値のある単一の仕事のストリームに沿って働くチームのことだ。ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザーペルソナの１つのような場合もあるだろう。さらに、なるべくそのチームだけですばやく安全に顧客やユーザーに価値を届けられるように、チームに権限が委譲されている。他のチームへの仕事の引き継ぎは必要ないということだ。（『チームトポロジー』p. 144）
とはいえ、優先されているのはチームの認知負荷の制限を超えないようにすることであり、ソフトウェアアーキテクチャーの設計もそこに向けて最適化する、というのが『チームトポロジー』の考え方です。
モノリシックアーキテクチャーかマイクロサービスアーキテクチャーを選ぶのではなく、ソフトウェアをチームの認知負荷の制限に合った形に設計するのだ。そうすることで初めて、持続可能で安全かつすばやいソフトウェアデリバリーが実現できる。（『チームトポロジー』p. 90）
チームの認知負荷の制限を超えないように担当範囲を限定するにあたって用いられる考え方が「節理面」です。「節理面」の候補としては、最も代表的なものであるビジネスドメインのコンテキスト境界の他に、変更のケイデンスやパフォーマンス、ユーザーペルソナなど様々なものが書籍の中では挙げられています（Chapter 6）。
もちろん、こうした議論を参照しつつ、ユーザーやビジネスからのソフトウェアへの変更要求に単一のチーム（が担当するソフトウェアの範囲）で極力対応可能にするのは設計の腕の見せ所ではあります。しかしながら、それを完璧にやりきるのは現実には困難で、特にソフトウェアを新しく作っていくフェーズや、作ったソフトウェアが更に成長していく場面においては、当初予想していなかった要求が生じることは避け難いと感じています。
そして、他のチーム（が担当するソフトウェアの範囲）との連携が必要になる場面においては、（『チームトポロジー』でいうところの「コラボレーションモード」の場合は）普段は担当していない部分についてのドメインや技術的な知識が要求されて認知負荷はかえって高まったり、知識やコンテクストの共有から始まることで時間がかかったりしますし、（「X-as-a-Serviceモード」の場合は）待ちが発生したり意図の食い違いが発生したりしやすいのではないかと思います。『チームトポロジー』では、特にコラボレーションモードが頻繁に、あるいは継続的に発生することは問題の兆候だと指摘されています。
インターフェイスの確立や改良のために、ときどき短時間もしくは軽度にコラボレーションするのはよいが、継続的にコラボレーションが必要になるなら、ドメインの境界やチームの責任が正しくないか、チーム内のスキルの組み合わせが正しくないことを示している。（『チームトポロジー』p. 225-226）
現時点での所感
新しいスキルや知識を学習するのには時間はかかるので最初から全部やるのは難しい一方で、チームの担当範囲を限定するアプローチにも難しさがあるとすると、どうするのがよいのでしょうか。
状況によって実際に取るべきアプローチは変わるであろうことから、この問いに対して抽象的に答えることにはあまり関心がないのですが、個人的にはLeSSの目指しているところ（スキルを拡張することで価値提供や柔軟性を最大化する）には妥当性があると思いますし、チームの境界（ソフトウェアの境界）の設計によって完全にチーム間の連携の必要性を排除できないことを踏まえると、むしろそのような連携の必要な場面を嫌って例外として扱うよりも、その存在を正面から認めて学習の機会ととらえるLeSSアプローチの方に現時点では魅力を感じています。
もちろん、現実の仕事においては既にチームごとに担当する範囲が規定されていて、そこがチームのレベルにおいても個人のレベルにおいても強みであり、熟達による面白さや優れた仕事にもつながっている場面も多いので、そこを捨ててしまおうというのではありません（し、LeSSでもそのような強みは存分に活用すべきだと言われています）。また、メンバーごとの特性もあるとは思います。とはいえ、チームの担当範囲を狭く限定しようとして他チームとの連携をそれからの逸脱として忌避するよりは、少しずつでも担当範囲を広くしていくというスタンスの方がよいのではないかと思います。
※こうした「少しずつチームの担当範囲を広げていく」という点に関連するツールとして、LeSSのWebサイトではFeature Team Adoption Mapが紹介されています。
おわりに
私自身、LeSSについてはまだまだ学び始めたばかりです。現職ではLeSSを一部で取り入れていて、実践をしながら考えることも多くあります。公式Webサイトで紹介されている事例研究を読んだり、コミュニティに参加したり、同僚と議論したりして更に学んでいきたいと思っています。一方で、今回久しぶりに『チームトポロジー』もパラパラと読み返してみて、今読むと最初に読んだときには得られなかった学びがあるような気もしています。『チームトポロジー』は数ヶ月前に原書は第2版が出版されていて、複数の事例研究が追加されているなどのアップデートもあるようなので、ぜひ読んでみたいなと思っています。
*1:現職である株式会社エス・エム・エスに費用は出してもらいました（大声）。
