MES改修は、MES（製造実行システム）を全面的に作り替えず、特定工程の実績入力画面の修正や特定設備・PLCとの連携追加など、部分的・小規模な範囲に手を加える取り組みです。フルスクラッチ・オーダーメイド開発は、部分改修で対応しきれないと分かったときに検討する例外的な選択肢です。
「MESのモダナイゼーション」「MES刷新」「MESのリアーキテクチャ」「MESリプレイス」は、システム全体または大部分を刷新する取り組みです。「MES更改」は保守契約の満了やEOS/EOLといった期限を起点にした全体の入れ替えで、「MESのリニューアル」は現場オペレーターの操作体験を刷新する取り組みです。
これらと違い、本記事のMES改修は、システム全体には手を入れず、「今困っている特定の箇所だけ」を対象にします。
「フルスクラッチ・オーダーメイド開発」というテーマも、他の6テーマとは前提が大きく異なります。他の6テーマでフルスクラッチといえば、システム全体をゼロから作り直す、最も大規模な選択肢を指します。
本記事が扱うのは、部分改修の枠組みの中での判断です。具体的には、特定工程の実績入力画面の修正や特定設備・PLC連携の追加といった小規模な改修を、部分的な追加開発で進めるか、フルスクラッチが必要になる場合があるのかを見極めることです。
「小規模な改修のはずなのに、なぜフルスクラッチが選択肢に挙がるのか」と疑問に思う方も多いかもしれません。実務では、「実績入力画面を1つ直したいだけ」という軽微な相談から始まっても、既存システムを調べるうちに、その画面が他の複数の機能と密接に絡み合っていると判明するケースが少なくありません。そうなると、部分的に手を入れること自体がリスクになります。
こうした事態を防ぐには、部分改修とフルスクラッチの違いと、どちらを選ぶかの判断基準を、あらかじめ押さえておくことが大切です。
本記事は、システム全体の作り替えを前提とする他の6テーマや、システムを問わない総論とは異なり、MESの部分的・小規模な改修に対象を絞ります。そのうえで、フルスクラッチ・オーダーメイド開発との関係を解説します。
- 位置づけ：MESの独自製造要件
- 基準：フルスクラッチを選ぶ条件
- 費用：開発・運用・保守の比較
本テーマの全体像は、下に挙げる全体ガイドで確認できます。開発期間・スケジュールやPoC・プロトタイプ、保守・運用費用については、姉妹記事もあわせてご参照ください。
▼全体ガイドの記事
・MES改修の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
MES改修におけるフルスクラッチという選択肢の位置づけ
フルスクラッチは、部分改修では対応しきれないと判明して初めて視野に入る例外的な選択肢です。そのため、MES改修でフルスクラッチを検討する前に、まず「部分改修で対応するのが原則」という大前提を理解しておく必要があります。
この原則を最初に共有しておけば、社内の検討が「フルスクラッチにするかしないか」という極端な二択に陥るのを防げます。まずは部分改修で解決できないかを丁寧に検証する、建設的な進め方につながります。
他の6テーマとの違い（全体刷新の手段か・部分改修の例外か）
「MESのモダナイゼーション」におけるフルスクラッチは、5R（リホスト・リプラットフォーム・リファクタリング・リビルド・リプレース）の1つ「リビルド」に相当します。「MES刷新」「MESのリアーキテクチャ」「MESリプレイス」「MES更改」でも、システム全体をゼロから作り直す大規模な意思決定が前提です。
他の6テーマでは、フルスクラッチは初期費用数千万円〜数億円、期間1年以上の規模で語られ、経営層が独自の工程管理ロジックや競争優位性への投資対効果を吟味する重い判断になります。一方、本記事のMES改修では、特定工程の実績入力画面修正や特定設備・PLC連携追加といった小規模な案件の原則は部分改修で、フルスクラッチは部分改修で対応しきれないと判明した場合の代替手段です。
本記事が扱うのは、現場の情報システム部門が、身の丈に合った部分改修で片付くか、大がかりな対応が要るかを見極める実務的な判断です。この違いを押さえると、社内の議論が全社的な刷新の是非へ広がるのを防げます。稟議でも規模感を最初に示せば、経営層に無用な警戒感を与えず、スピーディーな承認を得やすくなります。
「原則は部分的な追加改修」という基本方針
MES改修の対象になる「特定工程の実績入力画面修正」や「特定設備・PLCとの連携追加」といった小規模な案件は、原則として既存システムへの部分的な追加改修で対応するのが基本です。既存のMESが安定して稼働し、対象箇所の仕様が明確であれば、ゼロから作り直す必要はありません。その場合は、部分改修のほうが期間・費用ともに圧倒的に有利です。
ただし、既存システムの状態によってはフルスクラッチが必要になるケースもあります。そのため、まずは自社の現行システムの状態を客観的に点検することが、判断の出発点になります。
自社の現行システムの点検を省いて「とりあえず改修してみて、ダメならまた考える」という進め方をすると、着手後にシステムの限界が発覚し、投じた費用と時間が無駄になるリスクが高まります。
部分改修かフルスクラッチかの判断基準
自社の状態を点検して部分改修とフルスクラッチのどちらを取るべきかを判断するには、4つの観点を1つずつ確かめるのが近道です。感覚ではなく根拠に基づいて、意思決定できます。
将来の業務要件・現行システムの品質という2観点
1つ目の観点は「将来の業務要件（どう変えたいか）」です。今後、工場の業務プロセス全体を大きく変える予定がなく、特定工程の不便さだけを解消したいのであれば、部分改修が適しています。逆に、全社的な業務フローを根本から見直したい場合は、フルスクラッチが適しています。
この観点を確認する際は、情報システム部門だけで判断せず、現場の生産技術部門や品質保証部門にも「今後3〜5年でこの工程の運用は変わる見込みがあるか」をヒアリングするのが望ましいです。部門間で認識がずれていると、せっかく部分改修で片付けた案件が、翌年には別の改修として再び持ち上がる二度手間になります。
2つ目の観点は「現行システムの品質・限界」で、安定して稼働していれば部分改修で十分です。一方、場当たり的なカスタマイズの繰り返しでシステムがスパゲッティ化し、少し画面をいじっただけで関係ない工程が止まる限界状態なら、フルスクラッチ（リビルド）を視野に入れる必要があります。2つの観点を見るだけでも、多くのケースでどちらの方向が妥当かを絞り込めます。
ブラックボックス度・予算と期間の制約という2観点
3つ目は「ブラックボックス度（中身が分かるか）」です。当時の開発担当者が退職し、誰も中身や設備連携の仕様を説明できない状態で部分改修を行うと、致命的な障害を招く危険があります。この場合は、まず現行システムの仕様を調査・文書化する「読める化」の工程を挟み、それが不可能であればフルスクラッチへの切り替えを検討します。
4つ目は「予算と期間の制約」です。予算が限られる場合は、最初から全面刷新やフルスクラッチを狙うと失敗しやすいため、課題の最も大きい工程（設備連携など）に絞って、段階的に部分改修を進めるのが安全です。4つの観点すべてを点検し、現状調査に慣れた外部パートナーに早い段階で相談すると、判断のスピードと精度を両立させられます。
実務上は、4つの観点のどれかに「フルスクラッチ寄り」の兆候が見られても、すぐに全面的な作り直しへ切り替える必要はありません。たとえば、読める化を先に行い、課題のある範囲に限ってフルスクラッチ（部分的な作り直し）を行うという中間的な選択肢もあります。課題の所在を切り分けると、二択を避けて課題のある部分だけを作り直す、現実的な進め方が見えてきます。
規模別の費用感と期間の目安
部分改修とフルスクラッチでは、費用と期間の水準が大きく違います。この差を押さえておくと、投資判断の精度が上がります。
小規模な部分改修の費用感（約500万円〜2,000万円・期間約1〜3ヶ月）
小規模な部分改修（画面修正、特定設備連携など）の目安は、期間が約1〜3ヶ月、費用が約500万円〜2,000万円です。単純な文言変更や入力項目の追加なら、数万円〜数十万円で済むこともあります。一方、PLCなどの特定設備との連携追加が含まれると、テスト環境の準備や既存機能への影響確認（デグレードテスト）に多くの工数がかかり、費用が膨らみやすくなります。
この規模であれば、多くの製造業にとって年度予算の範囲で対応できる水準に収まります。一般的には、要件定義・設計に全体の35〜45%、開発・実装に30〜40%、テストに15〜30%程度が配分されます。部分改修でも要件定義・設計の比重は小さくなく、対象範囲の線引きや影響範囲の洗い出しに相応の工数がかかるためです。
見積もりを受け取ったら、内訳のバランスが極端に偏っていないかを確認してください。たとえば、開発費用だけが突出して安く、テスト費用がほとんど計上されていない場合は要注意です。後から想定外の追加費用を請求されないための、実務的なチェックポイントになります。
フルスクラッチ（全面刷新）の費用感（8,000万円〜数億円・期間半年〜複数年）
これに対しフルスクラッチ（全面刷新）は、期間の目安が半年〜複数年（1年以上）、費用の目安が8,000万円〜数億円以上です。システム全体を設計からゼロベースで作り直すため、期間とコストは多大になり、要件定義の負荷もかかります。両者の差は10倍〜数十倍にも及ぶため、部分改修で対応できる案件を安易にフルスクラッチへ寄せると、本来不要な投資を強いられます。
逆に、部分改修では根本的な解決にならないと分かっていながら部分改修に固執すると、改修のたびに追加費用が発生します。最終的にはフルスクラッチに近い総額を払うことになりかねず、本末転倒です。自社の状況が前の節の4つの観点のどこに当たるかを見極めてから、規模感を選ぶことが大切です。
上記の2つの費用の目安の間には大きな空白があり、明確な中間の選択肢は見当たりません。その空白に当たる、複数工程にまたがるがシステム全体ではない改修は、分けて段階的に進められないか、開発会社と検討する価値があります。一度に予算を確保せず、優先度の高い工程から年度をまたいで進める方法は、単年度の予算枠が限られる企業に現実的です。
開発会社選定のポイント（失敗しないための基準）
工場システムは「絶対に止められない業務」であるため、部分改修でもフルスクラッチでも、パートナー選定は慎重に行う必要があります。ここでは、選定時に確認したい基準を順に解説します。
製造業・PLC連携の実績と「読める化」の提案力
「実績多数」という言葉だけで判断せず、製造業（工場）のシステム改修や、PLCなどの設備連携の実績があるかを確かめます。大企業向けのシステム開発ばかりの会社に頼むと、仕様が過剰になってコストが膨らみます。逆に、Web系システムしか経験のない会社では、現場の業務やセキュリティ要件を理解できず、プロジェクトが混乱するおそれがあります。
あわせて、要望を聞いて「はい、作れます」と技術的な可否だけで即答する会社は、既存システムとの影響範囲を見落とす危険があります。真のパートナーは、「まずは業務フローや既存システムの仕様を拝見させてください」と述べ、課題の構造把握や「読める化」から着手することを提案してくれます。
この姿勢があるかどうかが、部分改修とフルスクラッチのどちらが妥当かを、発注側だけでなく開発会社の視点からも検証してもらえるかの分かれ目になります。
見積もりの内訳（工数・単価）の明確さ
「システム改修一式〇〇万円」といった総額だけの見積もりは、追加費用が発生しやすい典型的なパターンです。どの画面に何人月、テストに何人月、PM（プロジェクト管理）に何人月かかるかを示せる会社を選んでください。特に、部分改修とフルスクラッチのどちらで進めるか迷う段階では、両方の見積もりを取り、内訳ベースで比べると、想定外の予算超過を防げます。
見積もりの内訳が明確な会社ほど、後工程で仕様変更が起きても、変更箇所の工数を的確に算出してくれるため、プロジェクト全体を通じた信頼関係を築きやすくなります。契約形態も、あわせて確かめておきたい点です。改修範囲と要件が明確な案件では、納期とコストを確定させやすい請負契約が適しています。
一方、「読める化」の結果次第で方針が変わる案件では、まず調査・分析だけを準委任契約で発注し、方針が固まったら本改修を請負契約に切り替える二段階の進め方も有効です。最初から一括の請負契約で発注すると、調査でフルスクラッチが必要と分かったときに、契約の結び直しや見積もりとの差異をめぐる交渉が生じがちです。契約形態を柔軟に使い分けられるかも、選定時の確認ポイントです。
まとめ
MES改修とフルスクラッチ・オーダーメイド開発の関係について、他の6テーマとの違い、部分改修かフルスクラッチかの判断基準、規模別の費用感と期間の目安、開発会社選定のポイントを順に見てきました。
特定工程の実績入力画面修正や特定設備連携追加であれば、まずは「部分的な追加改修」を前提に進めるべきです。期間約1〜3ヶ月、費用約500万円〜2,000万円という現実的な水準で解決できるケースが大半です。
現行システムがブラックボックス化している、あるいはスパゲッティ化して限界を迎えている場合は、フルスクラッチへの切り替えも視野に入れる必要があります。
自社の状況は、将来の業務要件・現行システムの品質・ブラックボックス度・予算と期間の制約という4つの観点で点検します。そのうえで、製造業に強い開発会社に「既存システムの仕様調査」から依頼し、現行システムに手を入れても問題ないかを確かめてから、見積もりと方針を決めるのが最も確実です。
▼全体ガイドの記事
・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を創業。