2010年3月15日

このタスクへのインプットはつぎのとおりです。

－ソリューション[構築された]」

－要求[優先順位付き、かつ妥当性確認された]

構築されたソリューションが現在のビジネスニーズを満たしているかを確認するために、妥当性確認が必要です。

ここで質問です。

Q1：「ソリューションの検証」と「ソリューションの妥当性確認」の違いはなんでしょうか。

Q2：「ソリューションを検証する」タスクはありません。どうしてでしょうか。

Q3：「ソリューションを妥当性確認する」タスクでは実際に何を行うのでしょうか。

Q3：「ソリューションの妥当性確認」はV字モデルの「ビジネス要求」「ステークホルダー要求」「ソリューション要求」のどれに対応するのでしょうか。

A1：まず、「検証（Verification）」とは、成果物が仕様どおりに作成されているか（Do things right.）を確認するプロセスです（作る側の視点）。

一方「妥当性確認（Validation）」は、成果物が意図された正しいもの（役に立つもの）になっているか（Do right things）を確認するプロセスです（利用者側の視点）。

ですから、「ソリューションの検証」はソリューションが仕様どおりに出来上がっているかをチェックするもので、通常「結合テスト」や「総合テスト」で行われます。作る側の視点ですから、プロジェクト内部の仕事です。

そして、「ソリューションの妥当性確認」は利用者側の視点ですから、通常受入れ検査（テスト）になります。

他の知識体系（CMMI、SWEBOK、共通フレーム2007）でも同様の定義です。

A2：お分かりになると思いますが、「ソリューションを検証する」のはビジネスアナリストではなく、プロジェクトのテスト担当者の役割ですから、BABOK®のタスクにはありません。極めて重要なアクティビティですが、役割が異なります。

A3：実際の作業ですが、受け入れ検査そのものはユーザーの仕事です。ビジネスアナリストは検査で発見された不具合（欠陥や問題点）をアセスメントします。ここでは欠陥や問題にかかわらず、ステークホルダー要求を満たせないものすべて対象とし：

　－欠陥のあるソルーションのアウトプットを調査し、問題の根本原因を追及します。

　－欠陥を診断し、問題の重要性、ビジネスへの影響の重要性などを決定します。

さらに、ソリューションの検証で見つけられた不具合（欠陥）も、当然ステークホルダー要求を満たせないことにつながりますから、上記問題の一部として妥当性確認の作業の対象となります。

A4：V字モデルでは「ソリューションの検証」は「ステークホルダー要求」に対応し、「ソリューションの妥当性確認」は「ステークホルダー要求」に対応することがお分かりになると思います。

このタスクで使われる重要なテクニックをご紹介します。

【受け入れ基準と評価基準の定義】

妥当性確認の前提となる、ユーザーによる受け入れ基準を前もって定義しておく必要があります。その作成には優先順位付き、かつ妥当性確認された要求（このタスクへのインプット）が不可欠です。

しかも、この受け入れ基準はソリューションが構築される前に定義しておくべきものです。本来なら独立したタスクとして定義しておいてもよさそうに思いますが、タスクとして明示されていないのでわかりづらいところです。