V&V(検証と妥当性確認）とは何か

はじめに

政治家やコメンテータが、「○○を検証しなければなりません」、「○○の検証が必要です」と発言するのをよく聞きます。この「検証」という言葉、正しく使用されているでしょうか。
「検証（verification）」と「妥当性確認（validation)」の定義が多く存在し、その定義により意味が異なり、正しいのか間違っているのかわからなくなるため注意が必要です。

例えば、
・消費者が購入する、
「もの」の価格が適正かどうか検証する。
「もの」の価格が妥当か確認する。

について、検証と妥当性確認の定義に違いで意味が異なることを紹介します。また、検証可能か否かも述べてみます。
さらに、要求・要件と妥当性確認の関係を説明します。

ISO 9000：2005（品質マネジメント）の定義による解釈

ISO 9000:2005の定義はこうです。

・検証（Verification）：客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。
・妥当性確認（Validation）：客観的証拠を提示することによって、特定の意図された用途または適用に関する要求事項が満たされていることを確認すること。

まず、「もの」の価格が適正かどうか検証する。についてですが、日本では多くの「もの」は、製造販売者が自由に価格を設定できます。材料費、製造費、輸送費、人件費、販売費、管理費などと利益をもとに決定します。それらの費用と割合が規定要求事項としてある場合は、製造販売者自身は、「もの」の価格が適正か検証できます。ところが、第３者は、その「もの」に関する規定要求事項を持っていないため、価格が適正かどうか検証できません。ただし例外があり、政府が価格調整をしている「もの」、例えば、電気やガソリン価格については、不当な利益を上乗せしていないかどうかの確認のため、適正さを検証すると言う場合があります。
一方、「もの」が期待する価値を満たしているか、その価値に対して安いか高いかを判断することはできます。この場合は「価格が妥当か確認する」は正しいです。「もの」を何に使うのか、何のために買うのか（意図された用途または適用に関する要求を満たしているかどうか）が決まっていれば、価格が安いのか高いのか判断できるからです。

IEEE 1012:2012（ソフトウェアの検証と妥当性確認）の定義に基づく解釈

IEEE 1012:2012の定義はこうです。

検証（Verification）：各開発工程の成果物が前工程で意図した要求事項あるいは条件を満たしているかどうかを決定するプロセス
妥当性確認（Validation）：各開発工程の成果物が最終工程の成果物であるシステムまたはコンポーネントに対する利用者のニーズや意図された使用法などの要求事項を満たしているかどうかを決定するプロセス

「もの」の価格が適正かどうか検証するについては、「もの」が最終工程の成果物であるとすると、「もの」が販売されるまでの各工程が明確で、その前工程が明確である必要があります。さらに、各工程で発生する費用に関する要求事項が存在しなければなりません。それらの費用に関する要求事項をもとに価格が適正であるか「もの」を製造販売する当事者が検証することができます。ただしISO 9000:2005の章で述べた通り、これらの情報を持っていなければ検証できません。

「もの」の価格が妥当か確認するについては、「もの」の利用者のニーズや使用法の要求事項の満足度と価格の関係から、妥当性を確認することができます。そのため、この定義の下で「もの」の価格が妥当か確認するは、問題なく使えます。

ISO/IEC 17029:2019 （JIS Q 17029:2022）の（適合性評価―妥当性確認機関及び検証機関に対する一般原則及び要求事項定義）による解釈

・検証（Verification）：過去に行った活動の結果に関する主張の真実性を確認（過去の情報に 基づいた評価が対象）する行為。
・妥当性確認（Validation）：将来の活動に関する主張（claim）の妥当性（もっともらしさ）を 確認する行為。

「もの」の価格が適正かどうかの検証は、すでに製造販売された「もの」の価格の真実性を確認することです。

「もの」の価格が適正かどうか妥当性を確認するは、これから製造販売する「もの」の価格がもっともらしいかどうかを確認することです。

一般には、価格が適正かどうかの検証と妥当性確認については、この定義のを用いていると思われます。

JIS Q 17029の定義についての私見

「妥当性」の定義の説明に定義する「妥当性」の言葉を使っており再帰的定義が生じています。その妥当性を「もっともらしい」と再定義していますが、深い意味で説明されていません。「もっともらしさ」は主観的であり人によって解釈が変わり厳密ではないため、技術開発で用いる妥当性としては用いることはできないと考えます。
上の定義は、過去と将来に行う活動に関する主張の確認をそれぞれ、検証、妥当性としており、これらを製品開発に当てはめることは難しいと思われます。なぜなら、製品開発は「今」発生しているからです。

検証とは妥当性確認とは

ここで技術の話に戻しましょう。
多くの技術者が用いているISO 9000：2005の定義をもとに、設計の検証と妥当性確認の話をします。

「設計が正しいかどうか検証する」という表現は正しいです。ただし、設計の入力となる仕様書（規定）がなければなりません。入力仕様通り設計されているかを確認するのが検証なのです。

「設計の妥当性を確認をする」という場合は、これは、設計が入力となる要求、要件を満たしていることを確認することを意味します。例えば、要求、要件として存在する、機能や性能がこの設計に盛り込まれているかを確認することが妥当性確認です。実際には、設計だけでは文書上の確認しかできないため、ものが完成したあとに要求、要件を満たしていることを確認する必要があります。

要求または要件と妥当性確認

「要求」と「要件」は英語ではいずれもrequirementですが、日本人だけがこれを分けて使います。
これは、発注主が、おおまかな要求しか出さないため（例えば、下請けはA4一枚の情報しかもらえない）、下請け側がものつくりのために、発注主にヒアリングして「要件」すなわち必要な機能、性能などの要求を詳細化しているからです。
これは、日本だけの風習であり、ピラミッド型社会の典型ともいえます（細事をまかせる）。発注主が、設計を下請けに委託するのはよいのですが、要求が下請けに伝わらないまずい状況になっています。

話を戻しますと、日本で行われているのは、ほとんどが検証です。
下請けが設計仕様書を書いて、その通りものができたかを確認しているからです。妥当性確認は下請けに要求した発注主側の責任ですが、ほとんどされていませんし、それを下請けにさせていません（妥当性確認は下請けが行ってもよいです）。
簡単に説明しますと、まず、「したいこと、しなくてよいこと」の明確化が必要です。問題として起こりそうなことは、したいことができないことです。ものが出来上がったあと、したいことができるかどうかを確認するのが妥当性確認です。したいことが明確でないと妥当性確認ができません。そのため、下請けにすべて任せ、したいことを明確にしない発注者は、妥当性確認もできません。

今問題になっているマイナンバーカードの例を挙げます。
マイナンバーカードの個人情報登録または紐づけに誤りがあり、他人の住民票を取得してしまう問題がありました。これは書き込み情報の誤りが原因と思われます。

マイナンバーカード要求を書いてみます。（氏名、生年月日、性別、住所を個人情報としてひとくくりにしています）
・マイナンバーカードにはカード所有者の個人情報が書き込まれなければならない。
・マイナンバーカードからカード所有者の個人情報が読み出せないといけない。
があったとします。

すると、妥当性確認は、
・マイナンバーカードには所有者の個人情報が書き込まれていることを確認しなければならない。
・マイナンバーカードから所有者の個人情報が読み出せることを確認しなければならない。

マイナンバーカード作成時（更新時）に個人情報を書き込んでおり
・カード作成前（更新前）に、書き込み個人情報と読み出し個人情報（期待する情報）を別の業者または人物が作成しレビューします。特に読み出し個人情報は期待値となるため、複数の人物がレビューします。
・カードに個人情報を書き込んだ後にその個人情報を読み出して、書き込み個人情報と読み出した個人情報を機械的に比較すれば、多くの誤りは発見できます。
おそらく、ここまでは実施していたと思いますので、問題はレビューです。目視でIDと個人情報を照合しその結果をレビューし、見つけた誤りを手順を踏んで修正しても、誤りをゼロにすることはできません。人の力に限界があります。
以上のようなレビュー（書き込みデータを作成した人物と異なる人物が期待値データ作成し、複数人がレビュー）していたのであれば問題なしで、この誤りは下請け業者（または担当者）の責任ではありません（このように実施していたことを期待しますが、もし、このように実施していなかった場合は改善を要望します）。それからAIを用いたレビュー方法が提案されていますが、誤りをゼロにすることは難しいされており、その開発は今後の課題です。

付録

検証と妥当性確認についてはISO 26262でも明記され、さらに確証（Confirmation）が定義されています。ISO 26262の確証は大変厳しく、規格が要求する作業成果物がそろっており、規格を満たすかどうかレビューし、レビュー指摘事項の対応がべて行われて、安全が担保されていることを論証することです。
安全度水準が厳しい製品については、設計者自身が検証、妥当性確認のレビューを、そして確証を行ってはいけないことになっています。開発プロジェクトとは利害関係のない部署のエンジニアにレビューをしてもらいます。これらについては、改めてまとめてみたいと思います。