受け入れ条件や成果物を「機能要件か非機能要件か」「承認されたか、されていないか」のどちらかに必ず分類するのはなぜ？
公式仕様・オントロジー検証クエリ（cq-09）。スクラムガイドやカンバンガイド等の公式テキストと、オントロジー（SRO/KGO）の形式検証に基づく解説です。文献の事例報告ではなく、公式ルール上の規定と論理構造を示します。
結論（TL;DR）
Section titled “結論（TL;DR）”受け入れ条件は「機能要件」か「非機能要件」のどちらか一方に、成果物は「承認された」か「承認されていない」かのどちらか一方に、必ず分類します。どっちつかずの分類のままでは、その成果物が完成の定義を満たしたかどうかをチームが判断できません。
公式の根拠と詳細解説
Section titled “公式の根拠と詳細解説”スクラムガイドの規定
Section titled “スクラムガイドの規定”開発者は完成の定義を忠実に守ることで品質を作り込みます。完成の定義を満たしたかどうかを判定するには、まず何を満たせば完成なのか（受け入れ条件の性質）と、実際にそれを満たしたのか（成果物の承認可否）が、あいまいさなく決まっている必要があります。分類が宙ぶらりんのままでは、レビューで「完成」を宣言する根拠がありません。
オントロジー（SRO）による論理構造
Section titled “オントロジー（SRO）による論理構造”sro:AcceptanceCriteriaは機能要件（FunctionalAcceptanceCriteria）か非機能要件（NonFunctionalAcceptanceCriteria）のいずれか一方に、sro:Deliverableは承認された成果物（AcceptedDeliverable）か非承認の成果物（NotAcceptedDeliverable）のいずれか一方に、それぞれ排他的に分類されることがモデル上求められています。どちらにも分類されていない、または両方に分類されている状態は、構造の整合性チェックで検出されます。
根拠・出典一覧（トレーサビリティ）
Section titled “根拠・出典一覧（トレーサビリティ）”| 出典種別 | 参照先 | 該当箇所 / 概念 |
|---|---|---|
| GUIDE | 『スクラムガイド 2020』開発者 (Developers) | 開発者 (Developers) |
| SRO | SROモデル: sro:AcceptanceCriteria / sro:Deliverable の排他的サブクラス制約 | sro:AcceptanceCriteria |
🔍 妥当性検証レポート（クリックして展開）
- 総合判定: ✅ 合格 (スコア: 100/100)
- 形式論理検証: PASS
- LLM批判的評価: Faithfulness 5.0/5, Relevance 5.0/5
評価コメント:
- 回答文は前提コンテキストに忠実であり、スクラムガイド2020とSROモデルの規定を正確に反映しています。勝手な断定や俗説はなく、内容は完全にコンテキスト準拠です。また、質問の核心に直接回答しており、完成の定義を満たしたかどうかを判断するための必要性やSROモデルの論理構造を明確に説明しています。極めて的確な回答です。