老朽化したMESを前に、リホストで済ませるべきか、思い切ってフルスクラッチで作り直すべきか判断がつかず、検討が進まない製造業の担当者は少なくありません。開発会社によって得意な手法や実績が異なるため、知名度や見積金額の安さだけで選ぶと、PLC連携や生産実績データの移行で想定外のトラブルに直面することもあります。新規導入の実績を前面に出す開発会社であっても、稼働中システムを止めずに刷新するブラウンフィールド案件の経験が浅ければ、想定していた期間・費用で終わらない可能性が高まります。選定の出発点は、自社のMESがどこまで老朽化し、どの設備連携にリスクが集中しているかを明らかにすることです。
本記事では、MESのモダナイゼーション着手前に整理すべき自社課題、5R(リホスト/リプラットフォーム/リファクタリング/リビルド/リプレース)という選択肢の種類、保守運用コストから考える比較軸、開発会社を見極める評価軸、PoC・パラレルランと段階的カットオーバー計画の進め方を解説します。老朽化したMESの刷新をどこから手を付けるべきか整理したい担当者の方が、自社に合う進め方を判断できる内容です。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・MESのモダナイゼーションの完全ガイド
MESのモダナイゼーション着手前に整理すべき自社の課題
最初に行うべきことは、5Rのどれが良いかを決めることではなく、今のMESがどこで老朽化のリスクを抱えているかを特定することです。課題を一文で説明できれば、比較すべき手法と開発会社の実績が絞り込みやすくなります。生産管理システムなど隣接システムの刷新計画がすでに進んでいる場合は、その計画とMES側の刷新時期をどう合わせるかも、この段階で合わせて洗い出しておくと後工程が円滑になります。
ブラックボックス化・技術者不在の兆候を確認します
現場の例外処理に合わせて長年カスタマイズを重ね、内部構造を把握している技術者が退職・異動で不在化している場合は、密結合レガシー化が主な課題です。OSやAPIの世代交代のたびに高額な有償アップデート費用を請求されていないか、システム停止時に出荷・請求処理が止まるリスクをどこまで許容できるかを確認します。放置するほど保守できる技術者はさらに減り、選べる手法の幅も狭まっていきます。同じ老朽化でも、単にサーバーが古いだけなのか、工程進捗や実績収集のロジックそのものがブラックボックス化しているのかによって、適した手法は変わります。この見極めを曖昧にしたまま開発会社に相談すると、実態より重い(あるいは軽い)提案を受けてしまうことがあります。
設備連携の不確実性を放置していないか確認します
古いPLCや独自通信規格の設備が多いほど、最新MESとの直接連携が難しくなる可能性が高まります。現状で設備インターフェースの棚卸しができているか、生産実績データの品質がどの程度劣化しているかも、この段階で大まかに把握しておくと、後述する評価軸で開発会社の実績を確認する際の判断材料になります。設備台帳や通信仕様書が残っていない工場では、この棚卸し自体に相応の時間がかかることも珍しくありません。選定の初期段階で「棚卸しにどれだけの工数を要しそうか」を大まかに見積もっておくと、後工程のスケジュールを組み立てやすくなります。
5R(リホスト/リプラットフォーム/リファクタリング/リビルド/リプレース)という選択肢の種類
主な選択肢は、軽量な手法であるリホスト・リプラットフォームと、抜本的な手法であるリファクタリング・リビルド・リプレースに大きく分けられます。実際のプロジェクトは複数の手法を組み合わせることもあるため、分類名よりも、自社の老朽化度合いと現場の制約に合うかを確認します。
リホスト・リプラットフォームという軽量な手法
リホストは、既存のBOP(作業手順)や実績収集ロジックの構造を変えずにインフラだけをクラウドへ移す手法で、ハードウェア老朽化やEOS対応を急ぐ企業に向いています。リプラットフォームは、生産実績データベースのマネージド化や実績集計バッチのコンテナ化など、構造に一部手を入れながら機能はほぼ維持する手法です。どちらも初期費用を抑えやすい一方、ロジック自体の複雑さは温存されるため、根本的なブラックボックス化の解消にはつながりにくい点に留意します。
リファクタリング・リビルド・リプレースという抜本的な手法
リファクタリングは内部ロジックを整理しつつ外部機能を維持する手法で、新旧が同じ実績・進捗を返すかという回帰テストが中心的な検証になります。リビルドは既存を廃棄してクラウドネイティブで再構築するフルスクラッチであり、生産実績データベースや工程管理のデータモデルまで見直せる自由度がありますが、初期投資と期間は最大になります。リプレースはパッケージ・SaaS型MESへの移行にあたり、Fit to Standardの社内調整とデータクレンジングに想定以上の時間がかかることがある一方、標準機能への統一で将来の保守性を高めやすい手法です。
保守運用コストから考える5Rの比較軸
手法の選定は初期費用だけで決めず、刷新後にかかり続ける保守運用コストまで含めて比較する必要があります。老朽化を放置した場合のコスト構造と、刷新後の相場感の両方を押さえておくと、投資判断の材料になります。
刷新後の保守費用相場という基準
刷新後、継続的なバグ修正・死活監視・問い合わせ対応を保守契約とする場合、年間のシステム保守費用は初期開発費用の5〜15%程度が相場とされます。これにクラウドサーバーや自社インフラの維持費用として月額数万円〜数十万円程度が加わり、5〜7年周期で大規模なOS変更・API変更に伴う有償バージョンアップ費用が突発するリスクも考慮する必要があります。リホスト・リプラットフォームは初期費用を抑えつつ運用コスト削減を狙える一方、リビルドは初期投資が最大になる代わりに将来の保守コストをシンプル化しやすく、リプレース(SaaS)は最も低コスト・スピーディーですが、過度なカスタマイズを重ねると新たなレガシー化を招くリスクがあります。
Fit to Standardという評価軸
老朽化MESの刷新は「入れ替えること」自体をゴールにせず、標準機能への業務すり合わせ(Fit to Standard)を意識し、カスタマイズを最小限に抑えて保守性を高めるアプローチが将来の運用コスト削減に直結します。開発会社を比較する際は、Fit to Standardの考え方を提案の中に組み込んでいるか、逆に何でもカスタマイズで対応しようとしていないかを確認すると、将来の保守負担を見誤りにくくなります。
開発会社・ベンダーを比較する評価軸
MESのモダナイゼーションを主導できる開発会社は、新規導入だけを手がける会社よりも限られます。実績の有無だけでなく、実際の対応内容まで踏み込んで確認することが重要です。同じ質問を候補各社へ提示し、回答の裏付けをそろえることで、営業説明の分かりやすさに評価が引っ張られにくくなります。
PLC・レガシー制御連携の実績を確認します
要件定義の初期段階で設備インターフェースの棚卸しを主導した経験があるか、独自通信規格の設備でプロトコル変換やレトロフィットIoTによる代替を検討した実例があるかを確認します。プロトコル変換の要否が開発後期に判明するプロジェクトは、コスト超過のリスクが高くなるため、初期棚卸しへの姿勢は重要な判断材料です。
データ移行・リハーサル体制の実績を確認します
本番前に最低2回以上のリハーサル移行を実施する体制を標準としているか、データクレンジングの範囲をどう決めているか、ロールバック手順をリハーサルに組み込んでいるかを確認します。「移行はできます」という回答だけでなく、実際にどのようなエラー事象を経験し、どう対処したかを尋ねると、実務対応力の差が見えやすくなります。
開発会社への丸投げにしない体制を確認します
開発会社への丸投げは禁物であり、自社側にBOPや現場運用を判断できる担当者を置ける前提で提案を受けているかを確認します。開発会社がすべてを巻き取る提案は、一見負担が軽く見えても、現場の暗黙知が反映されないまま仕様が固まるリスクがあります。段階的リリース(コア機能を先行稼働させ、周辺機能は後続フェーズに回す進め方)を提案してくれるかどうかも、長期プロジェクトの頓挫を防ぐ観点で確認したい点です。見積もりの内訳が、要件定義・設計・開発・データ移行・現場立ち会いのどこにどれだけ配分されているかを開示してくれるかどうかも、丸投げにならない体制かを見極める手がかりになります。
PoCとパラレルラン(機能等価性検証)の進め方
比較資料やデモを見るだけでは、モダナイゼーションが本当にうまくいくかは判断できません。実際に手を動かして検証するPoCと、新旧を並行稼働させるパラレルランの2段階で確認することが有効です。
現場の物理的制約まで含めて検証します
PoCでは、デモを見るだけでなく、実際の作業スピード、作業員の導線、手袋や保護具を着用した状態での操作性など、現場の物理的制約を含めて検証することが重要です。モダナイゼーションでは特に「今と同じ結果が、より新しい環境で再現できるか」という移行の正確性の検証に主眼が置かれます。5Rのうちリホスト・リプラットフォームでは技術的な動作検証(実績収集データベースの構造を変えずに移行できるかの実現可能性検証)が中心になり、リファクタリング・リビルドでは新旧が同じ処理結果を返すかという機能等価性の検証が最大のハードルになります。
新旧システムを並行稼働させる検証方法
パラレルラン(並行移行方式)では、新旧MESを一定期間同時に稼働させ、両システムでのデータ入力・更新・削除が問題なく行えるか、実績収集や工程進捗の計算結果に想定外の違いがないかを分析・比較します。新システムでデータ整合性が完全に確認できた段階で旧システムを廃止する進め方で、安全性は高い一方、現場作業者による新旧両方へのデータ二重入力の負担と、同時運用のコストがトレードオフになる点は事前に共有しておく必要があります。
段階的カットオーバー計画の立て方
PoCとパラレルランで機能等価性を確認できたら、実際に生産ラインで新システムへ切り替える段階的カットオーバーの計画を立てます。ここでも一斉切替は避けるのが基本です。カットオーバー計画は開発会社に任せきりにせず、現場の生産計画・シフト表と突き合わせながら自社側でも妥当性を確認することが望ましいといえます。
段階移行方式と並行移行方式の選び方
特定のライン・業務機能から順次切り替える段階移行方式は、影響範囲を限定しやすい一方、切替時期がずれる期間中は新旧の運用が混在します。並行移行方式(パラレル方式)は安全性が高い反面、二重運用のコストが継続します。生産ラインの数、シフト体制、繁忙期のタイミングを踏まえ、自社にとって現実的な方式を選びます。複数拠点・複数ラインを持つ企業では、1つのラインで方式の有効性を確認してから他ラインへ展開する進め方も、リスクを抑えるうえで有効です。
ロールバック手順と緊急連絡体制の明文化
MESの分・秒単位のデータとERPなどの日・月単位のバッチデータを無理にリアルタイム連携させるとパフォーマンスが破綻するリスクがあるため、連携は必要最小限のマスタに絞り、疎結合にとどめます。リハーサルで実測したダウンタイムをもとに、切り戻し(ロールバック)手順と緊急連絡体制を文書として明文化し、関係者全員が同じ手順を参照できる状態にしておくことが、生産を止められない現場での切替を成功させます。
MESのモダナイゼーション選定で見落としやすいポイント
手法と開発会社の候補を絞った後も、見落とされやすい確認事項があります。ここでは選定時に判断が分かれやすいポイントを整理します。
手法を決める前に対象範囲を確定させます
MES本体だけを刷新するのか、PLC連携や生産管理システムとの受け渡し部分まで含めるのかを先に決めないと、5Rのどれを選んでも見積もりの前提が崩れます。範囲確定は開発会社への相談前に社内でひとまず整理しておくことが望ましいといえます。
小規模な工場でもモダナイゼーションは必要です
ライン数が少なくても、担当技術者が一人しかいない、独自通信規格の海外製設備を使っているといった状況では、リスクは工場規模に比例しません。規模の大小ではなく、老朽化の度合いと設備連携の複雑さで着手の優先度を判断します。
PoC・パラレルランの期間は品質検証を優先します
期間を急いでパラレルランを短く切り上げると、実績収集や工程進捗の計算結果に潜む微妙な差異を見逃すリスクが高まります。生産量の変動が大きい時期をまたいで検証できるかどうかも、期間設定の判断材料になります。
まとめ
MESのモダナイゼーションの選定では、まず老朽化のリスクとPLC連携の不確実性という自社課題を特定し、5R(リホスト/リプラットフォーム/リファクタリング/リビルド/リプレース)から自社に合う手法の方向性を選びます。そのうえで、保守運用コスト、PLC連携やデータ移行の実績、開発会社への丸投げにしない体制という評価軸で候補を比較し、PoCとパラレルランで機能等価性を確認したうえで、段階的カットオーバー計画まで固めることが重要です。
手法選定は保守運用コストまで含めて判断します
初期費用の安さだけで手法や開発会社を決めると、刷新後の保守費用や5〜7年周期のバージョンアップ費用で想定外の負担が生じることがあります。Fit to Standardの考え方を提案に組み込んでいるかどうかも、長期的な保守性を左右する判断材料です。
候補を絞ったら実案件のPoCで確認します
資料上の実績や提案の分かりやすさだけでなく、実際のPLC連携・データ移行・段階的カットオーバーの経験まで確認したうえで最終候補を決めてください。既製パッケージやクラウド型MESの標準機能では自社特有の設備連携や生産管理ロジックに対応しきれない場合、フルスクラッチによる刷新も選択肢になります。riplaはフルスクラッチ開発の立場から、PLC連携やデータ移行を含むMESのモダナイゼーションの要件整理から構築までを支援しています。具体的な候補を確認したい場合は、あわせて製品一覧もご参照ください。
具体的な候補はMESのモダナイゼーションのパッケージ・クラウド製品一覧を参照すると、共通軸で比較しやすくなります。
▼全体ガイドの記事
・MESのモダナイゼーションの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。