MESの導入で成否をもっとも左右するのは、要件定義とRFP（提案依頼書）を発注前にどこまで決め切るかです。要件が曖昧なまま丸投げすると、生産形態に合わないシステムになり、カスタマイズ費も膨らみます。
役割分担から補助金の申請要件まで解説します。全体像は、まずMESの完全ガイドで確認してください。
▼全体ガイドの記事
・MESの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ISA-95を前提にした役割分担の要件定義
MESの要件定義で最初に決めるべきは、ERPや既存の生産管理システムとの役割分担です。ISA-95の階層モデルでは、ERPが計画層、MESが実行層に位置づけられます。
この境界を曖昧にしたままRFPを出すと、ベンダーごとに想定するスコープがばらばらになり、見積もりを横並びで比べられません。そのため、「どこまでがMESの責任範囲か」を要件定義書の冒頭で明文化することが、すべての出発点になります。
計画層と実行層のスコープの明文化
役割分担を示さずに「MESを入れたい」とだけ伝えると、ベンダーは安全側に振った広いスコープで見積もるため、費用が高めに出がちです。
そこで、業務機能を一覧にし、それぞれを「ERPで担う」「MESで担う」「両者で連携する」のどれかに振り分けます。ISA-95の大枠を示したうえで、自社の事情に応じて境界を調整します。どちらに寄せるかは、機能が計画と経営に関わるか、現場の実行に関わるかで判断します。
- ERP側：受注、在庫、原価、購買といった計画と経営の機能
- MES側：作業指示、実績収集、トレーサビリティ、設備稼働といった現場の実行
すでに生産管理システムや在庫管理システムを使っている工場では、それらの機能とMESが重なる部分が出てきます。日本固有の生産管理システムは計画機能を多く含むため、ERPとの重複をどう整理するかも要件で詰めておきます。重複する機能の扱いは、どちらに寄せるか、既存システムを残すか置き換えるかを含めて決めておかないと、二重投資や機能の衝突を招きます。
この振り分けをRFPに添付すると、ベンダーは自社製品がどの範囲をカバーし、どこを連携やカスタマイズで補うかを示しやすくなります。その結果、提案の比べる観点がそろい、見積もりの妥当性を判断できます。スコープの明文化は、価格交渉の前提条件そのものです。
現状のシステム構成図を描き、MES導入後の姿と並べて示すと、ベンダーは無駄のない提案を組み立てられます。既存の資産を洗い出す作業は地味ですが、要件定義では欠かせません。
連携インターフェースの非機能要件
役割分担と並んで押さえたいのが、ERPとMESをつなぐインターフェースの要件です。連携の条件を具体的に書くのは、リアルタイム連携が必要か日次バッチで十分かによって、構築の難易度と費用が変わるためです。RFPには、次のとおり書き込みます。
- 連携の頻度とタイミング：計画をMESに渡す頻度、実績をERPに返すタイミング
- 障害時のリカバリ：停止したときに、どう元に戻すか
ここを曖昧にすると、リリース後に「思っていた即時性が出ない」というトラブルになります。また、インターフェースは疎結合に設計するよう要件で求めておくと、将来ERPやMESのどちらかを入れ替えても影響を局所化できます。
具体的には、連携を専用のミドルウェアやAPI経由にし、双方が相手の内部構造に依存しない形を指定します。データ項目の対応表（マッピング）の作成を誰の責任にするかも、RFPで明記しておくべき項目です。連携のどこまでを誰が受け持つかを決めないまま進めると、後で追加費用や責任のなすり合いが生じることがあります。
連携要件では、設備やPLCといった現場機器との接続も欠かせません。MESは実行層として、設備から稼働信号や生産数を自動で集めてこそ価値を発揮します。接続の要件を詰めておかないと、リリース後に「肝心の設備データが取れない」という事態になりかねません。
そのため、自社の設備が対応する通信規格やプロトコルを調べ、どの設備からどのデータを取るかを要件に書き込みます。古い設備で信号が取れないときは、後付けのセンサーや手入力で補う方針も、あわせて決めておきます。
生産形態別の要件と現場フローの落とし込み
MESの要件定義で最大の落とし穴は、自社の生産形態を要件に正しく反映できないことです。受注生産、見込み生産（量産）、個別生産では、現場の作業の流れも、管理すべき情報もまったく異なります。
生産形態を抽象的に伝えるだけでは、ベンダーは自社の標準モデルを当てはめて提案してしまいます。その結果、リリース後に「自社の段取り替えが表現できない」といったミスマッチが起きます。そのため、生産形態を要件の中心に据えることが、そうした食い違いを防ぐ第一歩になります。
受注・見込み・個別生産で変わる要件
受注生産では、注文ごとに仕様や工程が変わるため、品目マスタの柔軟性や、図面・仕様書とのひも付けが要件の核になります。Prevision（インプローブ）のように受注生産に特化した製品があるのは、この前提が量産向けと異なるためです。見込み生産と個別生産では、要件の中心が次のように変わります。
- 見込み生産：繰り返し量産の効率と在庫の適正さ、標準作業の徹底とOEE管理
- 個別生産：一品一様の進捗管理と、長い製造リードタイムの途中経過の把握
RFPには、自社の代表的な品目について「受注から出荷までの工程フロー」を具体的に記載します。どの工程で誰が何を入力し、どこで検査し、どんな帳票を出すかを書き下すと、ベンダーは自社の流れに製品が合うかを判断できます。この現場フローの記述の有無で、提案の精度はまったく変わります。
要件定義の前に現場ヒアリングを行い、現状（AsIs）の工程フローを整理したうえで、あるべき姿（ToBe）を描いてからRFPに落とし込むのが王道です。
PoC（実機検証）の要件への組み込み
生産形態のミスマッチを最終的に確かめる手段が、契約前のPoC（実機検証）です。RFPに「採用前に自社の生データを使った実機検証を行う」旨を要件として盛り込み、合格基準も明示しておきます。合格の判断は、受注と実データの二つの面から問いを立て、合否のチェックリストにして行います。
- 受注パターン：典型的な受注が、設定だけで最後まで流れるか
- 実データでの動き：自社の実データ量で表示速度が落ちないか、マニュアルなしで現場が触れるか
PoCを要件に組み込んでおくと、提案ベースの理想論と実際の動作のギャップを、契約前に潰せます。生産管理システム全般では、カスタマイズ費が初期費用の3〜4割を占めます。
それを踏まえれば、PoCで「標準では無理な箇所」を早期に特定し、そこに開発予算を集中させる進め方が、費用膨張を防ぐ最も確実な方法です。RFPでPoCの実施と判定基準を明記しておけば、発注側が主導権を保ったまま進められます。
Excel連携・データ移行・補助金の要件
現場の定着を左右するにもかかわらず、RFPで見落とされがちなのが、既存Excelとの連携とデータ移行の要件です。多くの工場には、設計部門の部品表や生産計画のマクロ、検査帳票など、長年かけて作り込んだExcel資産があります。
これらを無視して「Excel完全脱却」を掲げると現場が反発します。そのため、どのExcelを残し、どこを連携・移行するかを要件で具体的に決めておく必要があります。
Excel連携とデータ移行の要件の明記
Excel連携の要件では、「設計部門のExcel部品表を直接取り込めること」「帳票をCSV変換なしでExcelダイレクト出力できること」を具体的に求めます。CSV経由の出力は文字化けや列ズレを招き、かえって手直しの時間が増えます。そのため、ダイレクト出力の可否は現場の負担を左右します。
また、既存のVLOOKUPやマクロをどこまで活かせるかも、要件に書き込んでおくと現場の納得感が高まります。データ移行では、品目や工程などのマスタをどこまで移すか、いつ時点のデータを正とするかを要件で定義します。
この移行では、どこを内製化するかの判断が効いてきます。導入費を抑える方法の一つが、社内で担う作業を見積もりから外すことです。作業ごとの金額は、社内で担った場合に見積もりから外れる分の目安です。
- マスタ登録：社内で実施する場合の30〜80万円相当
- テスト運用：社内で回す場合の30〜80万円相当
RFPでは「マスタ登録は自社で実施する」など分担を明記し、ベンダーには移行ツールの提供や手順の支援に絞ってもらう、といった切り分けが有効です。
IT導入補助金など申請を見据えた要件
MES導入では、IT導入補助金などの活用も視野に入ります。補助率は1/2〜2/3が目安ですが、対象や上限は年度ごとに変動するため、最新の公募要領を必ず確認する必要があります。
RFPの段階で「補助金申請に必要な書類作成にベンダーが協力できるか」を要件に含めておくと、申請がスムーズになります。補助金は導入の動機づけになります。ただし、年度で条件が変わるため概要として捉え、申請前提でスケジュールを組みすぎないことが安全です。
申請に備えるには、見積もりの内訳と比べ方を、あらかじめ決まった形にそろえておきます。
- 費用の内訳：ライセンス、導入支援、カスタマイズなど、費目ごとに分ける
- 比較の形：5年・10年のTCO（総保有コスト）で比べられるようにし、補助対象かどうかの判断にも使う
こうした整理は、補助金の有無にかかわらず、申請にも稟議にも役立ちます。riplaはフルスクラッチ受託と製造現場への伴走の立場から、生産形態に即した要件整理と、補助金や内製化を踏まえた費用設計を支援しています。要件定義を丁寧に進めるほど、後工程の手戻りと費用膨張を防げます。
非機能要件とベンダー比較の評価項目
機能要件をどれだけ丁寧に書いても、非機能要件と評価項目が曖昧だと、提案を正しく比べられません。RFPには、性能や保守体制などの非機能要件と、ベンダーを横並びで採点する評価項目を、あわせて盛り込みます。これを整えておくと、価格だけに引きずられず、自社に合うベンダーを総合点で選べます。
性能・可用性・保守の非機能要件
非機能要件では、まず性能を具体的に定めます。ピーク時に何台の端末から実績を入力するか、画面の応答は何秒以内か、自社の実データ量で速度が落ちないかといった条件を、数値で示します。
MESは現場が常時使うため、わずかな待ち時間でも作業の妨げになり、入力が形骸化する原因になります。可用性についても、停止が許される時間や、設備からのデータ収集が止まったときのリカバリ方法を要件にします。
保守体制も非機能要件の大切な一部です。RFPには、障害時やバージョンアップの取り決めを明記してもらいます。
- 障害時の対応：連絡先と対応時間
- バージョンアップ：定期的な頻度と費用、サポートの範囲
こうした項目を求めるのは、とくにクラウド型では、数年後の大型バージョンアップで追加費用が発生する事例があるためです。また、保守費とバージョンアップ費を5年・10年のTCO（総保有コスト）に織り込んで見積もるよう求めます。運用フェーズの費用を要件段階で把握しておくと、導入後に予算が想定外に膨らむのを防げます。
提案を横並びで採点する評価項目
ベンダー選定の精度を上げるには、評価項目と配点をRFPの段階で決めておくことです。機能の適合度や費用とTCOなどに重みを付け、各社を同じ基準で採点します。配点を決めておくと、提案の見栄えや営業の熱意に流されず、客観的に比べられます。
評価では、価格の安さだけで決めない規律も大切です。初期費用が安くても、カスタマイズ費が初期費用の3〜4割に膨らんだり、運用フェーズで保守費がかさんだりすれば、総額では割高になります。総額を見るには、提案の中身と外部に頼る費用の二つを確かめます。
- 理解の深さ：機能の多さより、自社の生産形態をどれだけ理解しているか
- コンサル委託費：1人月100〜200万円を、内製化でどこまで圧縮できるか（提案内容によって変わる）
riplaはフルスクラッチ受託と製造現場への伴走の立場から、非機能要件の整理と、TCOを踏まえた公平な評価の観点づくりを支援しています。評価項目を事前に固めることが、後悔のないベンダー選定につながります。
要件定義書の体系と記載粒度の統一
RFPと要件定義書は、書く内容だけでなく、体系と粒度も成果を左右します。章立ては、業務要件、機能要件、非機能要件をそろえておきます。さらに、データ移行要件、運用・保守要件、制約条件も、同じ区分に入れます。粒度がばらばらだと、ある機能は細かく、別の機能はざっくりとなり、提案の精度も揃いません。
各要件に優先度（必須・推奨・任意）を付けておくと、ベンダーは「どこは絶対に外せず、どこは代替案で良いか」を判断しやすくなります。優先度ごとに、見積もりの範囲をどこまで含めるかを分けて考えます。
- 必須：まず、この範囲だけで見積もりを取る
- 推奨・任意：オプション扱いにし、予算に応じて段階的に導入範囲を調整する
これは、全機能を一斉に導入してカスタマイズ費が膨らむのを避けるための、実務的な手立てでもあります。優先度を示しておけば、費用の抑え込みにも役立ちます。要件を「必須から」積み上げる書き方にしておくと、スモールスタートの計画とも自然につながります。記載の体系と粒度をそろえることは、地味ですが、提案を比べるうえで欠かせない作業です。
最後に、要件定義書は一度書いて終わりではなく、PoCの結果やベンダーとの対話を通じて更新していく前提で扱うことが大切です。実機検証で「標準では無理」と分かった箇所は要件に反映し、逆に「運用で吸収できる」と分かった要件は外します。この往復を経て、要件定義書は実態に即した精度の高いものへと育ちます。
riplaは、この要件の磨き込みから現場定着まで一貫して伴走します。あわせて、要件定義の段階で社内の合意形成を進めておきます。MESは生産管理だけでなく、製造現場や品質保証など、多くの部門にまたがります。
各部門の要望を要件に取り込み、優先度を擦り合わせておかないと、リリース後に「この部門の要件が抜けている」という手戻りが発生します。要件定義書を各部門でレビューし、必須要件への合意を取り付けておくことが、プロジェクト全体の進行を支えます。RFPを出す前のこの社内調整が、外部ベンダーとのやり取り以上に成否を左右することも少なくありません。
まとめ
MESの要件定義とRFPを振り返ると、成否を分けるのは、「ISA-95に基づく役割分担の明文化」「生産形態を中心に据えた現場フローの落とし込み」「Excel連携・データ移行・補助金の具体化」の三つです。
スコープを明文化すれば、提案を横並びで比べられます。生産形態別の要件とPoCの組み込みがミスマッチを防ぎ、Excelダイレクト出力や内製化の分担は、現場定着と費用圧縮につながります。カスタマイズ費が初期費用の3〜4割を占める現実を踏まえれば、要件をどこまで決め切るかが投資の結果を左右します。
RFPを書くときに大切なのは、「製品を選ぶ前に、自社の業務を言語化する」という順序です。現場ヒアリングで現状（AsIs）の流れを整理し、あるべき姿（ToBe）を描いたうえで、役割分担と生産形態を要件に落とし込んでから引き合いに出してください。
riplaはフルスクラッチ受託と国内開発を組み合わせ、要件整理からPoC、現場定着までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。