MES更改でフルスクラッチ・オーダーメイド開発を選べるかは、期限内に実現できるかで決まります。期限のある更改では原則として非推奨で、例外に当たる場合に限り、リスク管理を前提に選びます。
モダナイゼーションでは、5R（リホスト、リプラットフォーム、リファクタリング、リビルド、リプレース）のどれが技術的に最適かを問います。刷新では、自社の工程管理・品質保証の独自性にどこまで投資すべきかを経営判断として問います。その詳細は、それぞれの記事に譲ります。
- フルスクラッチ開発を選ぶ理由と適用範囲
- 既存業務・データ・外部連携の整理
- 開発期間・費用・体制を踏まえた判断
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・MES更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
期限のある更改案件でフルスクラッチが原則非推奨である理由
フルスクラッチ開発は、自社業務に100%適合するシステムを作れる点が魅力です。ただし更改では期限があるため、その特性がかえってリスクに転じます。原則非推奨とされるのは、期限内に構築しきれないリスクと、フルスクラッチを選ぶ合理性が乏しい業務があるためです。
要件定義からの構築期間そのものが期限を超過するリスク
フルスクラッチ開発は、要件定義・設計・開発・テストをすべて一から行います。そのため、小規模なシステムでも半年〜1年、複数ラインを横断する大規模なMESでは1年以上かかることが珍しくありません。
更改の判断リミットは、契約満了・EOS/EOLの1年〜1年半前です。しかし、すでにその時期を過ぎている案件も多く、そこから要件定義に着手すると、期限超過を前提としたスケジュールになりかねません。
さらに、フルスクラッチ開発をウォーターフォール型で進めると、途中の仕様変更がそのままスケジュールの大幅な遅延に直結しやすく、契約満了やEOS/EOLのデッドラインを超えるリスクが極めて高くなります。一方、パッケージ・SaaSへの移行は、Fit to Standardの方針のもとで数ヶ月〜半年程度での導入が可能で、この期間の差は決定的です。
ノンコア業務・ブラックボックス化した業務での回避推奨
フルスクラッチを避けるべき典型的なケースは2つあります。1つ目は、標準的な帳票出力やマスタ管理のような、自社の競争優位性に直結しないノンコア業務です。こうした業務は差別化につながらないため、SaaS・パッケージの標準機能に合わせるべきで、期限のある更改でフルスクラッチを選ぶ合理性がありません。
2つ目は、既存システムがブラックボックス化し、仕様書も残っていない場合です。この場合、フルスクラッチで作り直すには、現行システムの実績収集ロジックや品質判定ルールを一から解読する作業が必要になります。その解読だけで、期限内のスクラッチ開発が炎上することはほぼ確実です。
老朽化したMESほど、長年の改修で仕様書の不備やブラックボックス化が進んでいるケースが多くあります。そのため、更改の検討初期段階で現行システムのドキュメント整備状況を確認しておくことが、フルスクラッチの可否を判断する材料になります。
それでもフルスクラッチを選ぶべき例外条件
フルスクラッチは原則非推奨ですが、期限内であってもなお選ぶべき正当な理由があるケースも存在します。その例外条件は、次の2つに分けて見ていきます。
独自工程管理ロジック・品質判定基準などコア・コンピタンスに直結する場合
1つ目の例外条件は、熟練技術者の勘・経験を形式知化した独自の工程管理ロジックや、混流生産、特殊な品質判定基準といった、自社の競争優位性（コア・コンピタンス）に直結する業務プロセスです。それを既存のパッケージ・SaaSでは代替できない場合に、この例外条件に当たります。
たとえば、ロット単位・製番単位で厳密なトレーサビリティ管理が必要な工場に汎用的な実績収集パッケージを適用してしまうと、必要な粒度でデータを記録できません。その結果、現場がExcelでの二重記録に戻ってしまうという、典型的なミスマッチが起こります。
このような自社特有の生産方式・品質管理体系を持つ企業にとって、標準機能への妥協は競争力そのものの喪失につながりかねません。そのため、期限内の実現が難しくても、フルスクラッチを選ぶ合理性は残ります。ただし、その場合も、後述するスケジュール管理を徹底して期限超過のリスクを最小化する工夫が不可欠です。
複数既存システム・老朽化PLCとの複雑な連携がSaaS標準APIで満たせない場合
2つ目の例外条件は、老朽化した現場設備や複数の既存システムとの連携が極めて複雑で、SaaSの標準APIでは要件を満たせない場合です。たとえば、古いPLCや独自の通信規格を持つハンディターミナル・産業用PCが数多く接続された生産ラインでは、パッケージの標準的なAPI連携機能だけでは対応しきれません。その場合、独自の中継システムや変換ロジックを一から構築する必要が生じることもあります。
なお、この条件に当たる場合でも、MES本体には標準パッケージやSaaSを採用し、現場設備との連携部分だけをフルスクラッチで開発する「部分スクラッチ」という、ハイブリッドな選択肢を検討する余地は残ります。
MES全体をフルスクラッチにするか、連携部分だけをスクラッチにするかで、必要な期間は大きく変わります。そのため、更改対象を一括りにせず、コンポーネントごとに開発方式を切り分けて検討します。これにより、期限内に完了する見込みが高まります。
期限超過リスクを回避するスケジュール管理
例外条件に当たってフルスクラッチを選んだ場合でも、期限を守るためのスケジュール管理を組み合わせれば、超過のリスクをある程度抑えられます。ここでは、その具体的な手法を見ていきます。
段階移行・パイロット移行によるコア機能の最優先開発
一括移行（ビッグバン方式）は、フルスクラッチのような開発規模の大きいプロジェクトでは、開発の遅れが致命傷になりやすい方式です。そのため、期限のある更改案件では原則として避けるべきです。
代わりに、段階移行やパイロット移行で開発範囲を局所化し、EOS/EOLなどの期限で外せないコア機能を最優先で開発して、第一弾としてリリースします。残りの機能は、期限後に段階的に開発していくのが有効です。
並行稼働（並行移行）を組み合わせれば、新システムに致命的なエラーが出ても旧システム側で業務を続けられ、期限直前の切り替えでも一定の安全性を確保できます。MESでは、実績収集・工程進捗の可視化から優先着手し、高度な分析機能や複数ライン展開は後続フェーズに回します。この優先順位付けが、期限内にコア業務を確実に守るための現実的な戦略になります。
Must/Want要件の厳格な切り分けとロールバック計画の明文化
フルスクラッチ開発は要件が際限なく膨らみやすいため、期限のある更改案件では、要件を「Must（期限内に絶対に必要）」と「Want（あれば望ましいが期限後でもよい）」に厳格に切り分けます。そのうえで、タイムボックス管理を徹底することが欠かせません。
仕様変更の申し出があったら、口頭で済ませず変更要求として起票します。その際は、影響範囲の調査・工数見積もり・承認を経てから実施するというルールを徹底します。これにより、要望が際限なく積み上がってスケジュールが破綻する事態を防げます。
あわせて、開発が万が一期限に間に合わなかった場合に備え、速やかに旧システムでの操業へ戻す「ロールバック計画（コンティンジェンシープラン）」を事前に明文化しておきます。現場・情報システム部門・ベンダー間の緊急連絡体制も整えておく必要があります。フルスクラッチという最も重量級の選択肢を取るなら、この安全網は必須です。
ハードウェア（PLC・現場端末）入替と連動したリスク管理
フルスクラッチでソフトウェアを作り直す場合、PLCやハンディターミナルのリース期限も同時に来ているケースが多くあります。そのため、ソフトウェアとハードウェアの入替を連動させたリスク管理が求められます。
ソフトウェア開発とハードウェア入替のタイムライン同期
フルスクラッチで開発した新しいMESを、老朽化したPLCや現場端末にそのまま接続すると、新旧の技術世代のギャップから予期せぬ不具合が起こるおそれがあります。
ソフトウェアの開発スケジュールと、ハードウェアのリース更新・入替スケジュールがずれると、せっかく期限内にソフトウェア開発を終えても、接続先のハードウェアが未対応のまま稼働開始を迎えかねません。
フルスクラッチ開発の計画段階で、対象となるPLC・ハンディターミナルのリース満了日とEOS/EOL時期を洗い出します。そのうえで、ソフトウェアの開発マイルストーンとハードウェアの入替タイミングを1つのタイムラインに統合して管理します。これが、更改プロジェクト全体の整合性を保つために欠かせません。
新機器での連携テスト・配線工事という現場負担の織り込み
ハードウェアを入れ替える場合、新しい機器で実績データが正しく飛ぶかを確認する連携テストや、既存の生産設備・センサーとの複雑な配線工事が必要になります。
フルスクラッチで開発した独自のソフトウェアであれば、なおのこと、標準パッケージ以上に念入りな連携テストが求められます。その分の期間と現場の稼働調整、一時的なライン停止という負担も、スケジュールに織り込んでおく必要があります。
連携テストは、PoC・プロトタイプの段階で目処をつけておくべき領域です。本番稼働直前になって初めて実機テストを行うと、期限内の修正対応が間に合わなくなるリスクが高まります。ソフトウェアとハードウェアの両方を入れ替える更改では、開発計画の初期段階で連携テストの時期をマイルストーンとして明確にしておくことが、期限とリスクを管理する鍵になります。
フルスクラッチを選んだ場合の投資規模と予算承認の注意点
期限内にフルスクラッチで更改するには、開発スケジュールの管理に加えて、投資規模に見合った予算を期限に間に合う形で確保する必要があります。資金計画も避けて通れない論点です。
パッケージ型との投資規模の差と稟議に要する時間
フルスクラッチ開発は、小規模でも300万〜1,500万円程度、中規模で1,500万〜5,000万円程度に達し、大規模になると5,000万〜数億円以上になります。パッケージ型・SaaS型と比べると、TCOは数倍から数十倍に膨れ上がるのが実勢です。
投資規模が大きいぶん、経営層の稟議承認には相応の時間がかかります。そのため、開発スケジュールの逆算に加えて、稟議承認のスケジュールも、判断リミットである契約満了・EOS/EOLの1年〜1年半前からさらに数ヶ月前倒しして設計する必要があります。
期限が迫ってからフルスクラッチの巨額投資を稟議にかけても、経営層が十分な検討時間を確保できません。その結果、承認そのものが期限に間に合わない事態にもなりかねません。
補助金の対象外リスクと資金計画上の注意
資金計画上、見落とされがちなのが補助金の適用範囲です。IT導入補助金のような制度は、多くの場合あらかじめ登録された特定のIT製品・サービスが対象です。そのため、自社の独自要件に合わせて一から構築するフルスクラッチ開発は、対象外となるケースがあります。
フルスクラッチを選ぶ場合は、IT導入補助金を前提とせず、ものづくり補助金など製造業の設備投資・システム投資を対象とした別の補助金制度を検討する必要があります。これらの補助金にも申請から採択までの審査期間があるため、期限管理には補助金の申請スケジュールも織り込んでおくべきです。
全社的な本格投資に進む前に、実データを使った特定のパイロットラインや特定工程でPoC・プロトタイプ検証を行い、現場オペレーションとの適合性を見極めます。この「スモールスタート」の発想が、期限と予算の両方の制約が重なる更改案件で、フルスクラッチのリスクを現実的な水準に抑える鍵になります。
まとめ
ここまで、期限のある更改でフルスクラッチが原則非推奨となる理由から、例外条件、スケジュールとハードウェア入替のリスク管理、投資規模と予算承認の注意点までを見てきました。
モダナイゼーションの技術的アプローチ選定や、刷新の独自性への投資判断とは異なり、更改におけるフルスクラッチの検討は、契約満了・EOS/EOLという期限内に本当に間に合うのかという実現可能性の問いから始まります。
代替できない独自の工程管理ロジックや品質判定基準、複雑な現場設備連携という例外条件に当たる場合に限り、フルスクラッチは現実的な選択肢になります。その際は、段階移行やパイロット移行、Must/Want要件の切り分けといったスケジュール管理と、ソフトウェアとハードウェアの入替を統合したタイムライン管理を徹底します。さらに、前倒しした稟議承認と補助金申請のスケジュールも欠かせません。
それ以外のケースでは、Fit to Standardによるパッケージ・SaaSへの移行を優先するのが、期限を守るうえで最も確実です。
▼全体ガイドの記事
・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を創業。