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