V&V

どちらがValidationでどちらがVerificationか？

SWEBOKでもCMMIでもVerification & Validationとなっている。V&Vは米国人にとって単にゴロがいいからという理由でこれらの単語が選ばれたらしい。ただ、順序は、Verification(検証)してからValidation(妥当性確認)するという流れで一貫されている。ここが分からないところだ。

ある活動（ActivityでもTaskでもいい）には入力の作業成果物があり、出力の作業成果物がある。Verificationは出力の作業成果物を入力で与えられた要件と照合して、要件を満足しているかであり、Validationは、その入力の作業成果物の源泉となっている所期の顧客ニーズを満足しているかである。Verificationは「正しく構築されていること」、Validationは「正しいものを構築しているか」ということになる。

　artifact-Roots --> ... --> artifact-A --> PROCESS --> artifact-B

Verificationは、artifact-Aとartifact-Bの照合、Validationはartifact-Rootsとartifact-Bの照合で可能な訳だ。artifact-Rootsがいわゆる「顧客要件」だ。

ここで考えられるのは、artifact-Aとartifact-BがVerificationされるという前提に立つならば、Validationはartifact-Rootsとartifact-Aを照合すればよいといえる。言い換えると、活動(PROCESS)の事前条件のチェックとしてとしてValidationを行い、事後条件のチェックとしてVerificationを行うということである。

開発の早い段階で予防的に中間的成果物に対してV&Vをセットで行う場合、Verificationを実施するという前提のもとではValidationを行ってからVerificationしても問題ないともいえる。その方が自然な流れではある。実際には、Verificationがinternal/localに行えるのに対し、Validationは顧客や関係者を巻き込む場合があるので、まずVerificationしてからValidationに臨めという意味合いもある。また作業が細分されていて、そのタスクの担当者はartifact-Rootsの内容を知らないということもあるかもしれない。それでも、正しくないものだと分かっているなら、わざわざVerificationするまでもないし、不自然な流れを作る必要はないように思う。

また「正しいものを構築しているか」という表現はもっともらしいが、どうもその評価方法が曖昧で具体化しにくいものに見えてくる。正しいかどうかと、構築しているかどうかの両方を含むニュアンスだからだ。シンプルなものを余計に難しくしてしまう。そこで、私は、Validationは「出力(artifact-B)は所期の顧客ニーズ／要求を正しく取り込んでいるか」と表現したい。この「正しく取り込んでいるか」の表現は単にマッピングできているかどうかを明示しているに過ぎない。トレースにより確認は容易である。