7.1.1　ガイド：あなたのプロダクトは何ですか？

プロダクトの定義が、 PBL のスコープを定めさせ、良いプロダクトオーナーを作り出す

プロダクトの定義が狭い場合（20 のチームによって開発されたコンポーネントの「プロダクト」）

顧客に価値を提供せず、技術的にクールなものをつくることになりがち

顧客中心ではないプロダクトオーナー

PBL には技術的な項目が並ぶ

プロダクトの定義が広い場合

顧客中心に向かいやすい

広すぎると

親しくない部門や外の企業まで含めることになるかもしれない。非現実的である

明確かつ魅力的なプロダクトビジョンを示すことが難しくなる

LeSS では広いプロダクトの定義が好ましいとしている

顧客中心でかつ、きめ細かな優先順位付け（開発とプロダクトの良い全体観）を可能にするから

プロダクトの定義が狭いと、小さな PBI が量産され、優先順位付けが難しくなる（全体観がなくなってしまう）

フィーチャーチームにより依存関係を解決できるから

プロダクトの定義が狭いと、プロダクト間に依存関係が生まれる。改修するときに「調整役」という追加の役割を用意して依存関係を管理する必要が出てくる（= 複雑になってしまう）

顧客と一緒に考えるから（要求された「要件」よりも実際の問題と影響に集中することができるから）

プロダクトの定義が狭いと、要件（ソリューション）はプロダクトのスコープに限定されているため、要求されたとおりに実装される

プロダクトの定義が広ければ、チームの創造性の範囲が広がり、チームはユーザーが達成したいことに対するより良い解決策を探ることができる

機能の重複を回避できるから

プロダクトの定義が狭いと、類似のプロダクトやプロダクトの亜種ができる可能性がある。これらは最後には別々のコードリポジトリを持つ、別々の部門になる

似たような、もしくは同じ機能が複数のプロダクトに必要とされたとき、以下のいずれかの対応が必要になる

最初のプロダクトの機能を別のプロダクトに移植する

追加の調整とコードの明確化が必要とされがちで、ほとんど上手く機能しない

別のプロダクト向けに同じ機能を再実装する

新しい内部「コンポーネントプロダクト」を作成して機能を移動する

関連する前組織の複雑さがついてくる

シンプルな組織づくりができるから

プロダクトの定義が狭いと、「プロダクト」間にまたがる作業と意思決定をするための追加の組織構造が作られる

a. プロダクトの定義を狭める制限力

共通性

バックログのアイテムには、同じプロダクトに属する共通の理由が必要である

ビジョン

プロダクトビジョンは、人に動機を与え、境界の中での創造性を促す

プロダクトの定義が広すぎると、ビジョンは「なにかする」というような一般的なものになり、人は気にかけなくなる

顧客または市場

複数の関連した小さめのプロダクトが同じ顧客や市場を相手にしている場合、それらのプロダクトすべてを含んだプロダクトの定義を持つことで、優先順位付けを容易にしたり、チームがまだ顧客の役に立ててない問題を見つけることを促すことがある

定義が広すぎると、集中すべき問題を理解できなくなる

ドメイン

定義が広すぎると、どのドメインにも特化できずチームは何も構築できずに新しいことを永遠に学ぶことになる

既存の構造

LeSS 導入において組織構造の変更が必要になる場合があるが、それらを制限する可能性があるものを挙げる

会社

雇われチームまたは外部委託開発

他の会社のチームはこのプロダクトのためのみによって働くため、彼らは同じバックログで同じスプリントで働かなければならない

別の会社に 1 つのコンポーネントを渡すと、コンポーネントチームと付随するすべての問題を引き起こす

カスタマイズされたコンポーネント

他の会社が彼らの汎用プロダクトをカスタマイズしたものがあなたのプロダクトのコンポーネントになります。彼らは複数の顧客を持つので、同じバックログで働くことはできません

汎用コンポーネント

あなたの会社が大きなプロダクトの一分になる汎用コンポーネントを作る、もしくは別の会社で作られた汎用コンポーネントを使っている場合、どちらにせよコンポーネントを作るチームは同じ PBL 、同じスプリントでは働かない

部署

既存の組織構造の変化が大きすぎる場合、 LeSS の導入はスタートから止められ続ける

e.g. アプリケーション A とその動作環境 X が、別のチームで開発されており、かつ共通のマネージャーが 5 階層上の CEO の場合 → 一時的に狭いプロダクトの定義を当てはめてスタートし、時間の経過の中で適切なプロダクトの定義に広げていく