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

資材管理システムの導入・開発で、プロジェクトの成否をもっとも大きく左右するのが要件定義です。資材管理は、入出庫や受払の記録だけでなく、直接材と間接材で要件が分岐し、多階層BOM（部品表）に紐づく所要量計算、加工委託先への支給品管理、ERPや在庫システムとのデータ連携、そして承認ルートや購買可視化といった内部統制まで絡む、業務の複雑性が高い領域です。これを曖昧なまま要件にすると、安価なパッケージを入れたものの業務に合わずExcelに逆戻りし、カスタマイズ費が膨らむという典型的な失敗に直結します。

本記事は、資材管理システムのRFP（提案依頼書）・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。現状（AsIs）の棚卸しと目指す姿（ToBe）の描き方、直接材と間接材の要件分岐、多階層BOMと支給品の要件化、ERP連携のデータ不整合を防ぐ要件、内部統制（J-SOX）・電帳法・インボイスへの対応要件、そしてRFPに盛り込むべき項目と見積りの妥当性を判断する軸まで、実務に即して掘り下げます。なお、全体像をまだ把握していない方は、まず資材管理システムの完全ガイドから読むことをおすすめします。

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

現状の棚卸しとToBeモデルから始める要件定義

資材管理システムの要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。出発点は、現場が今どのように資材を受け払いし、発注し、棚卸ししているかを徹底的にヒアリングして可視化することです。資材管理の現場は、長年の慣行と属人的な勘で回っている部分が多く、Excelや手書き台帳、ホワイトボードでの在庫管理が混在しているケースが珍しくありません。この実態を無視して理想論で機能を決めると、現場の運用と噛み合わないシステムができあがります。

最初に行うべきは、現状（AsIs）の業務フローを可視化するヒアリングです。資材調達の担当者、生産管理、倉庫、経理、そして加工委託先とのやり取りを担う部門まで、関係者に「どの資材を、いつ、どの基準で発注しているか」「在庫数をどう数え、どう記録しているか」「棚卸しの差異はどう調整しているか」「発注残や入荷予定をどう管理しているか」を細かく聞き取ります。ここで重要なのは、マニュアルに書かれた建前ではなく、現場が実際に行っている運用や、属人的な例外処理まで拾うことです。

資材管理の現場には、「この資材だけはベテランが感覚で発注量を決めている」「急ぎの場合は委託先に電話で直接手配する」といった、明文化されていない慣行が必ずあります。これらを見落とすと、システムに移行した途端に現場が回らなくなります。AsIsの可視化は地道な作業ですが、ここで現場の実態を正確につかむことが、後の要件の漏れを防ぎ、現場に定着する資材管理システムを生む土台になります。

AsIsを可視化したら、次に描くのがToBeモデル、つまり「システム導入後、あるべき資材管理の姿」です。手書き台帳とExcelで二重入力していた在庫を一元管理し、BOMから所要量を自動計算して発注を起こし、IoT重量センサーやハンディ端末でリアルタイムに受払を記録する。この新しい業務フローを具体的に設計したうえで、それを実現するために必要な機能を逆算します。ToBeを描かずに機能だけ決めると、機能はあっても業務がつながらない、という事態に陥ります。

ToBeモデルを描く際は、効果の目標も併せて設定します。たとえば棚卸し作業時間の削減、欠品による生産停止の防止、過剰在庫の圧縮といった改善目標を数値で置き、その達成に必要な機能だけを要件化していくのです。安価なパッケージを入れたものの現場に定着せず、結局Excelに戻ってカスタマイズ費だけが膨らんだという失敗の本質は、このToBeモデルを描かずにツール起点で導入を進めた点にあります。要件定義の出発点をToBeモデルに置くことが、無駄な投資を避ける最大の防衛策です。

直接材と間接材の要件分岐を整理する

資材管理システムの要件定義で最初に明確にすべきは、対象とする資材が直接材か間接材か、あるいは両方かという点です。直接材と間接材では、管理の論理がまったく異なり、要件も大きく分岐します。ここを曖昧にしたまま要件を作ると、片方の業務に偏ったシステムができ、もう片方の業務が回らなくなります。

製品を構成する直接材は、生産計画とBOM（部品表）に連動した所要量計算（MRP）が要件の中核になります。「どの製品を、いつ、何個作るか」という生産計画から、BOMを展開して必要な資材の数量と発注タイミングを逆算する仕組みです。要件定義では、BOMが何階層あるか、構成品にロット管理や有効期限管理が必要か、所要量計算の対象とする在庫（手持在庫・発注残・引当済）をどう扱うかを定義します。これらを曖昧にすると、欠品か過剰在庫のどちらかが必ず発生します。

多階層BOMを扱う場合は、設計変更（設変）への追従要件が特に重要です。製品の設計が変わると、どの構成品を、いつの製造ロットから新部品に切り替えるのか、旧部品の発注残や在庫をどう処理するのかを判断しなければなりません。この設変追従の要件を抜かすと、設計が変わるたびに現場が手作業で発注を組み替えることになり、発注ミスの温床になります。多階層BOMと設変追従は要件定義の段階で必ず言語化しておくべき論点です。

あわせて、所要量計算をどの粒度・周期で回すかも要件化します。日次でMRPを回すのか、生産計画の確定タイミングに合わせるのか、内示と確定注文をどう区別して引き当てるのか。さらに、調達リードタイムが長い資材は前倒しで手配する必要があるため、品目ごとのリードタイムや最小発注ロット、発注点を要件として持たせるかを定義します。これらの計算パラメータが曖昧なまま導入すると、システムが出す発注提案を現場が信用せず、結局手作業に戻ってしまいます。直接材の要件は、計算ロジックの精度がそのまま現場の信頼につながる領域です。

消耗品や工具、事務用品といった間接材は、BOMに紐づかず、カタログ購買と承認ルート設計が要件の中心になります。間接材は、各部門が個別に発注する「マーベリック購買（逸脱購買）」が起きやすく、内部統制上の弱点になりがちです。要件定義では、誰が、いくらまで、どの承認を経て発注できるのかという承認ルートを明確にし、購買データを一元的に可視化できる仕組みを定義します。楽楽販売やLeaner購買、楽々ProcurementIIといった間接材向け購買管理ツールが想定する業務像を参考に、自社の承認権限を棚卸しすると整理しやすくなります。

支給品の管理も、要件定義で見落とされやすい論点です。加工を外部委託する場合、委託先へ無償または有償で資材を支給し、その在庫と原価を自社側で管理し続ける必要があります。無償支給品は自社の資産のまま委託先にあり、有償支給品は売上と仕入が立つため、会計処理も変わります。委託先での消費実績をどう把握し、支給品の在庫差異をどう調整するかを要件に盛り込まないと、原価が合わなくなります。直接材・間接材・支給品という三つの管理対象を切り分けて要件化することが、資材管理システムの土台を固めます。

これら三つの管理対象は、それぞれ要件の重心が異なります。直接材は計算ロジックの精度、間接材は承認と可視化、支給品は在庫追跡と会計処理が肝になります。自社の資材構成のうち、どの対象が金額的・件数的に大きいかを把握し、要件定義の労力を配分することが現実的です。すべてを同じ深さで作り込もうとすると費用が膨らむため、自社にとって重要度の高い管理対象から優先的に要件を固め、残りは標準機能で吸収する、というメリハリのある要件化が、限られた予算で成果を出す進め方になります。

ERP連携と内部統制・法令対応の要件化

資材管理システムは単独で完結せず、ERP・会計・在庫・生産管理といった既存システムとつながって初めて効果を発揮します。同時に、資材調達は金額が大きく、不正や逸脱が起きやすい領域でもあるため、内部統制と法令対応の要件を欠かすことはできません。この連携と統制の要件こそ、資材管理システムでもっとも技術的な検討を要する部分です。

ERP連携の要件化では、既存の基幹システムが何か、どのデータ（品目マスタ・発注・入荷・在庫・原価）を、どの方向に、どのタイミング（リアルタイムかバッチか）で連携するかを定義します。資材管理で特に怖いのが、品目マスタの二重管理です。資材管理システムとERPで別々に品目を登録すると、同じ資材が別コードで存在し、在庫数が合わなくなります。マスタをどちらを正とするか、連携の単一情報源（マスタの主管）をどこに置くかを要件で決めておく必要があります。

既存システムの仕様や連携可能なインターフェース（API・CSV・ファイル連携）を事前に把握しておかないと、ベンダーが精緻な見積りを出せません。連携漏れや項目の不一致が後から発覚すると、追加開発費が発生します。実際、基幹連携の追加開発は100〜500万円規模になることがあり、要件定義で連携範囲を曖昧にした代償は小さくありません（費用感の出典はriplaの実績ベース）。連携範囲・連携項目・マスタの主管を要件定義の段階で明確にすることが、データ不整合と追加費の膨張を防ぎます。

内部統制（J-SOX）の観点では、承認証跡（誰がいつ何を承認したかのログ）、権限分離（発注者と承認者・検収者を分ける）、購買可視化を要件化します。間接材のマーベリック購買を防ぐためにも、承認ルートと権限分離は要件として明記すべき項目です。これらを後付けで作ろうとすると、データ構造の作り直しが必要になり、コストが跳ね上がります。

法令対応では、電子帳簿保存法（電帳法）とインボイス制度への対応を要件に織り込みます。発注書や請求書を電子で授受・保存する場合、電帳法の保存要件を満たす必要があり、インボイス制度では適格請求書の記載要件と仕入税額控除の管理が求められます。これらを導入時に織り込まず、後から追加すると、新規開発時に織り込む場合の2〜3倍のコストがかかると言われます。サポート費を年100万円節約したものの、稼働半年後のインボイス改正対応で別会社に500万円を追加発注した、という実例も報告されています（出典はriplaの知見）。法令対応は最初から要件に組み込むのが鉄則です。

RFPに盛り込む項目と見積り妥当性の判断

要件定義書がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。資材管理システムは導入形態によって費用幅が大きいため、RFPで土俵を揃えることが、見積りの妥当性を判断する大前提になります。

RFPには、最低限以下の項目を盛り込みます。プロジェクトの目的とKGI（棚卸し工数削減・欠品防止・在庫圧縮など）、現状（AsIs）と目指す姿（ToBe）の業務フロー、機能要件（直接材のBOM/MRP・間接材のカタログ購買と承認・支給品管理を分けて記述）、非機能要件（性能・セキュリティ・可用性）、既存システムとの連携要件（基幹システム名・連携範囲・マスタの主管）、内部統制と法令対応の要件、予算とスケジュールの目安、そして開発・運用の体制要求です。資材管理特有の論点である多階層BOMの設変追従や支給品管理は、機能要件の中核として具体的に記述します。

とくに見落とされがちなのが、追加要件が発生したときの単価ルールです。「追加開発の人月単価が当初の1.5倍になる契約だった」という罠が報告されており、これを避けるには、追加開発の単価テーブルを事前に取り決める条項をRFPに盛り込むことが有効です。あわせて、体制図の提出を求め、誰が実際に開発するのか、プロジェクトマネージャーは誰かを明記させると、プレゼンの上手さに惑わされないベンダー選定ができます。

集まった見積りの妥当性を判断するには、導入形態ごとの相場観を持つことです。クラウドSaaS型は初期0〜数十万円・月数万〜数十万円で、導入期間も1〜3ヶ月と手軽ですが、自社の複雑な業務には合わない部分が残ります。オンプレパッケージ型は初期400〜500万円・年保守はライセンスの10〜20%が目安です。自社業務に合わせて作るスクラッチ型は、小規模で300〜1,000万円、中規模で1,000〜3,000万円が目安となります（費用感の出典はriplaの実績）。見積りがこの相場から大きく外れる場合は、その理由を確認します。安すぎる場合はBOM連動や支給品管理といった固有機能が漏れている可能性、高すぎる場合は過剰なカスタマイズが含まれている可能性があります。

次に、見積りの内訳を精査します。「テスト・デバッグ費」「ディレクション費」が一式でまとめられている場合は、内訳の開示を求めます。機能ごと・工程ごとに工数と単価が示されていれば、どこにコストがかかっているかが見え、追加要件発生時の単価ルールも事前に取り決められます。要件定義書とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ず、ブラックボックスを解明しやすくなります。riplaはフルスクラッチ受託とAI駆動開発の立場から、要件の透明な整理と見積り内訳の明示を重視しており、AI駆動開発によって開発速度を3〜5倍に高め、期間を30〜70%短縮した実績があります。要件定義の精度が、見積りの妥当性判断の精度を決めるのです。

あわせて、ベンダーが資材管理の泥臭い業務をどこまで理解しているかも、提案内容から見極めます。多階層BOMの設変や支給品の在庫差異、間接材のマーベリック購買対策といった現場の難所に踏み込んだ提案ができるベンダーは、要件を正しく咀嚼している証拠です。逆に、一般論の機能説明に終始し、自社固有の業務に対する具体的な解決策を示せないベンダーは、リリース後に「想定と違う」というトラブルを起こしやすいと言えます。見積りの数字だけでなく、提案の中身が自社の業務実態をどれだけ捉えているかを、選定の最終的な判断軸に据えることが重要です。

まとめ

資材管理システムの要件定義・RFP・提案依頼書は、機能の列挙からではなく、現場ヒアリングでAsIsを可視化し、ToBeモデルを描くことから始めるのが鉄則です。そのうえで、直接材（BOM/MRP連動・多階層設変追従）と間接材（カタログ購買・承認ルート・支給品管理）の要件分岐を整理し、ERP連携のマスタ主管とデータ不整合を防ぐ要件、内部統制（J-SOX）・電帳法・インボイスの対応要件を詰めます。これらをRFPに目的・連携要件・体制要求・追加単価ルールまで明記すれば、ベンダーの提案を横並びで比較でき、導入形態別の相場（クラウド初期0〜数十万、オンプレ初期400〜500万、スクラッチ小規模300〜1,000万・中規模1,000〜3,000万：出典ripla）に照らして見積りの妥当性も判断できます。

安価なパッケージを入れたものの現場に定着せず追加費が膨らんだ失敗や、法令対応を後付けして2〜3倍のコストを払った失敗が示す通り、要件定義の質はそのままプロジェクトの成否に直結します。現場の業務実態と将来の法令を正確に映した要件こそが、現場に定着する資材管理システムを生みます。riplaはフルスクラッチ受託とAI駆動開発を組み合わせ、現場ヒアリングからToBeモデル作成、直接材・間接材・支給品の要件化、ERP連携設計、RFP作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社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を創業。