BtoB全般の受発注をEC化する場合でも、通販・ECサイトの構築は、開発そのものより、その前段にあるRFP（提案依頼書）と要件定義書の質で成否が決まります。
なかでも商習慣をどう落とし込むかが、現場で使われるか放置されるかの分かれ目です。全体像はBtoB通販・EC構築の完全ガイドからご覧ください。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
BtoB通販/ECの要件定義の進め方
BtoB ECの要件定義は、まず目的と現場の実態を押さえてから、機能を並べる段階に進みます。最初にやるべきは、なぜEC化するのかという目的の言語化と、現場で実際に何が起きているかを把握する現場ヒアリングです。
この土台をつくらずに進めると、後述する1億円廃止事例のような結末を招きます。要件定義の前半にあたる目的設定とToBeモデル作成は、発注側が踏むべき順番に沿って進めます。
目的・KGI設定と現場ヒアリング
要件定義の出発点は、EC化によって何を達成したいのかを数値で定めることです。BtoBの受発注EC化でよく掲げられるKGI（重要目標達成指標）は、受注処理の工数削減や、電話・FAX・メールでの注文受付に伴うミスの削減です。
たとえば、受注処理1件あたり20分を削減でき、それが月1,000件発生していれば、年間で約4,000時間（20分×1,000件×12カ月）の削減になります。
この規模感を最初に算出しておくと、投資判断の物差しになります。さらに、要件の優先順位も明確になります。
目的を定めたら、次は現場ヒアリングに進みます。BtoBの受発注は営業担当・受注担当・経理・倉庫など複数の部署にまたがり、現場ごとに独自の運用が積み重なっています。
「この得意先だけは特別価格」「この金額を超えると部長承認が必要」「月末締めで請求をまとめる」といったルールは、現場の人には当たり前すぎて、ヒアリングしなければ表に出てきません。
実際に注文がどう流れているかを、最初の問い合わせから入金確認までの一連の業務として書き出すことが、要件定義の質を決めます。
- 目的：EC化で達成したい数値（工数削減、ミス削減など）を経営と決める
- 現場：部署ごとの業務の流れと、例外的な取り決めを集める
ヒアリングでは、現状の業務フロー（AsIs）を関係者全員で共有し、どこに無駄や属人化があるかを洗い出します。
ここでは、現場が困っていることと経営が解決したいことがずれていないかも確認します。たとえば、経営は工数削減を狙っていても、現場は誤発注の防止を最優先に考えている、というずれはよく起こります。そのため、両者を突き合わせて初めて、本当に作るべきシステムの輪郭が見えてきます。
ToBeモデル作成（1億円廃止事例の教訓）
現状（AsIs）を把握したら、次は「EC化後に業務はどう変わるべきか」というToBeモデルを描きます。これは、無駄な工程を省き、システムに任せられる部分を任せた理想の業務フローを設計する作業です。
ToBeモデルがあると、ベンダーは「何を作ればよいか」を正確に理解でき、発注側も完成形をイメージしながら要件を固められます。一方で、ここを省くと取り返しのつかない事態になります。
その典型が、ある企業で起きた1億円規模のBtoBサイトの失敗です。この案件では、現場ヒアリングとToBeモデルの作成を怠り、要件をベンダーに丸投げしてしまいました。その結果、できあがったサイトは現場の実務とかみ合わず、誰にも使われないまま2年間放置され、最終的に廃止されました。
1億円という投資が、要件定義という前段の数十分の一のコストを惜しんだためにまるごと無駄になったのです。これはBtoB EC構築において、要件定義を怠った最大の教訓と言えます。
- 業務フロー：無駄な工程を省いた、EC化後の理想の流れ
- 分担：システムに任せる部分と、人が担う部分
この事例が示すのは、要件定義は発注側が主導すべき仕事だということです。ベンダーは技術のプロですが、自社の商習慣や現場の事情を知っているのは発注側だけです。
ToBeモデルを描く過程で、現場と経営の認識を揃えます。そのうえで優先順位を決め、何を作って何を作らないかを判断します。この一連の合意形成が、丸投げを防ぎ、使われるシステムにつながります。
機能要件と非機能要件の整理
ToBeモデルが固まったら、それを「機能要件」と「非機能要件」という二つの観点で整理していきます。機能要件は「システムが何をできるか」、非機能要件は「どれだけ速く・安全に・止まらず動くか」を指します。
BtoB ECでは、この両方を漏れなく洗い出してRFPに落とすことが、見積の精度とシステムの実用性を左右します。とくにBtoB固有の機能要件は、BtoCの感覚で見積もると見込みが外れやすいので注意が必要です。
商習慣の落とし込み（得意先別価格・掛売り・承認フロー）
BtoB ECの機能要件で中核となるのは、商習慣の落とし込みです。代表例は「得意先別価格」です。BtoBでは同じ商品でも、取引先や取引量、契約条件によって価格が異なるのが当たり前です。
これをシステムで実現するには、得意先マスタと価格マスタを紐づけ、ログインした取引先ごとに専用の価格を表示する仕組みが要ります。
次に「掛売り（請求書払い）」です。BtoBでは、月末締め・翌月払いといった掛売りが主流で、注文のたびにクレジット決済するBtoCとは前提が違います。
これを実現するには、経理と連動する請求書発行などの機能が必要になります。BtoCの即時決済とは別の設計思想のため、ここを軽視すると、経理現場が結局Excelで二重管理することになりかねません。
発注側は、与信限度を超えた注文をどう扱うか（自動で止めるか、承認に回すか）まで要件に明記すべきです。
- 価格：取引先ごとの価格表、段階価格、特別価格の条件
- 決済：掛売りの締め日、与信限度額、入金消込との連携
数量に応じた価格や、キャンペーン期間中の価格まで考慮すると、価格ロジックは一気に複雑になります。
また、承認フローも要件として外せません。取引先の担当者が注文を入れても、一定金額以上は上長の承認が必要になるケースは珍しくありません。
発注者側だけでなく、自社側でも「与信判断」「特別価格の適用承認」といった社内承認が走ることがあります。これらの多段階承認をシステム化するには、誰が・いくらから・何段階で承認するかを定義しておく必要があります。
こうしたBtoB固有の機能があるため、同規模のBtoCサイトと比べて開発費用は30〜100%増えるのが実情です。費用感としては、小規模で300〜800万円、中規模で800〜2,000万円、ERP連携を伴う大規模では2,000万円以上が目安となります。
非機能要件（速度・セキュリティ・可用性とIPAガイドライン）
機能要件が「何をするか」なら、非機能要件は「どう動くべきか」です。BtoB ECでは取引先が業務として日常的に使うため、非機能要件を軽く見ると信用問題に直結します。第一に挙げられるのは速度です。
注文業務の最中にページ表示が遅いと、現場のストレスになり、結局は電話注文に逆戻りします。
第二はセキュリティです。BtoB ECは得意先別価格や取引履歴といった機密情報を扱うため、不正アクセスや情報漏洩は致命的です。
要件定義では、独立行政法人情報処理推進機構（IPA）が公開する安全なウェブサイトの作り方などのガイドラインに準拠することを明記しておくとよいでしょう（出典：IPA）。
SQLインジェクションやクロスサイトスクリプティングといった代表的な脆弱性への対策を、ベンダー任せにせず要件として求めることが、後のトラブルを防ぎます。
- 負荷：ピーク時の見積もりに耐える性能目標
- 脆弱性：IPAのガイドラインに沿った対策の明示
ピーク時間帯（たとえば月初や締め前）にどれだけのアクセスが集中するかを、あらかじめ見積もっておきます。
第三は可用性です。取引先が必要なときに使えなければ、業務が止まります。
どの時間帯にどれだけの稼働率を保証するか、障害時の復旧目標時間はどの程度か、定期メンテナンスはいつ行うかといった点を要件に含めます。
非機能要件は数値が見えにくく見積から漏れがちですが、明記しておかないと「動くけれど遅い」「ときどき落ちる」システムになり、せっかくのEC化が定着しません。
RFP段階で性能・セキュリティ・可用性の目標値を示すことが、各社の見積を正しく比較する前提になります。
RFP（提案依頼書）に盛り込む項目
機能要件・非機能要件が整理できたら、それらをRFP（提案依頼書）という一つの文書にまとめます。RFPは、複数のベンダーに同じ条件で提案と見積を依頼するための土台です。
RFPがあいまいだと、各社がバラバラの前提で見積を出してくるため、金額の比較ができず、結果として「安いけれど中身がスカスカ」の提案を選んでしまう危険があります。
RFPに必ず盛り込むべき項目と、リプレイス時に見落としがちな隠れ費用は、どちらも要件定義の段階で押さえておく必要があります。
RFPの必須項目と書き方
RFPに最低限盛り込むべき項目は、おおよそ次の七つです。
- 1. プロジェクトの目的・背景：なぜEC化するのか、解決したい課題は何か
2. KGI・KPI：受注処理の工数削減目標（例：年間約4,000時間削減）など数値目標を盛り込みます。
3. 機能要件：得意先別価格・掛売り・承認フロー・カート・決済など、優先度付きで列挙します。
4. 非機能要件：速度・セキュリティ（IPAガイドライン準拠）・可用性の目標値を定めます。
5. 既存システムとの連携：ERPや基幹システム、会計ソフトとの連携範囲を示します。
6. 予算とスケジュール：想定予算レンジと希望リリース時期を伝えます。
7. 提案・見積に求める形式：体制図・工数内訳・検収条件の明示を求めます。
RFPの項目をそろえることで、ベンダーは同じ前提で提案でき、発注側は横並びで比較できます。
書き方のコツは、機能を箇条書きで並べるだけでなく、それぞれに優先度（必須・推奨・任意）を付けることです。予算には上限があるため、すべてを一度に作るのは難しいものです。
「これがないと業務が回らない必須機能」と「あれば便利な任意機能」を切り分けておくと、ベンダーは段階的な開発計画を提案しやすくなり、発注側も予算に応じた取捨選択ができます。
優先度のないRFPは、結局「全部入り」の高額見積か、肝心な機能が抜けた安価見積を招きがちです。
RFPの段階で予算レンジを開示することにためらう発注者は多いですが、おおよその予算を伝えたほうが、現実的で精度の高い提案を引き出せます。
前述のとおり、BtoB ECの相場は、小規模で300〜800万円、中規模で800〜2,000万円、ERP連携を伴う大規模で2,000万円以上です。この幅のどこを狙うかをRFPで示すと、ベンダーは身の丈に合った提案を組み立てられ、見積の食い違いも防げます。
リプレイス時に要件化すべき隠れ費用
既存のBtoB ECや基幹システムを置き換えるリプレイス案件では、新規構築にはない「隠れ費用」が発生します。これをRFPで要件化しておかないと、後から想定外の追加費用が発生します。
代表的なのがデータ移行です。重複や誤りを整理するクレンジングだけでも相応の工数がかかり、しかも、データが汚れているほど移行コストは膨らみます。
次はURLリダイレクトです。既存サイトのURL構造が変わると、検索エンジンの評価や取引先のブックマークが切れてしまいます。旧URLから新URLへ正しく転送する設定を怠ると、アクセスできなくなった取引先からの問い合わせが殺到します。
さらに、リプレイスに伴いログイン情報を再設定する場合は、全取引先へのパスワード再設定の告知と、その後の問い合わせ対応も発生します。これらは地味ですが、確実に運用部門の負担になります。
- 移行：得意先マスタ、商品マスタ、取引履歴の形式変換と整理
- 告知：URLの転送設定、パスワード再設定の案内と問い合わせ対応
データ移行・URLリダイレクト・パスワード再設定告知といった作業は、新規構築と比べて20〜50%の追加費用がかかるのが目安です。
リプレイスのRFPでは、これらを「移行要件」として明記し、見積に含めるようベンダーに求めることが欠かせません。
要件化されていない隠れ費用は、プロジェクト終盤で発覚し、予算超過やスケジュール遅延の大きな原因になります。最初から費用を見える形にしておくことが、健全なリプレイスの条件です。
ベンダー選定と見積の見方
RFPを各社に渡して提案と見積を受け取ったら、いよいよベンダー選定です。この段階で大事なのは、見積の総額だけを見て一番安い会社を選ばないことです。
BtoB ECの見積はブラックボックスになりやすく、安さの裏には「必要な工程の省略」や「後からの追加請求」が潜んでいることがあります。発注側は、見積の内訳と体制、検収条件まで踏み込んで確認する目を持つ必要があります。
見積の見極め（PM費約10%など）
見積の妥当性を判断する第一歩は、内訳が機能・工程ごとに分解されているかを確認することです。「システム開発一式◯◯円」とだけ書かれた見積は、何にいくらかかるのかが分からず、比較も交渉もできません。
良い見積は、画面設計・機能開発・テスト・データ移行・ディレクションといった項目ごとに分けて示されています。これがあって初めて、どこに費用が偏っているか、削れる余地はどこかを判断できます。
とくに注目したいのが、ディレクション費（プロジェクトマネジメントの進行管理費）です。これは見積総額の約10%が一般的な目安です。
この項目がまったく計上されていない見積は、一見安く見えても、進行管理が手薄でトラブルが頻発するリスクをはらみます。逆に20%や30%と過大に計上されている場合は、その根拠を確認すべきです。
PM費の有無と水準からは、ベンダーがプロジェクトを本気で管理するつもりがあるかを読み取れます。
- 内訳：機能・工程ごとの工数（人日・人月）と単価
- PM費：計上の有無と、見積総額に対する割合
各社の見積を比較するときは、RFPで示した必須機能がすべて含まれているかを一つずつ照合します。
安い見積ほど、得意先別価格や承認フローといったBtoB固有の重い機能が「別途見積」として外されていることがあります。
前述のとおり、BtoB固有機能によってBtoCより30〜100%増えるのが普通です。そのため、極端に安い見積は、BtoBの難所を見落としているか、意図的に外している可能性を疑うべきです。
評価の基準は、総額の安さよりも、要件をどれだけ正確に拾えているかです。
体制図と検収基準による丸投げの防止
見積金額と並んで確認したいのが、開発体制図です。誰がプロジェクトを率い、何人のエンジニアがどの工程を担当するのか、再委託（下請け）はどこまで使うのかを、ベンダーに明示してもらいます。
BtoB ECは商習慣の理解が必須なため、体制の組み方が品質を左右します。営業担当だけが窓口で、実装は顔の見えない下請け任せ、という体制では、せっかく整理した要件が現場まで届きません。
もう一つ欠かせないのが検収基準です。何をもって「完成」とするかを、契約前に明文化しておきます。
「得意先別価格が正しく表示される」「承認フローが定義通り動く」「与信限度を超えた注文が止まる」といった、要件に対応した合否判定の基準を検収項目として定めます。
これがあいまいだと、ベンダーは「動いています」と言い、発注側は「使えません」と言う、水掛け論に陥ります。検収基準は要件定義の成果物がそのまま判定基準になるので、要件定義と一体です。
- 体制：要件を理解した担当者が、最後まで関わるかどうか
- 検収：要件ごとの合否を判定できる項目
体制図と検収基準を契約に組み込むことは、発注側にとって「丸投げの防止策」そのものです。前述の1億円廃止事例は、要件を丸投げしただけでなく、検収の基準もあいまいなまま進んだ結果でした。
誰が作り、何をもって完成とするかを発注側が握っておくことで、ベンダー任せになるのを防ぎ、使われるシステムにつなげられます。
riplaはフルスクラッチ受託と国内開発の立場から、要件定義から検収まで一貫して伴走し、発注側の要件を確実に形にすることを重視しています。
まとめ
BtoB通販/ECサイトの構築は、RFPと要件定義書の質で成否がほぼ決まります。
掛売り・得意先別価格・承認フロー・与信といった商習慣をいかに正確に要件へ落とすかが、現場で使われるシステムと放置されるシステムを分けます。
BtoB固有機能のために、同規模のBtoCより30〜100%費用が増えます。相場は小規模で300〜800万円、中規模で800〜2,000万円、大規模で2,000万円以上です。PM費は総額の約10%が目安で、これらを押さえておけば見積の妥当性も判断しやすくなります。
そして何より忘れてはならないのが、現場ヒアリングとToBeモデル作成を怠って丸投げした1億円のサイトが、2年放置のうえ廃止された教訓です。
要件定義は発注側が主導すべき仕事であり、AsIs整理・ToBeモデル・RFPという三つの文書をそろえることが、その第一歩になります。
受注処理の年間約4,000時間削減のような効果を着実に実現するためにも、まずは自社の業務を言語化することから始めてください。
riplaはフルスクラッチ受託と国内開発の立場から、要件整理の受け皿として伴走します。全体像の確認には、あらためて完全ガイドをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。