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