はじめに
ソフトウェア開発の世界では、品質がプロジェクトの成功を左右する重要な要素となりますが、「ソフトウェア品質を高めるために何が必要か?」という問いは難解なテーマの一つではないでしょうか。
そこで今回は、ソフトウェアの品質を確保するために欠かせないプロセスであるVerification(検証)とValidation(妥当性確認)をまとめた、通称「V&V」という概念に焦点を当て、初心者にもわかりやすく解説していきたいと思います。
では、ソフトウェア品質とは何か?から解説していきます。
第1章:ソフトウェア品質とは何か?
ソフトウェアは今や私たちの生活に欠かせない存在となっています。周りを見渡すと、スマートフォンのアプリやWebサイト、さらには企業の業務を支える基幹システムまで、すべてがソフトウェアによって動いています。しかし、これらのソフトウェアが常に要求や期待通りに動くとは限りません。また、不具合やバグが発生すると、ユーザー体験が損なわれたり、企業に損害を与えることさえもあります。そこで重要となるのがソフトウェア品質です。
ソフトウェア品質とは、一般的に、ソフトウェアがどれだけ信頼性があり、機能が期待通りに動作するかを指します。質の高いソフトウェアを作るためには、ソフトウェア開発の過程で細かく確認や検証を行う必要があります。
ソフトウェア品質には外部品質と内部品質という概念がありますので、以下、簡単に触れておきます。
- **外部品質(External Quality)**は、ユーザーが直接体験する品質であり、ソフトウェアがどれだけ使いやすく、ユーザーの期待を満たすかを評価します。例えば、操作の簡単さや応答速度などがこれに当たります。
- **内部品質(Internal Quality)**は、ソフトウェア自体の構造やコードの品質を指します。つまり、ソフトウェアがどれだけ効率的に動作し、保守性や拡張性があるかを評価します。開発者やテスターが直接的に関わる領域であり、設計やコーディングの段階で重要な役割を果たします。
参考元
https://www.meti.go.jp/policy/it_policy/softseibi/metrics/product_metrics.pdf
(経産省:システム及びソフトウェア品質の見える化、確保及び向上のためのガイド)
この中で、外部品質がValidation(妥当性確認)に該当し、内部品質がVerification(検証)に該当します。
これから解説していくV&V(Verification&Validation)は、ソフトウェア品質を確保するための観点あるいはプロセスで、それぞれがソフトウェア開発にとってとても重要な役割を果たします。それでは順にみていきましょう。
第2章:Verification(検証)とは?
まずは、「V&V」のVerification(検証)から解説します。
1. Verification(検証)の定義と目的
**Verification(検証)**は、開発中のソフトウェアが設計や仕様に沿って正しく作られているかを確認するプロセスです。
言い換えると、「作ろうとしているものが正しく作られているか?」をチェックすることです。
Verification(検証)は主に開発者やテストチームによって行われ、設計書やコードが仕様書通りに正確に実装されているかを確認することが目的です。
2. Verification(検証)の基本プロセス
Verification(検証)には、主に次のようなプロセスがあります。
- STEP1:テスト計画の立案
まず、Verification(検証)を行うためのテスト計画を立てます。テスト計画では、何をどのようにテストするか、どのタイミングで行うか、誰が担当するかなどを明確にします。
この計画を事前に立てることで、効率的なテストが可能になります。 - STEP2:テストケースの作成
テスト計画に基づいて、テストケースを作成します。テストケースとは、具体的にどのような手順でソフトウェアを検証するかを示したものです。
たとえば、「ログイン画面で正しいパスワードを入力した際、正常にログインできるか」といったテストケースを作成し、それに沿ってテストを進めます。 - STEP3:テストの実施と評価
テストケースが準備できたら、実際にテストを実施します。ソフトウェアが仕様通りに動作するかを確認し、問題があれば修正します。
すべてのテストが成功した場合、設計や仕様に沿って正しく作られていることが確認できたことになります。
第3章:Validation(妥当性確認)とは?
ここからは、Validation(妥当性確認)について解説していきます。
1. Validation(妥当性確認)の定義と目的
**Validation(妥当性確認)**は、開発したソフトウェアがユーザーの要求や期待に応えているかを確認するプロセスです。
ここでの焦点は「作ったものが本当にユーザーのニーズを満たしているか?」がポイントになります。
検証(Verification)は、設計や仕様通りに作られているかを確認するのに対し、Validation(妥当性確認)は、実際にそのソフトウェアがユーザーにとって有用であるかを確認することが目的です。たとえば、ある機能が正しく動作していたとしても、それがユーザーにとって使いづらければ、その機能は妥当性があるとは言えません。
2. Validation(妥当性確認)の基本プロセス
Validation(妥当性確認)には、次のようなプロセスがあります。
- STEP1:ユーザー要件の確認
最初に、ユーザーの要求や期待を整理します。どのような問題を解決するためにそのソフトウェアを開発するのか、また、ユーザーがどのような機能を求めているのかを明確にしていきます。
- STEP2:ユーザー評価とフィードバックの収集
ソフトウェアが完成したら、受入テストや運用テスト等で実際にユーザーに使用してもらい、評価をフィードバックしてもらいます。
ここでは、単に機能が設計書通りに動作するかだけではなく、使いやすさや、要求したとおりか、期待通りに問題が解決されているか、といった点を確認することがポイントとなります。なお、ユーザーからのフィードバックに基づいて、必要があればソフトウェアの修正や改善を行います。
- STEP3:改善と再評価
ユーザーからのフィードバックを受けてソフトウェアの修正を行った後、再度ユーザーに使用してもらい、妥当性が確保されたかを確認します。
このプロセスは、実際にユーザーの満足度が得られるまで繰り返されることもあります。
第4章:ブラックボックステストとホワイトボックステスト
ソフトウェアのVerification(検証)やValidation(妥当性確認)のプロセスでよく使われるテスト手法として、ブラックボックステスト(Black-box Testing)とホワイトボックステスト(White-box Testing)の2つがあります。この章では、それぞれの手法について詳しく解説します。
▲図1:V字モデルでみる「Black-box Testing」と「White-box Testing」の位置づけ
1. ブラックボックステスト(Black-box Testing)
ブラックボックステスト(Black-box Testing)とは、ソフトウェアの内部構造や処理方法を意識せずに、外部からの入力と出力の結果に基づいてソフトウェアをテストする手法で、V&VのValidation(妥当性確認)に該当します。
ブラックボックステストは、ソフトウェアのコードやアルゴリズムは一切考慮せず、ユーザーがどのように操作するかのみを考慮するテストで、ユーザー目線でユーザーになりきってテストをするといった特徴があります。
ブラックボックステストは、実際にソフトウェアを利用するときのシナリオに基づいて行うため、ユーザーが直面する可能性のある問題や不具合が検出しやすくなります。
- 例: ユーザーがログインページで正しいIDとパスワードを入力し、ログインできるかどうかのテストでは、プログラムの内部処理がどうなっているかは気にせず、画面上の動作のみを確認します。
2. ホワイトボックステスト(White-box Testing)
ホワイトボックステスト(White-box Testing)とは、ソフトウェアの内部構造やコードを意識してテストする手法で、こちらはV&VのValidation(検証)に該当します。
ホワイトボックステストは、コードやロジックに基づいて、システム内部が期待通りに動作しているかを確認するテストで、システム目線でテストをするといった特徴があります。
たとえば、特定の条件下で関数が正しく呼び出されるか、すべてのループが期待通りに動作しているかを検証するのがホワイトボックステストの典型例です。
ホワイトボックステストの利点は、内部構造やコードの正当性を直接検証できる点で、バグや欠陥がコードレベルで検出されやすいため、信頼性の高いシステムを構築するためには欠かせないテスト手法です。
- 例: ログイン機能の内部処理をテストする際に、パスワードのハッシュ化やデータベースの問い合わせが正しく動作しているかどうかを確認します。
第5章:V&V(Verification&Validation)の重要性
この章では、V&V(Verification&Validation)の重要性について2点取り上げて解説します。
1. 不具合発見の早期化
ソフトウェア開発では、V&V(Verification&Validation)を的確に活用することで、開発プロセスの早い段階での不具合発見とその修正が可能になります。
例えば、詳細設計や単体テストなどVerificationのプロセスで設計ミスやコーディングミスを発見することができれば、結合テストに入る前に修正を行うことができ、品質を確保することにつながります。
2. 品質向上とコスト削減
適切なV&V(Verification&Validation)の実施は、ソフトウェアの品質向上と開発コストの削減につながります。先に示したように問題を早期に解決することができるため、後々の修正コストが抑えられるうえ、ユーザーの期待に応じた高品質な製品・サービスの提供が可能になります。
第6章:V&V(Verification&Validation)とV字モデル
ここまでで、Verification(検証)とValidation(妥当性確認)の基本的な概念を解説してきましたが、これらを実際のソフトウェア開発の中でどのように適用するのかが次の課題となります。そこで登場するのが、V字モデルです。
1. V字モデルの基本構造
V字モデルはその名の通り、開発プロセスを「V」の字で表したものです。V字モデルでは、左側に開発フェーズ、右側にテストフェーズを示し、開発ステップごとに対応するテストがあることを表現した概念モデルです。またV字モデルは、Verification(検証)とValidation(妥当性確認)を効率的に行うためのものと言うこともできます。
- 左側(開発フェーズ)
要件定義、基本設計、詳細設計、実装といったプロセスが含まれます。 - 右側(テストフェーズ)
各開発フェーズに対応したテストが行われます。たとえば、要件定義に対応するのがシステムテスト、基本設計に対応するのが結合テストです。
▲図2:V&V(Verification&Validation)とV字モデルの関係
2. VモデルにおけるVerification(検証)とValidation(妥当性確認)
Vモデルでは、開発段階ごとに対応するテストが行われるため、ソフトウェアの品質を早期に確認できるという利点があります。
Verification(検証)は、単体・結合テストに組み込まれ、設計した通りにソフトウェアが作られているかを確認します。
Validation(妥当性確認)は、システムテストや受入テストを通じて行われ、ソフトウェアが実際にユーザーのニーズに合致しているかを確認します。
第7章:VerificationとValidationの適用例
続いてこの章では、実際のプロジェクトでのVerification(検証)とValidation(妥当性確認)の適用例を解説していきます。
ある企業が新しいWebアプリケーションを開発する際、開発初期から検証と妥当性確認をしっかり行いました。まず、開発段階では、機能が設計書通りに正しく実装されているかを細かくレビュー(Verification)し、さらに完成後には実際のユーザーに試用してもらい、使いやすさや必要な機能が満たされているかを評価(Validation)しました。結果として、ユーザー満足度は非常に高く、リリース後も順調で今のところ大きなトラブルゼロが続いています・・・
これは、プロジェクトにVerification(検証)とValidation(妥当性確認)が適用できた成功例です。
では続けて、失敗例も確認しておきましょう。
別のプロジェクトでは、レビューやテストでの検証プロセスが不十分であったために、リリース後に多くのバグが発生しました。設計通りに実装されていなかった部分もあり、ユーザーから多くの不満が寄せられました。また、妥当性確認も行われていなかったため、実際に使ってみたユーザーは「使いづらい」と感じ、多くの機能がユーザーの期待に応えられていないことから、結局イチから作り直すことに・・・
第8章:おまけ
さいごにV&V(Verification&Validation)が国際的にどのように定義されているかを記しておきます。
馴染みのない表現が多くわかりにくいかもしれませんが、ニュアンスだけ押さえておけばOKです。
規格 | V&V | 定義 |
IEEE 1012:2012 | Verification(検証) | 各開発工程の成果物が前工程で意図した要求事項あるいは条件を満たしているかどうかを決定するプロセス |
Validation(妥当性確認) | それぞれの開発工程の成果物が最終のシステムあるいはコンポーネントに対する利用者のニーズや意図された利用法などの要求事項を満たしているかどうかを決定するプロセス | |
ISO 9000:2015 | Verification(検証) | 客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること |
Validation(妥当性確認) | 客観的証拠を提示することによって、特定の意図された用途又は適用に関する要求事項が満たされていることを確認すること | |
バリー・ボーム博士の説明 | Verification(検証) | 正しく成果物を作成しているか? |
Validation(妥当性確認) | 正しい成果物を作成しているか? |
引用・参考元
https://standards.ieee.org/ieee/1012/4021/
IEEE 1012:2012に関する説明(英語)
https://www.ipa.go.jp/archive/publish/qv6pgp00000011f7-att/000064877.pdf
ISO 9000:2015(JIS Q 9000:2015)に関する独立行政法人情報処理推進機構(IPA)発行資料
https://www.nae.edu/312132/BARRY-W-BOEHM-19352022
バリー・ボーム博士に関する記事(英語)
第9章:まとめ
ソフトウェアの品質を確保するためには、V&V(Verification(検証)とValidation(妥当性確認))が不可欠です。
そして、それを効果的に行うために先に示したV字モデルの図は、非常に有用なフレームワークとして活用していただけます。
この記事では、V&V(Verification(検証)とValidation(妥当性確認))について、さまざまな角度からIT初心者の方にもわかりやすい内容を心掛けて解説してきました。
ソフトウェア開発においては、この2つの“V”の観点を押さえ、確実にプロセスに落とし込むことにより、ソフトウェアの品質を向上させ、ユーザーに満足してもらえる製品・サービスを提供することが可能となりますので、理解に至るまで繰り返しこの記事を読んでいただければと思います。
そして理解に至りましたら、これらのV&V(Verification(検証)とValidation(妥当性確認))の概念を実際のプロジェクトに適用していただき、あなた自身の開発スキルを高めていくための次のステップへとつなげていってもらえれば幸甚です。
【さらに詳しく知りたい方へ】
Verification(検証)とValidation(妥当性確認)について、より詳しく知りたい!と思われた方は、以下のブログも公開しておりますので、この機会にあわせてご一読ください。
なお、ブログの最新リリース情報につきましては、当社メルマガでリアルタイムにご確認いただけますので、本記事がよかった、ためになった、という方はぜひメルマガ登録もお願いします。
最新IT情報やお役立ち情報をコンサルタントが配信中!
QualityCubeでは、最上流の企画/要求定義工程から下流のテスト工程まで、プロダクト分析とプロセス分析による現状分析や品質コンサルティング、更にはDXコンサルティングも行っております。開発製品やサービスの品質向上や品質改善、その他DXに関することでご課題やご検討中のことがございましたら、ぜひお気軽にご相談ください。
ご相談は無料で承っております!
品質コンサルティング、DXコンサルティング、
プロジェクト支援のほか、IT・DX教育サービスも展開中!