MESのテストが情報系システムと決定的に違う3点
会計システムや販売管理のテスト経験をそのままMESに持ち込むと、3つの前提が崩れます。
第一に、相手が機械であること。設備・PLC・バーコードリーダー・ラベルプリンタ・計量器という物理デバイスが絡み、これらはテスト環境に完全な複製を用意できないことが普通です。テスト環境ではシミュレータで通ったのに、本番の設備では通信タイミングの差で取りこぼす──この種の障害は机上では発見できません。
第二に、業務が止められないこと。既存ラインへの導入では、テストのために生産を止められる時間は限られます。テスト計画は「何を検証するか」と同時に「いつライン・設備を借りられるか」の調整計画でもあります。
第三に、異常系が主戦場であること。MESの実装工数の大半が例外処理であるのと同様に、テストの価値も異常系に集中します。正常に流れるロットのテストは全体の2割で、残り8割は「途中で不良が出た」「設備が止まった」「入力を間違えて取り消したい」の検証に使うべきです。要件定義でつまずく5つの論点で洗い出した例外処理の一覧は、そのままテストシナリオの母集団になります。
3層構造──各層で「それでしか見つからない欠陥」を狙う
| 層 | 検証対象 | それでしか見つからない欠陥の例 | 環境 |
|---|---|---|---|
| 結合テスト | 設備・外部システムとの接続 | 通信断からの復帰時の重複データ、文字コード・桁あふれ、時刻ずれ | テスト環境＋実機接続 |
| シナリオテスト | 業務の流れ（正常系＋異常系） | 手直し品の実績二重計上、ロット分割時の系譜切れ、権限逃れ | テスト環境＋本番相当マスタ |
| 現場リハーサル | 人・モノ・システムの同時動作 | 手袋でボタンが押せない、端末の設置位置と動線の不一致、ピーク時の入力渋滞 | 本番環境＋実際の現場 |
各層で重要なのは、上の層で下の層の欠陥を見つけようとしないことです。現場リハーサル中に設備接続の欠陥が出ると、現場の時間を借りたまま原因調査が始まり、リハーサルそのものが崩壊します。結合テストの完了を、シナリオテスト開始の条件として明示的にゲート化してください。
結合テストで特に手厚くすべきは異常からの復帰です。接続が切れることは仕方がありませんが、復帰時に何が起きるかは設計と実装の品質がそのまま出ます。確認すべき定番は、①切断中に設備側で発生した実績の扱い（欠落か、バッファ後送信か）、②再送による重複登録の防止、③ERPなど外部システムとの連携失敗時のリトライとアラート（MES-ERP連携の設計参照）の3つです。
テスト設計の半分は、テストデータとマスタの準備
シナリオテストが計画どおり始まらない原因の第1位は、プログラムの遅延ではなくマスタとテストデータの未整備です。サオスの導入支援経験にもとづく目安として（公表された統計ではありません）、シナリオテスト工程の実工数のうち3〜4割はデータ準備に消えます。ここを計画に載せていないプロジェクトは、その分だけテスト期間が黙って削られます。
準備で判断を要するのは次の点です。
- マスタは本番実データを使うか、専用データを作るか。 品目・工程マスタは本番実データの複製が原則です。テスト用の簡略マスタで通したテストは、本番マスタの複雑さ（代替工程、端数処理、ユニット違い）を検証していません。マスタ整備の考え方はMESのマスタ設計を参照してください
- 異常系データを意図的に仕込む。 期限切れロット、資格失効した作業者、校正期限切れの設備をテスト環境のマスタに用意し、「正しく拒否されること」を確認します。正しいデータだけのテスト環境では統制機能のテストができません
- 採番の衝突を避ける。 テストで発行したロット番号・シリアル番号が本番移行後の採番と衝突しないよう、テスト用の番号帯を分けておきます。移行時のデータ扱いは既存システムからの移行で詳述しています
現場リハーサルは「教育」ではなく「テスト」として設計する
最後の層である現場リハーサル（模擬稼働）は、実際の作業者が、実際の現場で、実際の製品（または模擬ワーク）を流しながらMESを操作する工程です。教育を兼ねられるため訓練として扱われがちですが、テストとして設計するなら合否基準を持たせる必要があります。
- 時間を測る。 1件の実績登録に何秒かかったか。要件で定めた目標（たとえばバーコード読み取りから登録完了まで数秒以内）を超える操作が何件あったかを記録します
- 迂回を観察する。 作業者がシステムを使わずに済ませようとした場面（メモに書いて後でまとめて入力する等）はすべて記録します。これは作業者の問題ではなく、画面設計か業務設計の欠陥のシグナルです
- ピークを再現する。 交替直後や昼休み明けなど、入力が集中する時間帯を意図的に作って渋滞を観察します。閑散時のリハーサルは合格しても情報量がありません
カットオーバー判定は「残欠陥ゼロ」以外の基準で行う
稼働判定会議で「バグが残っているので延期」か「予定どおり稼働」かの二択で紛糾するのは、判定基準を事前に決めていないからです。残欠陥ゼロは現実的な基準ではありません。実務的な判定基準は次の形です。
- 統制機能（止める機能）の欠陥はゼロであること。 誤投入や資格チェックのすり抜けは1件でも稼働不可です
- 回避策のない業務停止欠陥はゼロであること。 回避策（手作業での代替入力など）が定義され、現場が了解している欠陥は残して稼働できます。ただし回避策には期限と解消責任者を付けます
- 帳票・画面の体裁など軽微欠陥は件数上限で管理すること。 稼働後の改修枠をあらかじめ契約に確保しておくと、判定会議が「直してから」対「予定どおり」の対立になりません
この基準は稼働判定の場で初めて出すのではなく、テスト計画書の段階で合意しておきます。基準が先にあれば、テスト終盤の欠陥トリアージ（どれを稼働前に直すか）も機械的に進みます。
よくある質問
テスト工程にはどれくらいの期間を見込むべきですか？
1工場・1ライン規模で、結合〜リハーサルまで通算2〜3か月が目安です（サオスの導入支援経験にもとづく目安であり、公表された統計ではありません）。このうち現場リハーサルは、ラインを借りられる日程の制約で決まるため、暦上は2〜4週でも実働日は数日ということが珍しくありません。テスト期間の見積で最初に確認すべきは工数ではなく、設備とラインを借りられる日の一覧です。
ベンダーのテストと発注側のテストは、どう分担すべきですか？
単体・機能テストはベンダー、シナリオテストは共同、現場リハーサルは発注側主導が原則です。注意すべきはシナリオの作成主体で、ベンダーだけに任せると「実装した機能が動くことを確認するシナリオ」になり、業務の抜けは検出できません。異常系シナリオの列挙は、現場の業務を知る発注側にしかできない仕事です。
規制産業ですが、この3層とバリデーション（CSV）の関係は？
3層構造はそのままIQ/OQ/PQの考え方と対応させられます。結合テストの多くはOQ、シナリオテストと現場リハーサルはPQの証拠として文書化できるよう、テスト計画の段階でトレーサビリティ（要件→テストケースの対応表）を作っておくと二重の文書作成を避けられます。なお、FDAのCSA（Computer Software Assurance）の考え方を採る場合、リスクに応じてテストの厚みを変え、統制機能・電子記録に工数を寄せる設計が可能です。詳細はFDA CSAでバリデーション工数はどう変わるかを参照してください。
