資材所要量計画システム(MRP)開発の発注/外注/依頼/委託方法について

資材所要量計画システム(MRP)開発の発注は、現状分析、要件整理、方式選定、PoCの順に進めます。その後、開発、移行・テスト、教育を経ると、安定した運用につながります。

発注形態、RFPと契約、導入手順、費用相場、委託先の選び方を順に説明します。全体像は完全ガイドもご覧ください。

▼全体ガイドの記事
・資材所要量計画システム(MRP)開発の完全ガイド

資材所要量計画システム(MRP)の発注形態の選び方

発注形態は、標準機能に業務を合わせられる範囲と、独自ルールの重要度で決めます。拠点数や既存システムとの連携量も、判断材料になります。

SAP Insightsの「MRP(資材所要量計画)とは?」では、MRPは需要やMPSからBOM、在庫、入荷予定までを段階的に計算すると説明されています。そのうえで、正味不足量から製造または購買の数量と日付を提案します(出典:SAP Insights)。

方式選定では、画面の数よりも、データ構造と計画ロジックが自社の業務に合うかを見ます。

クラウド・SaaSやパッケージを発注するケース

クラウドやパッケージを選ぶ際は、標準機能に業務を合わせられるかと、追加費用がどこまで発生するかを確かめます。

  • 標準機能:BOM管理、在庫引当、購買提案、製造指図などを利用できます。
  • 段階導入:Fit to Standardや1工場・主要品目からの開始に向きます。
  • 追加費用:設定、移行、権限、帳票、教育、販売・会計・WMS・MES連携が、別途かかる場合があります。

クラウドでは、接続が不安定になったときに現場の業務を続けられるか、データをどこに保管するか、バックアップと復旧目標はどうかを確かめます。また、APIの利用上限や更新告知の期間も、導入前に把握しておきます。

Microsoft公式ページには、Dynamics 365 Supply Chain Managementの価格が通常版からPremiumまで掲載されています。1ユーザーあたり月額約3.1万〜4.5万円相当です(年払い・税別・掲載時点)。ただし、これはライセンスの参考価格で、導入支援、移行、追加開発を含むMRP導入費用ではありません。

スクラッチ開発やハイブリッドを発注するケース

独自ルールが競争力に関わる場合は、スクラッチやハイブリッドが候補になります。

  • 独自の生産ルール:独自BOM、製番管理、特殊な補充ルールなど。
  • 受注の混在:内示と確定受注、受注生産と繰返生産の扱い。
  • 能力制約:設備や熟練者を含む計画では、APS等との連携が候補になります。

ハイブリッドでは、在庫・購買・会計の中核をERPやパッケージに置きます。独自の計画画面やワークフローは別のサービスで作り、APIやデータ基盤で連携します。

ハイブリッドは、標準化する範囲と差別化する範囲を分けやすい点が利点です。

スクラッチでは、要件定義やテスト、保守人材を、発注側も長期的に担います。さらに、障害時の手動運用や法改正、セキュリティ対応も必要です。

MRPは無限能力で資材を計算する場合があります。そのため、塗装ラインや金型などの制約は、APSや有限能力計画と連携させて扱います。設備時間や熟練者を含めて、資材が揃っても設備が空かない問題を、別の機能で扱う要件にします。

発注前のMRP要件とRFPの整理

MRPのRFPで整理する業務範囲とデータ項目を4枚のカードで示した図。
計画の流れとマスタ情報を同じ資料で確認できます。

RFPで伝えるのは、業務課題をどのデータと判断で解決するかです。前提をそろえておくと、各社の見積を比べやすくなります。

業務範囲とデータの現状の記載

RFPに含める業務範囲とマスタ項目は、業務の流れに沿って洗い出します。

  • 計画業務:需要予測・受注、MPS、BOM展開、正味所要量計算。
  • 手配と実績:在庫・発注残、購買依頼、製造指図候補、納期回答、実績反映。
  • 品目マスタ:コード、名称、単位、調達区分、リードタイム、ロットサイズ。
  • BOMと工程:階層、数量、歩留まり、代替部品、改訂、有効期間。加えて、設備と休日も含みます。

品目マスタでは、安全在庫や発注点、廃番日、拠点の有無も押さえておきます。

BOMには変更承認の流れを、工程には作業時間と外注工程を含めて記載します。

まず診断すべきはBOMと在庫の品質です。Excelや担当者の経験に分散したデータをそのまま移すと、計算は速くなるものの、誤った発注提案を高速に出しかねません。たとえば、品目コードの重複、単位の揺れ、BOMの未登録と旧版を、サンプルで確認します。在庫差異、リードタイムの欠損、仕入先別の最小発注量も、同じサンプルで確かめます。

移行対象外のデータ、補正ルール、責任者もRFPに記載します。そうしておくと、見積の段階で、データ整備を誰がどこまで担うかがはっきりします。

KPIとPoCの検証シナリオの設定

KPIは、欠品や過剰在庫、緊急購買、計画担当者の手作業を減らすという目的に沿って決めます。

  • 在庫と欠品:欠品率、在庫回転日数。
  • 購買と納期:緊急購買件数、納期回答時間。
  • 計画作業:計画作成工数、MRP再計算時間。

各KPIの現状値と目標値を並べます。目標が未確定でも、測定方法とデータの取得元を決めれば、導入効果を確認できます。

PoCでは、正常な受注だけでなく、多段階のBOMを使い、在庫と発注残を差し引いて検証します。現場の担当者が結果を説明できるかも確かめます。

  • 変動の検証:納期変更、欠品、仕入先遅延、BOM改訂を試します。
  • 例外の検証:返品、代替部品、通信断を試します。
  • 拠点間の検証:内示減少や複数工場での部品競合を確認します。

PoCでは、担当者ごとのアクションメッセージまで確かめます。

RFPには、製品・ライセンス費、要件定義、設定、追加開発の費用を書き分けます。データクレンジングや移行、API・EDI連携も、別の行として並べます。テスト、教育、稼働支援、保守も、項目ごとに書きます。

各社には、前提条件と除外事項を同じ書式で回答してもらいます。成果物、開発会社・導入パートナー、発注側の作業も、あわせて書いてもらいます。予定、体制、検収条件、障害対応時間も含めて、回答を求めます。

ポイント

RFPは、業務課題をどのデータと判断で解決するかを示す資料と考えます。データの状態が分からない項目は、移行対象外や補正ルールを明記し、見積の前提をそろえます。

MRPの発注・外注の進め方

MRP外注の現状分析と要件定義から教育・稼働支援までの5工程を矢印で示した図。
PoCの後に設計へ進み、移行と教育を経て稼働を支援します。

MRPの外注は、現状分析から教育・稼働支援まで、この順に進めます。順番を守るのは、デモから契約へ急ぐと、標準機能と追加開発の境界が曖昧になりやすいからです。

  1. 現状分析と要件定義
  2. 方式選定とPoC
  3. 設計・開発
  4. 移行・テスト
  5. 教育・稼働支援

発注側は、生産管理責任者、購買、製造現場の担当者を含む意思決定チームを作ります。情報システムと経理、工場ごとの代表者も、このチームに加わります。

現状分析と要件定義の先行

現状分析では、計画担当者が見ている表や、数量を調整する時期、例外時の確認先を、業務フローとしてまとめます。

  • 製造形態:見込、受注、個別受注、多品種少量、プロセス製造。
  • 機能要件:BOM改訂、受注優先順位、在庫引当、手配提案、承認、履歴。
  • 非機能要件:同時利用者、計算時間、データ量、稼働時間、復旧目標。

製造形態によって、需要の持ち方やBOMの表し方は異なります。そのため、工場や製品群ごとに代表的なケースを選ぶと、要件の漏れを減らせます。

機能要件には、帳票や外注工程も含めます。

非機能要件には、バックアップや権限分離、監査ログを記します。さらに、APIの冪等性と、障害時に手動で業務を続ける方法も定義します。

要件を機能と非機能に分けると、提案の範囲がはっきりします。

PoCから設計・開発への段階的な進め方

PoCから設計・開発へ進むときは、段階ごとに、対象範囲と合格条件、業務責任者の承認を確かめます。

  • PoCの対象:1工場、主要品目、代表的なBOMを使い、需要投入から手配候補の出力までを確かめます。
  • 説明の確認:現場の担当者が結果を説明できるかを見ます。
  • 設計への移行:PoCに合格したら、基本設計、詳細設計、連携開発、移行設計へ進みます。
  • 独自ルールの実装:更新時に壊れない実装方法を、設定で吸収する方法や標準機能に戻す方法と合わせて設計書に記します。

説明の根拠として、BOM、在庫、リードタイム、ロットサイズの原因を追えるログも確認します。

移行・テスト・教育・切替の分割管理

テストでは計算式だけでなく、実際の発注から入荷実績の反映までを確かめます。

  • テスト種別:単体、連携、業務シナリオ、性能、権限・セキュリティ、受入。
  • 計算条件:日付逆算、休日、最小ロット、端数、代替部品。
  • 発注の流れ:在庫引当、発注残変更、承認、発注、入荷実績。

実データに近い条件で、購買担当者が提案を承認し、仕入先へ発注するまでの一連の流れを試します。

切替時は、旧システムとの並行期間、在庫残高の確定日時、未完了の購買発注を決めます。製造途中の仕掛の扱い、戻し方、緊急発注の手順も、あわせて決めておきます。

全工場を一斉に切り替えるより、影響範囲を絞った段階導入のほうが、生産停止のリスクを抑えやすくなります。

教育には、例外の扱いと根拠データの確認も含めます。

ポイント

次の工程に進むかは、業務の境界が決まっているかで判断します。境界が曖昧なまま契約へ進むと、標準機能と追加開発の線引きが後からずれやすくなります。

MRP開発の契約形態(請負・準委任)の使い分け

契約は、要件がどこまで確定しているか、検収できる成果物があるか、発注側がどの業務判断を担うかで使い分けます。

法的な適用と責任の範囲は、契約書と専門家で確認します。

データや現場ルールが変わりやすいMRP案件では、要件定義を準委任で進め、仕様が確定してから開発を請負にする段階分けが現実的です。

請負契約の成果物と変更条件

請負契約では、合意した成果物の完成と検収を中心に進めます。そのうえで、納品物と予算の扱いを確認します。

  • 成果物:設計書、画面・帳票、API仕様、移行ツール、テスト結果、操作マニュアル。
  • 予算管理:固定価格で管理しやすい一方、曖昧な要件は追加費用につながります。
  • 変更条件:仕様変更の単価、手順、承認者を契約前に決めます。

検収基準、瑕疵対応、保証期間を、契約書で明確にします。再委託、知的財産権、ソースコード利用権、第三者サービス費についても、あわせて決めておきます。

MRPでは、「計算結果が正しい」とは何かを定義しておくことが欠かせません。受入テスト仕様には、対象データと期待する数量・日付を記します。さらに、例外表示と再計算条件も書いておきます。

準委任契約が向く要件整理や伴走支援

準委任は、発注側と開発側が専門知識や作業を持ち寄る工程に向いています。調査結果や優先順位が途中で変わる作業も、この形で整理できます。

  • 要件整理:現状分析、Fit to Standard、RFP作成支援。
  • 導入支援:データ診断、プロジェクト管理、稼働後の改善。

準委任は作業時間や体制を基準に進むため、別紙で成果物と担当者、稼働時間を明確にします。報告方法と意思決定者も、同じ別紙に書いておきます。

週次の共有では、課題、決定事項、未決事項を伝えます。担当、リスク、消化工数もあわせて共有します。さらに、要件定義書やデータ診断報告書などの中間成果物も受け取ります。

請負へ移る判断基準を設けておくと、要件が固まらないまま固定価格で契約するリスクを抑えられます。

保守・運用契約と責任分界

稼働後に必要な支援と、障害時の責任分界を契約で定めます。

  • 運用費用:クラウド利用料、ライセンス、問い合わせ、監視、バックアップ。
  • 保守対応:障害、脆弱性、マスタ更新、法改正、追加連携。
  • 復旧体制:営業時間外の連絡先、初動、復旧目標、代替手順、責任者。

MRPが停止すると、購買や製造の停止にもつながります。

工場設備やIoTと接続する場合は、IT・OT分離やリモート接続、資産管理、ログ保管も、保守の範囲に含めます。

経済産業省は2025年4月、中小規模の製造事業者向けの工場セキュリティ解説書を公表しました。サプライチェーンを含む工場のサイバー・フィジカル・セキュリティを扱っています。

IPAの制御システム向けリスク分析ガイドは、要件定義やRFPの確認にも使えます。

購買発注、検収、仕入計上を会計と連携する場合は、電子帳簿保存法やインボイス制度の保存要件も、システム要件として確認します。

ポイント

契約は、要件がどこまで確定しているかで選びます。要件が固まらない段階は準委任、仕様が確定した開発は請負にするのが目安です。稼働後の保守と責任分界も、契約に定めます。

資材所要量計画システム(MRP)の費用相場の目安

MRP単体には標準価格がありません。そのため、費用は拠点数や品目数、BOM階層、同時利用者で大きく変わります。連携先やデータ移行、カスタマイズ、運用支援によっても差が出ます。

下記の数字は、公開されている生産管理システムの相場と案件規模から見た目安です。RFPの比較の基準に使うためのレンジで、確定見積ではありません。

導入形態別の費用レンジ

公開相場とMRP案件の規模別の目安は、対象範囲が異なるため、区別して読みます。

  • クラウド型:初期10万〜100万円、月額2万〜20万円程度。
  • パッケージ型:初期200万〜800万円、年間保守は本体価格の10〜15%程度。
  • スクラッチ型:1,000万円〜数千万円とされます。
  • 小規模PoC:主要品目を使うMRP案件で300万〜1,000万円程度。
  • 工場・複数拠点:1工場は1,000万〜5,000万円、複数拠点刷新は5,000万円超も個別見積。

生産管理システムの公開相場の出典は、キッセイコムテック「生産管理システムとは?」(2025年掲載)です。この数字は、MRPの移行・連携・教育を含む総額ではありません。

複数拠点連携の1,000万〜5,000万円程度と、スクラッチの1,000万円〜数千万円は、リサーチノートの類似業務システム相場からの推定です。規模や範囲が異なる案件には、そのまま当てはめられません。

初期費用とランニングコストの内訳

見積は項目ごとに分解し、データ整備や運用を含む総額で比べます。

  • 初期費用:利用料、要件定義、設定、追加開発。基盤、移行、連携、帳票も含みます。
  • 導入作業:データクレンジング、テスト、教育、稼働支援。
  • 継続費用:利用料、保守、監視、バックアップ、脆弱性・法改正対応。

BOM移行では件数だけでなく、階層や有効期間、改訂の不備を直します。単位や代替部品の不備も、同じ作業に含めます。

データが未整備の場合は、開発費とは別にデータ整備費を置きます。そうしておくと、予算の変動を説明しやすくなります。

ランニング費には、ユーザー追加や問い合わせ、マスタ保守、追加連携も含めます。スクラッチの場合は、初期費用の15〜25%程度を年間の保守運用の目安とする考え方があります。

ただし、その目安は監視時間や工場休日対応、SLA、改修上限によって変わります。5年間のTCO(総所有コスト)では、教育やデータ補正、旧システムとの並行稼働、緊急対応も含めて考えます。

費用対効果は、在庫金額だけでなく、生産停止や緊急購買、特急輸送を含めて考えます。納期回答の遅れや計画作業、棚卸差異も、金額と時間に換算します。

日立システムズの公開事例では、プリンタ部品製造業が11ライセンスを利用しています。同社は、内示・確定受注とMRPによる資材発注を扱い、複数工場のデータを共有しています。

数千万円の在庫金額削減も紹介されています。ただし、これは個別案件の効果なので、同額の削減を前提にせず、自社の現状値からROIを試算します。

ポイント

公開相場は、対象範囲が異なる数字を含むため、目安として扱います。比べるときは、データ整備や教育、5年間のTCOまで含めた総額で見ます。

委託先の選定と見積比較の確認事項

製造業実績とMRPの実装力を確認する4つの観点をチェックカードで示した図。
案件条件と実装時の扱いをそろえて候補を比べられます。

委託先は、知名度や総額だけでなく、自社と同じ生産方式や規模、データの複雑さの案件を任せられるかで選びます。製品ベンダーと、要件定義から運用まで担う導入パートナーは、別の会社である場合があります。そのため、工程ごとの責任者や再委託先を含む体制と実績を確認します。

製造業実績とMRPの実装力

実績を比較するときは、対象案件の条件をそろえて聞きます。

  • 案件規模:業種、生産方式、拠点数、品目数、BOM階層、利用者数。
  • 導入範囲:連携先、期間、担当工程、運用支援の範囲。
  • 製品情報:SCPLANやTPiCS-Xの公開資料を、候補比較に使います。

日立のSCPLANについては、高速なMRP計算を中心に、グローバル拠点間の需給計画を扱う公式資料が公開されています。

TPiCS-Xは、組立・加工・プロセスと繰返生産の混在を訴求しています。少量多品種や一品受注も含めた混在が、その対象として示されています。

公開情報で候補を絞ったうえで、自社データを使ったデモとPoCで確認します。

質問は「MRP機能がありますか」で終わらせず、実装や障害時の運用まで具体的に確かめます。

  • データ変更:BOMの有効期間・改訂、内示から確定への変化をどう扱うか。
  • 計画条件:発注残変更や能力制約をどう再計算するか。
  • 追跡と障害:計算根拠のログ、API障害時の手動運用が可能か。

回答が画面デモだけでなく、データモデル、処理時間、例外メッセージ、運用体制まで説明しているかを見ます。

同じ前提での見積の内訳と除外事項の比較

見積比較では、RFPの要求項目を縦に置き、各社の回答を横に並べます。

  • 対応内容:標準、設定、追加開発の区分と工数・単価。
  • 体制と期間:担当、スケジュール、前提、除外事項。
  • 含有範囲:データ整備、連携先ごとの接続、帳票、移行リハーサル。教育、並行稼働、稼働後支援も含みます。

「一式」とだけ書かれている項目が多い場合は、作業の分解と完了条件を、追加で依頼します。

社内評価の例は、製造業・MRP実績30%、BOM・計画機能25%、連携・拡張性20%、導入・保守体制15%、価格透明性10%です。

これは編集上の評価例で、契約前の客観的な点数ではありません。営業担当だけで決めず、現場、購買、情報システム、経理がそれぞれ確認項目を持ちます。提案時の質問とデモ評価は、関係する部門が同じ記録に残します。

発注後のリスクと対応責任

提案の段階でリスクと対応責任を確かめ、変更を記録する仕組みも決めておきます。

  • データ・設計:BOM未整備、現行踏襲、アドオン過多。
  • 移行・連携:テスト不足、移行遅れ、ネットワーク停止。
  • 体制・費用:属人化や導入後の保守費増加。

各リスクについて、発生条件、影響、予防策、発生時の担当と期限を示してもらいます。また、未確定の事項や追加費用の条件も、明らかにしてもらいます。

リスクを小さく見せるより、未確定事項を正しく示し、調査工程と追加費用の条件を説明する開発会社のほうが信頼できます。

追加要件は口頭で進めず、影響範囲、費用、納期、テスト、承認者を記録します。特に、小さな画面変更でも、連携や権限へ影響する場合があります。

月次の経営会議ではKPIと予算を、週次の現場会議では課題と変更を確認します。そのうえで、発注側が意思決定を止めない体制を作ります。

ポイント

委託先は、任せたい規模と生産方式に近い実績があるかで絞ります。見積は同じ前提で比べ、除外事項とリスクの扱いまで確かめてから決めます。

よくある質問(FAQ)

製品選びや費用、データ移行、契約責任など、初回相談や社内稟議で出やすい疑問に答えます。

MRPはパッケージとスクラッチのどちらで発注すべきですか?

標準的なBOM、在庫、購買、製造の流れであれば、パッケージやERP内蔵MRPから検証します。一方で、独自ロジックや生産方式が競争力に直結する場合は、スクラッチやハイブリッドを検討します。

方式を最初から決め切らず、代表データのPoCで標準機能との差分を確かめます。

データが整っていなくてもMRPを外注できますか?

外注はできますが、開発の前にデータ診断とクレンジングを行います。品目コード、BOM、在庫の状態をサンプルで確認します。リードタイム、単位、発注残も、サンプルで確かめます。

補正ルールと責任者を決めたうえで、データ整備を見積、スケジュール、受入条件に含めます。

MRPの発注から稼働まで何か月かかりますか?

クラウドの小規模導入は数週間から数か月、パッケージの1工場導入は数か月が目安です。一方、複数拠点連携や大規模スクラッチでは、6〜12か月以上かかる場合があります。

期間は、BOMと在庫の品質や既存連携、意思決定の速さ、段階導入の範囲によって変わります。また、PoCや移行リハーサル、教育、並行稼働を省くと、切替後のリスクが高まります。

MRPを導入すれば設備能力や人員不足も解決できますか?

MRPは、資材の必要量と手配時期を計算する仕組みです。そのため、設備能力や人員不足を解決できるとは限りません。

塗装ラインや金型などの制約には、APSや有限能力計画との連携が必要です。熟練者や設備時間の制約も、その連携の対象になります。RFPでは、各機能の担当製品と承認場所を明記します。

まとめ

発注前には、生産方式や対象拠点、BOM、在庫を洗い出します。リードタイムや既存連携も、あわせて確かめます。

そのうえで、標準化できる範囲はクラウド・パッケージやERP内蔵MRPを使い、独自ロジックはハイブリッドやスクラッチで補うと、費用と保守負担のバランスを取りやすくなります。

RFPでは、業務課題やKPI、PoC、データ移行の前提をそろえます。さらに、機能・非機能要件、連携、契約、検収、運用責任も、同じ前提で示します。見積は分解し、公開相場と案件固有の推定を区別したうえで、5年間のTCOと導入効果で比べます。

価格だけでなく、計算根拠を説明でき、例外や障害時にも現場を支えられる委託先を選ぶことが、安定した運用につながります。

▼全体ガイドの記事
・資材所要量計画システム(MRP)開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。