図面は新しいRevになったのに、製造現場では旧版の作業手順書が使われている。倉庫には旧部品が残り、検査部門には変更が伝わっていない。設計変更で起きやすいのは、変更内容そのものの誤りより、変更が必要な対象の見落としです。
ECR/ECOの申請フローでは、変更を承認するだけでなく、影響する部門と文書、旧品の処置、新Revへ切り替える条件、実施後の確認までを一つの案件として管理します。メールや口頭で進めると、承認記録はあっても、誰がどの対応を終えたのかを追えない場合があります。
この記事では、ECR・ECO・ECNの違いを確認したうえで、申請項目、影響確認、承認ルート、Rev切替、旧品処置、通知、変更完了の管理方法を順に解説します。Excelや既存のワークフローから始める場合にも使えるよう、状態遷移、部門ごとの権限、監査履歴、他システムとの連携範囲も取り上げます。
申請書の電子化だけを目的にせず、承認後の実施と確認まで追えるかという視点で読み進めてください。
設計変更管理では、ECRとECOに加えてECNという名称が使われます。ただし、略称の正式名称や文書の責任範囲は企業や使用するシステムによって異なります。一般的な役割を参考にしながら、自社ではどの時点を承認、実施指示、通知とするのかを明文化します。
| 文書・状態 | 主な役割 | 判断・記録する内容 |
|---|---|---|
| ECR Engineering Change Request |
変更の必要性を提案し、実施すべきか検討する | 発生事象、変更理由、対象、緊急度、技術面・費用面の影響 |
| ECO Engineering Change Order |
承認された変更の実施内容を指示する | 変更前後、対象Rev、切替条件、旧品処置、担当者、期限 |
| ECN Engineering Change Notice |
承認済みの変更内容と適用時期を関係者へ通知する | 通知対象、発効日、対象製品、実施事項、受領・確認状況 |
ECOとECNをひとつの文書として扱う企業もあれば、実施指示と通知を分ける企業もあります。「ECO承認後に変更を実施できるのか」「ECN発行まで製造へ反映しないのか」を社内規程と一致させます。
設計変更の申請フローを作る際は、最初にECRとECOの役割を決めます。両者を区別せず、ひとつの申請書で変更提案から実施指示まで行うと、検討中の内容と実施が決まった内容が混在します。
ECRを起票した時点では、変更方法や影響範囲が確定していないことがあります。その状態で実施日や在庫処置まで入力必須にすると、根拠のない予定が登録されたり、入力欄を埋めるためだけの回答が記載されたりします。
ECRでは変更の必要性を検討し、技術的な対応案と影響範囲を確認した後、実施する変更をECOとして確定する流れが分かりやすいでしょう。
画面イメージ：ECRとECOの役割を分ける
変更の検討段階と、承認後の実施指示を分けることで、未確定情報と確定事項を区別できます。
ECRを使用せず、軽微な変更をECOから開始する企業もあります。その場合は、どの条件ならECRを省略できるのかを規程として決めておく必要があります。
ECRの目的は、設計者に変更案を提出させることだけではありません。まず、なぜ変更を検討する必要があるのかを関係者が確認できる状態にします。
起票者が営業、品質保証、製造、購買など設計部門以外の場合、具体的な設計変更案を提示できないこともあります。そのため、ECRでは解決方法よりも、現在の問題、要求内容、発生条件を記録できる項目が必要です。
「コストを下げたい」「不具合があった」といった短い記載だけでは、変更の必要性や優先度を判断できません。対象数量、現在の不良率、部品の供給終了日、顧客から求められている回答期限など、判断に必要な背景を記録します。
変更理由を自由記述だけで登録すると、後から「部品廃止に伴う変更」「品質不具合に伴う変更」などを抽出できません。
変更理由には選択項目を設け、詳しい事情を自由記述で補足する構成が適しています。
分類項目があれば、変更理由別の件数や承認期間も集計できます。ただし、分類だけでは具体的な事情が分からないため、説明欄は別に設けます。
ECOでは、「何をどの状態からどの状態へ変更するのか」を明確にします。
「最新図面へ変更」「一部寸法を修正」だけでは、承認者や製造部門が変更内容を判断できません。変更箇所をマーキングした図面、変更前後の数値、BOMの差分などを添付し、確認対象を明確にします。
複数の品番や図面をひとつのECOで変更する場合は、対象ごとに変更前Revと変更後Revを記録します。代表品番だけを記載すると、派生製品や共通部品への反映状況を確認できなくなるためです。
設計変更で確認漏れが生じやすいのは、設計者が直接管理していない業務への影響です。図面とBOMは確認されても、製造手順、検査条件、認証書類、旧在庫、顧客への申請が対象から外れることがあります。
影響範囲を自由記述だけで回答すると、起票者が思い付いた内容しか記録されません。あらかじめ確認対象を一覧にし、それぞれの状態を登録できるようにします。
画面イメージ：影響範囲を「該当」「非該当」「要調査」で確認する
| 確認項目 | 状態 | 確認する内容 |
|---|---|---|
| BOMへの影響 | 該当 | 部材置換、数量変更、代替品、承認済み調達先の変更があるか |
| 製造工程への影響 | 要調査 | 作業手順、設備、治具、製造条件、検査箇所を変更する必要があるか |
| 試験への影響 | 該当 | 設計検証、妥当性確認、DVP&R、試験成績書の更新が必要か |
| 規格・認証への影響 | 非該当 | 認証、届出、宣言書、適合証明、顧客提出書類の更新が必要か |
| 在庫・仕掛品への影響 | 要調査 | 旧品、仕掛品、発注残、支給品の使用可否と処置を確認する |
| 顧客への影響 | 該当 | 事前通知、承認申請、サンプル提出、切替日の合意が必要か |
判断できない項目を無理に「非該当」とせず、担当者と期限を設定して調査できるようにします。
「影響なし」という判断にも確認が必要です。規格への影響を設計担当者だけで判断するのではなく、必要に応じて品質保証や認証担当者が確認します。
システム上では、状態だけでなく、判断した担当者、判断日、判断理由を記録できるようにします。後から条件が変わった場合も、当時どの情報を基に非該当としたのかを確認できます。
すべてのECOを同じ承認ルートにすると、関係のない部門まで毎回確認することになり、承認に時間がかかります。一方、設計部門だけで承認すると、製造、品質、購買、営業などに関係する条件を確認できません。
基本となる承認者を決めたうえで、影響範囲に応じて必要な部門を追加する方法が考えられます。
画面イメージ：影響範囲に応じて承認者を追加する
変更に関係する部門だけを承認へ加えることで、必要な確認を行いながら不要な待ち時間を減らせます。
承認ボタンを押すだけの運用では、各承認者が何を確認すべきか分かりません。
たとえば購買部門であれば、価格、納期、発注残、代替調達先を確認します。品質保証部門であれば、再試験、認証、顧客提出物、検査規格への影響を確認します。
承認画面に部門別の確認事項を表示すると、承認の目的を明確にできます。
差し戻し時は、単にステータスを「差し戻し」に変更するだけでなく、不足している情報、再確認が必要な項目、修正後の提出先を記録します。
再申請時には、前回から変更された箇所を確認できるようにすると、承認者が申請書全体を読み直す必要がありません。
ECOが承認されても、それだけでは新しいRevを使用できるとは限りません。図面、部品、製造設備、検査方法、顧客承認などの準備が完了してから切り替える変更もあります。
そのため、「実施予定日」だけでなく、どの基準で新Revへ切り替えるのかを記録します。
画面イメージ：切替条件と旧品処置を分けて記録する
日付だけでなく、どの製品から新Revになるのかを特定できる条件を記録します。
「5月1日から変更」と記載されていても、5月1日に製造する製品から変更するのか、5月1日に出荷する製品から変更するのかで対象が異なります。
製造日、完成日、検査日、出荷日など、何を基準にした日付なのかを明記します。
変更内容によっては、一部の工場や製造ラインで先行導入し、結果を確認した後に全体へ展開する場合があります。
この場合は、対象拠点、先行期間、評価項目、全体展開の承認条件を記録します。単一の切替日だけでは管理できないため、段階ごとの実施状態を確認できるようにします。
設計変更後も、倉庫や製造現場には旧Revの部品、仕掛品、完成品が残っていることがあります。新しい図面を発行しただけでは、これらを使用してよいのか判断できません。
ECOでは、在庫の種類ごとに処置を決めます。
部品在庫だけでなく、発注済みで未入荷の部品、外注先にある支給品、製造途中の仕掛品、出荷待ちの完成品、補修用部品も確認対象になります。
廃棄や追加工で費用が発生する場合は、数量、金額、負担部門、承認者も記録します。
設計変更に伴って更新する情報は、図面やBOMだけではありません。
ECOの承認と同時にすべての文書が更新されるとは限りません。そのため、関連文書ごとに更新担当者、期限、更新後Rev、完了日を管理します。
旧版の文書は削除するのではなく、使用停止の状態にし、変更前後の関係を確認できるようにします。現場で旧版を誤って使用しないよう、最新版の識別方法や配布先の更新も必要です。
ECOの承認後、関係者へ一斉メールを送るだけでは、受信者が自分に必要な対応を判断できない場合があります。
通知は影響範囲に応じて送信先を決め、通知本文に担当者が確認すべき内容を記載します。
画面イメージ：影響範囲に応じて通知先と依頼内容を変える
通知された事実だけでなく、受信者が何を確認し、いつまでに回答するのかを記載します。
通知本文には、少なくとも次の情報を含めます。
通知先を増やしすぎると、自分に関係のない通知が多くなり、重要な連絡も読まれにくくなります。承認が必要な人、作業が必要な人、情報共有だけでよい人を分けることも検討します。
ECOは、承認された時点で完了とは限りません。承認後に、図面発行、BOM更新、部品手配、作業手順書改訂、在庫処置、顧客通知などが残っています。
承認済みと変更完了を別の状態として管理します。
変更完了の条件として、次のような項目を確認します。
完了条件を満たしたことを変更責任者が確認し、完了日を登録します。未完了の作業がある場合は、担当者と期限を明示したまま管理します。
変更を実施した後に、不具合率、作業時間、試験結果、顧客からの反応などを確認する場合があります。
特に品質不具合の対策として行った設計変更では、変更した事実だけでなく、当初の問題が改善されたかを確認する必要があります。評価対象、確認期間、判定結果をECOや関連案件へ記録します。
供給停止、重大不具合、法令対応などでは、通常の承認順序を待てないことがあります。ただし、緊急であることを理由に、変更内容や対象範囲を記録しない運用にすると、後から影響を確認できません。
緊急変更では、承認者や事前確認を限定する代わりに、次の項目は記録します。
暫定変更を恒久的な変更として継続する場合は、後から正式な影響確認と承認を行います。
設計変更管理をシステム化する際、最初からPDMやPLMと同等の機能を作ろうとすると、入力項目や承認条件が多くなり、導入までに時間がかかります。
現在メールやExcelで管理している場合は、まず次の範囲から始める方法があります。
運用開始後に、承認に時間がかかっている工程、確認漏れが多い項目、二重入力が発生している情報を確認し、必要に応じて条件分岐、通知、文書管理、他システムとの連携を追加します。
一方、すでにPDM、PLM、ERP、生産管理システムを利用している場合は、同じ品番、BOM、Rev情報を新しいシステムへ重複登録しない構成を検討する必要があります。どのシステムを正本とするのかは、実装前に決めるべき設計事項です。
申請画面の項目だけでなく、案件がどの状態を経て完了するかを決めます。状態名と次へ進める人、必要な条件が曖昧だと、承認済みと実施済みが同じ扱いになりやすいためです。
| 状態 | この状態で行うこと | 次へ進む条件 |
|---|---|---|
| 起案中 | 変更理由、対象品番、希望時期を記入する | 必須情報を入力し、申請者が提出する |
| 影響確認中 | 設計、品質、製造、購買、営業などが担当範囲を確認する | 必要部門の回答と未確認事項の処置が決まる |
| 承認待ち | 変更案、費用、切替、旧品処置を承認する | 必要な承認が完了する |
| 実施準備中 | 図面、BOM、手順書、マスター、通知資料を更新する | 発効前に必要な作業が完了する |
| 適用中 | 決められた製番、ロット、日付から新Revへ切り替える | 実際の適用開始を記録する |
| 完了 | 関連作業、通知、旧品処置、変更後確認を終える | 完了条件を変更責任者が確認する |
| 却下・取下げ | 変更を実施しない理由を記録する | 再申請する場合の条件を明示する |
差し戻しは状態を戻すだけでなく、誰が、何を確認し直すのかを指定します。承認後に変更内容そのものを修正した場合は、影響の大きさに応じて再承認が必要かを判定します。
設計変更は多くの部門に関係しますが、全員へ同じ編集権限を与える必要はありません。情報の登録者、確認者、承認者、実施担当者を分け、確定後の内容を誰でも変更できないようにします。
代理承認を認める場合は、代理者、代理期間、元の承認者、代理で承認した事実を履歴へ残します。退職や異動の後も過去の承認者名が記録として確認できるようにします。
設計変更の履歴は、現在の内容だけでなく、どの情報がいつ変更されたかを確認できる必要があります。上書き後の値だけを残すと、承認時点の内容を後から再現できません。
添付ファイルを差し替える場合も、古いファイルを削除して置き換えるだけではなく、どの版を承認したか分かる状態にします。閲覧権限や保存期間は、品質記録、契約、規格、社内規程に応じて決めます。
設計変更管理システムだけで、図面、BOM、在庫、製造指示、顧客情報をすべて管理する必要はありません。各情報の正式な管理元を決め、変更案件には参照先と更新結果を記録します。
| 関連情報 | 主な管理元の例 | 設計変更側で持つ情報 |
|---|---|---|
| 図面・技術文書 | PDM、文書管理 | 文書番号、変更前後の版、更新完了 |
| BOM・品目 | PLM、ERP、生産管理 | 対象品番、変更内容、反映結果 |
| 在庫・仕掛品 | 在庫管理、生産管理 | 確認時点の数量、処置方針、処置完了 |
| 取引先・顧客 | 販売管理、CRM | 通知要否、承認要否、通知結果 |
| 試験・不具合 | 品質管理、試験管理 | 関連番号、判定、変更後の確認結果 |
最初は自動連携せず、既存システムの番号とURLを登録する方法もあります。二重入力の頻度、更新の即時性、誤入力時の影響を確認し、自動連携が必要な情報を選びます。
変更の重要度に応じて簡略化する企業もあります。ただし、どの条件ならECRを省略できるのか、誰が軽微変更と判定するのかを決めます。図面、互換性、安全性、規格、顧客仕様に影響する変更を、担当者の判断だけで簡易処理にしない仕組みが必要です。
承認は実施内容が決まった状態であり、通常は完了ではありません。文書やBOMの更新、現場への反映、旧品処置、通知、実際の切替記録など、定めた完了条件を満たした後に終了します。
日付だけでは、同じ日に製造した新旧品を区別できない場合があります。製番、ロット、製造指示、受注、仕向け地など、現場で対象を特定できる条件を併記します。
件数が少なく、関係者も限定されている段階では利用できます。ただし、同時更新、承認履歴、添付ファイルの版、期限通知、品番からの検索が必要になると管理が難しくなります。現在困っている範囲を確認し、申請・影響確認・承認・実施状況から必要な部分をシステム化します。
ECR/ECOの申請フローでは、設計変更の内容だけでなく、その変更が製造や品質、調達、在庫、顧客対応へ与える影響まで確認する必要があります。
ECRでは変更の理由と発生事象を記録し、ECOでは変更前後のRev、影響範囲、承認者、切替条件、旧品処置を確定します。判断できない影響項目は「要調査」とし、担当者と期限を設定します。
また、ECOは承認された時点で終了ではありません。図面・BOM・作業手順書の更新、試験、在庫処置、顧客通知などが完了し、実際の切替対象を確認できる状態になってから完了とします。
設計変更管理をWebシステム化する場合は、現在の申請書をそのまま画面へ置き換えません。どの段階で何を確定し、どの部門が何を確認し、承認後にどの作業を終えたら完了とするのかを先に決めます。
製造業における設計変更、品質管理、文書管理、部門間の申請業務をシステム化する例については、 製造業向けシステム開発例 でも紹介しています。