スコープの妥当性確認とは？品質管理との違いと受け入れの流れ

スコープの妥当性確認（Validate Scope）は、完成した成果物を、権限を持つ関係者が確認し、正式に受け入れることです。確認するのは、顧客やスポンサーなどです。受け入れの記録（署名、承認のメールなど）が残り、その成果物は「引き渡し済み」になります。

ポイントは、「誰が」行うかです。チームが「できました」と言うだけでは、受け入れになりません。成果物を使う側、お金を出す側が「これでよい」と認めて初めて完了します。

古い教材では「スコープ検証」と書かれていることもあります（PMBOK第4版までの名称）。PMBOK第6版では「スコープの妥当性確認」です。

2021年版の ECO には、スコープのタスクに「スコープを監視し妥当性を確認する」がありました。2026年版のタスクとイネーブラーには、「妥当性確認」という語はありません。

ただし、中身は残っています。次の3つのタスクに分かれて含まれています。

• ✓Process タスク2「スコープを作り、管理する」
• ✓Process タスク7「成果物の品質を計画し最適化する」
• ✓Process タスク10「プロジェクトの終結を管理する」（イネーブラーに「関係者からプロジェクト完了の承認を得る」がある）

問題文や教材では、今も旧来の用語として使われます。

似ていて混同しやすいのが、品質管理（Control Quality）です。違いを図で比べます。

品質管理で「仕様どおりか」をチームが確かめ、合格した成果物（検証済みの成果物）を顧客に見せて受け入れてもらう、という順序です。欠陥だらけの成果物を顧客に見せると、時間の無駄になるうえ、信頼も損ないます。

覚え方は、品質管理が 正確さ（correctness）、妥当性確認が 受け入れ（acceptance） です。品質マネジメント全体の流れは、品質マネジメントの記事で扱います。

受け入れの判定には、事前に合意した物差しが要ります。後から「思っていたのと違う」と言われないためです。

アジャイルでは、ストーリーごとの受入基準と、共通の完了の定義の両方を満たしたものが「完成」です。スプリントレビューで利用者に見せ、プロダクトオーナーが受け入れを判断します。予測型より頻繁に、小さな単位で受け入れが行われるのが特徴です。決め方は完了の定義（DoD）とは？で詳しく扱います。

受入基準は、要求事項を集める段階で決めておきます。要求事項トレーサビリティマトリクスで「どの試験で確かめるか」をつないでおくと、受け入れの場面で根拠を示しやすくなります。集め方は要求事項の収集方法で扱います。

予測型の典型的な流れを示します。

受け入れられた成果物は、最終的にプロジェクトやフェーズの終結の手続きへ進みます。

受け入れの本当の目的は、書類に署名をもらうことではありません。関係者にとって価値のあるものを届けたと確かめることです。新ECOも「価値に基づく提供」を Process タスク3に置き、価値の提供を重視しています。

受け入れの場で揉めるかどうかは、その前の準備でほぼ決まります。当サイトでは、次の準備をすすめます。

• ✓受入基準を計画の段階で合意しておく：測定できる形で書き、誰が判定するかも決めます。
• ✓受け入れの担当者を早めに確認する：決定権のある人が誰か、途中で替わっていないかを確かめます。替わったら、基準を改めて共有します。
• ✓途中で見せる：大きな成果物は、試作や中間成果物を途中で見せ、方向のずれを早めに直します。
• ✓品質管理の結果をそろえる：試験の結果や検査記録を、受入基準と対応づけて示せるようにします。
• ✓受け入れの記録の形を決めておく：署名、承認メール、レビューの議事録など、何をもって受け入れとするかを決めます。

受け入れの記録は、プロジェクトの終結のときに「すべての成果物が受け入れられた」ことを示す根拠になります。記録が無いと終結の承認が得られず、プロジェクトを閉じられません。

顧客が受け入れを拒んだら、まず理由を聞き、合意済みの受入基準に照らして原因を切り分けます。

• ✓基準を満たしていない（欠陥）：修正します。品質管理で見逃した原因も調べ、再発を防ぎます。
• ✓基準は満たしているが、新しい要望が出た：変更要求として扱い、影響を分析して、決められた手続きで判断します。
• ✓基準の解釈が食い違っている：受入基準を関係者と読み合わせ、必要ならスポンサーを交えて解釈をそろえます。

やってはいけないことは2つです。受け入れを得ないまま引き渡したことにすること、そして顧客の要望を何でも無償で取り込むことです。前者は終結の条件を満たさず、後者はスコープクリープを招きます。こうした場面は、無料模試30問にも含めています。