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