プロダクトバックログの順序付けはプロダクトオーナーの重要な責任であり、経験主義を通じて価値を最大化するために不可欠です。順序付けは、単一の優先順位付けルールではなく、複数の変数の継続的な検査を反映しています。
1. 価値と成果
主要な変数は価値です。プロダクトオーナーは次の点を考慮します。
* 顧客とユーザーの価値、
* ビジネスへの影響と成果
* 製品目標との整合性。
より高い価値やより緊急性の高い価値を提供するアイテムは、通常、上位に順位付けされます。
2. リスクと不確実性
リスクや不確実性を軽減するアイテムは、多くの場合、早めに注文されます。これには以下が含まれます。
* 技術的リスク、
* 市場リスクまたはユーザビリティリスク、
* 統合または依存のリスク。
早期学習により、より適切な意思決定が可能になり、長期的なコストが削減されます。
3. 依存関係
プロダクトオーナーは、バックログアイテムとチーム間の依存関係を考慮します。他の作業を妨げない、または依存関係を減らすアイテムは、フローを改善し、調整のオーバーヘッドを削減するために、優先順位を高く設定する場合があります。
4. 労力、複雑さ、実現可能性
開発者が労力を見積もる一方で、プロダクトオーナーはこの情報を用いて、価値とコスト、複雑さ、実現可能性のバランスを取ります。短期的な制約内で実現可能な高価値項目が優先されることが多いです。
5. フィードバックと学習
順序付けは、スプリントレビュー、ユーザーテスト、そして市場の反応からのフィードバックを反映します。以前のインクリメントから得られた知見に基づいて、項目は上下に移動する場合があります。
6. 時間的敏感性と機会費用
いくつかの項目は、次の理由により時間的に重要です:
* 規制期限、
* 市場の窓、
* 競争圧力。
こうした品目を遅らせると、その価値が下がったり、なくなる可能性があります。

スクラムでは、チーム構造が価値提供能力に大きな影響を与えます。よく議論される2つの構造は、コンポーネントチームとフィーチャーチームです。スクラムガイドではこれらの用語を明確に定義していませんが、スクラムチームの定義において、フィーチャーチームの特徴を強く支持しています。
コンポーネントチームは、データベース、フロントエンド、ミドルウェアなどの専門分野やシステムコンポーネントを中心に編成されます。これらのチームの業務は通常、製品機能への部分的な貢献であり、顧客価値を提供するためには複数のチーム間での調整と引き継ぎが必要になります。その結果、コンポーネントチームは依存関係を導入し、統合を遅延させ、スプリント内で独立して使用可能なインクリメントを作成することに苦労することがよくあります。
一方、フィーチャーチームは、完全な製品機能、つまりプロダクトバックログアイテムの提供を中心に編成されます。フィーチャーチームはクロスファンクショナルであり、設計、構築、テスト、そして「完了」した価値の増分の提供に必要なあらゆるスキルを備えています。フィーチャーチームは依存関係を最小限に抑え、各スプリントで顧客向けの機能を独立して提供できます。
Scrum Guide の観点から見ると、機能チームは Scrum の原則にさらに近づきます。
* スクラム ガイドでは、スクラム チームは機能横断的であり、機能チームを直接サポートし、コンポーネント チーム構造に挑戦すると述べられています。
* スクラムでは、各スプリントで使用可能なインクリメントを作成することが求められます。フィーチャーチームはこの期待に応えることができますが、コンポーネントチームは通常、他のチームに依存しなければ実現できません。
* スクラムは経験主義（透明性、検査、適応）に基づいています。フィーチャーチームにおける依存関係を減らすことで透明性が向上し、検査と適応が迅速化されます。
* スクラムは価値の提供と説明責任を重視します。機能チームは成果に対する明確な所有権を維持しますが、コンポーネントチームは技術サイロ間で説明責任を分散させます。
コンポーネントチームは、従来の組織構造や技術的な制約により存在する場合もありますが、理想的なスクラム実装というよりは、組織的な障害となるものです。プロフェッショナル・スクラムマスターIIIの観点から見ると、フィーチャーチームへの移行は、アジリティの向上、価値提供の向上、そしてスクラムガイドで定義されているスクラムの実現性向上につながります。

チームメンバーがスプリントゴールの設定に価値を感じていない場合、それはスクラムに対する根本的な誤解を示しています。スクラムマスターとして、私は同僚のスクラムマスターに、スプリントゴールはスクラムの中核要素であり、アラインメント、コミットメント、そして経験主義に不可欠であることを説明します。
まず、スプリントゴールは、スクラムチームがスプリントで作業を行う理由を説明します。スクラムガイドによると、スプリントゴールはスプリントの唯一の目標であり、スプリントバックログとの一貫性をもたらします。明確な「なぜ」がなければ、スプリントの作業は価値を提供するための目的のある取り組みではなく、無関係なタスクの集まりとなってしまいます。スプリントゴールは、チームが選択されたプロダクトバックログアイテムの背後にある意図を理解し、日々の意思決定をその意図に沿って行うのに役立ちます。
第二に、スプリントゴールはスクラムチームのコミットメントを表します。チームは、具体的なスコープが変更される可能性があったとしても、スプリントゴールの達成に向けて全力を尽くすことを約束します。このコミットメントは、集中力と責任の共有を促進します。チームは個々のタスクを最適化するのではなく、スプリントゴール全体の達成に向けて最適化します。
第三に、スプリントゴールは柔軟性を制限するのではなく、むしろ柔軟性を生み出すものです。スプリント中に新たな発見、リスク、あるいは機会が発生した場合、チームはスプリントゴールを損なわない限り、スプリントバックログを調整することができます。これにより、チームは目的の安定性を維持しながら変化に対応できます。
スプリント目標がないと、変更は恣意的になり、焦点を失うリスクが高まります。
4つ目に、スプリントゴールは効果的な検査と適応を可能にします。デイリースクラムでは、チームはスプリントゴールに向けた進捗状況を検査し、それに応じて計画を調整します。同様に、スプリントレビューでは、関係者がスプリントゴールが達成されたかどうかを検査できます。スプリントゴールがなければ、検査のための意味のあるベンチマークは存在しません。
最後に、スプリント目標がなければ、スクラムは意図したとおりに実践されていないということを明確にすることが重要です。
スプリント ゴールはスクラムの必須要素であり、これを削除すると透明性が損なわれ、フレームワークの実証的基盤が弱まります。

この状況は、プロダクトバックログの透明性とコラボレーションの崩壊を示しており、経験主義と価値提供を直接的に脅かしています。スクラムマスターとしての私の責任は、問題を自ら解決することではなく、スクラムチームと組織が問題を解決できるように支援することです。
1. 問題を再定義する: 要件と製品バックログ
まず、両者が問題を再考できるよう支援します。スクラムでは、従来の固定的な意味での「要件」を扱うのではなく、創発的で、順序付けられ、継続的に改良されるプロダクトバックログを扱います。プロダクトバックログアイテムの明確性が欠如していると、バックログが使用可能な状態になく、開発者にとって障害となります。
2. 影響を透明化する
次に、不明確なバックログ項目の影響を透明化するための会話を促進します。
* 開発者は作業を確実に予測できないため、
* スプリント目標が危険にさらされる、
* やり直しや無駄の増加、
* 価値の提供が遅くなります。
この会話にはプロダクトオーナーが参加し、非難ではなく、根拠に基づいた証拠を提示する必要があります。目標は、責任の所在を明確にすることではなく、結果についての共通理解を得ることです。
3. プロダクトオーナーの責任を強化する
スクラムガイドでは、プロダクトオーナーは価値の最大化とプロダクトバックログ管理の責任を負うことが明確に示されています。これには、プロダクトバックログアイテムが明確で、理解され、整理されていることを確認することも含まれます。「忙しすぎる」からといって、この責任が免除されるわけではありません。スクラムマスターとして、私はプロダクトオーナーに対し、対応能力の不足自体が組織にとっての障害となることを認識するよう指導します。
4. ハンドオフではなくコラボレーションを可能にする
同時に、開発者には、明確さは単に提供されるものではなく、多くの場合、共同で作り上げていくものであることを指導します。スクラムは、開発者とプロダクトオーナーの緊密な連携を推奨します。例えば、以下のような手法が挙げられます。
* 定期的な製品バックログの改良、
* スプリント計画中の共同討論、
* スプリントの目標に関して焦点を絞った質問をすることで、詳細な事前仕様に頼ることなく、共通理解を大幅に向上させることができます。
5. 組織の制約に対処する
プロダクトオーナーの対応能力の欠如が組織の過負荷や競合する責任による場合、これはシステム的な障害となります。その場合、スクラムマスターはこの問題を組織に提起し、対応能力が十分でないプロダクトオーナーが製品の成果を危険にさらしていることを経営陣に理解させる必要があります。

開発者が特定の知識や専門知識の不足を障害として挙げた場合、スクラム マスターは、スクラムの原則、特にクロスファンクショナル、経験主義、自己管理を強化しながら、価値の提供もサポートする方法で状況に対処する必要があります。
まず、これが本当に障害であるかどうかを確認することが重要です。スクラムでは、障害とはチームが自力で解決できないもののことです。スクラムマスターとして、私は開発者、そして必要に応じてプロダクトオーナーとの議論を促し、望ましい結果を達成するために専門知識が本当に必要かどうかを検証します。場合によっては、スコープやアプローチを調整したり、プロダクトバックログアイテムを改良して代替ソリューションを実行可能にしたりすることも可能です。この会話を通して、専門知識の必要性が当初想定されていたほど重要ではないことが明らかになるかもしれません。
第二に、専門知識が本当に必要な場合、スクラムマスターはチームが機能横断的なスクラムチームとして問題に取り組むよう促すべきです。スクラムでは、チームが価値を提供するために必要なすべてのスキルを保有、あるいは習得することが求められます。したがって、開発者には、必要な知識を自らどのように習得または獲得できるかを尋ねます。学習、調査、トレーニング、実験、プロトタイプ構築のための時間を確保することが選択肢として挙げられます。これらの活動はスプリントバックログの一部として計画することができ、長期的なチーム能力の向上に役立ちます。
第三に、スクラムマスターは、チームの自己管理を損なうことなく、外部の専門知識を効果的に活用できるよう支援します。スプリントの計画やリファインメントの過程で、チームは作業とスプリントバックログの所有権を維持しながら、洞察を得たり、アプローチを検証したり、不確実性を軽減したりするために、社内外の専門家に相談することができます。
最後に、これらの選択肢のいずれでも障害が解決しない場合、スクラムマスターは組織がスクラムチームを支援できるよう支援する責任を負います。これには、組織内の他の部署、あるいは必要に応じて組織外からの専門知識へのアクセスを促進することが含まれる場合があります。スクラムマスターは問題を自ら解決するのではなく、チームが前進できるよう組織的な障壁を取り除くよう尽力します。