BtoC通販・ECサイトの開発を外部に発注しようとするとき、成否の8割を決めると言われるのが、発注前の要件定義とRFP（提案依頼書）の準備です。要件があいまいなままベンダーに丸投げすると、見積もりは各社でバラバラになり、完成したサイトが現場で使われずに放置される、という最悪の結果を招きます。逆に、自社が何をしたいのか、どんな機能が必要で、どこまでの予算と期間で実現したいのかを言語化できていれば、ベンダー比較は正確になり、開発はスムーズに進みます。要件定義とRFPは、面倒な事務作業ではなく、プロジェクト成功への最重要投資なのです。
本記事は、BtoC通販・ECサイトのRFP・要件定義書・提案依頼書を、発注企業の視点から実務的に解説する「要件定義特化」の記事です。要件定義の進め方のステップ、機能要件と非機能要件の整理の仕方、RFPに盛り込むべき項目、そして見積もりのブラックボックスを見抜く方法まで、一次データとあわせて具体的に説明します。読み終えるころには、自社で要件定義の骨子を作り、ベンダーに正確に伝えられるようになるはずです。なお、BtoC EC構築の全体像をまだ把握していない方は、まずBtoC通販・EC構築の完全ガイドから読むことをおすすめします。
要件定義の進め方ステップ
要件定義は、思いついた機能を並べることから始めてはいけません。正しい順序は、まず「ECで何を達成したいのか」という事業目的を固め、それを数値目標（KGI）に落とし込み、そこから逆算して必要な機能を洗い出すことです。この順序を守ることで、目的に合わない過剰な機能を排し、本当に必要なものだけに予算を集中できます。BtoC ECでは、目的が「新規顧客の獲得」なのか「既存顧客のリピート化」なのか「業務効率化」なのかで、必要な機能はまったく変わってきます。
目的・KGI設定から始める
要件定義の第一歩は、目的とKGI（重要目標達成指標）の設定です。「ECサイトを作る」こと自体は目的ではなく、その先にある「年商をいくらにしたいのか」「どんな顧客に、いくらの商品を、年に何回買ってもらいたいのか」が本当の目的です。たとえば「3年で年商1億円、リピート率40%」といった具体的な数値目標を立てると、必要な集客規模、CVRの目標値、リピートを支えるCRM機能の要否が見えてきます。目的が数値で固まっていないと、ベンダーも何を提案すればよいか分からず、見積もりも的外れになります。
あわせて、目標年商に応じた投資の目安を持っておくと、予算設定がぶれません。年商3,000万円までなら50〜150万円、年商1億円までなら200〜500万円、年商3億円以上なら800万円以上が、システム投資の一つの目安とされています。この相場感を持って目的とKGIを設定すれば、「実現したい年商に対して、投資額が現実的か」を最初に検証でき、無理のない計画を立てられます。
現場ヒアリングとToBeモデルの作成
目的を固めたら、次は現場ヒアリングと、あるべき業務の姿（ToBeモデル）の作成です。BtoC ECでは、受注処理・在庫管理・出荷・問い合わせ対応といった日々の業務を、誰がどう回すのかを具体的に描く必要があります。この現場の業務フローを無視して要件を固めると、完成したシステムが現場の実態に合わず、使われなくなります。あるBtoB系の事例では、現場ヒアリングとToBeモデルの作成を怠ってベンダーに丸投げした結果、1億円かけたサイトが現場に使われず2年放置のうえ廃止になりました。この教訓はBtoC ECにもそのまま当てはまります。
現場ヒアリングでは、「いまどんな作業に時間がかかっているか」「どこでミスが起きやすいか」「将来どんな業務にしたいか」を、実際に手を動かす担当者から拾い上げます。そのうえで、新しいECサイトで実現したい理想の業務フロー（ToBeモデル）を描き、そこから必要な機能を逆算します。この現場起点のアプローチこそ、システムを「作って終わり」にせず「現場で使われる」ものにするための要諦です。要件定義に時間をかけることが、結果的に最も安く確実な投資になります。
機能要件と非機能要件の整理
要件は大きく、機能要件と非機能要件の2つに分けて整理します。機能要件は「何ができるか」を定義するもので、商品ページ・カート・決済・受注管理・CRMといった、これまで見てきた機能群がここに入ります。非機能要件は「どのくらいの品質で動くか」を定義するもので、速度・セキュリティ・可用性などが該当します。多くの発注者は機能要件には注意を払いますが、非機能要件を見落としがちです。しかしBtoC ECでは、非機能要件こそが消費者の信頼と売上に直結します。
BtoC ECに固有の機能要件
BtoC ECの機能要件は、消費者の購入体験を起点に整理します。集客面では、SEOに強いサイト構造やSNS・広告との連携、CVR面では多様な決済手段・かご落ち対策・ゲスト購入・レビュー表示、リピート面ではCRM・クーポン・ポイント、業務面では受注・在庫管理と将来の基幹連携、といった具合です。これらを「目的のどれに効くか」で紐づけて整理すると、目的に合わない機能を排せます。各機能について、必須なのか、あれば望ましいのか、将来でよいのかを優先順位づけしておくことが、予算配分とフェーズ分けの土台になります。
機能要件を書くときに注意したいのが、「曖昧な言葉で書かない」ことです。「使いやすい管理画面」「見やすい商品ページ」といった主観的な表現は、ベンダーによって解釈が分かれ、見積もりがブレる原因になります。「商品を一括登録できる」「在庫がゼロになったら自動で販売停止する」といった、誰が読んでも同じ動作を想像できる具体的な表現で書くことが、正確な見積もりと認識のズレ防止につながります。
速度・セキュリティ・可用性の非機能要件
非機能要件は、BtoC ECの信頼を支える土台です。第一に速度です。ページの表示が遅いと、せっかく集客した消費者が待ちきれずに離脱します。特にスマホで買い物をする消費者が多いBtoC ECでは、表示速度がそのままCVRに表れます。第二にセキュリティです。クレジットカード情報や個人情報を扱うため、情報漏洩は信頼の致命的な失墜につながります。IPA（情報処理推進機構）のガイドラインに準拠した対策を要件に含めることが、消費者の安心と事業継続の前提になります。
第三に可用性です。セールや人気商品の発売でアクセスが集中したときに、サイトが落ちてしまえば、最大の販売機会を逃します。想定される最大アクセス数に耐えられる設計を非機能要件に明記しておくことが重要です。これらの非機能要件は、目に見えにくいぶん見積もりから漏れやすく、後から「セキュリティ対策は別費用」と追加されるトラブルの温床にもなります。要件定義の段階で、速度・セキュリティ・可用性をどの水準で満たすかを明記し、見積もりに含めてもらうことが、後の揉め事を防ぎます。
RFP（提案依頼書）に盛り込む項目
RFP（提案依頼書）は、整理した要件をベンダーに伝え、提案と見積もりを依頼するための文書です。RFPの質が高いほど、各社から精度の高い提案が集まり、横並びで比較しやすくなります。逆にRFPが曖昧だと、各社が異なる前提で見積もるため、金額の比較ができず、ブラックボックスの中で発注先を選ぶことになります。RFPは、発注側が主導権を握ってプロジェクトを進めるための武器なのです。
RFPに必ず記載すべき項目
RFPに盛り込むべき項目は、おおむね決まっています。
・事業概要と背景：自社の事業内容、ECに取り組む背景、現状の課題
・目的とKGI：ECで達成したい数値目標
・機能要件：必要な機能とその優先順位
・非機能要件：速度・セキュリティ・可用性の水準
・予算と納期：想定予算の範囲と公開希望時期
・運用体制：公開後の保守・改修・サポートへの要望
・提案依頼事項：体制図、見積もり内訳、スケジュール、実績の提示要求
これらを漏れなく記載することで、ベンダーは自社の状況を正確に理解し、的確な提案を返せます。
特に重要なのが、「予算の範囲を伝えるかどうか」です。予算を隠すと各社が見当違いの規模で提案してくる一方、明示すれば予算内で最適な提案を引き出せます。また、「提案依頼事項」で体制図や見積もり内訳の提示を求めることは、後述するベンダー選定で下請け丸投げを見抜くための布石になります。RFPは単なる要望リストではなく、優良ベンダーを選び、見積もりを検証するための仕掛けを組み込んだ設計図と考えるべきです。
RFP作成でつまずかないコツ
RFPを初めて作る発注者がつまずきやすいのが、「完璧なRFPを作ろうとして手が止まる」ことです。すべての要件を細部まで固める必要はありません。重要なのは、目的・KGI・主要な機能要件・予算と納期・運用への要望という骨子を押さえることです。細部の仕様は、ベンダーとの対話の中で詰めていけばよく、むしろ初期段階でガチガチに固めすぎると、ベンダーの専門的な提案を引き出せなくなります。
もう一つのコツは、「自社の商習慣や特殊な業務フローを正直に書く」ことです。BtoC ECでも、独自のギフト対応、定期配送、特殊な送料計算などがあれば、それを隠さずRFPに書くことで、後から「想定外の要件」として追加費用が発生する事態を防げます。RFP作成に不安がある場合は、要件定義の段階から開発パートナーに伴走してもらうのも有効な選択肢です。riplaはフルスクラッチ受託と国内開発の知見をもって、現場ヒアリングから要件定義、RFP作成までを上流から支援しています。
ベンダー選定と見積もりの見方
要件定義とRFPが整ったら、いよいよベンダー選定と見積もりの検証です。ここで多くの発注者が直面するのが、「同じ要件なのに、A社とB社で費用が倍違う」という見積もりのブラックボックス問題です。なぜ差が出るのかを見抜き、見積もりの妥当性を判断できるかどうかが、適正価格での発注を左右します。RFPで提案依頼事項を明示しておけば、各社の見積もりを同じ土俵で比較できるようになります。
見積もりの内訳と妥当性の見抜き方
見積もりの妥当性を判断するには、内訳を分解して見る目が必要です。ECサイト構築の費用は、UI/デザイン（20〜150万円）、フロント実装（20〜100万円）、SEO初期設計（10〜30万円）、計測基盤（5〜20万円）、テスト・検収（5〜15万円）といった項目に分かれます。これに加えて、ディレクション/PM進行管理費は見積総額の約10%が目安です。これらの相場感を持っていれば、「テスト・デバッグ費」や「ディレクション費」が一式でまとめられている見積もりに対して、内訳の開示を求めることができます。
あわせて押さえておきたいのが、構築費だけでなくランニングコストの内訳です。ドメインは年500〜6,000円、サーバーは年500〜10,000円、SSLは年1〜9万円、撮影・データ登録（ささげ業務）は1点500〜2,000円が相場です。これらの運用コストを見積もりに含めず構築費だけを比較すると、公開後に想定外の費用が発生します。発注金額の平均が163.2万円、中央値が100.0万円という相場を念頭に、構築費と運用費の両面で見積もりの妥当性を検証することが大切です。
下請け丸投げを見抜く契約時の防衛策
ベンダー選定で警戒すべきが、「コンペにはエース級が出てくるが、実開発は技術力の低い下請けが担当する」というパターンです。あるケースでは、エース営業のプレゼンに惹かれて発注したものの、実開発部隊の技術力が低く、リリース後に障害が多発して泥沼化しました。これを防ぐには、RFPで体制図の提出を求め、実際に開発を担当するメンバーのスキルや、誰がプロジェクトマネージャーを務めるかを契約前に確認することが有効です。担当PMとの面談を必須にするのも防衛策になります。
契約時には、SLA（サービス品質保証）、検収基準、ソースコードの帰属権といった法務面の取り決めも欠かせません。特にソースコードの帰属は、将来別の会社に保守を引き継ぐときや、リプレイスするときに揉めやすいポイントです。これらを契約前に明文化しておくことで、後のトラブルを未然に防げます。要件定義からRFP、ベンダー選定、契約までを丁寧に進めることが、開発の失敗を避ける最大の防御策です。発注後に起こりがちな失敗や注意点については、後述の関連記事もあわせてご覧ください。
まとめ
BtoC通販・ECサイトの要件定義とRFPは、プロジェクト成功への最重要投資です。「目的・KGI設定→現場ヒアリングとToBeモデル→機能要件と非機能要件の整理→RFP作成→ベンダー選定」という順序を守り、目的を数値で固めてから逆算することが、過不足のない要件への近道です。発注金額の平均163.2万円・中央値100.0万円、ディレクション費は総額の約10%といった相場感を持って見積もりを検証すれば、ブラックボックスを見抜けます。
特に、現場ヒアリングを怠ったベンダー丸投げが1億円の廃止を招いた事例が示すように、上流の手間を惜しまないことが成功の鍵です。riplaはコンサルティングから開発まで一気通貫で支援できる立場から、現場起点の要件定義と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を創業。