機械設計 #73：レシピと機種管理 — 生産条件を改訂から逃がさない

1. 機能と証拠から始める

寸法、設定、センサー、部品を先に決めず、この生産レシピが何を行い、入力がどこから来て、境界でどう動き、何を故障と呼ぶのかを明確にする。「古い機械と同じ」では、タイミング、担当、アクセス、保全、安全の前提が隠れる。検証できる要求には入力状態、運転条件、期待結果、許容限界、測定方法を含める。社内標準は出発点であり、最終判断は実機、工程、作業者、設置場所で確認する。

2. 四つの層を同時に見る

機能と荷重では、定格、始動、衝撃、芯ずれ、異常、復旧を分け、システム全体の流れを追う。慣性、温度、通信遅延、圧力、洗浄、作業者の操作、実際のサイクル数を含める。実装では、機械、制御、ソフト、データ、作業票で同じ要求を作れて測れるかを確認する。インターフェースでは基準、信号、識別子、向き、アクセス、引渡し、変更権限を定義する。運転と保全では、交換、復旧、清掃、調整、基準値へ戻す証拠を実機で見る。

3. このテーマの基本チェック

パラメーターの責任者、単位、範囲、既定値：すべてのパラメーターに責任者、単位、有効範囲、既定値を与える。範囲外の値は黙って受け入れず、拒否されるようにする。
ハードウェアと図面に結び付けたレシピの版数：レシピの版数を、対応するハードウェアと図面に結び付ける。改造した機械では、同じ数値がもう有効ではない。
リリース前の妥当性確認と承認記録：リリース前に妥当性を確認し、承認記録を残す。生産中のレシピを、誰が受け入れたのかまでさかのぼれるようにする。
アクセス管理、監査証跡、バックアップ：アクセスを管理し、監査証跡を残し、制御器を失っても復元できる場所へバックアップする。
段取り替え、切り戻し、機種違いの防止：段取り替え、切り戻し、誤った機種で運転することの防止を設計する。誤ったレシピは、レシピがないことより高くつく。
ロットや製造番号ごとに使ったレシピの追跡：どの版のレシピがどのロット・製造番号を作ったかを記録する。顧客からの申し出の後に問われるのはこれである。

証拠のないチェックは完了ではない。「確認した」は「計算した」と同じではなく、「計算した」も「境界で試験した」と同じではない。要求の隣に証拠番号を置く。

4. ばらつきと故障モード

機能入力から守る特性までの連鎖を作り、公称、最悪値、工程が安定した場合だけ統計値を分ける。人の操作、遅延、データ欠落、摩耗、汚れ、復旧時間を含める。生産レシピでは特に、parameter ownership, revision, access control, validation, rollback, and model changeを境界条件で確認する。

故障モード	症状	確認
境界を楽観視	デモは通るが運転や異常で停止	最小・最大と異常条件で試験
機能と無関係な要求	がた、拘束、誤状態、誤記録	機能基準から再構築
工程やデータを省略	ずれ、欠落、復旧不能	ルートと重要段階を測定
復旧を未設計	停止が長い、安全に再開できない	中断・復旧トライアル
文書が不一致	改訂や設定が違う	図面、ソフト、レシピ、作業票を基準化

5. 発行と現場レビュー

機能に意味があり検査できる要求だけを書く。特殊要求には範囲、基準またはデータ源、条件、合否限界を示す。「注意して扱う」だけでは行動は決まらない。根拠、改訂、前提、レビュー、試作・FAT、変更後の再確認点を保管する。実機では始動、通常運転、停止、再始動、中断、管理された異常を通し、力、温度、タイミング、アラーム、識別子、接触痕、交換・復旧時間を記録する。

6. MINATA発行チェック

[ ] 機能、入力、サイクル、異常境界を記載した。
[ ] 材料、工程、制御、データ、検査方法を合意した。
[ ] 機能インターフェースと責任者が見える。
[ ] 六項目に証拠と合否基準がある。
[ ] 選択、組立、復旧、誤操作防止を実機で試した。
[ ] 故障モードに担当者、証拠、再試験条件がある。
[ ] サプライヤーと受入記録が改訂・ロットに紐付く。
[ ] 立上げ基準と保全対応を定義した。

この主題が単純化されやすい理由

試運転の段階では、条件出しのために現場で数値を直接書き換えることが日常になります。量産へ移ってもその習慣が残り、どの数値が正なのか、誰が変えたのか、いつ有効になったのかを誰も答えられなくなります。

原本、承認済み、稼働中を分ける

原本 — 管理された正のデータ。
承認済み — 審査を通った版。
稼働中 — いま機械に読み込まれている版。

画面にはこの三つが区別して見えなければなりません。機種名が一つ表示されているだけでは、どの版で作ったのかを後から言えません。

条件データの構造には約束事が要る

項目ごとに、単位、範囲、既定値、変更できる権限、値が無いときのふるまいを決めます。新しい項目を追加するときは、古いデータをどう移すのか、前の版との互換をどう保つのかも同時に定義します。

転送と有効化は別の行為です

手順は、転送、検証、互換性の確認、必要なら承認、有効化、そして受領の確認、という順序になります。工程が許さない限り、サイクルの途中で条件を切り替えないでください。

手作業の変更を管理する

誰が、何を、なぜ変えたのか、変更前と変更後の値、変更した時刻を記録します。品質に直結する項目には、権限または承認の段階を設けます。記録のない変更は、後から原因を追えません。

機種切替を試験する

切替の前後で、条件が正しく入ったか、前の機種の値が残っていないか、途中で切替が中断したときにどうなるかを確認します。切替が最も危ないのは、正常に完了したときではなく、途中で止まったときです。

8. まとめ

良い設計は、製造、運転、保全、変更を通過する明示された前提の連鎖である。生産レシピについて問うべきなのは「動くか」だけでなく、「境界が動いても動き続ける証拠は何か」である。これがMINATAの基準である。

まとめ

レシピと機種管理は、プロジェクトの最後に付け足すロジックではなく、アーキテクチャとライフサイクルの問題である。状態、識別、操作権限、データ、復旧のそれぞれに明確な取り決めがあれば、機械は運転しやすく、調査しやすく、変更しやすくなる。最初にプログラムを書いた人の記憶に頼らずに済む。

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