生産管理システムのRFPと要件定義書は、守備範囲を決め、生産形態に合わせて要件を書くことから始まります。移行と非機能要件、評価基準まで整えると、提案の比較精度が高まります。
ERP・MESとの役割分担から評価基準までを順に説明します。全体像は、生産管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・生産管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ERP・MESとの役割分担の要件定義
要件定義では、まず生産管理システムと既存システムの担当範囲を決めます。範囲が曖昧なままだと、機能が重複したり、必要な機能が抜けたりします。そこで、RFPの冒頭で守備範囲を明確に示しておくと、ベンダーごとの提案がぶれにくくなります。
ISA-95を前提とした守備範囲の切り分け
守備範囲を整理するときは、ISA-95という国際的な階層モデルを使えます。このモデルでは、ERPが計画層、MESが実行層を担うと位置づけられます。要件定義書では、この前提のうえで次の観点から範囲を書き分けます。
- 既存ERPの担当：会計や人事など、既存ERPに残す業務
- 対象外の機能：設備からの実績の自動収集など、今回の範囲から外す機能
- 責任分界点：業務ごとに、どのシステムが担当するかの境界
日本の生産管理システムは、計画から実行までを広く扱います。そのため、ERPやMESと機能が重なる領域が生じやすくなります。対象業務と責任分界点を表にして要件定義書に示すと、各社の提案を同じ条件で比べられます。
範囲が曖昧なまま複数社に依頼すると、会計まで含む提案と工程管理だけの提案が並び、見積を比べられなくなります。さらに、範囲を明確にしておけば、あとからカスタマイズ費が膨らむことも防げます。
既存システムとのデータ連携要件
担当範囲が決まったら、次はシステム間のデータ連携を定義します。連携するデータごとに、方向とタイミング、項目を具体的に書きます。
連携要件を決めるときは、既存システム側の制約も確かめておきます。連携要件の精度は、そのまま見積の精度に直結します。
- 連携する情報：受注データや在庫情報など、連携の対象
- 連携方式：業務ごとに、リアルタイムか夜間バッチかを選ぶ
- マスタの所有者：品目マスタなどを管理するシステムの指定
古い基幹システムにはAPIがなく、CSVやファイルでの連携が必要になる場合があります。その場合は、文字コードやファイル形式も要件に含めます。
品目や取引先を複数のシステムで更新すると、どれが最新か分からなくなり、データの不整合が生じます。そのため、「品目マスタの正は基幹システム、生産管理側は参照のみ」のように、データごとに所有権を決めておきます。所有権を決めないまま連携だけを作ると、稼働後は同じ情報を二か所で直す手間が現場の負担になります。
連携のタイミングは、業務の実態に合う粒度で決めます。たとえば、受注情報は即時に連携し、原価の確定データは月次締めで十分な場合があります。データの性質に合わせて頻度を定め、夜間バッチで足りる箇所はそのように指定すると、すべてをリアルタイムにするより費用を抑えられます。
連携相手の仕様が曖昧なままだと、ベンダーが見積もりを高めに置いたり、後から追加費用が発生したりします。連携項目と頻度を一覧にすると、提案の構成や見積が妥当かを確かめやすくなります。
生産形態別の要件の書き分け
生産形態によって、計画、在庫、原価の考え方が異なります。このため、形態を一律に扱うと、現場に合わないシステムになるおそれがあります。
生産管理システムの要件定義では、自社の生産形態に応じて書き分けることが特に重要です。形態とシステムがかみ合わないと、導入後の失敗につながりやすくなります。
形態を一つに決めつけず、複数の形態を組み合わせる製造業もあります。たとえば、主力製品は見込生産、特注品は個別受注生産という場合は、製品群ごとにどの形態が何割かをRFPに書いて伝えます。比率が分かれば、ベンダーは主な形態に合わせながら、例外の扱いも提案できます。
見込生産と受注生産で異なる計画要件
見込生産は需要を予測して、在庫を持ちながら生産します。一方、受注生産は注文を受けてから生産するため、在庫を持たない代わりに納期を守る必要があります。
- 見込生産：需要予測、適正在庫、補充ロジックに関わる要件
- 受注生産：受注ごとの所要量計算と、納期から逆算した工程の割り付け
見込生産では、販売実績や季節変動をもとにした計画と、安全在庫の自動計算が求められます。欠品と過剰在庫のバランスを取ることも、要件の中心になります。また、過去データを分析する機能も、生産計画や需要予測に役立ちます。
受注生産では、内示や仕様変更に柔軟に対応できることも必要です。形態が曖昧なままだと、汎用的で使いにくいシステムになりがちです。
同じ生産管理システムでも、見込生産向けと受注生産向けでは重視する機能が異なります。そのため、RFPには自社の形態を明記し、「この形態に最適化された提案を求める」と書きます。
個別受注生産に固有の原価・進捗要件
個別受注生産は、案件ごとに仕様が異なる一品一様のものづくりです。製品ごとに部品表が異なり、都度設計も発生するため、要件の難易度が高い形態です。
- 案件別原価：案件単位で集計する実績原価
- 進捗とコスト：案件ごとの工程進捗とコスト
- 設計変更：変更による原価への影響
個別受注生産では標準原価が使いにくいため、案件ごとの実績原価を正確に積み上げる必要があります。そこで、案件番号や工事番号をキーにして集計できるよう、要件に具体的に書いておきます。
案件ごとに工程が変わるため、量産品とは違い、工程の進捗とコストを案件単位でリアルタイムに追う仕組みが求められます。汎用パッケージでは対応しきれず、フルスクラッチ開発が選択肢に上がることもあります。
設計と製造の境界も決めておく必要があります。図面が完成する前に手配や工程に着手する「先行手配」が当たり前になっている場合は、未確定の部品表でどこまで進めてよいかを定義します。
「すべて確定してから着手する」だけの要件では、実務と合わなくなり、使われなくなるおそれがあります。例外的な進め方も RFPに書き、その進め方を前提にした提案を求めます。自社の生産形態を見極め、それに合った要件を書くことが、ミスマッチを防ぐことにつながります。
データ移行・補助金まで含めた要件整理
機能要件に加えて、移行と補助金の要件もあらかじめ整理しておきます。RFPに含めておくと、手戻りや想定外の費用を防ぎやすくなります。
移行や補助金は、RFPの本題から外れて見えるかもしれません。しかし、プロジェクトの成否とコストを左右する重要な項目です。
マスタ移行とExcel連携の要件
移行では、何を、どこから、どの形式で移すかを決めます。対象になるのは、品目・取引先マスタ、部品表、過去の在庫・受注データなどです。移行の要件では、Excel部品表の取り込みから稼働後の連携、データ品質、取り込みの検証まで、項目ごとに具体的に書いておきます。
- Excel部品表：設計部門が管理する部品表の取り込み方法
- 稼働後の連携：稼働後もExcelを使い続ける前提の要件
- データ品質：クレンジングの担当者と期限
- 取り込み検証：リハーサルの回数と受け入れ基準
設計部門がExcelで管理する部品表は、現場の作業に直結します。列構成や記載ルールがそろっていないと移行の工数が想定以上に増えるため、まず現状を洗い出します。
現場のExcel運用をすべてなくすのは、現実的でない場合があります。そのため、「帳票をCSV変換なしでExcel出力する」「既存マクロを活かす」といった形で、具体的に要件を定めます。
Excelの連携要件を要件定義の段階で書いておけば、ベンダーはExcel利用を前提に提案できます。地味な項目ですが、現場への定着を左右します。
移行前の部品表に表記のゆれや未使用の品目が残っていると、その不備も新システムへ移ります。クレンジングには発注側でしかできない作業が多いため、ベンダーに任せきりにはできません。
移行データの品質をどこまで保証するかも、要件に明記しておきます。CSVの文字コードや区切り位置が原因で、文字化けや列ずれが起きることもあります。そこで、移行リハーサルでは件数や金額の合計を照合し、移行前後の一致を確かめる手順を定めます。
補助金申請を見据えた要件と見積の整理
生産管理システムは、IT導入補助金などの対象になることがあります。補助率はおおむね1/2〜2/3が目安で、中小製造業にとって投資の負担を軽くする手段です。申請に向けては、導入の効果と見積の区分、申請の時期を、要件定義の段階から整理しておきます。
- 改善効果：導入前後の工数や在庫水準
- 見積の内訳：機能単位で分けた、補助対象と対象外の区分
- 申請時期：公募締切と、交付決定前の発注制約
補助金の要件や枠は年度ごとに変わるため、最新の公募要領を確かめる必要があります。申請では、導入による改善の見込みを計画として示すことが多く、ROIの定量化が役立ちます。そのため、導入前後の効果を数値で示せるよう、現状の工数や在庫水準を記録しておきます。こうした情報が、申請書類の説得力につながります。
要件定義書は、開発の基準となるほか、補助金申請や稟議の根拠資料にもなります。また、見積を機能別に整理しておくと、コストを押し上げる要件や優先度の低い要望を見つけられます。
投資の判断と要件の整理は、一体として捉えます。要件定義支援を外部コンサルタントに頼む場合、費用はおおむね1人月あたり100万〜200万が相場です。また、カスタマイズの初期費用が800万〜1,500万のケースでは、3〜4割が個社固有の作り込みに充てられることもあります。
補助金の時期の制約は、要件定義の進め方と結び付いています。要件定義に時間をかけすぎると公募期間を逃す一方、締切に追われて要件を詰めずに発注すると手戻りが生じます。
こうした制約を踏まえ、申請日程と開発日程を合わせる視点も必要です。補助金を手段として位置づけ、要件の精度と開発日程のバランスを取ります。
非機能要件とPoC・評価基準の盛り込み方
機能や移行の要件を固めたあとで、RFPの完成度を左右する非機能要件と提案の評価方法を盛り込みます。ここが抜けると、機能は満たしていても使いにくいシステムになったり、提案の優劣を判断しにくくなったりします。どちらも、発注側が主導権を保つための要件です。
性能・セキュリティ・運用保守の非機能要件
非機能要件は、機能そのものではなく、システムの品質に関する要件です。検証できる形で定める必要があり、中心になるのは、処理速度、情報の守り方、稼働後の保守です。
- 性能：自社のデータ量や同時利用人数に応じた処理速度
- セキュリティ：機密情報の保護方法とアクセス権限
- 運用保守：障害時の復旧体制とサポート時間
「快適に動くこと」のような曖昧な表現では、検証も評価もできません。ベンダーごとに解釈が割れ、提案の比較も難しくなります。そこで、端末数や繁忙期のピークを踏まえ、たとえばピーク時に50名が同時アクセスしても主要画面が3秒以内に表示される、と数値で書きます。
自社のデータ量で速度が落ちないかは、PoCで確かめる点です。検証できる水準を要件に書いておけば、合否の判断もぶれにくくなります。
クラウド型では、生産データや図面の保管場所やバックアップ体制も要件に含めます。非機能要件は、稼働後に問題が起きてから重要性に気づくこともあります。後付けでは間に合わないため、RFPで品質の基準を示します。
品質の基準を明示しておくことが、安心して使えるシステムの前提になります。非機能要件を数値で書くほど、提案の精度も上がります。
障害時の一次対応時間、夜間・休日のサポート、軽微な改修の扱いは、契約前に文書にしておきます。保守の範囲が曖昧なままだと、稼働後に追加費用のやり取りが発生します。
「この対応は別料金です」というやり取りが続けば、現場の信頼も損なわれます。サポートのSLAまで要件定義で決めておくと、稼働後も安定して使い続けるための基準になります。
PoCの実施と提案評価基準のRFPへの明記
本格契約の前にPoC（実機検証）を行い、合格基準をRFPに書いておきます。自社データを使って検証すれば、カスタマイズが必要かどうかも契約前に判断できます。PoCでは、業務の流れや例外処理、現場での操作を確かめます。提案の評価の観点も、あわせて事前に決めておきます。
- 業務の流れ：典型的な受注が、最初から最後まで処理できるか
- 例外処理：特殊な納期指定、イレギュラーな値引き、複数拠点をまたぐ在庫
- 現場での操作：日々入力する担当者が、マニュアルなしで扱えるか
- 提案評価：機能、費用、実績、サポート、形態適合度の観点
整ったデモデータだけでなく、自社の生データで確かめます。例外的なパターンが詰まらず流れてこそ、本番で使えるかを判断できます。
現場の担当者が実際に画面を操作すると、項目の多さや、いつもの順番との違いに気づけます。契約前であれば要件や設定を見直せますが、稼働後の対応では追加のカスタマイズ費が発生することがあります。PoCは、契約前に現場の納得を得るための、費用対効果の高い工程です。
提案評価では、各項目に重み付けをして点数化する枠組みを用意します。事前に基準を決めておかないと、提案の印象や営業担当者の熱意といった主観で選ぶことにつながります。
要件定義書とRFPは、発注側が主導して公正に選定するための道具です。非機能要件と評価基準を盛り込むことで、その役割を果たせます。
まとめ
RFPと要件定義では、ISA-95を踏まえた守備範囲と連携、生産形態ごとの要件、移行とExcel連携、補助金までを整理します。非機能要件やPoC、評価基準も盛り込んでおくと、提案の比較と導入後の運用を見据えられます。
守備範囲と連携要件の精度は、見積の精度を左右します。見込・受注・個別受注の違いを書き分けておくと、生産形態とのミスマッチを防げます。移行と補助金の要件を整理することは、稼働後の混乱と投資負担を軽くします。
大切なのは、ベンダーに任せきりにせず、自社の業務と生産形態を起点に要件を言葉にすることです。こうして提案を比べやすくしておくと、開発後の認識違いやカスタマイズ費の膨張を防ぎやすくなります。
riplaは、フルスクラッチ受託の立場から、生産形態に即した要件づくりと、現場に定着する提案依頼書づくりを一貫して支援します。生産管理システム全体の流れは、下記の完全ガイドでも確認できます。
▼全体ガイドの記事
・生産管理システムの完全ガイド
▼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を創業。