MES更改の発注は、発注先を選ぶ、RFPやBOPで要件を整える、委託範囲と契約を定める、という順に進めます。この順で決めておくと、稼働後のトラブルを減らしやすくなります。
まず発注、外注、委託の違いを確かめます。全体像は、MES更改の完全ガイドでも確認できます。
▼全体ガイドの記事
・MES更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
MES更改の発注・外注の全体像 — 「丸投げ」が失敗しやすい理由
MES更改では、外部に任せる業務と自社で担う業務を切り分けることが出発点です。要件が曖昧なまま委託すると、システムが現場の実態と離れてしまい、使われなくなるおそれがあります。
発注・外注・委託の違いと使い分け
実務では同じ意味で使われることもありますが、契約と責任分担では違いがあります。発注は、成果物や業務をベンダーに正式に依頼する行為全般を指します。
- 外注：自社で行える業務を、外部リソースに切り出す意味合いです。
- 委託：請負か準委任の業務委託契約を前提に、責任の所在を契約書で定めるものです。
MES更改では、開発は委託しつつ、要件定義や現場ヒアリングは自社が主導する進め方もあります。データ移行の一部を外注する場合も、工程ごとの責任者を先に決めておくと、認識のずれを防ぎやすくなります。
MESは「止まれば工場が止まる」— 発注先選定が成否を分ける理由
基幹会計システムなら数時間の停止を許容できても、MESが止まれば製造ラインも止まり、製品を作れなくなります。そのため、発注先を選ぶときは、現場が止まる影響を踏まえて次の2点を確認します。
- 止めない移行の経験：製造現場を理解したうえで、稼働を止めずに移行を設計できるかどうか。
- MES案件の経験：製造業の案件数と、現場停止のリスクを設計に織り込んだ実績の有無。
価格やパッケージ機能だけで選ぶと、切り戻しの手順や古い設備からのデータ取得が整わないまま進み、計画が頓挫するおそれがあります。このため、発注先の選定がプロジェクト全体の成否を左右します。
MES更改の発注先の種類と選び方
発注先は、パッケージベンダー、システムインテグレーター（SIer）、MES専門の開発会社、コンサルティングファームに大別できます。得意領域とコスト構造を踏まえて、自社の体制や更改の目的に合う先を選びます。
パッケージベンダー・SIer・専門開発会社・コンサルの違い
各発注先の強みと注意点は、対応範囲や現場要件との相性で比べられます。見積もりの幅にも関わるため、各社の特徴を得意な工程と見積もりの水準の両面から見ておきます。
- パッケージベンダー：Fit to Standard型の導入を得意とし、導入が速く、保守も安定しやすい点が強みです。
- SIer：大規模な統合やERP・PLM連携、多拠点展開に強い一方で、見積もりは高額になりやすい傾向があります。
- MES専門開発会社：現場事情に通じており、レガシー設備との連携やスクラッチ開発に柔軟に対応できます。
- コンサルティングファーム：要件定義やベンダー選定など上流の支援に強く、発注側の体制が手薄なときに役立ちます。
パッケージに現場固有の例外処理を追加していくと、カスタマイズ費用が膨らみがちです。
一方で、近年はAI駆動開発により、こうしたカスタマイズの工期やコストを30〜70%圧縮できるケースもあります。要件が特殊な工場ほど、専門会社に任せる価値が高まります。
自社の体制別に見る最適な発注先
発注先の分け方は、社内で要件をまとめる力と、プロジェクト管理に割ける余力を基準に決めます。
社内に情シス部門があり、要件を固められる企業は、自社が主導する形が効率的です。
- 要件を自社で固められる：専門開発会社やSIerに、開発を委託する形が合います。
- IT人材が不足している：要件定義から運用定着まで伴走してくれる会社を候補に入れます。
コンサルティングから開発、定着支援まで一社に任せると、ベンダー同士が責任を押し付け合う事態を避けられます。
発注先を1社に絞るか、複数社に分けるかは、自社の管理体制と契約形態に合わせて判断します。
発注前の準備 — RFP・要件定義・BOP整備
準備が足りないまま見積もりを依頼すると、各社の提案がばらつき、金額が妥当かどうかを比べられません。高い見積もりや後からの追加費用を避けるため、発注側は提案依頼書（RFP）と現場マスタを整えておきます。
RFP(提案依頼書)に必ず盛り込むべき項目
RFPには、目的・対象から記録要件までの四つを書いておきます。見積もりを同じ前提でそろえるには、この四つが欠かせません。
- 目的・対象：更改の背景、生産ラインや拠点の範囲。
- 機能・連携：必要な機能と既存システム、ERP、設備との連携要件。
- 移行・稼働：移行方式、稼働時期などの非機能要件。
- 記録要件：トレーサビリティの取得単位（ロットかシリアルか）と、4M（人・機械・材料・方法）の記録範囲。
あわせて、レガシー設備からのデータ取得の可否、稼働時の切り戻し要件、保守・運用体制も示します。見積もりに影響する条件を先に共有しておくと、後出しによる追加費用を防ぎやすくなります。
発注前に済ませるBOP・マスタ整備
MESの基盤となるBOP（工程順序・作業手順・標準時間）や各種マスタは、発注前に整えておく必要があります。
- 整備の責任：マスタ整備は本来、発注側が担うべき作業です。
- 外部支援：自社だけで整備するのが難しいときは、支援を委託範囲に含めることをRFPに明記します。
BOPやマスタが整わないままでは、優秀なベンダーでも正しく構築できず、プロジェクトが頓挫するおそれがあります。未整備のマスタを前提に開発すると、後工程で手戻りが起き、移行時の在庫不整合や実績の不一致、業務停止のリスクにつながります。発注前の整備が、プロジェクト全体の安定性を左右します。
委託範囲と契約形態の決め方
発注先を決めたら、委託範囲と契約形態を定めます。ここが曖昧なままだと、トラブルが起きたときに責任の所在をめぐって揉め、プロジェクトが停滞してしまいます。
MES更改では、工程ごとに適した契約形態が異なります。そのため、それぞれの特性を理解して使い分けることが大切です。
一括委託 vs 分離発注(マルチベンダー)のトレードオフ
一括委託と分離発注は、管理の負担と専門性のどちらを重視するかで選びます。それぞれの違いを踏まえて、自社の管理体制に合う形を判断します。
- 一括委託：要件定義から保守まで一社に任せ、窓口と責任をまとめられます。
- 分離発注：工程ごとに専門会社へ依頼できる一方で、工程どうしの連携を取り、どこまでを誰が受け持つかを決めておく必要があります。
一括委託は、製造現場とITの橋渡しを一社が担うため認識のずれを防ぎやすい反面、特定のベンダーへの依存が強まり、価格の交渉力が弱くなりがちです。
分離発注では、たとえば設備連携を専門会社に、アプリ開発をSIerに頼むような形があります。コストを抑えやすい一方で、発注側には相応の管理体制が求められます。
請負契約と準委任契約の使い分け
請負と準委任は、成果物の完成責任を求めるのか、業務の遂行を委ねるのかで使い分けます。工程の仕様が固まっているかどうかも、判断材料になります。
- 請負契約：成果物の完成に責任を負うため、仕様が固まった設計・開発・テストに向いています。
- 準委任契約：業務の遂行そのものに報酬を支払う形で、要件定義や稼働後の運用・保守に合います。
請負は検収と契約金額が明確なため予算を管理しやすい一方で、上流工程で仕様変更が続くと追加の契約が必要になります。準委任は、要件がまだ流動的な工程との相性が良い形です。
MES更改では、上流は準委任、開発は請負、運用は準委任とする方法が現実的です。契約形態は、リスクの所在とコストの見通しに直結します。
発注時に見落としがちなMES特有の落とし穴
MES更改には、一般的な開発の常識だけでは対応しにくい、製造現場特有の落とし穴があります。これらを委託範囲や契約に織り込んでおかないと、開発の後半や稼働直前に追加費用や遅延が生じます。
レガシー設備のデータ連携・移行の委託範囲
工場では、稼働から10年、20年が経つ古いPLCや海外製の設備が使われていることがあります。独自の通信規格やデータ出力口を持たない設備は、MESとの連携が難しい場合があります。
設備連携の方法は、全面更新とレトロフィットIoTのどちらを選ぶかで、投資やデータの取得方法が変わります。
- 設備の全面更新：数千万円規模の投資が必要になります。
- レトロフィットIoT：後付けのセンサーやゲートウェイを使い、設備を更新せずにデータを取得できます。
発注時には、取得する設備とデータ、必要な精度を洗い出し、連携作業を委託範囲に明記しておきます。
「開発に含まれるはず」と曖昧にしたままだと、稼働直前になってデータが取れないことが分かり、計画が崩れるおそれがあります。
設備連携は専門性が高いため、発注先がこの分野で実績を持つかどうかも確認します。
切り戻し計画・多拠点ロールアウトの契約上の扱い
切り戻しと多拠点展開について、契約に含める事項を発注時にそれぞれ明確にしておきます。
- 切り戻し計画：許容ダウンタイム、判断者と判断時期、手順の作成者を定めます。
- 多拠点展開：展開を見据える場合は、工場側のデータバッファ設計と、スケールアウトを前提としたインフラのサイジングを委託範囲に含めます。
稼働初日の問題に備えた取り決めがなければ、現場は混乱し、生産停止も長引いてしまいます。
多拠点展開では、工場数が増えることによる処理量の増加も見込んでおきます。1工場で導入したあと、トランザクションやログが増えると、ネットワーク帯域やサーバーの能力が不足し、レスポンスの低下やセッションの切断が起きることがあります。
回線やサーバーの増強に数千万円単位の追加投資が後から発生しないよう、発注時に見通しを立てておきます。
発注後の進め方とベンダーマネジメント
MES更改では、契約後のベンダーマネジメントも欠かせません。委託したあとも任せきりにせず、発注側が現場を巻き込みながら主体的に進めます。
検収基準とテスト・リハーサルの取り決め
検収基準が曖昧だと、納品されたシステムが現場で使えるかどうかを客観的に判断できません。そのため、検収完了の条件、テスト範囲、合格基準を契約時に定めておきます。
データ移行では、本番同様の環境でマッピング定義やクレンジングを行います。そのうえで複数回のリハーサルを重ね、在庫や実績に不整合がないことを確かめます。
段階移行では、新旧システムを並行稼働させるため、データ同期の中継プログラムの開発や二重入力が発生します。その工数とコストを見積もりに含め、リハーサルの回数も委託範囲に明記しておくと、安全性を担保しやすくなります。
保守・運用フェーズの体制と費用
MESでは、稼働後の保守・運用体制も発注時に決めておきます。体制が不十分だと障害への対応が遅れ、現場の信頼を失うおそれがあります。費用を見積もるときは、次の費用を比べます。
- 保守費用：初期開発費の年間10〜20%程度が目安で、24時間の即時対応には体制費用が上乗せされます。
- SaaS型の従量課金：設備数、データ量、アカウント数に応じて増え、数年でオンプレミス型のTCO（総保有コスト）を上回ることもあります。
- ランニングコスト：初期費用に加えて、5年程度の費用も含めて見ておく必要があります。
運用フェーズの費用構造を確かめておくことが、後悔の少ない発注につながります。
まとめ — MES更改の発注の成功要因
MES更改では、丸投げを避けたうえで、発注先を自社の体制に合わせて選びます。
RFPやBOPを整えて要件を明確にし、設備連携や切り戻し計画を委託範囲と契約に含めておくと、失敗を避けやすくなります。
費用相場は、小規模で数百万円〜1,500万円、中規模で1,500万円〜5,000万円、大規模で数千万円から数億円が目安です。
IT導入補助金なども視野に入れつつ、初期費用だけでなく、保守・運用を含むTCOで判断します。
発注の準備に手間をかけるほど、稼働後のトラブルが減り、投資対効果も高まります。自社に合う発注の進め方を、この流れに沿って設計してください。
発注に関するよくある質問
発注から稼働までの期間は、どのくらいかかりますか。規模によって異なりますが、要件定義からスモールスタートまでは、一般的に半年から1年半程度です。多拠点への横展開を含めると、さらに期間が延びます。
稼働を早めたいとき、要件定義やリハーサルを省いてもよいのでしょうか。稼働を急いで要件定義やリハーサルを省くと、手戻りが生じ、結果として時間がかかります。工程は省かずに進めましょう。
IT人材が手薄な企業でもMES更改は進められるのでしょうか。要件定義から運用定着まで伴走してくれるパートナーを選べば、十分に実現できます。その際は、現場業務への理解と製造業の発注実績を確認しておきます。
追加費用を抑えるための発注のコツ
追加費用を抑えるには、発注前の要件整理と見積もりの比較が判断材料になります。
- 要件を固める：変更の回数を減らし、例外処理の作り込みはFit to Standardで線引きします。
- 複数社の見積もりを比べる：内訳の妥当性を確かめます。不透明な内訳や極端に安い金額は、あとから追加費用が生じるリスクがあります。
発注の透明性を保ち、現場を巻き込んで段階的に進めることが、総コストを抑える近道です。
▼全体ガイドの記事
・MES更改の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。