機能の有無を確かめるPoCには、意味がない
MESのPoC計画書を見せていただくと、検証項目に「実績登録機能の確認」「トレーサビリティ機能の確認」といった項目が並んでいることがよくあります。これらは、製品カタログとデモで確認できることです。PoCという形で3か月かける必要はありません。
PoCで確かめるべきは、製品の機能ではなく、自社の現場と製品の組み合わせが成立するかです。カタログには書かれておらず、デモでも見えず、契約後に判明すると取り返しがつかない領域は、経験上3つに絞られます。
- 現場での入力が、実際の作業テンポで回るか
- 自社の設備から、必要な粒度でデータが取れるか
- 例外が起きたときに、現場が自力で復帰できるか
この3つは、どれも実機と実際の作業者がいなければ検証できません。逆に言えば、この3つを検証しないPoCは、会議室でのデモと変わりません。
PoCで検証すべき3項目
1．現場での入力が作業テンポで回るか
MESが現場に受け入れられるかどうかは、1回の操作にかかる秒数で決まります。検証は次のように設計します。
- 実際の作業者に、実際の作業服・手袋・照明条件で操作してもらう。 情報システム部門の担当者が試して「問題なし」と判断したPoCは、ほぼ例外なく稼働後に覆ります
- 1サイクルの作業時間に対する、入力操作時間の比率を測る。 作業時間3分の工程で入力に30秒かかるなら、生産性が16%落ちる計算になります。この数字を許容できるかを経営判断として確認します
- 交替勤務の全直で試す。 夜勤帯は照明も要員構成も違います。日勤だけで検証したPoCは、条件の半分しか見ていません
- 入力ミスからの復帰を含める。 誤って読み取ったとき、何タップで戻れるか。ここが5タップ以上なら、現場は入力を後回しにし始めます
この項目の合否は感想ではなく、操作時間の実測値と、作業者からの定量評価で判定してください。判定基準の例は後述します。関連する設計指針は現場端末のUI設計で扱っています。
2．設備から必要な粒度でデータが取れるか
カタログには「主要な産業プロトコルに対応」と書かれています。しかし実際の工場にある設備は、次のような状態です。
- 制御盤が20年前のもので、通信ポートがない
- 通信はできるが、メーカー独自仕様でドキュメントが残っていない
- データは出るが、必要な項目（品番、良否判定）が出力に含まれていない
- 出力はあるが、更新周期が10秒で、1サイクル2秒の工程の実績が拾えない
PoCでは、最も条件の悪い設備を1台選んで接続してください。新しい設備で接続できることを確認しても、判断材料になりません。検証すべきは「接続できるか」ではなく、「接続できない設備が何台あり、その対処にいくらかかるか」です。
対処の選択肢は、通信ユニットの後付け、外部センサーの追加、信号線からの接点取得、手入力での代替の4つです。PoCの成果物として、対象設備の一覧と、台ごとの対処方針・概算費用を出させてください。これが出れば、本番の見積精度が大きく上がります。詳細は設備接続の現実で扱います。
3．例外が起きたときに現場が自力で復帰できるか
正常系はどの製品でも動きます。差が出るのは例外系です。PoCのシナリオには、次の6つを必ず入れてください。
| # | 例外シナリオ | 見るべきこと |
|---|---|---|
| 1 | ネットワークが切れる | 何分間、作業を継続できるか。復旧時にデータは自動同期されるか |
| 2 | 端末が故障する | 別端末で作業を引き継げるか。作業中のデータは失われないか |
| 3 | 誤った実績を登録した | 訂正できるのは誰か。訂正の記録は残るか |
| 4 | 材料が途中で足りなくなった | 分割投入・途中中断をシステム上で表現できるか |
| 5 | 検査で不良判定が出た | 手直しして同じ工程へ戻す流れをたどれるか |
| 6 | 指定と違う設備で作った | 実績として記録できるか、それともエラーで止まるか |
このうち1番は、最も軽視され、最も重大です。事務系システムなら復旧を待てますが、ラインは止められません。オフライン継続の可否は製品アーキテクチャに依存し、後から追加できる機能ではありません。PoCで実際にLANケーブルを抜いて確認してください。カタログの「オフライン対応」という記載だけで判断しないことをおすすめします。
3番も重要です。訂正機能がないと現場は正しいデータを入れられなくなり、訂正が無制限だとデータの信頼性がなくなります。訂正の権限と証跡の設計は、規制産業でなくとも顧客監査で問われます。
PoC計画書に必ず書く6要素と、合否の判定基準
PoCの契約書と計画書には、次の6要素を入れてください。抜けやすいのは5番と6番です。
- 検証項目と、それぞれの合否判定基準（数値）
- 対象範囲：ライン、工程、品目、期間、参加者
- 発注側が提供するもの：設備情報、マスタデータ、作業者の時間、ネットワーク
- ベンダーが提供するもの：ライセンス、技術者の稼働日数、環境
- PoCで作った環境・データの扱い：本番へ流用するのか、破棄するのか。知的財産の帰属
- PoCの結果が「不合格」だった場合の扱い：契約はどうなるか、費用はどうなるか
合否の判定基準は、次のような形で数値化します。曖昧な基準しか書けない項目は、そもそもPoCの対象から外したほうが健全です。
| 検証項目 | 判定基準の例 |
|---|---|
| 現場入力 | 1工程あたりの入力操作時間が15秒以内。作業者10名中8名が「継続可能」と回答 |
| 入力ミスからの復帰 | 誤読み取りから正常状態へ戻る操作が3タップ以内 |
| 設備接続 | 対象10台のうち、追加投資なしで接続できる台数と、追加費用の総額が確定していること |
| データ粒度 | 1サイクルごとの良否判定が、取りこぼしなく取得できること（1直分の実測で欠損率0.1%以下） |
| オフライン継続 | 通信断から30分間、作業継続と実績登録が可能。復旧後の自動同期で欠損なし |
| 例外処理 | 6シナリオすべてを、ベンダー技術者の介助なしに現場の参加者だけで完了できること |
最後の行の「ベンダー技術者の介助なしに」は、必ず入れてください。技術者が横にいれば、たいていの例外は処理できます。本番稼働の夜勤帯に技術者はいません。
PoCをやらないほうがよい場合もある
すべてのケースでPoCが有効なわけではありません。次の条件に当てはまる場合、PoCの代わりに別の手段を選ぶほうが合理的です。
- 既存設備が新しく、通信が確立している。 検証項目2のリスクが小さいため、PoCの価値の3分の1が失われます。この場合は、RFPで連携仕様を具体的に問い、回答の質で判断するほうが速く済みます
- 同業種・同規模の導入実績が複数ある製品を候補にしている。 稼働中の現場を見学し、そこの担当者に例外処理の実情を聞くほうが、自社でのPoCより情報量が多い場合があります。ベンダーに導入先訪問を依頼してください
- 予算と期間の制約で、PoCの結果にかかわらず候補製品を変えられない。 この場合のPoCは、実質的に設計の前倒しです。それ自体は有効ですが、「検証」と呼ばずに「先行設計フェーズ」として位置づけたほうが、目的と成果物が明確になります
逆に、PoCを必ず行うべきなのは、既存設備が10年以上前のものである場合、多品種少量で例外処理が多い場合、そして候補製品の国内導入実績が少ない場合です。この3つはいずれも、カタログと提案書から実態を読み取れない領域です。PoCの設計手順はMES PoC設計ガイドにまとめています。
よくある質問
PoCの費用はベンダーが無償で持つべきですか？
無償のPoCは、範囲と期間が限定され、ベンダー側の都合の良い条件で設計されがちです。有償にすると発注側が条件を指定できるようになり、上に挙げた「最も条件の悪い設備で試す」「介助なしで例外処理を行う」といった要求が通ります。金額の多寡より、PoCの設計権限がどちらにあるかが本質です。無償を選ぶ場合でも、検証項目と判定基準は発注側が書いてください。
PoCの期間はどれくらいが適切ですか？
6〜10週間が目安です。これより短いと、交替勤務の全直での検証や、1直分の実データ取得が入りません。逆に3か月を超えると、参加した作業者が習熟してしまい、「初めて触る人でも使えるか」という最も重要な観点が失われます。習熟前のデータを取るために、開始1週目の操作時間を必ず実測して記録しておいてください。
PoCで作った環境をそのまま本番に使えますか？
使えることが多く、そこに罠があります。PoC環境はマスタの整備が簡略化され、権限設計や監査証跡が省かれ、テストデータが混在した状態です。この環境を本番へ昇格させると、省いた設計がそのまま残ります。原則として、PoCの成果物として引き継ぐのは設定内容と設計判断の記録であり、環境そのものではないと決めておいてください。これを契約書の5番目の要素として書いておくと、後の議論が不要になります。
