生産管理システムのRFP/要件定義書/提案依頼書について

生産管理システムの導入プロジェクトで、その後の成否をもっとも左右するのが、開発の前段にあたるRFP（提案依頼書）と要件定義です。ベンダーに「いい感じの生産管理システムを作ってほしい」と曖昧に依頼してしまうと、提案の比較ができず、開発が始まってから要件の認識違いが噴出し、カスタマイズ費が膨張します。逆に、自社の生産形態と業務を起点に要件をきちんと言語化できれば、提案の質も見積の精度も格段に上がります。

本記事は、生産管理システムのRFP・要件定義書・提案依頼書の作り方を、発注側の視点から実務に即して解説する「要件定義特化」の記事です。ISA-95を前提としたERP・MESとの役割分担、見込生産・受注生産・個別受注生産という生産形態別の要件、Excel連携やデータ移行の要件、補助金申請を見据えた要件整理まで、一次データとあわせて具体的に掘り下げます。生産管理システム導入の全体像をまだ把握していない方は、まず生産管理システムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・生産管理システムの完全ガイド

ERP・MESとの役割分担を要件で定義する

要件定義の出発点は、「生産管理システムにどこまでをやらせ、どこからを既存の基幹システムや製造現場のシステムに任せるか」という範囲の線引きです。これが曖昧なまま開発に進むと、機能が他システムと重複したり、逆に重要な機能が抜け落ちたりします。RFPの冒頭で、システムの守備範囲を明確に宣言することが、提案のブレを防ぎます。

システムの守備範囲を整理するうえで有効なのが、ISA-95という国際的な階層モデルです。このモデルでは、ERPが計画層、MESが実行層を担うと位置づけられます。日本の生産管理システムは計画から実行まで幅広くカバーするため、ERPやMESと機能が重なる領域が必ず生じます。RFPでは「会計・人事は既存ERPが担う」「設備からの実績自動収集は対象外」といった形で、重複領域の責任分界点を明記する必要があります。

この切り分けを最初に固めておくと、ベンダーからの提案を同じ土俵で比較できます。逆に範囲を曖昧にしたまま複数社に提案を求めると、A社は会計まで含み、B社は工程管理だけ、というように提案の前提がバラバラになり、見積の比較が成り立ちません。要件定義書には、対象業務の一覧と、各業務をどのシステムが担うかの責任分界点を表で示すことを推奨します。守備範囲の明確化は、後のカスタマイズ費膨張を防ぐ最初の防波堤になります。

守備範囲を分けたら、システム間でどのデータをどう連携するかを要件として定めます。受注データは販売管理から流れてくるのか、在庫情報を会計システムへ渡すのか、連携の方向・タイミング・項目を具体的に記述します。リアルタイム連携なのか、夜間バッチでよいのかによって、開発の難易度と費用が大きく変わるため、要件段階で明確にしておく必要があります。

連携要件で見落とされがちなのが、既存システム側の制約です。古い基幹システムだとAPIが用意されておらず、CSVやファイル連携に頼らざるを得ないこともあります。この場合、前述したCSVの文字化けや列ズレといった問題が連携でも起きうるため、文字コードやファイル形式まで踏み込んで要件化しておくべきです。連携相手の仕様を曖昧にしたままRFPを出すと、ベンダーは安全をみて高めに見積もるか、後から追加費用を請求することになります。連携要件の精度が、見積の精度に直結すると理解してください。

連携の方向を整理する際は、どのシステムを「正」とするマスタ管理の役割をどこに置くかも合わせて決めておきます。品目や取引先の情報を生産管理システムと基幹システムの双方で更新できる状態にすると、どちらが最新か分からなくなり、データの不整合が生じます。RFPには「品目マスタの正は基幹システムとし、生産管理側は参照のみ」といった所有権のルールまで書き込むのが理想です。所有権を決めずに連携だけ作ると、運用開始後に二重メンテナンスの負担が現場にのしかかります。

連携のタイミングについても、業務の実態に即した粒度で要件化します。受注情報は即時に生産計画へ反映したいが、原価の確定データは月次の締めで十分、というように、データの性質ごとに必要な鮮度は異なります。すべてをリアルタイム連携にすると開発費が膨らむため、夜間バッチで足りる箇所はバッチと明記して費用を抑えます。要件定義書に連携項目ごとの頻度を一覧化しておくと、ベンダーは過不足のない構成を提案でき、見積の妥当性も検証しやすくなります。

生産形態別に要件を書き分ける

生産管理システムの要件定義で最大の固有性が出るのが、自社の生産形態に応じた要件の書き分けです。後述する失敗事例で多いのが、生産形態とシステムのミスマッチです。見込生産、受注生産、個別受注生産では、計画・在庫・原価の考え方がまったく異なるため、要件を一律に書くと現場に合わないシステムができあがります。

注意したいのは、多くの製造業が単一の生産形態に収まらないという実態です。主力製品は見込生産でつくりながら、特注品だけは個別受注で対応する、といった混合形態は珍しくありません。この場合、RFPには形態を一つに決めつけず、「製品群ごとにどの形態が何割を占めるか」を整理して伝える必要があります。比率まで示すことで、ベンダーは主たる形態に最適化しつつ、例外をどう吸収するかまで踏み込んだ提案ができます。

見込生産は、需要を予測して在庫を持ちながら生産する形態です。この場合、需要予測の精度や、適正在庫を保つための補充ロジックが要件の中心になります。販売実績や季節変動をもとに生産計画を立てるため、過去データの分析機能や、安全在庫の自動計算が求められます。在庫を前提とした計画なので、欠品と過剰在庫のバランスをどう取るかが要件の肝になります。

一方、受注生産は注文を受けてから生産する形態で、在庫を持たない代わりに納期遵守が至上命題になります。受注ごとに所要量を計算し、納期から逆算して工程を割り付ける機能が要件の中心です。内示や仕様変更への柔軟な対応も求められます。同じ生産管理システムでも、見込生産向けと受注生産向けでは重視すべき機能がまるで違うため、RFPには自社の生産形態を明記し、「この形態に最適化された提案を求める」と明示することが重要です。形態を曖昧にすると、汎用的で使いにくいシステムになりがちです。

個別受注生産は、案件ごとに仕様が異なる一品一様のものづくりで、要件の難易度がもっとも高い形態です。製品ごとに部品表が異なり、都度設計が発生するため、案件単位（プロジェクト単位）で原価を集計する機能が不可欠になります。標準原価という概念が使いにくく、案件ごとの実績原価をいかに正確に積み上げるかが要件の中心になります。

進捗管理も、量産品とは考え方が異なります。同じ作業を繰り返すのではなく、案件ごとに工程が変わるため、案件単位で工程の進捗とコストをリアルタイムに追える仕組みが求められます。要件定義書には、案件番号や工事番号をキーにした原価集計、設計変更が原価に与える影響の追跡といった、個別受注生産に固有の要件を具体的に書き込む必要があります。汎用の生産管理パッケージでは対応しきれず、フルスクラッチでの開発が選択肢に上がりやすいのも、この形態の特徴です。自社がどの形態に当てはまるかを正しく見極め、それに即した要件を書くことが、ミスマッチを防ぐ最大の鍵です。

個別受注生産で要件を固める際は、設計と製造の境界をどう扱うかも論点になります。図面が完成する前に部材の手配や工程の着手が始まる「先行手配」が常態化している現場では、未確定の部品表をもとに進める運用をシステムがどこまで許容するかを定義しなければなりません。理想を追って「すべて確定してから着手」という前提で要件を書くと、現実の業務と乖離して誰も使わなくなります。RFPには、自社の例外的な進め方こそ具体的に書き出し、それを織り込んだ提案を求めることが、定着への近道です。

データ移行・補助金まで含めた要件整理

機能要件を固めたら、見落とされがちな移行要件と、投資負担を軽くする補助金の要件も整理しておきます。これらはRFPの本題から外れて見えますが、実際のプロジェクトの成否とコストに直結する重要な項目です。最初に要件として組み込んでおくことで、後の手戻りや想定外の費用を防げます。

データ移行の要件は、品目マスタ、取引先マスタ、部品表、過去の在庫・受注データなど、何を・どこから・どの形式で移すかを具体的に定めます。とくに設計部門がExcelで管理してきた部品表を取り込めるかは、現場に直結する要件です。Excelの列構成や記載ルールがバラバラだと、移行に想定以上の工数がかかるため、移行対象データの現状を棚卸ししたうえで要件化することが大切です。

あわせて、稼働後のExcel連携要件も忘れてはいけません。前述のとおり、現場のExcel運用を完全に捨てるのは非現実的です。要件定義の段階で「帳票をCSV変換なしでExcel出力したい」「既存マクロを活かしたい」といった連携要件を明記しておけば、ベンダーはそれを前提に提案できます。移行と連携の要件を曖昧にすると、稼働直前に「思っていたデータが入っていない」「Excelが使えなくなった」という混乱が起き、現場の反発を招きます。地味ですが、定着を左右する重要要件です。

移行データの品質をどこまで保証するかも、要件として明記しておく価値があります。長年運用してきたExcelの部品表には、同じ部品が表記ゆれで複数登録されていたり、すでに使われていない品目が残っていたりするものです。これらをそのまま移行すると、新システムに過去の汚れを持ち込むことになります。移行の前に、誰がいつまでにデータをクレンジングするかという役割と期限を要件に含めておくと、移行工程での手戻りを防げます。クレンジングは発注側にしかできない作業が多く、ベンダー任せにできない点に注意が必要です。

取り込みの検証方法も決めておきます。CSVで部品表を取り込む際、文字コードの違いで文字化けが起きたり、区切り位置のずれで列がずれたりするトラブルは、要件段階で想定していないと稼働直前に発覚します。移行リハーサルを行い、件数の突合や金額の合計チェックで移行前後のデータが一致するかを確認する、という検証手順までRFPに織り込んでおくと安心です。移行は一度きりの作業に見えて、実際は試行錯誤を要するため、リハーサルの回数や受け入れ基準を要件に明示しておくことをおすすめします。

生産管理システムは、IT導入補助金などの対象になることがあり、補助率はおおむね1/2〜2/3が目安です。中小製造業にとって、この補助金は投資負担を大きく軽くする手段になります。ただし補助金は年度ごとに要件や枠が変動するため、最新の公募要領を必ず確認する必要があります。申請には、導入によって何をどれだけ改善するかという計画の提出が求められることが多く、ここで前述したROIの定量化が活きてきます。

補助金を見据えるなら、RFPと要件定義の段階から、申請に必要な情報を意識して整理しておくと有利です。導入前後の業務改善効果を数値で示せるよう、現状の工数や在庫水準を記録しておくことが、申請書類の説得力につながります。あわせて、見積を機能単位で分解しておけば、補助対象と対象外の切り分けもしやすくなります。要件定義は単なる開発の設計図ではなく、補助金申請や稟議の根拠資料でもあるという視点を持つと、整理の精度が一段上がります。投資判断と要件整理は一体だと捉えてください。

見積を機能単位で分解しておく効用は、補助金の切り分けだけにとどまりません。要件定義の支援を外部のコンサルタントに頼む場合、その費用はおおむね1人月あたり100万〜200万が相場です。カスタマイズの初期費用が800万〜1,500万に及ぶケースでは、そのうち3〜4割が個社固有の作り込みに充てられることもあります。費用の内訳を要件と紐づけて把握しておけば、どの要件がコストを押し上げているかが見え、優先度の低い要望を削る判断もしやすくなります。

補助金のスケジュールと開発のスケジュールを合わせる視点も忘れないでください。補助金には公募の締切や、交付決定の前に発注してはいけないといった時期の制約が伴います。要件定義に時間をかけすぎて公募期間を逃すと、せっかくの補助を受けられなくなります。逆に補助金の締切に追われて要件を煮詰めないまま発注すると、後の手戻りで補助額以上の損失を被りかねません。補助金は目的ではなく手段だと位置づけ、要件の精度とスケジュールのバランスを取ることが肝心です。

非機能要件とPoC・評価基準の盛り込み方

機能要件・移行要件・補助金要件を固めたら、RFPの完成度を左右する非機能要件と、提案の評価方法を盛り込みます。これらが抜けると、機能は満たしていても使い物にならないシステムを掴んだり、提案の優劣を客観的に判断できなくなったりします。発注側の主導権を保つための、いわば守りの要件です。

非機能要件とは、機能そのものではなく、システムの品質に関わる要件です。代表的なのが性能で、「自社のデータ量で処理が何秒以内に終わるか」「同時に何人が使っても遅くならないか」を具体的な数値で定めます。前述のとおり、自社のデータ量で速度が落ちないかはPoCで必ず確認すべき点であり、それを要件として明文化しておくことが重要です。漠然と「快適に動くこと」では検証も評価もできません。

セキュリティと運用保守の要件も欠かせません。自社の生産データや図面といった機密情報をどう守るか、アクセス権限をどう設定するか、障害時の復旧体制やサポートの対応時間はどうかを定めます。とくにクラウド型を選ぶ場合は、データの保管場所やバックアップ体制まで踏み込んで要件化すべきです。これらの非機能要件は、稼働後に問題が起きて初めて重要性に気づくことが多く、後付けでは間に合いません。RFPの段階で品質の物差しを明示しておくことが、安心して使えるシステムの前提になります。

非機能要件は数値で書くほど提案の精度が上がります。「同時に何人が使うか」を例に取ると、現場の端末数や繁忙期のピーク時刻を踏まえ、「ピーク時に50名が同時にアクセスしても主要画面が3秒以内に表示される」といった水準まで落とし込みます。前述のとおり、自社のデータ量で速度が落ちないかはPoCで必ず検証すべき点であり、検証可能な形で要件を書いておけば、合否の判断がぶれません。漠然とした表現は、ベンダーごとに解釈が割れ、提案の比較を難しくします。

運用保守の要件では、稼働後の体制を具体的に取り決めます。障害発生時に何時間以内に一次対応するか、夜間や休日のサポートは含むか、軽微な改修は保守の範囲か追加費用かといった線引きを、契約前に文書化しておきます。これらを曖昧にすると、稼働後に「この対応は別料金です」というやり取りが頻発し、現場の信頼を損ないます。要件定義の段階でサポートのSLAまで踏み込んでおくことが、長く使い続けるための土台になります。

RFPには、本格契約の前にPoC（実機検証）を行うことと、その合格基準を明記することを推奨します。デモ用の整ったデータではなく、自社の生データで「典型的な受注パターンが最初から最後まで流れるか」「マニュアルなしで現場が触れるか」を確かめる。この検証を要件として組み込んでおけば、カスタマイズが本当に必要かを契約前に見極められ、後のカスタマイズ費膨張を防げます。

PoCで使うデータは、整った見本ではなく、あえて自社の生データを持ち込むことに意味があります。実際の受注には、特殊な納期指定や、イレギュラーな値引き、複数拠点をまたぐ在庫の動きといった、マニュアルに載らない例外が必ず含まれます。こうした例外的なパターンが最初から最後まで詰まらずに流れるかを確かめてこそ、本番での使い物になるかが判断できます。きれいなサンプルだけで合格にしてしまうと、稼働後に「自社のデータでは動かない」という事態に陥ります。

PoCには現場の担当者を巻き込むことも欠かせません。要件定義に関わった担当者だけでなく、日々入力を行う現場のメンバーに実際に触ってもらい、マニュアルなしで操作できるかを観察します。この段階で「画面の項目が多すぎる」「いつもの順番と違う」といった声が出れば、それは要件の見直しや設定の調整で対処できます。稼働後に同じ不満が噴出すると、追加のカスタマイズ費が発生します。PoCは、現場の納得を契約前に得るための、もっとも費用対効果の高い工程だと位置づけてください。

あわせて、複数社の提案を公平に比べるための評価基準もRFPに示します。機能の充足度、費用、導入実績、サポート体制、自社の生産形態への適合度といった評価項目に重み付けをし、点数化する枠組みを用意しておくのです。評価基準を事前に決めておかないと、提案の印象や営業担当者の熱意といった主観で選んでしまい、後悔につながります。要件定義書とRFPは、発注側が主導権を握って公正な選定を行うための道具です。非機能要件と評価基準まで盛り込んで初めて、その役割を果たせます。

まとめ

生産管理システムのRFP・要件定義を振り返ると、成否を分けるのは「ERP・MESとの守備範囲をISA-95を前提に切り分け、自社の生産形態に即して要件を書き分け、データ移行とExcel連携、補助金まで含めて整理する」という一貫した姿勢です。守備範囲と連携要件の精度が見積の精度を決め、見込生産・受注生産・個別受注生産という形態別の書き分けがミスマッチを防ぎ、移行と補助金の要件整理が稼働後の混乱と投資負担を軽くします。

要件定義で大切なのは、「ベンダーに丸投げしない」という当事者意識です。自社の業務と生産形態を起点に要件を言語化できれば、提案の比較が成立し、開発後の認識違いとカスタマイズ費の膨張を防げます。riplaはフルスクラッチ受託の立場から、生産形態に即した要件の言語化と、現場に定着する提案依頼書づくりを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。