MES(製造実行システム)の移行は、工場の生産活動そのものを左右する基幹プロジェクトです。「現行のMESが老朽化してサポート終了が迫っている」「Excelと属人運用が限界で、トレーサビリティに不安がある」といった課題を抱えながらも、自社だけで移行を完遂できる製造業はほとんどありません。設備制御やデータ連携、現場業務の例外処理まで絡むMES移行は、適切な発注先へ外注し、委託範囲を見極めることが成功の前提条件になります。
本記事では、MES移行を「発注・外注・依頼・委託」する際の実務に的を絞り、発注先の種類と選び方、発注前に準備すべきドキュメント、契約形態と委託範囲の線引き、費用相場、そして発注後のマネジメントまでを体系的に解説します。単なる業者選びの一般論ではなく、製造現場を止めないために発注側が押さえるべき「不都合な真実」まで踏み込みます。この記事を読めば、自社にとって最適な委託の形が描けるようになります。
▼全体ガイドの記事
・MES移行の完全ガイド
MES移行を外注すべき理由と発注前に押さえる全体像

MES移行は、生産ラインの制御や設備からのデータ収集、品質・トレーサビリティ管理など、製造現場の根幹に直結します。止まれば工場が止まり、そのまま売上が止まるという性質を持つため、汎用的な業務システムの刷新とは難易度が大きく異なります。まずは、なぜ外注が前提になるのか、そして「発注・外注・依頼・委託」という言葉の違いを整理しておきましょう。
MES移行が内製では難しい理由
MES移行を内製で完結できない最大の理由は、必要なスキルセットが極端に広く深いからです。PLCやSCADAといった設備制御の知識、古い独自通信規格からデータを取得するレトロフィット技術、ERPやPLMとのデータ連携設計、製造業務の業務知識、そして大規模システムの移行ノウハウが同時に求められます。これらをすべて社内に抱えている製造業は稀で、情報システム部門が数名規模という企業がほとんどです。
さらにMES移行は数年に一度の非定常プロジェクトです。専任の移行チームを内製で常時抱えるのは人件費の観点で現実的ではありません。サポート終了(EOL/EOSL)が迫る中で短期間に確実に移行を完遂するには、移行を専門に手がける外部パートナーへ委託し、自社は要件と現場知識の提供に集中するのが合理的です。内製にこだわった結果、スケジュールが遅延しサポート切れと重なって生産が止まる、という事態こそ最も避けるべきリスクです。
発注/外注/依頼/委託の違いと選択肢
「発注」「外注」「依頼」「委託」は日常的にはほぼ同義で使われますが、契約実務では意味合いが分かれます。発注は対価を払って成果物やサービスを正式に注文する行為全般を指し、外注は自社で行わず社外のリソースに任せることを意味します。委託は、業務の遂行そのものを第三者に任せる契約上の概念で、成果物の完成を約束する「請負」と、業務の遂行を約束する「準委任」に分かれます。
MES移行では、これらを工程ごとに使い分けるのが実務の勘所です。たとえば要件定義やコンサルティングは準委任で伴走してもらい、開発・データ移行は請負で成果物責任を明確にする、といった組み合わせが典型です。発注先に「丸投げ」するのではなく、どの業務をどの契約形態で委託するかを設計できるかどうかが、後のトラブルとコストを大きく左右します。
MES移行の発注先の種類と選び方

MES移行の発注先には大きく分けて4つのタイプがあります。それぞれ得意領域と費用感、現場対応力が異なるため、自社の課題に応じて選ぶ必要があります。発注先選びを誤ると、現場の実態に合わない標準機能を押し付けられたり、設備連携でつまずいてプロジェクトが頓挫したりします。
発注先の4タイプと特徴
1つ目はMESパッケージベンダーです。自社製品の導入・カスタマイズに強く、業界標準のテンプレートを早く適用できますが、製品の範囲外の要件には弱く、過度なカスタマイズはコスト肥大を招きます。2つ目は大手SIerで、大規模な多拠点展開やERP連携を含む全体最適に強い一方、費用は高めで現場の細かな例外処理への機動力は劣りがちです。
3つ目は製造系に特化した専門コンサル・開発会社で、現場業務やBOP整備、レトロフィットIoTといった泥臭い領域に強みがあります。4つ目はコンサルから開発・定着支援まで一気通貫で担う企業で、要件整理から運用まで窓口が一本化できるため、社内リソースが限られる企業に向きます。自社が「現場フィットを最優先したいのか」「全社標準化を優先したいのか」で適切なタイプは変わります。
製造現場を止めない発注先を見極める基準
発注先を見極める最重要基準は「現場を止めない移行」の実績です。具体的には、古いPLCや海外製設備からデータを取得するレトロフィットの経験、データ移行のリハーサルを複数回回す方法論、そして稼働初日に問題が起きた際の切り戻し(ロールバック)計画を提示できるかを確認します。提案段階でこれらに触れず、機能や価格だけを訴求する発注先は要注意です。
あわせて、ERP(計画層)とMES(実行層)の粒度差を理解しているかも見極めポイントです。月次・日次で動くERPと、分・秒単位で動くMESを安易にリアルタイム密結合させると性能が破綻し、画面が重くなって現場が使えなくなります。疎結合・非同期連携を当然のように提案してくるかどうかで、設計の地力が判断できます。同業種・同規模の製造業での移行実績を、可能な限り具体的な数字とともに確認しましょう。
発注前に準備すべきドキュメントと要件整理

発注の成否は、発注前の準備で8割が決まります。要件が曖昧なまま発注すると、見積もりが膨らみ、後から追加費用と仕様変更が頻発します。発注側がどこまで自社の現状を言語化できるかが、見積もり精度とプロジェクトの安定性を左右します。
RFP・要件定義・As-Is/To-Be整理
発注前に最低限そろえたいのが、現状業務を可視化したAs-Is資料、目指す姿を描いたTo-Be構想、そしてそれらを要求仕様としてまとめたRFP(提案依頼書)です。RFPには、対象工場・ライン・対象機能の範囲、連携対象システム、移行対象データの量、希望スケジュール、予算レンジ、評価基準を明記します。これがあると複数社から同じ土俵の見積もりを取れ、比較精度が一気に上がります。
自社だけでRFPを書き切れない場合は、要件定義フェーズだけを準委任契約で専門会社に伴走してもらう方法が有効です。要件整理に数十万円から数百万円を投じることをためらう企業は少なくありませんが、ここを省くと開発フェーズで数倍の手戻りコストが発生します。発注前の投資こそ、総コストを抑える最大のレバーです。
BOP・マスタ整備という前提工程
MES移行で見落とされがちなのが、BOP(工程順序・作業手順・標準時間)とマスタデータの整備です。BOPが未整備のままMESを導入しても、システムは正しく工程を制御できず機能不全に陥ります。これは発注先に任せれば済む話ではなく、現場の暗黙知を持つ発注側が主体的に整理すべき前提工程です。ここを飛ばして発注すると、開発途中で「そもそも標準作業が定義されていない」と判明し、プロジェクトが止まります。
マスタデータも同様で、品目・設備・工程・ロット単位などの定義が拠点ごとにバラバラだと、データ移行時に在庫不整合やトレーサビリティの断絶が起きます。発注前にマスタの棚卸しとクレンジング方針を固め、誰が整備の責任を持つかを社内で合意しておくことで、移行の手戻りと追加費用を大幅に減らせます。
契約形態と委託範囲の決め方

委託契約の形態と範囲の決め方は、リスク配分と費用を直接左右します。MES移行は不確実性が高い工程と、仕様が固まる工程が混在するため、フェーズごとに契約形態を使い分けるのが鉄則です。一律に請負で固めると、要件変更のたびに高額な追加見積もりが発生します。
請負契約と準委任契約の使い分け
請負契約は成果物の完成に責任を負う契約で、仕様が明確な開発・データ移行フェーズに適します。発注側は完成責任を負わせられる安心感がある一方、仕様変更には弱く、変更のたびに再見積もりが必要です。準委任契約は業務の遂行に責任を負う契約で、要件定義やコンサルティング、PoC(実証)のように仕様が流動的なフェーズに向きます。
実務では、要件定義は準委任で柔軟に進め、仕様が固まった開発・移行は請負で成果物責任を明確にし、稼働後の保守・運用支援は再び準委任で継続する、という組み合わせが一般的です。この使い分けを発注側が理解していないと、流動的な上流まで請負で縛ってしまい、結果として発注先が安全側に大きなバッファを乗せた高い見積もりを出すことになります。
委託範囲の線引きと体制の明確化
委託範囲は、設計・開発・データ移行・設備連携(レトロフィット)・テスト・教育・保守という工程ごとに、どこまでを外注しどこを自社が担うかを明確に切り分けます。とくに設備連携やマスタ整備は責任の所在が曖昧になりやすく、「発注先がやってくれると思っていた」というすれ違いがトラブルの典型です。RACI(責任分担表)のような形で役割を文書化しておくと、後の紛争を防げます。
また、丸投げに見える一括委託でも、発注側にプロジェクトオーナーと現場のキーマンを必ず置く必要があります。MESは現場の業務に深く根ざすため、発注先だけでは要件を正しく引き出せません。委託範囲を広げるほど、発注側の体制づくりと意思決定の速さがプロジェクトの推進力を決めるという逆説を、契約前に理解しておきましょう。
発注時の費用相場と見積もりの読み方

発注にあたっては、費用相場の感覚を持っておくことが交渉力につながります。相場から大きく外れた見積もりには必ず理由があり、その理由を発注側が読み解けるかどうかが、適正価格で発注できるかの分かれ目です。MES移行の費用は規模と要件の複雑さで大きく変動します。
規模別の費用相場と内訳
MES移行の費用相場は、小規模(単一ライン・限定機能)で数百万円から1,500万円程度、中規模(複数ライン・標準的な機能セット)で1,500万円から5,000万円程度、大規模(多拠点・フルスコープ)で数千万円から数億円規模が目安です。費用の大半は人件費、すなわち工数(人月)で構成され、要件定義・設計・開発・データ移行・テスト・教育の各工程に積み上がります。
発注時には、IT導入補助金などの公的支援を活用できる場合があり、対象となれば初期費用の負担を軽減できます。補助金は申請要件や採択スケジュールがあるため、発注先が申請支援に対応しているかを確認しておくと、資金計画が立てやすくなります。
見積もりで見落としがちな隠れコスト
発注時に最も注意すべきは、初期費用以外の隠れコストです。代表例が、新旧システムを並行稼働させる段階移行で必要になる「データ同期中継プログラム」の追加開発費と、現場の二重入力にかかる人的コストです。段階移行は安全ですが、この中継開発と移行期間の長期化で、一括移行より総コストが膨らむトレードオフがあります。
もう一つ見落としやすいのが、SaaS型MESのTCO(総保有コスト)逆転です。接続設備数・データ量・アカウント数の増加に応じて従量課金がスケールし、数年単位で見るとオンプレミスを上回ることがあります。さらに多拠点展開時には、トランザクションとログの急増でネットワークやサーバが不足し、数千万円規模のインフラ再投資が突発的に発生する場合もあります。見積もりは初期費用だけでなく、3〜5年のランニングを含めた総額で比較しましょう。費用の詳しい内訳と相場は、後述の関連記事でも解説しています。
外注を成功させる発注後のマネジメント

発注して契約を結べば終わりではありません。MES移行の成否は、発注後にどれだけ発注側が主体的にプロジェクトをマネジメントできるかにかかっています。外注は責任の移転ではなく、協働の始まりだと捉える必要があります。
切り戻し計画とダウンタイムの合意
MESは止まれば工場が止まります。だからこそ、稼働切替の前に切り戻し(ロールバック)計画を発注先と必ず固めておくことが最大の防衛策です。具体的には、どの状態になったら切り戻すかの判断基準、許容できるダウンタイムの上限、切り戻しを発動する権限者を、経営層も含めて事前に合意します。これを稼働後に決めようとすると、トラブル発生時に判断が遅れて被害が拡大します。
あわせて、データ移行は本番前に複数回のリハーサルを行い、マッピングとクレンジングの精度を検証します。リハーサルを省くと、本番移行で在庫不整合やトレーサビリティの断絶が起き、業務が止まります。発注先がリハーサル計画を提案に含めているか、その回数と内容まで踏み込んで確認しておきましょう。
現場キーマンの巻き込みとFit to Standard
MES移行で定着に失敗する典型は、情報システム部門主導で進めて現場が反発するパターンです。これを防ぐには、発注後の早い段階から現場のキーマンをプロジェクトに巻き込み、要件と業務フローのレビューに参加してもらうことが欠かせません。現場が「自分たちのシステム」と感じられるかどうかで、稼働後の活用度が大きく変わります。
同時に重要なのが、現場の例外処理や暗黙ルールをどこまで標準機能に寄せるか、というFit to Standardの線引きです。すべての例外をシステムに作り込むとカスタマイズが無限に肥大し、コストと保守負担が跳ね上がります。発注側が主体となって、本当に必要な独自要件と、標準機能に合わせるべき業務を仕分けることで、コストを抑えつつ定着するMESを実現できます。
まとめ

MES移行を外注・委託する際は、発注先の種類を理解し、現場を止めない実績を持つパートナーを選ぶことが出発点になります。そのうえで、発注前にRFPやAs-Is/To-Be、BOP・マスタ整備という前提工程をそろえ、契約形態をフェーズごとに使い分け、委託範囲を文書で明確化することが、見積もり精度とプロジェクトの安定性を高めます。
費用は規模別の相場を押さえつつ、段階移行の中継開発やSaaSのTCO逆転、多拠点展開時のインフラ再投資といった隠れコストを総額で見極めることが重要です。そして発注後は、切り戻し計画とダウンタイムの合意、データ移行リハーサル、現場キーマンの巻き込みとFit to Standardの線引きを発注側が主体的にマネジメントすることで、工場を止めずに移行を完遂できます。外注は丸投げではなく協働であるという原則を踏まえれば、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を創業。
