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