設計変更（ECO）と評価結果のトレーサビリティ設計｜図面・BOM・試験データをつなぐ

設計変更（ECO）は、図面やBOMを更新するだけで終わらせると、後から「なぜ変えたのか」「どの試験で妥当性を取ったのか」が追えなくなります。
この状態は、監査・顧客説明・不具合再発時に必ず痛みになります。
この記事では、ECOを起点に、影響範囲・評価計画・試験結果・承認の証跡まで一本で追えるトレーサビリティ設計を整理します。

1. ECOを「申請」ではなく「変更レコード」として扱う

ECOは書類ではなく、変更の履歴そのものです。
よって、ECOには最低限、次を持たせます。

• 変更理由：不具合是正、コスト、入手性、性能、規格対応など
• 変更対象：図面、仕様、ソフト、治具、工程、検査基準など
• 影響範囲：対象品番、ロット、顧客、工程、在庫
• 必要評価：何を以って妥当性を取るか（評価計画）

影響範囲を引くには、品目・BOMが整っていることが前提になります（品目マスタ・BOM設計）。

2. Rev（版）を揃える：図面Rev・BOM Rev・仕様Revを必ず結びつける

トレーサビリティが崩れる最大要因は、版のズレです。
ECOから見て、どのRevが「変更前」で、どのRevが「変更後」かを明確にします。
版管理の思想は 版管理 を土台にし、差し替えではなくRevで管理します。

• 変更前：図面Rev=A / BOM Rev=3
• 変更後：図面Rev=B / BOM Rev=4
• 有効開始日（いつから切替か）

3. 評価計画をECOに紐づける：何をやれば承認できるのか

ECOの承認で揉めるのは「評価が足りる/足りない」の論点です。
これを防ぐには、ECOに評価計画をぶら下げ、承認条件を明示します。

• 評価項目（耐久、環境、機能、安全、互換など）
• 合否基準（数値・判定条件）
• 供試体（サンプルID、ロット、前処理）
• 期限（設計DR、量産切替、顧客提出）

評価依頼をフォーム起点で回すなら、案件一覧の“見える化”（試作・評価依頼フォーム）と繋ぐと、計画が現場で回ります。

4. 試験結果は「探せる形」で格納し、ECOにリンクする

ECOに「試験しました（PDF添付）」だけだと、後で探せません。
試験結果は条件で引ける形（試験レコード＋条件＋添付）で整理し（評価データ整理）、ECOからリンクします。
ここで初めて、ECO→評価→根拠が一本で繋がります。

5. 不具合（RMA）起点の設変：原因と恒久対策の鎖を切らない

設変の多くは不具合起点です。
不具合受付（RMAフォーム）→原因分析→ECO→評価→承認、の鎖が残ると再発防止が効きます。
技術問い合わせが起点の場合は、ナレッジ化（最低限の項目設計）へも戻せるようにします。

6. 承認・リリース：いつから切替で、現場にどう伝えるか

承認は、技術的妥当性だけでなく、切替手順（在庫・工程・検査）の合意が必要です。
承認フローは 承認フロー設計 を土台に、誰がどこまで承認するかを決めます。

• 技術承認（設計）
• 品質承認（検査・規格）
• 製造承認（工程・治具・手順）
• リリース（有効開始日・切替条件）

品質保証・規格認証との共有は、Webで証跡が残る形が強いです（品質保証・規格認証との情報共有）。
インテンスでも、ECOは「図面更新」ではなく、評価と承認の鎖が切れない設計を重視します。

まとめ

ECOのトレーサビリティは、変更理由→影響範囲→評価計画→試験結果→承認→リリースの鎖を切らないことです。
図面Rev・BOM Rev・評価結果を結び、試験結果は探せる形で格納し、RMAやナレッジにも戻れる動線を作る。
この設計ができると、監査・顧客説明・再発防止が現実的に強くなります。