設計変更は、図面やBOMを更新して終わる仕事ではありません。
部材、工程、試験、規格、在庫、出荷、客先提出物まで含めて影響が広がるため、申請の入口が曖昧だと後工程でずれが出やすくなります。
現場で本当に困るのは、変更の是非そのものよりも、どこまで影響が及ぶかを拾いきれないことです。
図番Revは更新されたのに旧在庫の扱いが決まっていない、工程変更があったのに検査条件が旧版のまま、客先通知が必要なのに営業へ伝わっていない。設計変更の事故は、こうした抜けから起こります。
ECR/ECOをWeb化するときに狙うべきなのは、申請を速く流すことだけではありません。 影響範囲・承認・切替条件・通知先を漏らしにくい形にすることが中心です。 このページでは、そのために最低限必要な項目と画面の考え方を、実務に沿って整理します。
設計変更の運用で最初に整理したいのは、ECRとECOを同じものとして扱わないことです。 ここが混ざると、「まだ変更理由を整理している段階」なのか「すでに切替を指示する段階」なのかが曖昧になります。
ECRの段階では、影響範囲がまだ読めないことも普通です。 だからこそ、ECRでいきなりすべてを確定させようとせず、ECOに上げる前に影響を確認する流れを持たせた方が運用しやすくなります。
画面イメージ：ECRとECOの役割を分ける
ECRは「問題の整理」、ECOは「反映の指示」と役割を分けると、途中で判断が飛びにくくなります。
ECR段階で影響範囲まで全部埋めるのは現実的ではありません。影響を見てからECOに上げる前提の方が、現場では回しやすいです。
ECRで大事なのは、「どう変更するか」を最初から書かせることではなく、 何が起きていて、なぜ変更が必要なのかをそろえることです。
不具合起点なら、RMAや不具合受付フォームに近い項目構成がそのまま使えることもあります。 設計側だけが分かる書き方にせず、品質、製造、購買、営業が見ても前提を追える程度に情報をそろえておくと、後のやり取りが短くなります。
ECOで一番価値が出るのは、変更内容そのものよりも、どこに影響が及ぶかを一覧で見られることです。 ここを自由記述だけにすると、項目の抜けが起きやすくなります。
そのため、影響範囲はテキスト欄だけでなく、チェック項目として持たせた方が安全です。 設計者がその場で判断できないものもあるので、状態は「Yes/No」だけでなく「要調査」も入れておくのが現実的です。
画面イメージ：影響範囲チェックは Yes / No / 要調査 で持つ
| 確認項目 | 状態 | 確認したい内容 |
|---|---|---|
| BOM影響 | Yes | 部材置換、代替品、AVL変更があるか |
| 工程影響 | 要調査 | 作業手順、治具、検査ポイントに変更が必要か |
| 試験影響 | Yes | 再評価、DVP&R更新、試験成績の取り直しが必要か |
| 規格影響 | No | 認証、宣言書、提出物の更新要否 |
| 在庫影響 | 要調査 | 旧品在庫、仕掛、払い出し条件、廃棄判断 |
| 客先影響 | Yes | 通知、承認、提出物、切替説明が必要か |
「要調査」を用意しておくと、その場で曖昧なまま No に流されるのを防ぎやすくなります。
設計変更の承認が重くなるのは、毎回同じメンバーを通すからです。 逆に軽すぎると、必要な部門が抜けます。 現場で回しやすいのは、影響項目に応じて承認対象を追加する形です。
たとえば次のような分岐は比較的分かりやすく、運用にも乗せやすいです。
画面イメージ：影響項目に応じて承認ルートを増やす
関係ない承認者まで毎回入れるより、影響項目に応じて追加する方が停滞しにくくなります。
この分岐が作れると、承認が単なる通過儀礼ではなく、必要な確認の場として機能しやすくなります。 最初から細かくしすぎず、停滞しやすい箇所が見えてから分岐を足す進め方の方が現実的です。
設計変更でよく揉めるのは、変更内容そのものより「いつから切り替えるのか」です。 ここが曖昧だと、製造基準と出荷基準がずれたり、旧品在庫の扱いが宙に浮いたりします。
そのため、ECOでは切替条件を必須にしておく方が安全です。
画面イメージ：切替条件を曖昧にしない
切替日だけでなく、どの条件から新Revかを持たせると、現場側の判断が揃いやすくなります。
通知は、送信の仕組みを作っただけで安心しやすい部分です。 ただ、関係者の全員に毎回送る形だと、通知疲れが起きて読まれなくなります。
そのため、通知は一律ではなく、影響項目ごとに送る先を分ける方が扱いやすくなります。
画面イメージ：影響項目に応じて通知先を切り替える
通知は多ければ安心ではありません。必要な人だけが必要な内容を見る形にした方が機能します。
通知先の例としては、次のような考え方が分かりやすいです。
あわせて、通知本文も「ECOが起票されました」だけでは弱いです。 対象品番、現行Rev、新Rev、切替条件、要確認項目が短く入っていた方が、受け取った側が動きやすくなります。
ECR/ECOの仕組みを作るとき、最初からPDM/PLMのような厳密さを全部再現しようとすると重くなります。 現場で止まらずに使い始めるには、まず次の3点が揃うだけでもかなり変わります。
ここまででも、メールや口頭中心の運用よりはかなり抜けを減らしやすくなります。 そのうえで、条件分岐の承認、帳票自動生成、DVP&Rや規格提出物との連携などを段階的に足していく進め方の方が現実的です。
ECR/ECOを回すときに重要なのは、設計案の是非だけではありません。 どこに影響が及ぶのか、誰が確認すべきか、いつから切り替えるのか、誰へ知らせるのかまでを漏れなく押さえることが中心です。
そのためには、 ECRで理由と現象をそろえる、 ECOで影響範囲を Yes / No / 要調査 で持つ、 影響に応じて承認を分岐させる、 切替条件を必須にする、 通知先を条件付きで絞る、 という設計が扱いやすくなります。
製造業の実務を止めずにまとめたいなら、こうした設計変更フローは 製造業向けシステム開発例 の文脈とも相性が良いです。 まずは「どこが抜けやすいか」を見える形にするところから始めると、運用に乗せやすくなります。