通販サイト・通販システムの構築を外部のベンダーに依頼するとき、プロジェクトの成否を最も大きく左右するのが「要件定義」と、その前段で発注側がまとめるRFP（提案依頼書）です。どれほど技術力の高い開発会社に依頼しても、発注側が「何を作りたいのか」「どんな業務をシステム化したいのか」を言語化できていなければ、出来上がるのは現場で使われないシステムです。実際に、現場ヒアリングを怠ってベンダーに丸投げした結果、1億円もかけたBtoBサイトが2年放置の末に廃止された事例も報告されています。
本記事は、通販サイト・通販システムのRFP・要件定義書・提案依頼書の作り方を、発注する通販事業者の視点から実践的に解説します。要件定義をどう進めるか、機能要件と非機能要件の整理、RFPに盛り込むべき項目、そして見積のブラックボックスを見抜きベンダーを選定する判断軸まで、競合記事が手薄な「発注側が準備すべき最低限」を主軸に掘り下げます。読み終えるころには、ベンダーに丸投げせず、自社主導でプロジェクトを進めるための具体的な準備が見えてくるはずです。なお、通販サイト構築の全体像をまだ把握していない方は、まず通販サイト構築の完全ガイドから読むことをおすすめします。
要件定義の進め方ステップ
要件定義は、いきなり「どんな機能が欲しいか」をリストアップすることから始めてはいけません。まず「なぜ通販システムを作るのか」という目的と、達成したい数値目標（KGI）を定めることがすべての出発点です。目的が「業務効率化」なのか「新規売上の獲得」なのか「リプレイスによる老朽化対策」なのかで、必要な機能も投資すべき場所もまったく変わってきます。
目的・KGIの設定から始める
最初のステップは、事業として達成したいゴールを数値で定義することです。「3年後に通販事業で年商1億円」「受注処理にかかる人件費を年間4,000時間分削減」「ECサイトの寿命とされる3〜5年の間に投資を回収する」といった具体的な目標を立てます。ECサイトはトレンドやセキュリティの刷新が早く寿命が3〜5年とされるため、その期間内に投資を回収できる計画かどうかを、要件定義の段階で見極めておく必要があります。
目的とKGIが定まれば、必要な機能の優先順位が自ずと決まります。新規売上が目的なら集客・コンバージョン強化の機能を、業務効率化が目的なら受注・在庫・基幹連携を優先する、という具合です。逆にこの段階を飛ばすと、ベンダーから提案された機能を「あったら便利そう」という理由で次々に追加し、予算が膨らんだ末に肝心の目的を達成できない、という典型的な失敗に陥ります。要件定義は機能の足し算ではなく、目的からの引き算で考えるのが鉄則です。
現場ヒアリングとToBeモデルの作成
目的が定まったら、次は現状業務（AsIs）の棚卸しと、あるべき姿（ToBe）の設計です。これは要件定義の中で最も手間がかかる一方、最も重要な工程です。受注・在庫・出荷・顧客対応・経理といった各業務を、誰が・いつ・どんな手順で行っているかを現場担当者にヒアリングし、現状の課題とムダを洗い出します。そのうえで、システム化によってどう業務を変えたいか（ToBe）を描きます。
この工程を省いてベンダーに丸投げすると、深刻な失敗を招きます。前述の通り、現場ヒアリングとToBeモデルの作成を怠ったBtoBサイトは、1億円をかけたにもかかわらず現場で使われず、2年放置の末に廃止されました。教訓は明快で、システムの成否は技術力よりも「発注側が自社の業務をどれだけ精緻に整理できているか」で決まります。とくにBtoB通販では、得意先別価格・掛売り・承認フローといった独自の商習慣を、漏れなくToBeモデルに反映することが欠かせません。現場を巻き込んだ業務整理こそ、要件定義の核心です。
機能要件と非機能要件の整理
業務整理ができたら、それを「機能要件」と「非機能要件」という2つの軸で文書化します。機能要件はシステムが「何をするか」、非機能要件はシステムが「どんな品質を備えるか」を定めるものです。通販システムでは、機能要件ばかりに目が行き、非機能要件が抜け落ちることが多く、これが公開後のトラブルの温床になります。両方をバランスよく定義することが、安定したシステムへの第一歩です。
カート・決済・受注・在庫の機能要件
機能要件では、通販システムに必要なフロント機能（商品検索・カート・決済・会員）、バックオフィス機能（受注・在庫・出荷・商品登録・CRM・分析）、外部連携機能（ERP・WMS・POS・決済代行・配送・モール）を漏れなく洗い出します。重要なのは、自社のビジネスモデル固有の必須機能を取りこぼさないことです。定期購入ならフォーム一体型LPとステップメール自動化、BtoBなら得意先別価格・掛売り・承認フロー、越境なら多言語・多通貨・海外配送計算といった具合です。
機能要件を書く際のコツは、各機能に優先度をつけることです。「必須（Must）」「あると望ましい（Should）」「将来的に検討（Could）」と分類しておけば、予算オーバー時にどこを削るかの判断がスムーズになります。また、連携要件は特に詳細に記述すべきです。「自社の基幹システム（製品名・バージョン）と、どのデータを、どの頻度で連携するか」まで具体化しないと、後から「実は連携できなかった」という致命的な手戻りが発生します。連携をケチって手作業で1日100件超を手入力し崩壊した失敗事例を繰り返さないためにも、連携要件の精緻化が欠かせません。
速度・セキュリティ・可用性の非機能要件
非機能要件は、システムの品質を定める要件です。具体的には、表示速度（ページ読み込みが遅いとカゴ落ちが増える）、セキュリティ（個人情報・決済情報を扱うため最重要）、可用性（セール時のアクセス集中に耐えられるか）、拡張性（将来の機能追加や規模拡大に対応できるか）などが含まれます。通販システムは顧客の個人情報と決済情報を扱うため、セキュリティ要件は特に厳格に定める必要があります。
セキュリティ要件を定める際は、IPA（情報処理推進機構）が公開する安全なウェブサイトの作り方などのガイドラインを参照し、SQLインジェクションやクロスサイトスクリプティングといった代表的な脆弱性への対策を要件に含めることが推奨されます。可用性については、セールやテレビ放映直後のアクセス急増にどこまで耐えるかを定量的に示しておくと、ベンダーがインフラ構成を適切に提案できます。非機能要件を曖昧にすると、公開後に「セール中にサイトが落ちた」「情報漏洩が起きた」といった、事業を揺るがすトラブルにつながります。
RFP（提案依頼書）に盛り込む項目
RFP（提案依頼書）は、整理した要件をベンダーに伝え、各社から提案と見積を引き出すための文書です。RFPの質が、集まる提案の質と比較のしやすさを決めます。RFPが曖昧だと、各社が異なる前提で提案してくるため横並びで比較できず、見積も「念のため」の上乗せで膨らみます。逆に必要事項を漏れなく記したRFPを用意すれば、各社が同じ土俵で提案でき、適正な価格と内容で発注先を選べます。
事業背景・予算・納期・運用体制の記載
RFPに最低限盛り込むべき項目は、事業背景と目的、現状の課題、解決したいこと、必須機能と優先度、連携要件、想定予算と納期、そして公開後の運用体制と保守の要望です。とくに想定予算は、明記すべきか迷う発注担当者が多いものの、レンジ（範囲）でも示しておくほうが、各社が現実的な提案をしやすくなります。発注金額の平均は163.2万円・中央値100.0万円というデータがありますが、これは構築手法や規模で大きく変動するため、自社の目的に見合った予算感を持っておくことが大切です。
運用体制についても、RFPで明確に問うべきです。通販事業は「作って終わり」ではなく、公開後の運用にこそ継続的なコストがかかります。運用費の目安として「構築費用の3倍の年間運用費」あるいは「制作費と同額以上の運用予算」を想定すべきとされており、RFPの段階で保守費・改修費・サポート体制を確認しておかないと、公開後に想定外の費用に苦しむことになります。さらに、自社側で何人の体制（WEBディレクター・商品登録・CS）が必要かも、ベンダーに相談しながら見積もっておくと安心です。
検収基準・ソースコード帰属など契約面の防衛策
RFPと契約の段階で、後の揉めごとを防ぐ法務面の防衛策も盛り込んでおきましょう。代表的なのが、検収基準（何をもって完成とするか）、SLA（サービス品質保証）、ソースコードの帰属権（成果物の権利が自社に残るか）、追加要件が発生した場合の単価ルールです。これらを曖昧にしたまま発注すると、「完成したはずなのに動かない」「ソースコードをもらえず他社へ乗り換えられない」といったトラブルに発展します。
とくに注意したいのが、コンペでエース級の担当者がプレゼンに出てきて、実開発は技術力の低い下請けが担当する、というパターンです。実際に、プレゼン力だけで選定した結果、実開発部隊の技術力が低くリリース後に障害が多発して泥沼化した事例も報告されています。これを防ぐには、RFPで体制図の提出を求め、実際に開発を担当するPMやエンジニアとの面談を必須化することが有効です。誰が作るのかを契約前に確認することが、丸投げ失敗を防ぐ防衛策になります。
ベンダー選定と見積の見方
RFPを各社に渡して提案と見積が揃ったら、いよいよベンダー選定です。ここで多くの発注担当者がつまずくのが、見積のブラックボックス問題です。同じ要件を伝えたのに、A社とB社で費用が倍違う、ということは珍しくありません。その差がどこから来ているのかを見抜けないと、安さだけで選んで品質を落とすか、高さに惑わされて損をすることになります。見積の内訳を読み解く目を持つことが、適正な選定の前提です。
見積のブラックボックスを見抜く判断軸
見積の妥当性を判断するには、項目ごとの相場を知っておくことが武器になります。一般的な内訳として、UI・デザインは20〜150万円、フロント実装は20〜100万円、SEO初期設計は10〜30万円、GA4などの計測基盤は5〜20万円、テスト・検収は5〜15万円が目安です。そしてディレクション・PM進行管理費は見積総額の約10%が相場とされます。これらの相場から大きく外れた項目があれば、その理由をベンダーに質問しましょう。
とくに警戒すべきが「一式」でまとめられた見積です。「テスト・デバッグ費 一式」「ディレクション費 一式」のように、内訳が示されないまま大きな金額が計上されている場合は、その内訳と算出根拠を必ず確認します。また、追加要件が発生した際の人月単価や単価ルールを事前に取り決めておかないと、開発途中で「これは追加です」と次々に費用を上乗せされかねません。見積を読むときは、「なぜこの金額なのか」を一項目ずつ説明させ、ブラックボックスを残さないことが防衛策になります。
ランニングコストと補助金まで含めた総額判断
ベンダー選定では、初期費用だけでなくランニングコストを含めた総額で判断することが鉄則です。「ランニングコストが長期的に初期費用を上回る」のが通販システムの常識であり、月額利用料・決済手数料・サーバー代・保守改修費・広告費が継続的にかかります。とくにリプレイス案件では、データ移行・URLリダイレクト・パスワード再設定の告知などで、新規構築比20〜50%の追加費用が発生することがあるため、見積にこれらが含まれているかを確認しましょう。
補助金の活用を検討する場合も、要件定義・発注の段階で落とし穴に注意が必要です。「交付決定前の発注は補助対象外」になるルールや、「上限額と補助率の混同」（限度300万・補助率1/2の制度で400万円の事業を申請しても200万円しか出ない）といった誤解が、実際のトラブルとして報告されています。補助金ありきで予算を組む場合は、交付決定のタイミングと実際の補助額を正確に把握したうえで、要件と発注計画を立てることが欠かせません。要件定義から導かれる失敗の全体像は、関連記事の失敗・リスク解説で詳しく扱っています。
まとめ
通販サイト・通販システムの要件定義とRFP作成は、目的・KGIの設定から始め、現場ヒアリングでToBeモデルを描き、機能要件と非機能要件に落とし込み、RFPで各社の提案を引き出し、見積のブラックボックスを見抜いてベンダーを選ぶ、という一連の流れで進めます。この工程を発注側が主導できるかどうかが、現場に定着するシステムと、使われず廃止されるシステムの分かれ道です。1億円のサイトが廃止された事例が、その重みを物語っています。
要件定義で大切なのは、システムをベンダー任せにせず、自社の業務知識を総動員して「何を作りたいか」を言語化することです。ディレクション費は総額の約10%、リプレイスは新規比20〜50%の追加費用、運用費は構築費の3倍といった一次データを判断材料に、適正な発注を実現してください。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を創業。