プロダクトのデモンストレーションでステークホルダーが期待はずれだと主張しています。プロジェクト・マネジャーはこのステークホルダーの意見を評価するためにどの作成物（アーティファクト）を使用すべきでしょうか？「最小実行可能プロダクト（MVP）の記述」「Doneの定義（DoD）」「Readyの定義（DoR）」「ユーザー・ストーリーの受入基準」

→ユーザー・ストーリーの受入基準

プロジェクト・マネジャーは「ユーザー・ストーリーの受入基準」を使ってステークホルダーの意見を評価すべきです。これは、プロダクトが完成しステークホルダーに受け入れられる状態かを判定するための具体的な要件です。プロダクトが備えるべきフィーチャーや機能を簡潔に記述したもので、一般的にはユーザー・ストーリーの中で定義します。

その他の選択肢は誤りです。Doneの定義やReadyの定義も重要な作成物ですが、受入基準よりも広義的です。DoDは、プロダクトを「完成」と見なすために必要な条件です。DoRは、作業開始前に確認すべき条件を定義したものです。MVPは必要最小限の機能しか持たないプロダクトのことなので、この状況とはあまり関係がありません。

理由

この問題のポイントは、**「ステークホルダーの期待」と「実際の成果物との乖離をどう評価するか」**です。

アジャイル・プロジェクトでは、ステークホルダーの主観的な満足度ではなく、
**あらかじめ合意された“受入基準（Acceptance Criteria）”**に基づいて成果物を評価します。

ユーザー・ストーリーには、「何を達成すればそのストーリーが完了したと見なせるか」を定義する
**受入基準（Acceptance Criteria）**が設定されています。

したがって、プロジェクト・マネジャーがステークホルダーの「期待はずれ」という主張を客観的に評価するには、
その主張が定義された受入基準を満たしているかどうかを確認するのが最も適切です。

これは、アジャイルの「透明性（Transparency）」と「検査（Inspection）」の原則にも合致します。

❌ 他の選択肢の誤りの理由

「最小実行可能プロダクト（MVP）の記述）」

→ MVP（Minimum Viable Product）は、ビジネス上の仮説検証のための初期版製品を指します。
　ステークホルダーの“期待”を評価するには広すぎる概念で、
　個別の機能やストーリーが完了しているかどうかを判断する基準にはなりません。

「Doneの定義（DoD）」

→ DoD（Definition of Done）は、チーム内で「完了」と見なす共通基準です。
　例：「コードがレビューされ、テストを通過している」など。
　ただしこれは技術的完了基準であり、ステークホルダー視点での価値達成を判断するものではありません。
　よって、ステークホルダーの不満を評価するには不十分です。