MES（製造実行システム）の導入を発注する側に立つとき、プロジェクトの成否をもっとも左右するのが、要件定義とRFP（提案依頼書）の作り込みです。MESはISA-95でいう実行層を担い、現場の作業の流れと密着するため、要件が曖昧なままベンダーに丸投げすると、生産形態に合わないシステムが出来上がり、カスタマイズ費が膨張します。逆に、要件とRFPを的確に整理できれば、各ベンダーから比較可能な提案を引き出し、費用と期間の見通しも立てやすくなります。だからこそ、何をどこまで決めてから引き合いに出すかが、発注側の腕の見せどころになります。
本記事は、MESのRFP・要件定義書・提案依頼書の作り方を、発注する製造業の視点から整理する「要件定義特化」の解説です。ISA-95を前提とした役割分担の明文化、受注生産・見込み生産・個別生産といった生産形態別の要件、Excel連携やデータ移行の要件、そしてIT導入補助金などの申請要件まで、一次データとあわせて具体的に解説します。読み終えるころには、自社が「RFPに何を書き、どこを決め切ってから発注すべきか」のイメージが描けるはずです。なお、MES導入の全体像をまだ把握していない方は、まずMESの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・MESの完全ガイド
ISA-95を前提にした役割分担の要件定義
MESの要件定義で最初に決めるべきは、ERPや既存の生産管理システムとの役割分担です。ISA-95の階層モデルでは、ERPが計画層、MESが実行層と位置づけられます。この境界を曖昧にしたままRFPを出すと、ベンダーごとに想定するスコープがバラバラになり、見積もりを横並びで比較できません。「どこまでがMESの責任範囲か」を要件定義書の冒頭で明文化することが、すべての出発点になります。
計画層と実行層のスコープを明文化する
役割分担を明文化するには、業務機能を一覧化し、それぞれを「ERPで担う」「MESで担う」「両者で連携する」に振り分けます。受注・在庫・原価・購買といった計画と経営の機能はERP側、作業指示・実績収集・トレーサビリティ・設備稼働といった現場の実行はMES側、という大枠を示したうえで、自社の事情に応じて境界を調整します。日本固有の生産管理システムは計画機能を多く含むため、ERPとの重複をどう整理するかも要件で詰めておきます。
この役割分担表をRFPに添付すると、ベンダーは自社製品がどの範囲をカバーし、どこを連携・カスタマイズで補うかを明示しやすくなります。結果として、提案の比較軸が揃い、見積もりの妥当性を判断できます。逆に役割分担を示さずに「MESを入れたい」とだけ伝えると、ベンダーは安全側に振った広いスコープで見積もるため、費用が高めに出がちです。スコープの明文化は、価格交渉の前提条件そのものだと考えてください。
役割分担の整理では、既存システムとの重複も棚卸しします。すでに生産管理システムや在庫管理システムを使っている工場では、それらの機能とMESが重なる部分が出てきます。重複機能をどちらに寄せるか、既存システムを残すのか置き換えるのかを要件で決めておかないと、二重投資や機能の衝突を招きます。現状のシステム構成図を描き、MES導入後の姿と並べて示すことで、ベンダーは無駄のない提案を組み立てられます。既存資産の棚卸しは、要件定義の地味だが欠かせない作業です。
連携インターフェースの非機能要件
役割分担と並んで重要なのが、ERPとMESをつなぐインターフェースの要件です。計画をどの頻度でMESに渡すか、実績をどのタイミングでERPに返すか、障害時にどうリカバリするかといった非機能要件を、RFPに具体的に書き込みます。リアルタイム連携が必要なのか、日次バッチで十分なのかによって、構築の難易度と費用が大きく変わるためです。ここを曖昧にすると、リリース後に「思っていた即時性が出ない」というトラブルになります。
インターフェースは疎結合に設計するよう要件で求めておくと、将来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は現場が常時使うため、わずかな待ち時間でも作業の妨げになり、入力が形骸化する原因になります。可用性についても、停止が許される時間や、設備からのデータ収集が止まったときのリカバリ方法を要件にします。
保守体制も非機能要件の重要な柱です。障害時の連絡先と対応時間、定期バージョンアップの頻度と費用、サポートの範囲を明記してもらいます。とくにクラウド型では、数年後の大型バージョンアップで追加費用が発生する事例があるため、保守費とバージョンアップ費を5年・10年のTCO（総保有コスト）に織り込んで見積もるよう求めます。運用フェーズの費用を要件段階で見える化しておくことが、導入後の予算ショックを防ぎます。
提案を横並びで採点する評価項目
ベンダー選定の精度を上げるには、評価項目と配点をRFPの段階で決めておくことです。機能の適合度、生産形態への理解、費用とTCO、導入実績、保守体制、PoCの結果といった軸に重みを付け、各社を同じ物差しで採点します。配点を事前に決めておくと、提案の見栄えや営業の熱意に流されず、客観的に比較できます。とくに「自社の生産形態をどれだけ理解しているか」は、機能の多さよりも重視すべき軸です。
評価では、価格の安さだけで決めない規律も大切です。初期費用が安くても、カスタマイズ費が初期費用の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、現場定着までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。