製造業向けの部品／資材の通販・ECサイトを開発するうえで、プロジェクトの成否をもっとも大きく左右するのが要件定義です。とくに部品・資材の調達ECは、取引先別単価・掛け率、企業間決済（掛売り）と与信、購買承認フロー、何万・何十万という品番（型番）マスタ、特注品の見積（RFQ）、生産管理システムや基幹システム（ERP/MRP）連携といった、調達現場の複雑な商習慣を抱えます。これをいかに正確に要件として整理し、RFP（提案依頼書）や要件定義書に落とし込めるかが、調達現場に使われるECになるか、使われず廃止になるかの分かれ目になります。実際、現場ヒアリングとToBeモデル作成を怠ってベンダーに丸投げした結果、1億円を投じたサイトが現場に使われず廃止された失敗が起きています。
本記事は、製造業向けの部品／資材通販・ECのRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。調達現場のヒアリングとAsIs/ToBeモデルの描き方、製造業特有の商習慣（取引先別単価・掛け率・掛売り・購買承認・型番マスタ）を要件に落とす方法、機能要件と非機能要件の整理、RFPに盛り込むべき項目、そして見積りの妥当性を判断する軸まで、部品・資材調達の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まず製造業向けの部品/資材通販/EC開発の完全ガイドから読むことをおすすめします。
調達現場のヒアリングとToBeモデルから始める進め方
製造業部品／資材ECの要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。出発点は、自社と取引先が今どのように部品・資材の受発注を処理しているかを徹底的にヒアリングし、可視化することです。部品・資材調達は、長年の慣行や取引先ごとの細かな取り決め、図面・部品表（BOM）に紐づく型番運用の積み重ねでできています。これを無視して理想論で機能を決めると、現場の実態と噛み合わないシステムができあがります。
AsIsの調達・受発注フローを可視化するヒアリング
最初に行うべきは、現状（AsIs）の業務フローを可視化するヒアリングです。受注担当者、営業、購買、生産管理、経理、倉庫といった関係者に、「取引先からどう注文が来るのか（FAX・電話・メール・営業経由）」「規格品と特注品で発注経路がどう違うのか」「それをどう基幹や生産管理に入力しているか」「在庫や納期、生産計画をどう確認しているか」「請求や入金消込はどう回しているか」を細かく聞き取ります。ここで重要なのは、マニュアルに書かれた建前ではなく、現場が実際に行っている運用や、属人的な例外処理まで拾うことです。
製造業の調達現場には、「この取引先だけは特別な協定単価で対応している」「急ぎの部品は電話で営業が直接処理し、納期も口頭で回答している」「廃番品はベテランが相当品・後継品を判断して案内している」といった、明文化されていない慣行が必ずあります。これらを見落とすと、ECに移行した途端に現場が回らなくなります。AsIsの可視化は地道な作業ですが、ここで現場の実態を正確につかむことが、後の要件の漏れを防ぎ、調達現場に使われるECを生む土台になります。
ToBeモデルで「あるべき調達業務の姿」を設計する
AsIsを可視化したら、次に描くのがToBeモデル、つまり「ECと連携システムを導入した後、あるべき調達業務の姿」です。FAX・電話で来ていた注文をECで受け、型番入力やクイックオーダーで受注処理を自動化し、在庫・納期を取引先が自分で確認できるようにする。規格品はそのままEC発注、特注品は見積（RFQ）フローに乗せる。この新しい業務フローを具体的に設計したうえで、それを実現するために必要な機能を逆算します。ToBeを描かずに機能だけ決めると、機能はあっても調達業務がつながらない、という事態に陥ります。
1億円のサイトが廃止になった失敗の本質は、まさにこのToBeモデルを描かずにベンダーへ丸投げした点にあります。調達担当者が日々どう発注し、何に困っているかを起点にせず、理想論だけでシステムを作った結果、現場は従来のFAX・電話に戻ってしまいました。逆に、ToBeを丁寧に描いた企業は、現場が「これはFAXより楽になる」と実感できるシステムを実現しています。要件定義の出発点をToBeモデルに置くことが、巨額の無駄遣いを避ける最大の防衛策です。こうした失敗の詳細は関連記事『製造業向けの部品/資材通販/EC開発/導入の失敗/課題/注意点/リスクについて』もあわせてご覧ください。
製造業の商習慣を機能要件に落とす方法
ToBeモデルを描いたら、いよいよ製造業特有の商習慣を具体的な機能要件に落とし込みます。ここが製造業部品／資材ECの要件定義でもっとも難しく、かつ最重要の工程です。取引先別単価・掛け率、掛売りと与信、購買承認フロー、そして膨大な型番マスタという商習慣は、ルールが複雑で例外も多いため、曖昧なまま要件にすると後で必ず手戻りが発生します。なお、これらの機能そのものの中身については関連記事『製造業向けの部品/資材通販/ECの必要機能や標準機能の一覧について』で詳しく解説しているため、本記事では「どう要件として言語化するか」に焦点を当てます。
取引先別単価・掛け率・掛売りルールの要件化
取引先別単価を要件化するには、自社の価格決定ルールをすべて棚卸しする必要があります。取引先区分（直需・代理店・特約店）別の掛け率はどうなっているか、個別協定単価を持つ取引先はどれか、数量別の段階値引き（ボリュームディスカウント）はあるか、相当品・後継品に切り替わった際の単価をどう引き継ぐか、キャンペーン価格や期間限定価格はどう扱うか。これらをひとつずつ言語化し、「どの取引先に、どの型番を、どの単価で見せるか」を明確に定義します。この価格ルールの定義が曖昧だと、「見せてはいけない取引先に他社の協定単価が表示される」という重大な事故につながります。
掛売り（請求書払い）についても、ルールを詳細に要件化します。取引先ごとの与信枠の設定方法、与信枠を超えた発注をどう制御するか（警告のみか、発注不可か、承認を求めるか）、締め日と支払いサイクル、請求書の発行タイミング、入金消込の方法などを定義します。掛売りは回収リスクに直結するため、与信と承認の制御を要件に明記することが欠かせません。取引先別単価・掛け率・掛売りのルールを漏れなく要件化できれば、製造業ECの中核は固まったと言えます。
購買承認フロー・型番マスタ・ERP連携の要件化
購買承認フローの要件化では、取引先企業側の承認と、自社側の承認の両方を整理します。取引先企業では、調達担当者の発注を購買責任者や予算管理者が承認してから正式発注になる二段階以上のフローや、予算枠・発注限度額との照合を求められることがあります。自社側でも、与信枠超過や特別価格の適用に上長承認が必要な場合があります。誰が、どの条件で、何を承認するのか、差し戻しはどう扱うのかを明確にし、承認の段階数や権限をすべて要件に記述します。購買統制を重視する製造業では、この承認フローの設計漏れが内部統制上の問題に直結します。
製造業ならではの難所が、膨大な型番マスタとERP/生産管理（MRP）連携の要件化です。型番マスタについては、品番・型番・図番の体系、規格・寸法・材質・公差・表面処理といったスペック項目、廃番・後継品・相当品の紐付けルール、図面の添付方法までを定義します。ERP連携では、既存の基幹システムや生産管理システムが何か、どのデータ（受注・在庫・出荷・請求・型番マスタ・所要量計画）を、どの方向に、どのタイミング（リアルタイムかバッチか）で連携するかを定めます。既存システムの仕様や連携可能なインターフェース（API・CSV・ファイル連携）を事前に把握しておかないと、ベンダーが見積りを出せません。連携は製造業ECの効果を最大化する一方、技術的難易度が高く費用もかさむため、要件定義の段階で連携範囲を明確にすることが、見積りの精度と妥当性判断を左右します。
機能要件と非機能要件の整理
要件定義書は、機能要件と非機能要件の両方を網羅する必要があります。機能要件は「何ができるか」、非機能要件は「どれだけの品質で動くか」を定めるものです。製造業部品／資材ECでは、機能要件に目が行きがちですが、何万・何十万という型番と多数の取引先を抱えるがゆえに、非機能要件もおろそかにできません。
機能要件を必須・優先・将来で分類する
機能要件は、ただ列挙するのではなく、優先度を付けて分類することが重要です。「これがないと調達業務が回らない」必須機能（取引先別単価・掛け率・掛売り・購買承認・型番検索とクイックオーダー・基幹連携）、「効果は大きいが初期になくても運用できる」優先機能、「将来追加でよい」機能の三段階に分けます。製造業部品ECは機能を盛り込むほど費用が膨らみ、同規模BtoCより30〜100%増となるため、この優先度付けが予算管理の生命線になります。
優先度を付けておくと、見積りが予算を超えた場合に、どの機能を初期リリースから外すかを冷静に判断できます。すべてを必須にしてしまうと、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。逆に優先度が明確なら、まず必須機能でリリースし、効果を見ながら優先機能を追加する段階的なリリース計画が立てられます。たとえば高度なレコメンドや3D CADによる自動見積などは「将来追加」に回し、まずは型番発注と取引先別単価、掛売り、基幹連携という調達の根幹だけで立ち上げる、という判断ができるのです。機能要件の分類は、要件定義書の中でも特に投資判断に直結する部分です。
非機能要件（性能・セキュリティ・可用性）
非機能要件では、性能・セキュリティ・可用性を定義します。性能は、何万・何十万という型番を抱える製造業ECで特に重要です。膨大な品番の中から型番・図番・スペックで瞬時に検索でき、多数の取引先が同時にアクセスしても表示が遅くならない、という性能要件を明記します。発注のピーク時間帯に型番検索が固まるようでは、調達担当者は使ってくれません。想定する品番数・取引先数・同時アクセス数を要件に記述することで、ベンダーは適切なインフラ構成を見積もれます。
セキュリティは、取引先別単価や与信、図面といった機密情報を扱う製造業ECでは極めて重要です。取引先ごとのデータが他社に見えないアクセス制御、通信の暗号化、図面ファイルの取り扱い、不正アクセス対策などを、IPA（情報処理推進機構）のガイドラインなどを参照しつつ要件化します。可用性については、受発注が止まると取引先の生産ラインにまで影響するため、稼働率の目標や、障害時の復旧時間、バックアップ体制を定めます。非機能要件を曖昧にすると、リリース後に「遅い」「止まる」「漏れる」というトラブルが起き、現場の信頼を一気に失います。機能要件と同じ熱量で非機能要件を詰めることが、製造業ECの品質を担保します。
RFPに盛り込む項目と見積り妥当性の判断
要件定義書がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。製造業部品ECは費用幅が大きいため、RFPで土俵を揃えることが、見積りの妥当性を判断する大前提になります。
RFPに必ず盛り込むべき項目
RFPには、最低限以下の項目を盛り込みます。プロジェクトの目的とKGI（受注処理時間の削減や調達リードタイムの短縮など）、現状（AsIs）と目指す姿（ToBe）の調達・受発注フロー、機能要件（必須・優先・将来の分類付き）、非機能要件（性能・セキュリティ・可用性）、既存システムとの連携要件（ERP・生産管理システム名・連携範囲）、予算とスケジュールの目安、そして開発・運用の体制要求です。製造業特有の商習慣（取引先別単価・掛け率・掛売り・購買承認・型番マスタ）は、RFPの機能要件の中核として具体的に記述します。
とくに見落とされがちなのが、体制要求です。「コンペにエース級の担当者が出てきたが、実際の開発は技術力の低い下請けが行い、リリース後に障害が多発した」という失敗事例があります。これを避けるには、RFPで体制図の提出を求め、誰が実際に開発するのか、PMは誰かを明記させることが有効です。あわせて、取引先別単価やERP連携を実装した製造業ECの実績を提案書に記載させると、実装力の実態が見えてきます。プレゼンの上手さではなく、実開発体制と実績を確認できる項目をRFPに盛り込むことが、ベンダー選定の防衛策になります。
見積りの妥当性を判断する軸
集まった見積りの妥当性を判断するには、まず相場観を持つことです。製造業部品ECの相場は、小規模で300〜800万円、中規模で800〜2,000万円、ERP・生産管理連携を含む大規模で2,000万円以上が目安です。同規模のBtoCより30〜100%高くなるのが通常で、この上乗せは取引先別単価・掛売り・購買承認・型番マスタ・連携といった製造業固有機能の作り込みによるものです。見積りがこの相場から大きく外れている場合は、その理由を確認します。安すぎる場合は製造業固有機能や連携が漏れている可能性、高すぎる場合は不要な要件が含まれている可能性があります。なお、構築手法ごとの費用や向き不向きの判断は、関連記事『製造業向けの部品/資材通販/EC開発/導入のメリット/デメリット/効果と判断基準について』もあわせてご覧ください。
次に、見積りの内訳を精査します。「テスト・デバッグ費」「ディレクション費」「連携開発費」が一式でまとめられている場合は、内訳の開示を求めます。機能ごと・工程ごとに工数と単価が示されていれば、どこにコストがかかっているかが見え、追加要件が発生したときの単価ルールも事前に取り決められます。要件定義書とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ず、ブラックボックスを解明しやすくなります。riplaはフルスクラッチ受託と国内開発の立場から、要件の透明な整理と、見積り内訳を明示する進め方を重視しています。要件定義の精度が、見積りの妥当性判断の精度を決めるのです。
まとめ
製造業向けの部品／資材通販・ECの要件定義・RFP・提案依頼書は、機能の列挙からではなく、調達現場のヒアリングでAsIsを可視化し、ToBeモデルを描くことから始めるのが鉄則です。そのうえで、取引先別単価・掛け率・掛売り・購買承認・型番マスタという製造業特有の商習慣を漏れなく機能要件に落とし、必須・優先・将来で分類し、非機能要件（性能・セキュリティ・可用性）も詰める。これらをRFPに目的・連携（ERP/生産管理）要件・体制要求まで明記すれば、ベンダーの提案を横並びで比較でき、相場（小規模300〜800万、中規模800〜2,000万、大規模2,000万〜：出典ripla）に照らして見積りの妥当性も判断できます。
1億円のサイトが廃止になった失敗が示す通り、要件定義の質はそのままプロジェクトの成否に直結します。調達業務の実態を正確に映した要件こそが、現場に使われるECを生みます。riplaはフルスクラッチ受託と国内開発を組み合わせ、調達現場のヒアリングからToBeモデル作成、商習慣の要件化、RFP作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。