ハードウェアにおけるVerificationとValidationの違いとは？

ハードウェア設計は、テストベンチ上では完全に正しく見えることがあります。たとえば、MCU は安定して 160 MHz で動作し、センサーは I²C で通信し、電源はフルロード時でも 12 V を維持している、といった具合です。しかし、あらゆる要件を満たしている製品でも、実際にユーザーの手に渡ると期待に届かないことがあります。

検証と妥当性確認（V&V）は、要件を満たすことと、実環境で本当に必要とされることを満たすこととの間にあるギャップを埋めるためのものです。ハードウェアチームの中には、この 2 つの用語を混同している場合があります。V&V をひとつの工程として扱ったり、プロトタイプが動いているように見えるからといってどちらかを省略したりすると、監査時や製品が現場に出た後になって問題が見つかることがあります。

この記事では、ハードウェア開発における検証と妥当性確認の意味と、その違いを説明します。また、V-Model を通じて V&V がどのように要件と結び付くのか、V&V 計画をどのように作成するのか、そしてよくあるミスをどのように避けるのかについても取り上げます。

主なポイント

• 検証は、ハードウェアが定義された技術要件を満たしているかを確認します。 
• 妥当性確認は、完成した製品全体が、設計時に想定されたニーズを満たしているかを確認します。
• V&V は早い段階で開始し、ハードウェア開発全体を通して、要件を計画された活動、受け入れ基準、結果、裏付けとなる証拠に結び付ける必要があります。

検証とは何か

検証とは、ハードウェアが定義された要件およびエンジニアリング仕様に適合しているかを確認するプロセスです。これは次の問いに答えるものです。 私たちは製品を正しく作っているか？

検証の目的は、思い込みを証拠に置き換えることです。回路が動作するはずだと想定するのではなく、チームは設計や物理プロトタイプを定義済みの要件と照らし合わせ、それを満たしているかどうかを示す証拠を記録します。

検証には、次のような活動が含まれます。

• 要件レビュー： 要件が明確で、一貫性があり、達成可能で、トレーサブルであり、かつ検証可能であることを確認します。
• 設計レビュー： 回路図、PCB レイアウト、機械図面、インターフェースを、定義された要件および設計ルールと照合します。
• 解析とシミュレーション： 計算やモデルを用いて、熱マージン、信号整合性、タイミング、消費電力などのパラメーターを確認します。
• 検査： 物理ハードウェア、寸法、実装、部品、接続が設計文書どおりであるかを確認します。
• 試験と測定： ハードウェアを測定し、その結果を要求された制限値または期待される設計動作と比較します。

妥当性確認とは何か

妥当性確認とは、ハードウェアが意図された用途、ユーザー、運用環境において実際に機能するかを確認するプロセスです。これは次の問いに答えるものです。 私たちは正しい製品を作っているか？

妥当性確認の主な目的は、その製品が設計時に解決しようとした問題に実際に対処できていることを示す証拠を得ることです。ある設計がすべての技術要件を満たしていても、実際の運用条件で期待どおりに機能しなければ不十分である可能性があります。妥当性確認によって、完成したシステム全体が、関係者が実際に必要としている役割に適しているという確信が得られます。

妥当性確認には、次のような活動が含まれます。

• 要件の妥当性確認：  要件がステークホルダーのニーズと、製品が実使用時に直面する条件を適切に捉えていることを確認します。
• システムレベル試験： 完成品全体を評価し、すべてが意図どおりに連携して動作することを確認します。
• ユースケース試験： 製品が、想定されたタスクやシナリオを実行できるかを確認します。
• 環境試験： 現実的な温度、湿度、振動、負荷、その他の運用条件下で製品を評価します。
• フィールド試験： ハードウェアを意図された環境で動作させ、ラボでは現れない問題を明らかにします。
• ユーザー評価： 代表的なユーザーに製品を実際に使用してもらい、実際のワークフローやニーズを支援できているかを確認します。

ハードウェア開発プロセスにおける検証と妥当性確認。

検証と妥当性確認の違い

V&V では、試験、測定、検査、解析といった同じエンジニアリングツールが使われることがよくあります。違いは、その結果によって何を証明しようとしているかです。

たとえば、恒温槽試験によって、製品が規定された −20 °C ～ 60 °C の範囲で動作することを検証できます。一方、妥当性確認で問われるのは、その温度範囲が実際のニーズに合っているかどうかです。製品が日光にさらされる筐体に設置され、その内部温度が 75 °C に達するのであれば、検証には合格しても、実使用では失敗する可能性があります。同じ恒温槽でも、完成品が現場で実際にさらされる温度プロファイルで試験を行えば、妥当性確認にも活用できます。

検証は通常、定義済み要件に対してより直接的な合否結果を与え、個々の要件、設計、またはハードウェア要素に適用できます。妥当性確認は、より広い視点で統合されたシステム全体を見て、その総合的な振る舞いが意図された用途に対して許容できるかを評価します。

要件主導のプロセスでは、検証は個々の技術要件が満たされたことを示す証拠を積み上げます。次に妥当性確認では、完成品全体が実際の運用条件下でステークホルダーのニーズを満たしているかを確認し、要件そのものが不完全または誤っていたことを明らかにする場合もあります。

V&V は V-Model にどう当てはまるか

V-Model は、ハードウェア開発プロジェクト全体で V&V をどのように整理するかを示します。

V-Model は、システムのライフサイクルを V 字型で表したものです。左側はステークホルダーのニーズや期待から始まり、それらをシステム要件およびサブシステム要件に変換し、さらにアーキテクチャや詳細設計へと具体化していきます。V の底辺が実装です。右側では統合を通じて上へ戻り、コンポーネント、サブシステム、完成品の各レベルで試験を行います。

システムエンジニアリングプロセスの V-Model。

左側の各レベルは右側の試験レベルと対応しており、その対応関係によってトレーサビリティが生まれます。各要件は、それを確認する V&V 活動とその証拠に結び付けられ、チームは設計が進行中の段階でその活動を計画します。 

たとえば、「12 V 入力はフルロード時でも ±5% 以内を維持しなければならない」という要件は、複数のレベルで確認できます。回路図に対する部品定格の確認、基板の電源シミュレーション、そして組み立て後の製品での測定です。

この構造の中で、V&V はそれぞれ異なる役割を持ちます。

• 検証は、各レベルにおいて、構築されたものが左側にある対応する要件や設計と一致していることを確認します。レビュー、解析、シミュレーションは左側で始まり、試験と測定は右側を上がっていく形で実施されます。
• 妥当性確認は、左上にあるステークホルダーのニーズに対して確認を行います。まず、それらのニーズに照らして要件の妥当性確認を行い、次に右上でシステムレベルの確認として再び現れます。すなわち、完成品はステークホルダーのニーズと意図された用途を満たしているか、という問いです。

V&V 計画の作成方法

ハードウェアが試験段階に到達する時点では、チームはすでに、何を確認するのか、それがどの要件に関係するのか、結果をどのように判断するのか、そしてどのような証拠を記録しなければならないのかを把握しているべきです。V&V 計画は、そうした判断を 1 つの文書にまとめるものです。

V&V 計画では通常、次の 6 つの判断を扱います。

• 対象範囲を定義する： どの製品、サブシステム、またはハードウェア機能を計画の対象とするのか、何を対象外とするのか、そしてリスクに基づいてどこに優先的に V&V の工数を割くのかを決定します。
• V&V 活動を要件に結び付ける： 技術要件は検証活動に、ステークホルダーのニーズは妥当性確認活動に結び付けます。これにより、それぞれに証拠へ至る明確な経路ができます。
• 方法を選ぶ： 各要件を、検査、解析、実証、試験、またはその他の適切な方法のどれで検証するか、また各ステークホルダーのニーズを、ユースケース試験、環境試験、ユーザー評価、またはフィールド試験のどれで妥当性確認するかを決定します。
• 条件と受け入れ基準を定義する： ハードウェア構成、運用条件、設備、そしてその活動が合格か不合格かを決める測定可能な結果を明記します。
• 誰が何をいつ行うかを計画する： 責任、必要なリソース、タイミングを割り当て、各活動をプロトタイプ、EVT、DVT、PVT ビルドなど、ハードウェア開発の適切な段階に対応付けます。
• 結果と証拠をどのように記録するかを決める： 各結果をどのように記録し、裏付けとなる証拠にどう結び付けるか、また設計変更後にどの活動を再実施する必要があるかを定義します。

よくある落とし穴とその回避方法

ソフトウェアのバグはアップデートで修正できることが多い一方で、ハードウェア設計の問題は、基板を製造する前の段階で対処するのが最も容易です。こうした問題の多くは、要件の記述方法や、V&Vの計画方法に起因しています。

以下の表では、V&Vでよくある落とし穴と、それを避けるためのベストプラクティスを示します。

V&Vの利点

開発後半でのハードウェア変更は、ソフトウェア変更より高コストになる傾向があります。基板のリスピン、金型変更、認証試験の失敗は、実際に時間と予算を消費し、出荷済み製品のハードウェアは後から修正するのが困難です。これが、ハードウェア開発において検証と妥当性確認が特に重要視される理由です。両者を組み合わせることで、チームは主に次の4つの利点を得られます。

• 問題の早期発見: レビュー、シミュレーション、初期プロトタイプにより、要件の抜け漏れ、設計ミス、見落としを明らかにできます。この段階であれば、通常は仕様書や回路図の修正で対応できます。
• 各要件に対する証拠: 検証では、各要件が結果に結び付けられるため、チームは何を、どのように確認し、どのような結果になったかを示せます。こうした証拠はコンプライアンス対応にも役立ち、医療機器のような規制対象ハードウェアでは、通常、設計管理の一環として求められます。
• 実際の使用への適合性: 妥当性確認では、環境、ユーザー、作業内容に照らして完成品全体を評価します。これにより、要件ごとのチェックでは見落とされがちな、センサーのドリフトや日光下でのディスプレイの映り込みといった問題もカバーできます。
• 次のサイクルへの入力: 測定されたマージンや不具合の発見結果は、設計変更、将来の改訂、次世代製品の開発に活かされます。また、要件を厳しくすべき箇所、あるいは緩和すべき箇所も明らかになります。

検証と妥当性確認を管理するためのソフトウェアツール

ハードウェア開発では多くの要件とテスト結果を扱うため、プロジェクト全体でそれらを手作業で追跡するのは困難になりがちです。チームは、次のような分散したファイルや連携していないツールの寄せ集めに陥ることがあります。

• スプレッドシートとドキュメント: 要件数やテストケースが限られた小規模プロジェクトには実用的です。しかし、V&Vの範囲が広がるにつれて、トレーサビリティや監査対応の維持には手作業の管理が必要になり、記録の整合性が崩れることがあります。
• 課題管理ツール（例: Jira、GitHub）: これらのツールは、リンク、フィールド、タグを使ってV&V作業を整理し、関連項目を結び付けるように調整できます。ただし、要件のトレーサビリティとV&Vの完全なカバレッジを維持するには、通常、追加設定やカスタムプラグインが必要です。
• 専用の要件管理ツール: 要件の構造化とトレーサビリティのために設計されています。ただし、ツールによっては、テスト計画や証跡の収集に別モジュールや外部テストツールとの統合が必要になる場合があります。 

要件とあわせて共有ワークスペース内でV&V活動を計画・追跡したいチーム向けに、Requirements Portalは要件を検証計画、テスト実行、証跡、変更履歴と結び付けます。これにより、チームは何が検証済みで、何にまだ対応が必要かを把握できます。

結論と次のステップ

要するに、検証はハードウェアが仕様を満たしていることを証明し、妥当性確認はそれが実際にユーザーにとって機能することを証明します。これを実現するには、V&Vを最終段階のチェックリストにしてはいけません。初日から製品開発プロセスに組み込む必要があります。

V&Vのフレームワークについてさらに理解を深めたい場合は、次の資料が役立ちます。

• NASA Systems Engineering Handbookは、宇宙グレードのハードウェア製品におけるV&Vの計画と実行に関する実践的なガイダンスを提供します。
• Guide to the Systems Engineering Body of Knowledge（SEBoK）は、V&Vをより広いシステムズエンジニアリングの観点から説明しています。
• INCOSE V&V Across Product Lifecycleでは、ライフサイクルの各段階におけるV&V、Vモデル、V&V手法、テストケース、成功基準を扱っています。

理論から実践へ進む準備ができているなら、Requirements Portalを試して、テストケースを要件や電子設計に関連付け、カバレッジを追跡し、エンジニアリング証跡を記録してください。

よくある質問

VerificationとValidationは同じですか？

いいえ。同じではありません。Verificationは、ハードウェアが定義済みの要件に適合しているかを確認します。Validationは、その要件と製品が、実際の使用においてステークホルダーのニーズを反映しているかを確認します。

VerificationとValidationでは、どちらが先ですか？

どちらも早い段階で計画すべきであり、どちらも単一の工程ではありません。Verificationは、設計が進むにつれてレビュー、解析、シミュレーションから始まります。Validationは、まず要件がステークホルダーのニーズに合っているかを確認することから始まり、統合された製品の形が見えてくるにつれて、より重要性が高まります。

一般的なV&V手法にはどのようなものがありますか？

一般的なV&V手法には、レビュー、検査、解析、シミュレーション、デモンストレーション、試験があります。同じ手法でも、定義済み要件を確認するのか、意図された用途の文脈で製品を評価するのかによって、VerificationにもValidationにも用いることができます。