製品開発では、試作が進むほど評価項目が増えます。耐久、温度、振動、安全性、規格、顧客要求、量産条件――それぞれの試験結果がExcel、PDF、測定ログ、共有フォルダ、メール添付に分かれて残ると、後から確認するときに時間がかかります。
特に困るのは、「この要求は、どの試験で確認したのか」「この試験結果は、どの図番Revのものなのか」「顧客や認証機関へ出す証跡はどれなのか」がすぐ分からない状態です。 DVP&R（Design Verification Plan & Report）は、試験計画表を作ること自体が目的ではありません。 要求、仕様、図番Rev、試験条件、結果、判定、提出物をつなぎ、後から説明できる状態を維持するための管理設計です。
DVP&Rの画面を作るとき、最初に考えるべきなのは表の列数ではありません。 どの情報とどの情報を結び付けるかです。 最低限、次の4点がつながっていないと、後から説明するときに確認が増えます。
構造例 要求から証跡までをつなぐ見せ方
REQ-034
高温環境で連続稼働できること。
T-202604-018
85℃／96h 連続運転試験。
PASS
出力低下は許容範囲内。
試験報告書、測定ログ、写真、校正証明を添付。
この関係が画面上で確認できると、監査・顧客説明・設計変更時の確認が短くなります。
DVP&Rの運用が乱れる大きな原因は、何を基準に結び付けるかが決まっていないことです。 ファイル名や担当者名で探す運用では、担当交代やRev変更が入ったときに確認に時間がかかります。
最低限、次のIDを固定しておくと、Web化したときにデータを扱いやすくなります。
DVP&RをWeb化するときは、Excelの台帳に近い見え方から始めると、現場に受け入れられやすくなります。 ただし、Excelの列をそのまますべて移すのではなく、要求・試験・判定・証跡を確認するために必要な列から始めます。
管理画面 DVP&R台帳の列イメージ
まずは、要求・対象Rev・試験条件・判定・証跡を一覧で確認できる列構成から始めると運用に乗せやすくなります。
品質クレームや不具合対応とつなぐ場合は、品質クレーム管理の設計例 の「原因・対策・再発防止を結び付ける考え方」も参考になります。
DVP&Rで特に注意したいのが、Rev違いの試験結果を混ぜてしまうことです。 古い図番Revで実施した試験結果を、最新版の設計に対する証跡として扱ってしまうと、後で説明が難しくなります。
対策としては、試験登録時に対象Revを必須にし、試験実施後は簡単に書き換えられないようにします。 変更が必要な場合は、理由と承認履歴を残す設計にします。
Rev管理 試験結果と設計変更の関係を確認する画面
設計変更時に、関連する試験IDを洗い出せると、再試験や追加評価の判断がしやすくなります。
この考え方は、ECR/ECO（設計変更）の申請フロー設計 と組み合わせると実務に近い形になります。 設計変更が入ったときに、どの試験を見直すべきかが分かる状態にしておくことが重要です。
顧客や認証機関に提出する場合、試験結果のファイルを個別に探して集める運用は危険です。 提出レポート、測定ログ、校正証明、写真、試験手順書、逸脱説明書などを、提出単位のパッケージとして管理すると確認漏れを減らせます。
提出物 証跡パッケージの管理画面
提出物をパッケージ化すると、「どのファイルを提出したか」「誰が確認したか」が後から確認できます。
技術資料の公開範囲やゲート管理は、技術資料DLのゲート設計 に近い考え方です。 社内用の編集ファイルと、顧客提出用の固定版PDFを分けて扱うと、誤提出を防ぎやすくなります。
DVP&Rの管理は、項目を増やせばよいわけではありません。 入力が面倒になると、担当者は最低限しか登録しなくなります。 結果として、台帳は存在していても、実際にはファイル名やメールで探す状態に戻ってしまいます。
入力負担を抑えるには、手入力を減らし、選択式・検索式・自動補完を使うのが現実的です。
試験管理は範囲が広いため、最初から全部を作ろうとすると要件が膨らみます。 小さく始めるなら、まずは要求と試験結果を結び付ける台帳から入るのが現実的です。
手順 DVP&R管理を小さく始める流れ
仕様書や要求事項に暫定IDを付け、試験結果と結び付けられる状態にする。
試験項目、対象Rev、条件、責任者、期限を台帳化する。
判定、報告書、ログ、写真、関連不具合を同じ画面で確認できるようにする。
顧客提出や認証提出がある場合は、証跡パッケージとして管理する。
DVP&Rを管理する目的は、試験表をきれいに作ることではありません。 要求に対して、どの試験を行い、どのRevで評価し、どの結果で判定し、どの証跡を提出できるのかを、後から説明できる状態にしておくことです。
そのためには、要求ID、試験ID、成果物ID、対象Revを固定し、Rev違いの結果を混ぜない仕組みを作る必要があります。 さらに、顧客や認証機関へ提出するファイルは、個別ファイルではなく提出パッケージとして扱うと確認しやすくなります。
最初から大きな仕組みにする必要はありません。 まずは、既存のExcelやファイルサーバーを活かしながら、要求・試験・判定・証跡をWeb上で結び付けるところから始めるのが現実的です。 製造業全体の活用イメージは、製造業向けシステム開発例 でも紹介しています。