“V&V”はご存じでしょうか？ “V&V”は、”Verification & Validation”の頭文字をとったもので、日本語では「検証と妥当確認」と呼びます。V&Vは、品質保証の肝となる考え方なので、ぜひ理解していただきたいと思います。
V&Vの定義
まず、V&Vの定義からご紹介します。規格によってさまざまな定義があるので、代表的なものとして、IEEE Std 1012:2012 およびISO9000:2005、そしてソフトウェア工学の大物 B.Boem氏による説明の3つを提示します。
IEEE Std 1012:2012による定義
IEEE Std 1012:2012はソフトウェア開発の規格であるため、V&Vをプロセスとして定義しています。「検証」を前工程で意図した要求事項あるいは条件を満たしていること、「妥当性確認」を最終のシステムあるいはコンポーネントに対する利用者のニーズや意図された利用法などの要求事項を満たしていることを、各々確認することと説明しています。
ISO9000:2005による定義
ISO9000:2005は産業横断の規格であるため、ソフトウェア開発向けの説明ではなく、V&Vを意味として定義しています。「検証」を規定要求事項が満たされていること、「妥当性確認」を特定の意図された用途または適用に関する要求事項が満たされていることと説明し分けています。規定要求事項と特定の意図された用途に関する要求事項という両者の違いは、よく考えないと理解しにくいかもしれません。
B. Boem氏による説明
B. Boem氏による説明は、とても面白く有名です。”right”が文のどこにかかり受けするかで検証と妥当性確認を説明し分けています。「正しく開発」と「正しい成果物を開発」の差異です。B. Boem氏の説明を知っていると見識がある人だと思ってもらえるかもしれませんね。
V&Vを端的に説明すると
実は、V&Vを正確に理解している方は多いとは言えず、上記の定義だけではなかなか本質が伝わらないかもしれないと思いますので、次に、筆者作成の図でV&Vを解説します。
プロセス(工程)によって、入力は出力へ変換されます。その入力に対して、出力が正しく変換されているかを確認することが「検証（Verification）」です。一方、その出力がもともとの要求と合致しているかを確認することが「妥当性確認（Validation）」です。出力の正しさを、何に基づいて確認するかが両者で異なります。検証は入力、妥当性確認は要求に基づいて、出力の正しさを確認します。品質保証するときには、常にV&Vのこれら2つの視点で、出力の正しさを確認していくことが重要です。さらに説明を加えますね。
伝言ゲームに例えてみよう
突然ですが、伝言ゲームを想像してみてください。最初に与えられたお題を次から次へ伝えて、最後の人にそのお題がより正しく伝わったほうが勝ち、というあのゲームです。伝言ゲームでは、いつの間にか伝言内容が変わってしまいますよね？ ときには、最後の人に伝わっている内容が、与えられたお題とは似ても似つかない内容に変わっていることがあります。それがウォーターフォールモデル開発で起こっていないかを確認するのがV&Vの２つの視点なのです。伝言ゲームなら誤っても楽しいですが、ソフトウェア開発で起きたら大変ですからね。
ウォーターフォールモデル開発では、要求を入力して、それを要求定義で定義して、次の設計へ伝えます。設計は、受け取った内容に基づいて設計し、次の実装へ伝えます。この伝言ゲームを繰り返して最終品であるソフトウェアができあがるのです。
上図で、左から右へ正しく詳細化し変換されているかを確認することが「検証」です。伝言ゲームで言えば、左から右へ伝えるときに、左の人から聞いた内容と右の人へ伝えようとする内容が合っているかを確認することになります。一方、それが、もともとの要求と合致しているかを確認するのが「妥当性確認」です。妥当性確認は、伝言ゲームでいえば、一人隣へ伝えるたびに、最初の与えられたお題と合っているかを確認する、という意味になります。要するに、一人隣へ伝えるたびに、その内容は①左の人から聞いた内容と合っているか（検証）、②与えられたお題と合っているか(妥当性確認)という２つの視点で確認するということです。この検証と妥当性確認を、ウォーターフォールモデル開発の各工程で、きちんと実施すれば、伝言ゲームのような誤りは発生しなくなるはずです。
さいごに
V&Vの意味は理解していただけたでしょうか、V&Vの2つの視点は、レビューなどでの重要な確認視点となります。この2つの視点でソフトウェア開発の成果物の正しさを確認することが、品質のよいソフトウェア開発につながるはずです。