MES(製造実行システム)の更改は、単なるソフトウェアの入れ替えではありません。工場の生産ラインそのものを支える基盤の差し替えであり、発注の進め方を一つ間違えるだけで「稼働初日に工場が止まる」という最悪の事態を招きかねない難易度の高いプロジェクトです。それにもかかわらず、発注の現場では「とりあえず付き合いのあるベンダーに丸投げする」「パッケージを買えばなんとかなる」といった安易な判断が後を絶ちません。
この記事では、MES更改を外部に発注・外注・委託する際の具体的な進め方を、発注先の種類と選び方、発注前に準備すべきドキュメント、契約形態の決め方、そしてMES特有の落とし穴まで体系的に解説します。生産技術や情シスの担当者が「どこに、何を、どこまで任せれば失敗しないのか」を判断できるよう、相場感や契約上の注意点も含めて整理しました。発注の意思決定に関わるすべての方に読んでいただきたい内容です。
▼全体ガイドの記事
・MES更改の完全ガイド
MES更改の発注・外注の全体像 — なぜ「丸投げ」では失敗するのか
MES更改の発注を成功させるには、まず「発注・外注・委託」という言葉が指す範囲を正しく理解し、自社が何を外部に任せ、何を自社で抱えるべきかを切り分けることが出発点になります。MESは基幹システムの中でも特に現場依存度が高く、発注側が要件を曖昧にしたまま丸投げすると、出来上がったシステムが現場の実態と乖離し、使われないまま放置されるという結末を迎えます。
発注・外注・委託・依頼の違いと使い分け
実務上、これらの言葉はほぼ同じ意味で使われますが、契約と責任分担の観点では意味合いが異なります。「発注」は成果物や業務をベンダーに正式に依頼する行為全般を指し、「外注」は自社で行える業務を外部リソースに切り出すニュアンスが強い言葉です。「委託」は法律上の業務委託契約(請負・準委任)を前提とした表現で、責任の所在が契約書で明確に定義されます。
MES更改では、システム開発そのものを「委託」しつつ、要件定義や現場ヒアリングは自社主導で進め、データ移行作業の一部を「外注」する、といった組み合わせが一般的です。どの工程を誰の責任で行うのかを最初に決めておくことが、後の認識ずれを防ぐ最大のポイントになります。
MESは「止まれば工場が止まる」— 発注先選定が成否を分ける理由
MESが他の業務システムと決定的に異なるのは、停止が即座に生産停止、つまり売上の停止に直結する点です。基幹会計システムであれば数時間の停止は許容できても、製造ラインを制御・記録するMESが止まれば、その瞬間から製品が作れなくなります。だからこそ、発注先には開発力だけでなく、製造現場を理解し「止めない移行」を設計できる経験が求められます。
価格やパッケージの機能だけで発注先を選んでしまうと、いざ稼働段階で切り戻し手順が未整備だったり、古い設備からのデータ取得方法が決まっていなかったりして、プロジェクトが頓挫します。発注先選定の段階で「製造業のMES案件をどれだけ手掛けてきたか」「現場停止リスクをどう設計に織り込むか」を見極めることが、プロジェクト全体の成否を左右するのです。
MES更改の発注先の種類と選び方
MES更改の発注先は、大きくパッケージベンダー、システムインテグレーター(SIer)、MES専門の開発会社、そしてコンサルティングファームの4タイプに分けられます。それぞれ得意領域とコスト構造が異なるため、自社の体制や更改の目的に合わせて選ぶ必要があります。
パッケージベンダー・SIer・専門開発会社・コンサルの違い
パッケージベンダーは自社製MES製品を持ち、標準機能に業務を合わせる「Fit to Standard」型の導入が得意です。導入スピードが速く、保守体制も安定している一方、現場固有の例外処理に対応しようとするとカスタマイズ費用が膨らみがちです。SIerは大規模なシステム統合やERP・PLMとの連携に強く、多拠点展開を伴う案件で力を発揮しますが、見積もりは高額になりやすい傾向があります。
MES専門の開発会社は、製造現場の事情に精通し、レガシー設備からのデータ収集やスクラッチ開発に柔軟に対応できます。近年はAI駆動開発によってスクラッチの工期やコストを30〜70%圧縮できるケースも出てきており、要件が特殊な工場ほど専門会社の価値が高まります。コンサルティングファームは要件定義やベンダー選定の上流支援に強みがあり、発注側の体制が手薄な場合に重宝します。
自社の体制別に見る最適な発注先
社内に情シス部門があり、要件を自社で固められる場合は、開発力の高い専門開発会社やSIerに開発を委託し、自社がプロジェクトの舵取りを担う体制が効率的です。一方、製造業ではIT人材が不足しているケースが多く、要件定義から運用定着までを伴走できるパートナーを求める企業も増えています。
そうした場合は、コンサルティングから開発、定着支援までを一気通貫で任せられる会社を選ぶと、ベンダー間の責任の押し付け合いを避けられます。発注先を1社に絞るか複数社に分けるかは、自社の管理体制と密接に関わるため、次章で解説する契約形態とあわせて検討することをおすすめします。
発注前に準備すべきこと — RFP・要件定義・BOP整備
MES更改の発注で最も多い失敗は、準備不足のまま見積もりを依頼してしまうことです。要件が曖昧なままでは各社の提案がばらつき、金額の妥当性を比較できず、結果的に高い見積もりを掴まされたり、後から追加費用が発生したりします。発注の前に、提案依頼書(RFP)と現場マスタの整備を済ませておくことが、適正な発注の土台になります。
RFP(提案依頼書)に必ず盛り込むべき項目
RFPには、更改の目的と背景、対象となる生産ラインや拠点の範囲、必要な機能要件、既存システムやERP・設備との連携要件、そして移行方式や稼働時期といった非機能要件を明記します。特にMESでは、トレーサビリティの取得単位(ロット単位かシリアル単位か)や、4M(人・機械・材料・方法)のどこまでを実績として記録したいのかを具体的に示すことが重要です。
あわせて、レガシー設備からのデータ取得の可否や、稼働時の切り戻し要件、保守・運用の体制といった「見積もりに大きく影響する項目」を最初から提示しておくと、後出しによる追加費用を防げます。RFPの精度がそのまま提案の精度と見積もりの正確さに直結すると考えてください。
BOP・マスタ整備という「前提工程」を発注前に済ませる
MES更改で見落とされがちなのが、BOP(工程順序・作業手順・標準時間)や各種マスタの整備です。MESはこれらのマスタを土台に動くため、BOPが未整備のまま発注すると、いくら優秀なベンダーでもシステムを正しく構築できず、プロジェクトが途中で頓挫します。マスタ整備は本来、発注側が責任を持つべき前提工程です。
もし自社だけで整備が難しい場合は、マスタ整備の支援を委託範囲に含めることをRFPで明示しておきましょう。整備されていないマスタを前提にしたまま開発を進めると、後工程で手戻りが発生し、移行時の在庫不整合や実績の不一致といった業務停止リスクにもつながります。発注前のひと手間が、プロジェクト全体の安定性を大きく左右します。
委託範囲と契約形態の決め方
発注先を決めたら、次に委託の範囲と契約形態を取り決めます。ここを曖昧にすると、トラブル発生時に「どちらの責任か」で揉め、プロジェクトが停滞します。MES更改では工程ごとに適切な契約形態が異なるため、それぞれの特性を理解して使い分けることが大切です。
一括委託 vs 分離発注(マルチベンダー)のトレードオフ
一括委託は、要件定義から開発、移行、保守までを1社に任せる方式で、窓口が一本化されるため管理が容易で、責任の所在も明確です。製造現場とITの橋渡しを一社が担うため、認識ずれが起きにくいというメリットがあります。半面、特定ベンダーへの依存が強まり、価格交渉力が弱くなる点には注意が必要です。
分離発注(マルチベンダー)は、設備連携は専門会社、アプリ開発はSIerといったように工程ごとに最適な会社へ発注する方式です。各領域で高い専門性を活用でき、コストを抑えやすい一方、ベンダー間の連携や責任分界点の管理を発注側が担う必要があり、相応の管理体制が求められます。自社のプロジェクトマネジメント力に応じて選択してください。
請負契約と準委任契約の使い分け
請負契約は成果物の完成に責任を負う契約で、仕様が固まった設計・開発・テスト工程に適しています。発注側は完成したシステムを検収し、契約金額が確定するため予算管理がしやすい点が利点です。一方、要件が固まっていない上流工程で請負契約を結ぶと、仕様変更のたびに追加契約が必要になり、かえって硬直的になります。
準委任契約は業務の遂行そのものに対して報酬を支払う契約で、要件が流動的な要件定義フェーズや、稼働後の運用・保守に向いています。MES更改では、上流は準委任、開発は請負、運用は準委任といったように、フェーズごとに契約形態を切り替えるのが現実的です。契約形態の選択は、リスクの所在とコストの予見性に直結することを念頭に置きましょう。
発注時に見落としがちなMES特有の落とし穴
MES更改の発注では、一般的なシステム開発の常識だけでは対応しきれない、製造現場ならではの落とし穴が存在します。これらを発注段階で委託範囲や契約に織り込んでおかないと、開発後半や稼働直前になって想定外の追加費用とスケジュール遅延に直面します。
レガシー設備のデータ連携・移行を委託範囲に含める
工場には、稼働して10年、20年が経過した古いPLCや海外製の設備が現役で残っているケースが珍しくありません。これらは独自の通信規格を使っていたり、そもそもデータ出力の口を持っていなかったりするため、MESへのデータ連携が一筋縄ではいきません。設備をまるごと入れ替えれば数千万円規模の投資になりますが、後付けのセンサーやゲートウェイを使ったレトロフィットIoTで、設備を更新せずにデータを取得する現実的な手段もあります。
発注の際は、どの設備からどのデータを、どの精度で取得するのかを洗い出し、その連携作業を委託範囲に明記しておくことが重要です。ここを「開発に含まれているはず」と曖昧にしたまま進めると、稼働直前に「肝心の設備データが取れない」という致命的な問題が発覚し、計画全体が崩れます。設備連携は専門性が高い領域だけに、発注先の実績確認も欠かせません。
切り戻し計画・多拠点ロールアウトを契約に明記する
MESは止まれば工場が止まるため、稼働初日に問題が発生した場合の切り戻し(ロールバック)計画を、発注時点で委託範囲に含めておく必要があります。許容できるダウンタイムはどの程度か、誰がどのタイミングで切り戻しを判断するのか、その手順は誰が用意するのかを契約で取り決めておかないと、いざという時に現場が混乱し、生産停止が長引きます。
また、1工場でのスモールスタートが成功しても、全社・多拠点へ展開する段階でトランザクションやログが急増し、ネットワーク帯域やサーバー能力が不足してレスポンス低下やセッション切断を招くことがあります。多拠点展開を見据えている場合は、工場側のデータバッファ設計やスケールアウトを前提としたインフラサイジングを委託範囲に含め、回線増強やサーバー増強の追加投資が後から数千万円単位で発生しないよう、発注時点で見通しを立てておきましょう。
発注後の進め方とベンダーマネジメント
発注は契約を交わして終わりではありません。MES更改の成否は、発注後にベンダーをどうマネジメントし、現場を巻き込みながらプロジェクトを進めるかにかかっています。委託したからといって任せきりにせず、発注側も主体的に関与する姿勢が求められます。
検収基準とテスト・リハーサルの取り決め
発注時に検収基準を明確にしておかないと、納品されたシステムが現場で使えるかどうかを客観的に判断できず、トラブルの火種になります。どのような条件を満たせば検収完了とするのか、テストの範囲と合格基準を契約段階で具体的に定義しておくことが大切です。
特にデータ移行は、本番同様の環境でマッピング定義やクレンジングを行い、複数回のリハーサルを通じて在庫や実績の不整合が起きないことを確認します。段階移行を選ぶ場合は、新旧システムを並行稼働させるためのデータ同期中継プログラムの開発や二重入力の手間が発生するため、その工数とコストを見積もりに織り込んでおく必要があります。リハーサル回数を委託範囲に明記しておくと、安全性を担保できます。
保守・運用フェーズの体制と費用
MESは稼働してからが本番です。保守・運用フェーズの体制と費用を発注時に取り決めておかないと、稼働後の障害対応が遅れ、現場の信頼を失います。一般に、保守費用は初期開発費の年間10〜20%程度が目安とされますが、24時間稼働の工場で即時対応を求めるなら、その分の体制費用が上乗せされます。
また、SaaS型のMESを選ぶ場合は、接続する設備数やデータ量、アカウント数の増加に応じて従量課金がふくらみ、数年単位で見るとオンプレミス型のTCO(総保有コスト)を上回る逆転現象が起きることがあります。発注時には初期費用だけでなく、5年程度のランニングコストまで含めて比較し、運用フェーズの費用構造を見極めることが、後悔しない発注につながります。
まとめ — MES更改の発注を成功させるために
MES更改の発注・外注・委託を成功させる鍵は、「丸投げしない」という一点に集約されます。発注先の種類と特性を理解し、自社の体制に合わせて選定すること、RFPやBOPを発注前に整備して要件を明確にすること、そしてレガシー設備の連携や切り戻し計画といったMES特有の落とし穴を委託範囲と契約に織り込むことが、失敗を避けるための要諦です。
費用相場は規模によって幅があり、小規模なら数百万円〜1,500万円、中規模で1,500万円〜5,000万円、大規模では数千万円から数億円規模に及びます。IT導入補助金などの活用も視野に入れつつ、初期費用だけでなく保守・運用まで含めたTCOで判断することが大切です。発注の準備に手間をかけるほど、稼働後のトラブルは減り、投資対効果は高まります。本記事を参考に、自社にとって最適な発注の進め方を設計してください。
発注に関するよくある質問
「発注から稼働までどのくらいの期間がかかりますか」という質問が多く寄せられます。規模にもよりますが、要件定義からスモールスタートでの稼働まで、一般的に半年から1年半程度を見込んでおくとよいでしょう。多拠点への横展開を含めると、さらに期間が延びます。短期間での稼働を急ぐあまり、要件定義やリハーサルを省略すると、結局は手戻りで時間を要するため、焦りは禁物です。
「自社にIT人材がいなくても発注できますか」という不安もよく聞かれます。要件定義から運用定着まで伴走してくれるパートナーを選べば、IT人材が手薄な企業でもMES更改は十分に実現可能です。重要なのは、現場の業務を理解し、製造業の発注を成功に導いた実績を持つ会社を選ぶことです。
追加費用を抑えるための発注のコツ
追加費用を抑える最大のコツは、発注前の要件を可能な限り固め、変更が発生しにくい状態で開発工程に入ることです。現場の例外処理をすべてシステムに作り込もうとするとカスタマイズ費用が際限なく膨らむため、標準機能に業務を寄せるFit to Standardの考え方で線引きをすることが、コスト肥大化を防ぐ鍵になります。
また、複数社から見積もりを取り、内訳の妥当性を比較することも欠かせません。見積もりの内訳が不透明な会社や、極端に安い金額を提示する会社は、後から追加費用が発生するリスクが高いと考えてください。発注の透明性を確保し、現場を巻き込みながら段階的に進めることが、結果的に総コストを抑える近道になります。
▼全体ガイドの記事
・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を創業。