一つの設計変更が、どの製品・どの部品にまで影響するのか——それを追いきれず、変更のたびに現場が混乱していないでしょうか。設計変更（ECO/ECR）の管理は、紙やExcelで回している限り、製品が増えるほど破綻していきます。本記事では、変更管理の基本的な流れと、つまずきの正体である「影響範囲の追跡」を解説し、仕組みで解くと何が変わるのかを中立に整理します。
1. 設計変更の管理でこんな状態になっていませんか
設計変更は、最終的にBOMや図面の更新という形で現れます。だからこそ、変更管理の混乱はBOM・図面まわりの症状として表面化します。
変更が関係部署に伝わっておらず問題になる
BOMの変更だけであれば非常に簡単そうに聞こえるのですが、すでに関係部署に連携されているBOMなどを変更するのは大変な作業です。自分の部署のBOMを更新して上長などの承認をもらったうえで、関係部署に丁寧なメールで変更意図や箇所を説明しなければいけません。変更作業そのものだけでなく、社内の人間関係にも気を使わないといけません。また、BOMの変更が関係部署に伝わっていないと、間違ったBOMで製造が進んでしまうというリスクもあるので、自分自身のストレスも相当です。念には念を入れて確認のリマインドを入れることもあるでしょう。
変更への質問に誰も即答できない
1つのBOMの変更について、変更を依頼する人と実際の変更作業担当者が違うことがあります。設計会議で決まった内容を特定の人がBOMに反映する状況が想像しやすいでしょう。会議で決まった内容であれば、ある程度のメンバーには周知されているので、変更への理解は浸透しています。しかし、一部のメンバーだけで決まった変更だったりすると、他の人が「この変更はどんな意図なのか」「他にどんな影響が出るのか」に即答できないことは起こり得ます。結局、「〇〇さんに聞かないとわからない」という属人化につながってしまいます。
変更依頼が多方面からいろんな方法で送られてくる
1つのBOMに対して変更依頼が重なることはあります。部署内での変更依頼、関係部署からの変更依頼が、時にメール、時に電話、時に書類で送られてきたりします。多方面からいろいろな方法で依頼が来ると、確認漏れや反映漏れが起こる確率はどうしても上がります。内容がわかりにくかったり、読みにくかったり、本当に正式な変更依頼なのかと疑ったりと、依頼フォーマットが決まっていないと非常に大変です。
変更履歴が後から追跡できない
BOM管理で難しいのは、どうやって変更履歴を残して管理するかです。製品の振り返りやトラブル時の見直しなど、過去のBOM状況を確認したい場面は出てきます。ただ、紙やExcelなどで管理していると、変更履歴を蓄積する方法が確立していない限り、変更履歴を追跡するのはデータ上ほぼ不可能です。担当者にヒアリングをして記憶を頼りに回答してもらうしか方法がなくなりますが、記憶というものは曖昧で、都合の良い変換をするので、あまり信頼できないこともあります。誰がいつどのような意図でどんな変更をしたのかがわかりません。結局、はっきりとしない報告書や説明書ができあがるだけで、根本的な改善にはつながりません。
変更依頼が多すぎて、対応・承認が追いつかない
変更する人と、それを確認して承認する人が分かれているケースがほとんどだと思います。そうなると、変更に対して最低でも二人が関与することになります。場合によってはもう少し階層があり、多くのメンバーが承認フローに登場することもあるでしょう。変更作業が多いと、承認フローのどこかで作業が滞ることはあり得ます。承認フローが正常に回っていないことは他部署からは把握しにくいので、設計BOMの変更があるのに関係部署への連携が遅れ、現場が変更前の内容で進んでしまっていた、ということもあります。
2. そもそもECO/ECRとは
ECRは設計変更要求・依頼
ECRとはEngineering Change Requestの略で、製品の設計、部品、製造プロセスなどの変更を関係部門に提案・要求するための正式なフォーマットです。文書の書式やプロセスなどが定義され、決めたプロセスを踏んだECRは正式な依頼であることを明確化し、曖昧な変更依頼を防ぐという目的があります。曖昧な依頼を防ぐことで、結果として品質トラブルや生産ラインの混乱を避けやすくなります。
ECOは設計変更指示
ECOとはEngineering Change Orderの略で、ECRが検討・承認を経て、関係部署に指示を出す際の正式なフォーマットです。ECRと同様、文書の書式やプロセスなどが定義され、実際にどう変えるかを伝えるのが目的です。ECRが「変えたい」という意思表示なのに対し、ECOは「こう変えることが決まった」という確定情報である、と対比して捉えるとわかりやすいでしょう。
流れとしては、ECR（要求）→検討・承認→ECO（指示）というものです。このプロセスを経て、BOMや図面、仕様などに、変更が関係部署も含めて反映されます。
3. なぜ設計変更が「回らない」のか
原因1：変更の影響範囲がすぐに見えない
製造業における1つの変更は、その影響範囲が非常に広く複雑です。関連部署のBOMに影響したり、図面データの変更が必要だったり、ユニット内の他部品にも変更が必要だったりします。担当者一人ではとても扱いきれず、関係者で検討しないといけないこともあります。検討に時間と人員を割かないといけないので、なかなかすぐには結論が出ず、ECOが出せないという状況が続くことになります（変更がBOMにどう波及するかは「どのBOMが最新版かわからない」でも扱っています）。
とくに注意が必要なのが、複数の製品で共用されている部品です。1つの部品変更が、想定していなかった別の製品にまで同時に影響します。「この部品はどの製品で使われているのか」（いわゆる Where-used）を洗い出せないと、影響範囲の確定そのものができず、検討は振り出しに戻ります。
原因2：変更プロセスが標準化されていない
変更の依頼（ECR）から検討・承認を経て指示（ECO）に至るプロセスにおけるフォーマットが存在せず、人や場面によってバラバラな方法になってしまっていることもあります。そうすると、依頼の内容が伝わりづらかったり、付随データが不足していたり、実は正式な変更依頼ではなかったりと、いろいろな問題を抱えやすい構造になってしまいます。変更依頼を捌くだけでも大変なのに、無駄な作業をしていたと後から気づくのは、精神的にもこたえます。
原因3：変更履歴が残らない
変更依頼の検討において、過去に似たような点が論点に上がっていた、と気づくことがあります。しかし、そう気づけたからといって、その時の検討内容や結論を必ずしも覚えているわけではありません。後から過去の変更履歴を辿ろうとしても、変更履歴が管理されていないとその経緯を追えず、また同じ議論を繰り返さなければならなくなります。
原因4：承認プロセスが多すぎる・周知が追いつかない
変更にはある程度のスピードが求められるケースもあります。ただし、スピードを求められるからといって、承認プロセスを飛ばしてよいわけではありません。すでに決まっているプロセスを遵守したうえで対応しなければなりません。承認プロセスが多いと、どうしてもスピードが落ちるので、期日に間に合わなかったり、周知に十分な時間がなかったりします。関連部署での変更指示の見落としや作業遅れにつながりかねません。
4. まず自力でできること
ここまで設計変更が抱える問題を見てきました。これらの解決のために、まずは何をすべきかを見ていきましょう。特定のツールを入れなくても取り組める運用はあります。
ECR/ECOのフォーマットを作る
ECR/ECOのフォーマットを決める作業は、早めに取り組みたいところです。基本的には、依頼書・指示書の命名規則と書式（入力項目など）、受け渡し方法（メールでのPDF添付やメール本文など）を、まずは決めるのがおすすめです。余裕があれば、いろいろな製品に関する依頼書や指示書が飛び交うので、受付済み・処理済みなどのステータス管理をどうするかも決めてもよいかもしれません。
変更の影響範囲チェックリストを用意する
変更の内容を確認すると、BOMの連携状態や対象部品によって、いくつかの種類やパターンに分類できます。もちろん例外的なパターンもあるので100%分類できるとは言いませんが、大まかには分類できるはずです。各分類において共通点を抽出し、変更の影響範囲や周知すべき部署に関するチェックリスト（どのBOM・製品・部門が影響範囲に入るのか）を作れるでしょう。次からの変更作業の際にチェックリストがあれば、作業の抜け漏れを防げる可能性が高くなります。例外や新たな共通事項に気づいた際にはチェックリストを更新し、より網羅性の高いものに育てていくことも重要です。
承認プロセスを整備し、関連部署の周知先を事前に決める
各部署での承認フローと、窓口となる連絡先を整備したうえで、その内容を関係部署に周知するのがよいでしょう。組織図のように窓口を一覧にまとめておくと便利です。誰に連絡すればよいのかが一目でわかるので、迷うポイントを減らせます。
これらの運用だけでも、大きな改善を感じられます。しかし、どうしてもメンバー依存になるため、限界があるのも事実です。とくにメンバーや拠点が増えるほど、人の注意力に頼った運用は限界に近づきます。そこで次に、こうした限界を仕組み（システム）でどう補えるのかを見ていきます。
5. 仕組み（システム）で解くとどう変わるか
自力での運用が難しいとなると、次の解決方法はシステム運用です。システム運用で変更管理がどのように変わるかを見ていきましょう。
変更の影響範囲をシステムが追跡する
システム化すると、E-BOMとM-BOMをどのようにデータ連携するかなど、細かく定義します（E-BOMとM-BOMの違いは「BOMとは」で解説しています）。システム運用の開始前は定義に苦労しますが、いったん運用が始まると、部品の変更がどのBOMに関係があるのか、他の部品に影響があるのかなど、波及範囲が素早くわかるようになります。影響があるか100%は確定できない箇所にアラートを立てることも、設定によっては可能になるので、変更の追跡が非常に楽になります。
ECR→ECOの承認フローを標準化し、周知まで完結させる
システム上で変更依頼や指示を実行できるようになるので、それぞれの入力項目・必須項目を設定することで、入力内容を制御できます。これはECRとECOの標準化を意味し、それに伴う承認もシステム内で完結させられます。承認ステータスや指示の受入ステータスなど、他のメンバーの状況もシステムを通して把握できるようになるので、忘れていそうだったり遅れていたりしたらリマインドをするなど、心遣いもしやすくなります。人間関係のギクシャクが減る可能性もあります。
「誰が・いつ・なぜ」の変更履歴が自動で残る
システム運用の優れている点として、変更履歴を残せることも忘れてはいけません。ECRやECO、承認・周知プロセスが標準化されたことで各データを蓄積しやすくなり、履歴の蓄積もしやすくなります。誰がいつどの項目をどのように変更したのかを自動で蓄積し、変更履歴を時間軸で検索することもできるようになります。また、その変更意図は何だったのかを、メモや備忘録を活用して残すことも設定によっては可能です。
ここまで書くとシステムが万能に見えますが、決してそうではありません。運用準備や運用時のフィードバックを経て、自社に合うシステムを構築するという努力が積み重なって初めて、使いやすいシステムになります。システム運用の良さを聞くと導入を急ぎたい気持ちも出てくると思いますが、一度落ち着いて、社内の状況やシステム運用を引っ張る人材がいるかを確認したうえで、慎重に判断するのがよいでしょう（変更管理を含むPLMの役割は「PLMとは」で解説しています）。
6. まとめ：どこから手をつけるか
設計変更が「回らない」原因は、変更の影響範囲が見えないことと、ECR・ECOの標準化が整っていないことです。まずは自力でできることに取り組んでみることが重要です。そして、どうしても自力では限界だと感じたら、システム運用を本格的に検討すべき時期になります。
なお、設計変更の混乱は、BOMの版管理・分断の問題と根を同じくしています。あわせて対処を考えると、より効果が出やすくなります。
- 自社に何が必要かを課題から逆引きする →「製造業システムの選び方」
- 変更管理を含むPLMの役割 →「PLMとは」
- BOMの版・分断の課題 →「どのBOMが最新版かわからない／部門ごとにBOMが分断している」