試験計画（DVP&R）を迷子にしない管理設計｜要求→試験→判定の紐づけ

製品開発が進むほど、試験の数は指数的に増えます。ところが、試験結果が散らばったままだと、最後に必ず同じ壁に当たります。
「この要求は、どの試験で満たした？」／「この結果は、どのRevの評価？」／「提出用の証跡はどれ？」
DVP&R（Design Verification Plan & Report）は、計画表を作ることが目的ではなく、要求・仕様・試験・結果をつないで“説明できる状態”を作るのが本質です。

1. まず“紐づけの単位”を決める：要求ID／試験ID／成果物

DVP&Rが破綻する原因の多くは、紐づけの単位が曖昧なまま運用が始まることです。
最低限、次の3つのID（またはキー）を固定します。

• 要求ID：仕様書・要求事項の通し番号（例：REQ-123）
• 試験ID：試験計画／実施を一意に示す番号（例：T-202512-014）
• 成果物：提出レポート、ログ、生データ、写真など（添付群）

2. 画面（台帳）の見え方：DVP&Rを“表”として持つときの列設計

Excelで慣れている現場ほど、Webに移すなら“同じ見え方”から入ったほうが理解コストが下がります。
その上で、Webならではの強み（リンク、履歴、検索、添付の整列）を足していきます。

2-1. 最低限の列（まずはここまで）

• 要求ID／要求概要
• 対象（品番・型式、図番、Rev）
• 試験項目（試験種別）
• 試験条件（要点だけ）
• 判定（PASS/FAIL/保留）
• 証跡リンク（レポート／ログ）
• 責任者／期限

2-2. “あとで効く”列（本格運用で差が出る）

• 逸脱時の扱い：再試験／設計変更／特採（例外承認）など
• 関連不具合：不具合ID、是正措置（8D/対策）
• 提出先：社内、顧客、認証機関（提出物セットの単位）

※ このあたりは、品質クレーム系の設計思想（“原因・対策・再発防止の紐づけ”）と近いので、品質クレーム管理の設計例 の考え方も流用できます。

3. “Rev地獄”を避ける：図番Revと結果を自動でズラさない仕組み

DVP&Rで最も痛い事故は、古いRevの結果を最新版に転用してしまうことです。
対策はシンプルで、試験IDに「評価対象Rev」を固定し、後から書き換えられないようにします。

• 試験登録時に「対象Rev」を必須入力（プルダウン＋自由記述）
• 試験実施後は「対象Rev」をロック（変更は申請制）
• 設計変更（ECO）が起きたら「影響を受ける試験」を一覧で洗い出せる

4. 提出物が絡む場合：証跡セット（提出パッケージ）の管理

顧客や認証機関に提出する場合、個別ファイルではなく“セット”で管理した方が事故が減ります。
例：提出レポート、測定ログ、校正証明、写真、手順書、逸脱説明書（必要時）など。

• 提出パッケージID（例：SUB-202512-03）を作る
• パッケージに含まれる成果物をチェックリスト化
• 提出版（PDF化・押印版）と、社内版（編集可能）を分ける

技術資料の扱いに近いので、公開範囲やゲートの設計は 技術資料DLのゲート設計 を土台にすると整理が早いです。

5. 運用の現実：入力負荷を増やさずに“正確性”を上げるコツ

入力が面倒だと、DVP&Rは必ず形骸化します。
そこで、入力を増やす代わりに、選択肢化と自動補完で正確性を上げます。

• 試験種別・設備・測定機はマスタ化（表記揺れを潰す）
• 品番／図番は検索して選ぶ（手入力を減らす）
• 添付は「ドラッグ＆ドロップ」でまとめて登録できる

インテンスでも、試験台帳のWeb化は「入力を増やす」方向に行くと失敗しやすいので、まずは“揃えるだけ”から始める設計を採ることが多いです。
製造業の活用イメージとしては 製造業向けシステム開発例 の考え方とも相性が良いです。

まとめ

DVP&Rを“作る”のではなく、“説明できる状態を維持する”ためには、要求ID・試験ID・成果物を一貫して紐づけ、Revをズラさない仕組みを先に作るのが要点です。
そのうえで提出パッケージ、逸脱、関連不具合までつながると、会議や監査の準備が劇的に短くなります。