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