検証と妥当性確認（V&V）

検証（verification）と妥当性確認（validation）は互いに補い合う 2 つのチェックで、通常は Barry Boehm の言い回しで説明されます。検証は、作業成果物が仕様に適合しているかを確認します。つまり「製品を正しく作っているか？」です。妥当性確認は、製品が想定された環境でユーザーの実際のニーズを満たしているかを確認します。つまり「正しい製品を作っているか？」です。仕様が間違っていれば、システムは検証に完全に合格しても、妥当性確認で不合格になりえます。

例

ある要件に「エクスポートボタンは全注文の CSV ファイルを生成する」とあります。

• 検証: チームは設計をレビューし、コードをインスペクションし、エクスポートをクリックすると全注文を含む正しい形式の CSV が生成されることをテストします。実際にそうなるので、検証は合格です。
• 妥当性確認: 経理チームが実際に使ってみると、本当に必要なのは月ごとに絞り込まれ、税額が別の列になった注文であり、さらに自分たちのスプレッドシートのテンプレートはセミコロン区切りを前提としていることがわかります。機能は仕様を満たしていますが、ニーズは満たしていません。妥当性確認は不合格です。

違いのまとめ

	検証	妥当性確認
問い	製品を正しく作っているか？	正しい製品を作っているか？
比較対象	要件、設計、標準	ユーザーのニーズと想定される用途
典型的な活動	レビュー、ウォークスルー、インスペクション、静的解析、ユニット・結合・システムテスト	ユーザー受け入れテスト、ベータテスト、ユーザビリティ調査、デモ、本番からのフィードバック
動くソフトウェアが必要か？	必ずしも必要ない：レビューは検証	基本的に必要。または現実的なプロトタイプ
主な実施者	開発者と QA	ユーザー、顧客、プロダクトオーナー

要件レビューやコードレビューのような静的技法は、常に検証です。QA が仕様に対して行う動的テストの大半も検証です。妥当性確認には、その製品を使う当事者が関わります。

なぜ重要なのか

検証だけに集中するチームは、欠陥のある要件にぴったり一致したソフトウェアを出荷してしまうことがあります。シフトレフトの実践は両方に役立ちます。受け入れ基準を早い段階でユーザーとレビューするのは安価な妥当性確認であり、コミットごとの自動テストは継続的な検証です。医療機器のような規制業界では V&V は別々に文書化された活動であり、監査人はそれぞれの証拠を求めます。