単一のチームでスクラム開発を行う時と比べて，LeSS や Nexus といった Scrum of Scrums，または大規模スクラムを実践する際，「プロダクトは何か」という定義はより重要になります．
LeSS の解説書である Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) を読み進める中で，プロダクトの定義についての記述が結構良いなと思ったので，自分なりの例も交えつつ説明したいなと思います．

なぜプロダクトの定義が重要なのか

大規模スクラムに限らず，スクラムにおいてプロダクトの定義が明確であることは極めて重要です．プロダクトの範囲が明確でなければ，プロダクトバックログがどこまでをカバーするべきかも，プロダクトバックログアイテムの受け入れ基準にどのようなことが書かれているべきかも判断することが出来ないし，誰がプロダクトオーナーとして適しているかを判断することも出来ないからです．

これが大規模スクラムとなると，その重要性は更に増します．

複数のスクラムチームがひとつのプロダクトバックログを実現していくようになると，ほとんどすべてのケースでプロダクトは複数のシステム (LeSS では コンポーネント と呼びます) から構成されるようになります．プロダクトを構成する特定のシステムの開発や改善に注力する中で，システム単体が大きくなったり，複雑さが増すに従い，各システム単体での最適化を目的としてしまう心理が働いたり，他システムとの関連や顧客への影響がわかりにくくなったりします．このことは，LeSS でいうところのプロダクト全体の観点や顧客中心的といった価値観の促進を阻害してしまいます．

この問題を解決するためのアプローチとして最初に取られるべきなのがプロダクトの定義の明確化です．プロダクトの定義が明確になることで，プロダクトを構成する各サブシステムが最終的にどのような価値を顧客に提供するのかを明らかにし，この定義に従ってプロダクトバックログの作成や詳細化，価値ある単位へのスライスが可能になります．

なぜ，より広いプロダクトの定義が好まれるのか

プロダクトの関心や価値の範囲は，可能な範囲で広く取る ことを LeSS は推奨しています．

例えば，大規模な EC サイトの開発を例に取りましょう．EC サイトの運営には大雑把に言うと大きく2種類のシステムが必要になります．ひとつは商品を購買するエンドユーザーが回遊し，商品をカートに入れ，チェックアウトを行うフロントサイトであり，もう一方は在庫や価格を管理するために， EC サイトを運営する企業の担当者が利用する商品管理システムです．
ここでプロダクトを「EC フロントサイト」と捉えるのが狭いプロダクトの定義であり，「EC フロントサイトと管理システム」と捉えるのが広いプロダクトの定義です．どちらの定義でも，エンドユーザーに多くの購買行動を EC サイト上で起こしてもらうことで収益をあげよう，としている点は同じですが，そのアプローチとして取れる範囲が両者の間では異なります．

仮にプロダクトの定義を狭く取り，フロントサイトの開発に最適化した組織があったとしましょう．フロントサイトでストレスなく驚きや楽しみを与えるユーザーインターフェース (UI) を提供することで顧客のアテンションを惹き，ショッピングが楽しくなる環境を作り上げたとしても，そこに並ぶ商品自体が魅力的でなかったり，頻繁に欠品を起こしていたり，価格設定が不適切であったりという商品管理システムの機能不全が起きていれば台無しです．このような状況は「局所最適」と呼ばれます．

プロダクトの定義を広く捉えることで，フロントサイトと商品管理システムを合わせてどのような価値や強み，魅力といったものを提供するかを決め，一貫して実現に向かうことができるようになります．これが，より顧客にとって意味のあるプロダクトを開発するために必要不可欠だということは明白でしょう．

プロダクトの定義を拡張し続けること

プロダクトの定義は広いほうがよいとは言えど，大規模スクラムチームの所属する組織や企業の構造などが妨害となって実現が難しいケースがあります．例えば，そもそもフロントサイトを開発する部署と商品管理システムを開発する部署が分かれていたり，開発拠点が物理的に離れていたり，どちらかのシステム (または両方) の開発をアウトソースしていれば，プロダクトの定義を広く取って全体最適を図ることは難しくなります．

また，スクラムチームのスキルの範囲が限られているために，理想的な広いプロダクトの定義を持ってプロダクトに携わることが出来ないケースも多いでしょう．フロントサイトでリッチなユーザーインターフェースを実現するスキルも，スマートフォン向けのネイティブアプリを開発するスキルも，堅牢なな商品管理システムを構築するスキルも，収益効率を改善する価格設定アルゴリズムを実装するスキルもそれぞれ専門性が高く，一つの組織が持つスキルのバリエーションを増やすことは比較的長期的なスパンで考えなければならず，一朝一夕に実現はできません．このことは多くのソフトウェア開発者にとっては想像に難くないでしょう．

このような状況で LeSS が提唱しているのは，大規模スクラムの開始時点では現実的な範囲で組織が対峙するプロダクトを定義し，その後に定期的にその定義を見直しながらプロダクトの定義を継続的に拡張し，理想的な広さに近づけてゆくという方法です．これはさながら，スクラムチームが成熟するとともに完成の定義が拡張されてゆく現象と類似しますが，プロダクトの定義を拡張するということは組織の構造自体を変更する必要が生じるため，完成の定義の拡張よりは難しくエネルギーを要することだと述べられています．

ということで，興味を持った人は読んでみてください． (というかぜひ一緒に読みながらディスカッションしてくれる人とかいたら嬉しい)