MESリプレイスのPoC・プロトタイプ・モックアップ開発について

MESリプレイスにおけるPoC（概念実証）・プロトタイプ・モックアップ開発は、「MESのモダナイゼーション」「MES刷新」「MES更改」「MESのリニューアル」「MESのリアーキテクチャ」の各記事群が扱うPoCとは、そもそもの性質が大きく異なります。MESのリアーキテクチャにおけるPoCは、イベント駆動アーキテクチャやPLC・OPC UAのエッジ処理といった、自社でゼロから技術検証を行う「作るためのPoC」です。これに対し本記事が扱うMESリプレイスのPoCは、FactoryTalkやAsprovaといった既に世の中に存在するMESパッケージ製品を、自社の工程進捗・実績収集ロジックやBOP（Bill of Process）、そして現場のPLC・設備連携という実データ・実環境を使って複数ベンダーで比較評価する「選ぶためのPoC」です。ゼロから試作するのではなく、既製品が自社の生産方式にどこまでフィットするかを見極めるという点が、本記事群を貫く最大の違いです。

本記事では、MESリプレイスにおけるPoC・プロトタイプ・モックアップ開発について、RFI・RFPによる一次選定からデモ評価までの流れ、Fit&Gap検証というトライアル環境でのPoCの進め方、実績データ・BOM等の実データを用いた検証の3段階、そしてPLC・現場設備との連携実証までを体系的に解説します。自社のMESをどのMESパッケージに乗り換えるべきか、複数の候補製品をどう客観的に比較評価すればよいか悩んでいる経営層・情シス部門・生産技術部門の方にとって、判断の拠り所となる内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・MESリプレイスの完全ガイド

MESリプレイスにおけるPoCの位置づけ（既製品比較評価という文脈）

MESリプレイスにおけるPoCの位置づけを正しく理解するための出発点は、「何を検証するのか」という対象の違いです。自社でゼロからMESを開発する場合のPoCは、独自の工程管理・実績収集ロジックが技術的に実現可能かを検証するものですが、本記事群が扱うリプレイスのPoCは、すでに市場に存在するMESパッケージが自社の生産方式にフィットするかどうかを検証するものであり、性質がまったく異なります。

MESリプレイスにおけるPoCは、フルスクラッチ開発における「動くものを作れるか」という技術的実現可能性の検証ではなく、「複数のMESパッケージ候補のうち、どれが自社の生産方式・実績収集ロジック・PLC連携に最もフィットするか」を見極めるための比較評価プロセスです。そのため検証すべき対象も、独自ロジックの実装可能性ではなく、パッケージの標準機能が自社の業務要件にどこまで適合するか（Fit&Gap）、実際の工程進捗・実績データを投入した際の挙動、そして現場のPLC・設備との連携可否という3点に絞られます。この違いを理解しないまま「PoC＝試作品を自社で作ること」と捉えてしまうと、本来必要のない開発コストをかけてしまいかねません。

姉妹記事「MESのモダナイゼーション」は5R（技術的アプローチ）の使い分けに、「MES刷新」は経営層の投資判断プロセスに、「MES更改」は契約満了・EOS/EOLという期限管理に、「MESのリニューアル」は実績入力画面のUI/UXプロトタイピングに、「MESのリアーキテクチャ」はイベント駆動アーキテクチャやPLC・OPC UAエッジ処理の技術的なパイロットフェーズに、それぞれ焦点を当てています。本記事が扱うMESリプレイスのPoCは、このいずれとも異なり、自社で何かを作る検証ではなく、FactoryTalkやAsprovaのような既製のMESパッケージを複数社で比較し、自社にとって最良の1社を選び抜くための検証プロセスに焦点を絞ります。

RFI・RFPによる一次選定からデモ評価までの流れ

本格的なPoCに入る前段階として、まず候補となるMESパッケージ・ベンダーを絞り込むプロセスが必要です。ここを丁寧に進めることが、後続のPoCの精度を高めます。

要件を完全に固める前の初期段階で、市場に存在するMESパッケージのベンダー10社程度をピックアップし、RFI（情報提供依頼書）を送付します。会社情報、導入実績、工程管理・実績収集・品質判定・トレーサビリティ照会といった基本機能の対応範囲、概算費用などを広く浅く収集し、この回答をもとに自社の生産方式に明らかに合わない製品を除外して、候補を3〜5社程度に絞り込みます。この段階ではまだ本格的なPoCには入らず、あくまで書面・カタログ情報での一次スクリーニングに留めることが、無駄な工数をかけずに候補を絞る効率的な進め方です。

絞り込んだ候補に対しては、自社の生産方式や課題、機能・非機能要件、スケジュールを明記したRFP（提案依頼書）を提示し、精度の高い提案書と見積もりを依頼します。提出された提案書をもとに最終候補によるデモンストレーションを実施する際、最も重要なのが、経営層や情報システム部門だけでなく、実際に工程進捗・実績入力を行う現場のオペレーターを必ず参加させることです。現場目線で「操作感」「入力の負担」「今の運用とどれだけ乖離するか」を審査させることで、机上の機能比較だけでは見えない導入後の定着リスクを事前に洗い出せます。あわせて、ベンダーのプロジェクトマネージャーが自社の製造現場の課題を理解し、専門用語を使わずに分かりやすく説明できるかどうかも、その後のプロジェクト推進力を占う重要な評価軸です。

Fit&Gap検証というトライアル環境でのPoC

机上の比較（カタログスペック）やデモだけでは判断しきれない部分を確認するのが、ベンダー提供のトライアル環境を用いたPoC（実機検証）フェーズです。ここでは既製品を自社の実データ・実業務シナリオに当てはめて評価します。

Fit&Gap検証では、洗い出した自社の工程管理・実績収集・品質判定の業務プロセスが、パッケージ製品の標準機能にどこまで適合するかを実機で確認します。現場の熟練者の勘や例外的な運用ルールを無理にシステムへ組み込もうとするのではなく、逆に運用をパッケージ側の標準機能に合わせられるかどうかを検証することが主眼です。あわせて、手袋着用時のタッチ操作性や、月末の生産計画確定処理といった負荷が集中するタイミングを意図的にトライアル環境で再現し、システムの処理性能・レスポンスタイムが実運用に耐えられるかを「実測」で確かめます。カタログ上のスペックだけでは分からないパッケージの実力を見極める、PoCの中核となる工程です。

複数のMESパッケージ候補を公平に比較するためには、担当者の主観に頼らない評価マトリックスの活用が欠かせません。「要件適合度」「導入・運用コスト」「セキュリティ」「サポート体制・事業継続性」「PLC・現場設備との連携実績」といった評価軸をあらかじめ設定し、各候補をスコアリングすることで、経営層への説明責任を果たしやすくなります。加えて、自社の生産プロセスをシナリオ単位に分解し、「標準機能で対応可能」「運用変更で吸収可能」「追加開発が必要」という3ラベルに分類するフィット&ギャップ分析を実施しておくと、過度なカスタマイズを避けるための判断材料としても機能します。

実績データ・BOM等の実データを用いた検証の3段階

データ移行はシステムリプレイスにおける最大の難所であるため、PoCの段階から生産実績・トレーサビリティ・BOMという実データを用いた検証を組み込んでおくことが、後工程での手戻りを防ぐ最も確実な方法です。

実データ検証の第1段階は、新パッケージを前提とした品目・BOM・在庫階層の構成やルールを定義し、旧システムに蓄積された表記ゆれ・重複・欠損を解消するためのデータクレンジング計画を立てることです。続いて第2段階として、旧システムから一部の代表的な生産実績・ロット履歴・BOMデータを抽出し、実際に新パッケージへ投入するサンプル移行テストを行い、データ変換ロジックや項目マッピングが論理的に正しく機能するかを確認します。この段階で、自社独自の複雑な実績収集ロジックが標準パッケージの構造にうまく変換できるかどうかが、早期に判明します。

サンプル移行テストで論理的な正しさを確認した後の第3段階として、本番相当の全量データを用いたシステム統合テスト（SIT）を実施し、大量データ投入時のデータ品質の破綻がないか、処理パフォーマンスに問題が生じないかを検証します。もっとも、PoCの段階でここまでの全量データ検証を全候補に対して実施するのは現実的ではないため、通常は最終候補1〜2社に絞り込んだ段階でこのSIT相当の検証を行い、契約締結前に「本当にこのパッケージでデータ移行がやり切れるか」の最終確認とすることが実務上の進め方です。

PLC・現場設備との連携実証（周辺機器・異常系テスト）

MESパッケージは単独で動くわけではなく、工場現場の他システムや機器と連動して初めて価値を発揮します。PoCの最終段階では、この周辺領域を含めた統合的な実証まで行うことが欠かせません。

実績入力に用いるハンディターミナルやバーコードリーダー、RFIDスキャナーといった周辺機器が、新しく採用するMESパッケージのもとで正常に利用できるかを検証します。あわせて、PLC・生産設備や上位ERPとのインターフェース要件（API連携、ファイル連携、通信コードのマッピング等）を定義し、システムを連携させた統合状態で稼働確認を行います。カタログ上は「連携可能」と謳われていても、実際に自社が使用している設備・機種との組み合わせで正しく動作するかは、実機を用いたPoCでしか確認できません。

影響範囲が大きく不確実性の高いPLC・外部設備連携については、2〜4週間程度の短いスプリントを設定し、小さく素早くPoCを繰り返すアプローチが効果的です。あわせて、通信エラーやネットワーク異常が発生した際にアラート通知・ログ出力・再送処理（リカバリ）が運用ルールどおりに機能するかという「異常系」の動作確認も、この段階で行っておくべき重要な検証項目です。正常時の連携確認だけで終わらせず、現場で実際に起こりうるトラブルを想定した検証まで踏み込んでおくことが、契約後に「実はこの設備とはうまく連携できなかった」という致命的な事態を防ぐ実務上のポイントになります。

まとめ

本記事では、MESリプレイスにおけるPoC・プロトタイプ・モックアップ開発について、既製品比較評価という文脈での位置づけ、RFI・RFPによる一次選定からデモ評価までの流れ、Fit&Gap検証というトライアル環境でのPoC、実績データ・BOM等の実データを用いた検証の3段階、そしてPLC・現場設備との連携実証を体系的に解説しました。MESリプレイスにおけるPoCの本質は、自社で何かを新しく作ることではなく、FactoryTalkやAsprovaといった既製のMESパッケージが、自社の生産方式・実績収集ロジック・PLC連携という実データ・実環境にどこまでフィットするかを、複数ベンダーで公平に比較評価するプロセスにあります。RFI・RFPによる絞り込みから、標準機能適合度の実機確認、実データを用いた3段階の移行検証、そしてPLC・現場設備との連携実証までを丁寧に積み重ねることが、契約後の「こんなはずではなかった」という失敗を防ぐ最大の鍵です。開発期間・スケジュールや保守・運用費用の詳細については、姉妹記事もあわせてご参照ください。

▼全体ガイドの記事
・MESリプレイスの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。