MES移行の発注/外注/依頼/委託方法について

MES移行の発注は、現状と目指す姿を整理し、委託範囲と契約形態を決め、発注後の管理体制を整える順に進めます。この順で進めると、工場を止めずに移行を完遂しやすくなります。

▼全体ガイドの記事
・MES移行の完全ガイド

MES移行を外注すべき理由と発注前に押さえる全体像

MESは生産ラインの制御や設備データの収集に関わり、品質管理やトレーサビリティにも関係します。また、停止すれば工場も売上も止まるため、一般的な業務システムより移行が難しくなります。

MES移行が内製では難しい理由

内製で完結させにくい最大の理由は、必要なスキルの幅が広く、専門性も高いことです。たとえば、PLCやSCADAといった設備制御の知識も求められます。

  • 設備データ取得:古い独自通信規格への対応やレトロフィット技術
  • システム連携:ERPやPLMとのデータ連携設計
  • 業務と移行:製造業務の知識と大規模システムの移行ノウハウ

これらをすべて社内にそろえている製造業はまれで、情報システム部門が数名規模の企業がほとんどです。

MES移行は数年に一度の非定常プロジェクトです。そのため、専任チームを常時抱える方法は、人件費の面で現実的ではありません。

サポート終了(EOL/EOSL)が迫るなかで短期間に確実に移行するには、専門の外部パートナーへの委託が合理的です。委託すれば、自社は要件と現場知識の提供に集中できます。

内製にこだわって移行が遅れ、サポート切れと重なると、生産が止まるおそれがあります。このリスクは避けるべきものです。

発注/外注/依頼/委託の違いと選択肢

日常会話では「発注」「外注」「依頼」「委託」をほぼ同じ意味で使いますが、契約実務では意味が分かれます。

  • 発注:対価を払い、成果物やサービスを正式に注文する行為
  • 外注:自社で行わず、社外のリソースに任せること
  • 依頼:業務や作業を頼む広い意味の言葉
  • 委託:第三者に業務の遂行を任せる契約上の概念

委託には、成果物の完成を約束する「請負」と、業務の遂行を約束する「準委任」があります。

MES移行では工程ごとに契約形態を使い分けます。

たとえば、要件定義やコンサルティングは準委任で伴走してもらい、開発やデータ移行は請負とする組み合わせが典型です。

発注側は発注先に丸投げせず、業務ごとの委託形態を設計しておくことが、後のトラブルやコストを左右します。

MES移行の発注先の種類と選び方

発注先は大きく4タイプに分かれます。

タイプごとに得意領域、費用感、現場対応力が異なるため、自社の課題に合わせて選ぶことになります。

発注先の4タイプと特徴

各タイプの得意分野と留意点を並べて比べると、優先する条件に合う発注先が見えてきます。

  • MESパッケージベンダー:自社製品の導入と標準テンプレートに強い
  • 大手SIer:多拠点展開やERP連携を含む全体最適に強い
  • 製造系専門会社:現場業務、BOP整備、レトロフィットIoTに強い
  • 一気通貫の企業:コンサルから開発、定着支援まで担う

パッケージベンダーは製品の範囲外の要件に弱く、無理に合わせて過度なカスタマイズを重ねると、コスト肥大を招きます。一方で、大手SIerは費用が高めで、現場の細かな例外処理に対しては機動力が劣りがちです。さらに、一気通貫の企業は要件整理から運用まで窓口を一本化できるため、社内リソースが限られる企業に向いています。

現場への適合を優先するか、全社標準化を優先するかで、適切なタイプは変わります。発注先を誤ると、現場に合わない標準機能を押し付けられたり、設備連携でつまずいたりします。その結果、プロジェクトが頓挫することもあります。

製造現場を止めない発注先を見極める基準

最も重要な基準は、現場を止めずに移行した実績です。提案の場では、次の対応を具体的に確認します。

  • 設備対応:古いPLCや海外製設備からのデータ取得経験
  • 移行検証:データ移行リハーサルを複数回行う方法
  • 障害対応:稼働初日の問題に備えた切り戻し計画

これらに触れず、機能や価格だけを訴える発注先には注意が必要です。

ERPは計画層、MESは実行層で、動く粒度も異なります。

月次や日次で動くERPと分・秒単位のMESを安易にリアルタイムで密結合すると、性能が破綻し、画面が重くなって現場で使えなくなるおそれがあります。

発注側は、疎結合・非同期連携を提案するかを発注先に確認します。

同業種・同規模の移行実績も、可能な限り具体的な数字とともに確かめます。

ポイント

発注先候補で迷ったら、現場への適合と全社標準化のどちらを優先するかを先に決めます。そのうえで、現場を止めずに移行した実績を比べると絞り込みやすくなります。

発注前に準備すべきドキュメントと要件整理

発注の成否は、発注前の準備で8割が決まります。

要件が曖昧なままだと、見積もりが膨らみ、追加費用や仕様変更も頻繁に起きます。

RFP・要件定義・As-Is/To-Be整理

要件整理は、現状業務と目指す姿を資料にするところから始まり、その内容をRFPにまとめます。

  • As-Is資料:現状業務を示す資料
  • To-Be構想:目指す姿を描いた構想
  • RFP(提案依頼書):要求仕様をまとめた資料

RFPには、対象の工場・ライン・機能、連携システム、移行データ量を記します。さらに、希望日程、予算レンジ、評価基準も書き入れます。

資料がそろっていれば、複数社から同じ条件で見積もりを取れるため、比較の精度も高まります。

自社だけではRFPを書き切れない場合でも、要件定義だけを専門会社に準委任で伴走してもらう方法があります。

要件整理に数十万円から数百万円を投じることをためらう企業は少なくありません。しかし、要件整理を省くと開発段階で数倍の手戻りコストが発生するため、発注前の投資こそ総コストを抑える手段になります。

BOP・マスタ整備という前提工程

工程を正確に制御し、移行後のデータ整合性を保つには、BOPとマスタの整備が欠かせません。

  • BOP:工程順序・作業手順・標準時間。未整備だとシステムが工程を正しく制御できません
  • マスタデータ:品目・設備・工程・ロット単位の定義が拠点ごとに異なると、在庫不整合やトレーサビリティの断絶につながります

BOPは発注先任せにせず、現場の暗黙知を持つ発注側が主体となって整理します。標準作業が未定義のまま開発中に判明すると、プロジェクトが止まります。

発注前にマスタの中身を一覧にして洗い出し、クレンジングの方針と整備の責任者を社内で合意しておくと、手戻りや追加費用を減らせます。

ポイント

RFPの条件が曖昧なまま見積もりを取ると、比較の土台がずれます。As-Is・To-Beと主要な条件を先にそろえておくと、見積もりの差の理由を読み取りやすくなります。

契約形態と委託範囲の決め方

請負と準委任を、責任を負う対象で左右に比べた図
契約を分ける軸は、完成物と業務遂行のどちらに責任を置くかです。

契約形態と委託範囲は、リスクの配分と費用を左右します。仕様が固まっている工程と、まだ不確実な工程が混在するため、フェーズごとに契約を使い分けます。

すべてを一律に請負契約で進めると、要件変更のたびに高額な追加見積もりが発生します。

請負契約と準委任契約の使い分け

仕様がどこまで確定しているかに応じて契約を選ぶと、変更のリスクと責任の範囲を整理できます。

  • 請負:成果物の完成に責任を負い、仕様が明確な開発・データ移行に適する
  • 準委任:業務の遂行に責任を負い、要件定義・コンサル・PoC(実証)に向く

請負は完成の責任を求められる一方で、仕様変更に弱く、変更のたびに再見積もりが必要です。

実務では、要件定義を準委任、仕様確定後の開発と移行を請負、稼働後の保守と運用支援を準委任とする組み合わせが一般的です。

流動的な上流工程まで請負で縛ると、発注先は安全余裕を大きく見積もるため、費用が高額になる場合があります。

委託範囲の線引きと体制の明確化

工程ごとに、外注する範囲と自社で担う範囲を決めておきます。特に責任が曖昧になりやすい項目は、文書にして明確にします。

  • 開発工程:設計・開発・データ移行
  • 現場対応:設備連携(レトロフィット)・テスト・教育
  • 稼働後:保守

設備連携やマスタ整備では、「発注先が担当すると思っていた」という行き違いが起きがちです。そこでRACI(責任分担表)などで役割を文書にしておくと、紛争を防ぐ助けになります。

一括で委託する場合でも、発注側にはプロジェクトオーナーと現場キーマンが必要です。発注先だけでは、現場の要件を正しく引き出せないためです。

委託範囲を広げるほど、発注側の体制と意思決定のスピードが推進力を左右します。

ポイント

一律に請負で縛らず、仕様が固まった工程は請負、流動的な上流工程は準委任と分けて考えます。委託範囲は発注側が担う工程まで含めて文書にすると、行き違いを防ぎやすくなります。

発注時の費用相場と見積もりの読み方

小規模・中規模・大規模のMES移行費用相場を3枚のパネルで示した図
対象範囲の広さと機能の組み合わせに沿って、相場が段階的に変わります。

費用相場を把握しておくと、発注時の交渉に役立ちます。相場から大きく外れた見積もりには必ず理由があり、その理由を読み解けるかどうかが、適正価格で発注できるかを左右します。

MES移行の費用は、規模と要件の複雑さによって変動します。

規模別の費用相場と内訳

規模ごとの目安と照らし合わせて、対象範囲に見合った見積もりかどうかを確認します。

  • 小規模:単一ライン・限定機能で数百万円から1,500万円程度
  • 中規模:複数ライン・標準機能で1,500万円から5,000万円程度
  • 大規模:多拠点・フルスコープで数千万円から数億円規模

費用の大半は人件費、つまり工数(人月)です。工数は工程ごとに積み上がり、要件定義や設計、開発のほか、データ移行、テスト、教育の工程でも発生します。

IT導入補助金などの公的支援を使える場合は、対象になれば初期費用を軽減できます。ただし、申請要件と採択日程があるため、発注先の申請支援も確認します。

見積もりで見落としがちな隠れコスト

初期費用以外の隠れコストも含めて、移行方式や運用環境ごとの総額を把握しておきます。

  • 段階移行:データ同期中継プログラムの追加開発費と、現場の二重入力にかかる人的コスト
  • SaaS型MES:接続設備数・データ量・アカウント数に応じて増える従量課金
  • 多拠点展開:トランザクションやログの急増でネットワークやサーバが不足し、再投資が必要になる場合

段階移行は安全ですが、中継開発と移行期間の長期化によって、一括移行より総コストが膨らみます。

数年単位で見ると、SaaS型MESのTCOがオンプレミスを上回ることがあります。

数千万円規模のインフラ再投資が突発する場合もあります。

見積もりは初期費用だけでなく、3〜5年のランニング費用を含む総額で比べます。

費用の内訳と相場については、後述の関連記事でも解説しています。

ポイント

金額だけで比べず、3〜5年のランニング費用を含めた総額で判断します。相場から外れた見積もりは、理由を発注先に説明してもらうと見極めやすくなります。

外注を成功させる発注後のマネジメント

発注後の管理項目として切り戻し条件、データ移行検証、現場キーマンの参加、Fit to Standardを並べた図
移行前の備えと現場参加、標準機能への適合を一緒に進めます。

契約後も、発注側が主体となって管理する必要があります。外注は任せきりにすることではなく、発注先との協働の始まりです。

切り戻し計画とダウンタイムの合意

MESが止まると工場停止につながるため、事前の準備が防衛策になります。

稼働切替の前に、発注先と計画を固めておきます。

  • 切り戻し条件:判断基準、許容するダウンタイムの上限、実行権限者を経営層も含めて事前に合意する
  • データ移行検証:本番前に複数回リハーサルし、マッピングとクレンジングの精度を確かめる

切り戻しを稼働後に決めようとすると、障害が起きたときの判断が遅れます。

リハーサルを省くと、在庫不整合やトレーサビリティの断絶によって業務が止まるおそれがあります。そのため、発注先の提案で実施回数と内容を確認します。

現場キーマンの巻き込みとFit to Standard

情報システム部門だけで主導するのは、現場の反発を招いて定着に失敗する典型的なパターンです。

  • 現場キーマンの参加:発注後の早い段階から要件や業務フローのレビューに加わってもらう
  • Fit to Standard:例外処理や暗黙ルールをどこまで標準機能に合わせるか決める

現場が自分たちのシステムだと感じられるかどうかで、稼働後の活用度が変わります。

例外をすべて作り込むと、カスタマイズと保守の負担が膨らみます。そこで発注側が、独自要件とするものと標準機能に合わせるものを仕分けると、コストを抑えながら定着を目指せます。

ポイント

障害が起きてから切り戻しを迷うと、判断が遅れて止まる時間が延びます。事前に決めた判断基準と実行権限者があれば、その場で動けます。

まとめ

MES移行では、現場を止めない実績のある発注先を選びます。そのうえで、RFPやAs-Is/To-Be、BOP・マスタ整備を進め、契約と委託範囲を文書で明確にします。

費用は規模別の相場に加え、移行や運用の隠れコストも含めて総額で比べます。発注後は、切り戻し計画やリハーサル、現場キーマンの参加、Fit to Standardを発注側が主体となって管理します。

外注を丸投げせず発注先と協働することが、工場を止めずにMES移行を完遂するための基本になります。

▼全体ガイドの記事
・MES移行の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。