MESは内製かパッケージか──判断を分ける4条件

「工程が特殊だから内製」という理由は、ほぼ成立しない

内製を選ぶ理由として最も多く挙がるのが「工程の特殊性」です。しかし要件定義の場で特殊性の中身を分解していくと、その大半は次の3つに収まります。

• 例外処理が多い：手直し、飛び番、途中投入、判定保留といった正常系から外れた流れ
• 他部門との受け渡しが独特：紙の受け渡し表や口頭連絡で運用してきた工程間の引き継ぎ
• 帳票の書式が決まっている：顧客支給フォーマットや社内の伝統的な帳票

このうち3つ目はパッケージでも帳票定義で吸収できます。1つ目と2つ目は本質的に難しい要件ですが、内製したところで難しさは消えません。むしろ「何でも作れる」状態で例外処理を書き始めると、例外の数だけ分岐が増え、5年後には誰も全体を説明できないシステムが残ります。これは実際に起きます。

判断を分けるのは工程の特殊さではなく、変更頻度・保守要員・統制要求・展開範囲という運用側の4条件です。

4条件で判定する

4条件のうち、実務で最も軽視されるのが条件1です。着手時点では情報システム部門に人がいるため成立して見えますが、内製MESは「作った人がいなくなった瞬間」に保守不能になります。仕様書ではなくコードが仕様になっているためです。異動と退職を織り込んで10年の要員計画を書いてみると、多くの企業でここが崩れます。

条件3も見落とされがちです。医薬・医療機器・食品といった規制産業に限らず、自動車部品でも顧客監査で作業記録の改ざん防止を問われます。監査証跡と権限管理は「作れば動く」機能ではなく、「壊れていないことを証明できる」必要がある機能です。内製で同等の説明責任を果たすのは、機能開発そのものより高くつきます。

費用は初期ではなく10年で並べる

内製が安く見えるのは、比較の期間が短いからです。同じ範囲を10年運用したときの費用項目を並べると、構造が反転します。

年間保守料が重いのは事実ですが、その対価としてOSやデータベースの更改追随、セキュリティパッチ、法規制対応が含まれます。フルスクラッチ内製では、この3つが毎年そのまま自社の作業として残ります。10年のあいだにWindowsもデータベースも確実に世代交代しますから、「作って終わり」にはなりません。

現実解は「コアは買い、周辺は作る」

2026年時点で増えているのは、内製かパッケージかの二択ではなく、境界を引いて組み合わせる構成です。境界の引き方には原則があります。

• 記録・統制・トレーサビリティはパッケージ側に置く：あとから「そのデータは正しいのか」を問われる領域。実績の裏づけと監査対応が買える
• 現場UIと現場固有の補助機能は内製側に置く：変更頻度が高く、変更が現場の納得感に直結する領域。ローコード／ノーコードMESの適所はここ
• 境界はデータではなくAPIで引く：パッケージのデータベースを内製アプリが直接読み書きし始めた時点で、この構成は崩壊します。バージョンアップのたびに全数検証が必要になり、両方の悪いところが残ります

この構成をとる場合、契約時に確認すべきなのはAPIの公開範囲と、そのAPIがバージョンアップで維持されるかどうかです。ベンダーロックインの回避は機能比較ではなく、この一点で決まります。

よくある質問

既存の自社開発システムがあります。作り直すべきですか？

まず条件1（要員の10年維持）を判定してください。現行システムを書いた担当者が在籍していて、かつ後任が育っているなら、刷新より機能追加のほうが合理的な場合があります。逆に「触れる人が1人しかいない」状態なら、それは技術的な問題ではなく組織的なリスクなので、パッケージへの移行を検討する段階です。判断材料は老朽化したMESを延命するか、刷新するかで整理しています。

ローコードで内製すれば、要員は1人でも回りますか？

開発は1人でも回りますが、運用は回りません。24時間稼働の工場でMESが止まった場合、復旧できる人間が常に1人しかいない状態は事業継続上の欠陥です。ローコードを選ぶ場合でも、最低2名体制と、基盤ベンダーのサポート契約はセットで考えてください。

パッケージを選んだ場合、社内に技術者は不要ですか？

必要です。ただし役割が変わります。開発する人ではなく、業務要件をシステムの用語に翻訳し、ベンダーの見積の妥当性を判断できる人が要ります。この役割を外部に丸投げすると、追加開発の単価が検証できなくなり、結果的に内製より高くつきます。運用を内製化したい企業のMES選びも参考にしてください。