機械設計 #45：Engineering change — 一つの部品を変えたら何を再確認するか

「小さな変更だから問題ない」は、自動機プロジェクトで危険な言葉です。センサーを交換し、ブラケットを移動し、パラメーターを調整し、ソフトウェアを編集する。機械が動くように見えるため記録を閉じますが、後でFAT、生産、安全レビューに隠れた依存が現れます。

本当に問うべきは、部品の数ではありません。

この変更で、どの要求、インターフェース、リスク、動作、証拠、ベースラインが変わる可能性があるか。

Engineering changeは、現状、提案状態、影響、検証、展開、ロールバックを見える化する管理された判断です。別の技術者が同じ判断を再現できる強さが必要です。

1. すべての「修理」が同じ変更ではない

一時的な是正は運転を戻すための暫定処置です。対象資産、制限、所有者、期限、リスク、恒久対応を記録し、新しい設計ベースラインへ黙って変えません。

恒久的なEngineering changeは、承認済み設計、ソフトウェア、部品、工程、文書を変更します。影響分析、承認、実装、範囲に応じた証拠が必要です。

緊急変更は人、設備、生産を守るために行います。レビューを短縮しても、as-runningを取得し、後で管理されたベースラインへ照合します。

2. Change requestは現状と提案状態を書く

「センサーXをYへ交換」だけでは不十分です。アイテムIDと版、機能、モード、機械・電気・ソフトウェア境界、理由、提案部品、前提、影響文書、期待効果、新しい故障モードを記録します。前後の絵がなければ、部品番号の好みで影響を判断することになります。

3. 部品番号ではなく要求から始める

その部品が支える要求を確認します。近接センサーは位置確認、許可、衝突防止、シーケンス時間、品質トレーサビリティ、安全入力を同時に担うかもしれません。要求ID、合否基準、運転条件、証拠を追跡します。要求が曖昧なら、交換時に明確化します。

4. 複数領域の影響マップを使う

要求・契約では性能、受入れ、顧客約束、規格、成果物を確認します。機械では外形、基準、剛性、荷重、摩耗、整列、アクセス、ガード、工具を確認します。電気では電圧、電流、配線、保護、接地、ノイズ、I/O、盤スペースを見ます。制御ではタグ、スケール、デバウンス、状態、許可、アラーム、レシピ、HMI、復旧を確認します。

インターフェースではタイミング、意味、所有、タイムアウト、エラー、再同期を見ます。安全・リスクではハザード、安全機能、診断、停止、再起動、妥当性確認を見ます。品質・性能ではサイクル、精度、再現性、不良、トレースを見ます。ライフサイクルでは予備品、廃番、供給者、保全、教育、バックアップを見ます。

5. 直接、下流、共有の影響

直接影響は変更部品、取付、配線、パラメーター、コード、試験です。下流影響はロボット順序、レシピ、品質判定、アラーム、データ、オペレーター手順です。共有影響はライブラリ、インターフェース契約、標準部品、安全機能、校正工具、共有予備品です。「影響なし」は理由付きの結論であり、初期値ではありません。

6. インターフェースは最も速く波及する

信号極性、状態の意味、時間、タイムアウト、所有、エラー、復旧が変わると、機械的に置換可能でも許可ロジックや診断が壊れます。境界の両側をレビューし、仕様、シーケンス図、状態モデル、HMI、試験を読みます。供給者の口頭説明だけで閉じません。

7. 分類はルートを決めるが分析の代わりではない

Minor、Major、Emergency、安全関連、供給者起因、文書のみなどの分類で承認者とゲートを決めます。Minorだから影響が小さいとは限りません。ブラケットでもガードやアクセスを変え、文書変更でもベースラインの誤りが判明します。分類の理由を記録します。

8. 実装とロールバックを計画する

対象資産、工具、前提、バックアップ、隔離、順序、確認、担当、連絡を決めます。新しい構成が失敗した時、既知良品へ戻す方法、必要ソフト、パラメーター、校正、部品、所要時間を明記します。「戻せるはず」は計画ではありません。

9. 直接検証、回帰、再妥当性確認

直接検証は変更部品や変更要求を確認します。回帰試験は隣接状態、アラーム、レシピ、インターフェース、再起動、異常経路を確認します。再妥当性確認は、実際の利用コンテキストでニーズを満たすかを確認します。直接試験が合格でも共有インターフェースが失敗するため、影響に応じて三つを組み合わせます。

10. 古い試験はまだ有効か

以前の試験をそのままコピーしません。新部品の条件、許容差、故障モード、環境、証拠を覆うか確認します。古いセンサーの切替点を測る試験では、新センサーのヒステリシス、応答、診断を証明できないかもしれません。無効な手順を削り、サンプルと合否を更新し、適用理由を残します。

11. 依存関係で回帰範囲を選ぶ

変更部品と直接機能、同じシーケンスと隣接状態、共有ライブラリ・インターフェース・安全機能、品種・レシピ・モード、サイト統合と復旧の層で考えます。固定割合で試験数を決めず、アーキテクチャ上の依存を根拠にします。

12. 近接センサー交換の例

クランプ閉を確認し、動作許可、アラーム、トレースイベントへ使うセンサーを交換するとします。検出距離、対象材、取付、コネクター、電圧、出力、応答、ヒステリシス、環境、診断を比較します。クランプ時間、誤閉検出、アラーム文、時刻、ロボットハンドシェイク、安全前提、予備品、試験サンプルを確認します。新部品を付けただけでは完了しません。

13. Compile passは検証ではない

コンパイル成功は構文とツール互換性だけを示します。順序、タイミング、状態、アラーム、データ、安全、復旧は別に試験します。Build ID、展開記録、結果、ベースラインを管理し、オンライン編集と保持パラメーターを分けて確認します。

14. 供給者変更は購買だけではない

部品、樹脂、ファームウェア、ライブラリ、製造拠点の変更では、技術差分、資格証拠、互換性、廃番時期、文書を入手します。購買承認は工学承認の代わりになりません。挙動、保全、予備品、検証への影響を所有者が判断します。

15. 複数資産への展開

同じ変更でも、ファームウェア、配線、治具、品種、オプションが違えば結果は変わります。対象資産、前提版、パイロット順序、ロールバック在庫、教育、展開後確認を定義します。各資産がどのリリースと証拠を受けたかを残します。

16. 変更を閉じる条件

承認範囲を実装し、直接・回帰試験を完了し、必要な再妥当性確認を行い、偏差の担当を決め、文書・構成・教育を更新し、新ベースラインを保護し、復旧証拠を置いた時に閉じます。未確認の前提を注記へ隠しません。

17. 展開後に有効性を確認する

試験に合格しても実運転で失敗することがあります。期待効果、再発故障、アラーム、保全時間、品質、停止、利用者の声を合意期間で確認します。仮説と違えば新しい是正変更を開き、古い記録を無理に成功へ変えません。

18. 構成状態を追跡する

提案、承認、実装、試験、展開、文書化、完了を、資産、リリース、証拠、偏差へリンクします。コードだけ変わり図面、マニュアル、予備品、教育が古い状態を防ぎます。

19. Engineering changeチェックリスト

[ ] 現状と提案状態が明確である。
[ ] 要求と受入れ基準へリンクしている。
[ ] 機械、電気、制御、インターフェース、安全、品質、ライフサイクルを確認した。
[ ] 直接、下流、共有の影響を識別した。
[ ] 分類が分析の代わりになっていない。
[ ] バックアップ、実装、検証、ロールバック、連絡を計画した。
[ ] 必要な回帰試験と再妥当性確認を完了した。
[ ] 古い試験の有効性とサンプル条件を見直した。
[ ] 供給者と複数資産の互換性を確認した。
[ ] ベースライン、文書、教育、状態表を更新した。
[ ] 展開後の有効性レビューを予定した。

まとめ

物理的な変更が小さくても、Engineering changeはシステム変更です。現状と提案状態から始め、要求と依存へ追跡し、インターフェースと安全を調べ、影響に基づいて検証し、展開、証拠、状態、保護ベースラインで閉じます。これは書類のためではなく、修理、供給者変更、オンライン調整、生産圧力の後も機械を理解可能にするための規律です。

20. 変更審査を短い周期で行う

変更を一度承認して終わりにせず、設計レビュー、実装前、FAT準備、SAT準備、展開後の各ゲートで同じ変更IDと影響表を確認します。新しい前提、例外、現場の調整が出たら、要求、リスク、試験、教育、予備品、文書への影響を一緒に更新します。

21. 変更の証拠を再利用できるようにする

Change request、比較表、写真、測定、Build ID、展開記録、試験結果、偏差、承認を同じベースライン参照へリンクします。ファイル名だけでなく、資産、版、時刻、担当者、条件を持たせ、別の技術者が判断を追跡できるようにします。

22. 小さな変更にもロールバック訓練を行う

ソフトウェア、パラメーター、センサー、治具を戻す手順を管理対象で一度試します。旧版の所在、工具、ライセンス、校正、再起動、初良品確認、顧客連絡を明記します。試していないロールバックは、障害時に初めて設計される計画です。

20. 変更審査を短い周期で行う

21. 変更の証拠を再利用できるようにする

22. 小さな変更にもロールバック訓練を行う

23. 変更の大きさを数値だけで決めない

価格やコード行数ではなく、安全機能、共有ライブラリ、複数モデル、現場チューニング、供給者互換性へ触れるかを見ます。影響表には「なぜ試験が不要か」も記録します。

24. 保全変更を同じ地図で見る

保全で交換した部品、調整値、ケーブル経路、ラベルが図面やソフトウェアと違う場合、as-runningは変わっています。保全記録、RCA、予備品、要求、試験、構成ベースラインを同じ変更IDへつなぎます。

25. 承認者は結果を理解しているか

目的、残留リスク、適用資産、試験範囲、ロールバック、展開後レビューを説明できる人が承認します。緊急変更でも、後のレビューで判断を再現できる証拠を残します。

承認後も、試験結果、偏差、展開後の有効性を変更記録へ戻します。変更を閉じることは記録を消すことではなく、次のベースラインが何を含むかを明確にすることです。

26. 展開後レビューで変更を学習にする

展開後に、停止、品質、アラーム、保全時間、オペレーターの質問、予備品の使用、再発を合意した期間で確認します。期待した効果が出なければ、実装不良、仮説の誤り、別の共通原因、測定条件の差を分けます。レビュー結果を要求、FMEA、保全手順、教育、次の変更計画へ戻すことで、変更管理を一回限りの申請で終わらせません。

変更完了時には、旧版の扱い、残した部品、更新した図面、教育、予備品、保全タスク、試験証拠、資産一覧を一つの引渡しパッケージへまとめます。これにより、変更の意図とas-runningの関係が次の担当者にも伝わります。

公開参考資料

ISO 10007:2017 — Guidelines for configuration management: https://www.iso.org/standard/70400.html
ISO 9001:2015 — Quality management systems: https://www.iso.org/standard/62085.html
ISO 12100:2010 — Risk assessment and risk reduction: https://www.iso.org/standard/51528.html

MINATAの技術記事をすべて見る