ECサイトやECシステムの構築では、RFP（提案依頼書）と要件定義が成否を最初に決めます。要件を固めれば、ベンダー選定の精度が上がり、追加費用や炎上のリスクも減らせます。
要件があいまいだと、A社とB社で見積金額が倍違っても理由がわからなくなります。EC構築の全体像をまだ把握していない方は、まずECサイト構築の完全ガイドから読むことをおすすめします。
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
要件定義の進め方ステップ
要件定義は、思いつきで機能を並べるのではなく、順序立てて進めることが成功の前提です。まず発注側が事業目的とKGI（重要目標達成指標）を定め、そこから逆算して必要な機能を洗い出します。最後に、それをRFPとしてまとめます。
この順序を守れば、「なんとなく便利そう」な機能に予算を取られず、目的に直結する要件に集中できます。
目的・KGIの設定
要件定義の出発点は、「何のためにECを作るのか」という事業目的を明確にすることです。新規の売上チャネルを作りたいのか、既存のアナログ受発注を効率化したいのか、リピート顧客を育てたいのかによって、必要な機能はまったく変わります。
目的を「年商1億円を目指す」「受注処理工数を月○時間削減する」といったKGIに落とし込むと、要件の優先順位が明確になります。
KGIを設定する際は、ECの利益構造を理解しておくと役立ちます。EC事業では「3:3:4の法則」（売上の30%が原価、30%が広告販促、40%がその他経費と利益）が一つの目安になります。物販ECの営業利益率は10〜20%とされます。
この構造を踏まえると、システムにいくら投資できるか、広告にいくら回すべきかが見えてきます。目的とKGIが定まって初めて、機能要件の議論が意味を持ちます。
- 事業目的：何のためにECを作るのかを、一文で言い切れるか
- KGI：年商や受注処理工数など、目的を数値で表せているか
As-IsとTo-Beモデルの作成
目的を定めたら、発注側は現状業務（As-Is）とあるべき姿（To-Be）を整理します。具体的には、現場担当者へのヒアリングで実際の業務フローを洗い出し、どこに無駄や手作業があるかを把握したうえで、システム化後の理想の流れを描きます。
As-IsとTo-Beの作成は、要件定義の質を決める最重要の工程です。ここを怠ると、致命的な失敗につながります。たとえば、1億円を投じたBtoBサイトが、現場ヒアリングとTo-Beモデルの作成を省いてベンダーに丸投げした結果、現場で使われず2年放置の末に廃止になった事例があります。
逆に、現場の業務を理解したうえで要件を整理すれば、現場が本当に使うシステムになります。とくにBtoBでは、掛売り・承認フロー・得意先別価格といった商習慣をTo-Beに織り込む必要があり、現場ヒアリングの精度がそのまま成否を分けます。
- 現状業務：現場担当者へのヒアリングで洗い出した業務フロー
- To-Be：掛売りや承認フローなど、自社の商習慣が織り込まれた理想の流れ
機能要件と非機能要件の洗い出し
要件は「機能要件」と「非機能要件」に分けて整理します。機能要件はカート・決済・在庫管理など「システムが何をするか」を、非機能要件は速度・セキュリティ・可用性など「どの品質で動くか」を表します。
発注側はつい機能要件に目が行きがちですが、非機能要件を軽視すると、リリース後に表示が遅い、障害が頻発するといった問題が起きます。
機能と非機能の両方を、バランスよく洗い出すことが重要です。
必須機能と任意機能の優先順位づけ
機能要件を洗い出したら、必ず「必須（Must）」と「任意（Want）」に分けます。
すべてを必須にすると見積もりが膨らみ、予算オーバーで頓挫します。
機能を詰め込みすぎるのは、要件定義の典型的な失敗パターンです。そのため、目的に直結しない機能は思い切って後回しにする判断が求められます。
たとえば、年商フェーズに応じて立ち上げ期は必須機能だけに絞り、拡大期に任意機能を足していくのが賢明です。
優先順位づけでは、ビジネスモデル固有の必須機能を見落とさないようにします。BtoBなら得意先別価格・掛売り・承認フロー、越境ECなら多言語・多通貨・海外配送が該当します。
定期購入ならフォーム一体型LP・ステップメール・LTV分析が、それぞれモデルの根幹を支える必須機能になります。これらをWant扱いにすると、そもそも事業が成立しません。
機能の優先順位は、自社のビジネスモデルから逆算して決めることが鉄則です。必要機能の全体像は、関連記事「ECサイト/システムの必要機能や標準機能の一覧について」で詳しく整理しています。
- 必須（Must）：目的に直結し、事業の成立に欠かせない機能
- 任意（Want）：立ち上げ後の拡大期に足していく機能
速度・セキュリティ・可用性の非機能要件
非機能要件は、ECサイトの信頼性を左右する要素です。表示速度は離脱率に直結し、ページが重いだけで売上を失います。
セキュリティは、顧客の個人情報やクレジットカード情報を扱う以上、外せない項目です。
可用性（サーバーが止まらないこと）も、セール時のアクセス集中で落ちないかどうかが売上を左右します。非機能要件を書き込んでおくと、ベンダーの提案を品質面でも比べられます。
SSL証明書は年1〜9万円、サーバーは年500〜10,000円から、計測基盤（GA4等）は5〜20万円が目安です。これらのインフラや運用のコストも、要件に含めて見積もりに反映させます。
ECサイトの寿命は3〜5年とされ、その間にセキュリティの脅威も変わっていきます。そのため、リリース後の保守や改修まで含めて非機能要件を考えることが、長く使えるシステムの条件です。
- セキュリティ：準拠するガイドラインと、最低限の水準
- インフラ・運用：SSL証明書、サーバー、計測基盤の費用
準拠先の例として、IPA（情報処理推進機構）が示すセキュリティガイドラインがあります。
RFPの作成とベンダー選定・見積もりの見方
要件が固まったら、RFP（提案依頼書）にまとめてベンダーに提示します。RFPは、各社に同じ条件で提案させるための共通の土俵です。そのため、RFPがあるかないかで提案の比較精度がまったく変わります。
RFPには、事業目的・予算・納期を盛り込みます。加えて、As-Is／To-Beや、必須と任意の機能、非機能要件を書き込み、評価基準も示します。曖昧なRFPには、曖昧な見積もりしか返ってこない点に注意が必要です。
RFPに盛り込むべき項目
ここまで整理した内容は、RFPに次の観点でまとめて書き込みます。
- 事業概要と目的：事業の概要と、KGI（達成したい数値目標）
- 現状業務とあるべき姿：As-Is（現状業務）とTo-Be（あるべき姿）
- 機能要件：必須・任意機能の一覧と優先順位
- 非機能要件：速度・セキュリティ・可用性
- 予算・納期・評価基準：予算の上限、希望納期、何を重視して発注先を決めるか
これらを明記すると、各社の提案を同じ観点で比べられ、優劣を判断する材料がそろいます。
とくに評価基準は、事前に明示しておくことが重要です。価格だけで選ぶのか、技術力や保守体制を重視するのかを決めておかないと、提案が出揃ったときに比較軸がぶれてしまいます。
RFPは発注側の意思を伝える文書です。ここに自社の優先順位を込めておけば、ベンダーも的を射た提案を返してくれます。
見積もりの妥当性とブラックボックスの解明
提案が出揃ったら、見積もりの妥当性を判断します。ここが発注側にとってもっとも難しい関門です。
同じ機能でもA社とB社で費用が倍違うことは珍しくなく、その理由を見抜く目が必要になります。
まず確認したいのは、「テスト・デバッグ費」や「ディレクション費」が一式でまとめられていないかどうかです。一式表記は内訳が見えないブラックボックスになりやすいため、内訳を分けて提示してもらいましょう。
判断の物差しになるのは、各項目の業界水準です。ディレクション・PM進行管理費は見積総額の約10%が目安で、UI/デザインは20〜150万円、フロント実装は20〜100万円です。SEO初期設計は10〜30万円で、テスト・検収は5〜15万円が相場です。
手法別の総額相場は、SaaSが50〜500万円、オープンソースが200〜1,000万円です。パッケージ初期は500〜5,000万円、フルスクラッチ初期は3,000万円〜とされます。これらと照らせば、提示額が妥当かどうかの当たりがつきます。
追加要件が発生したときの単価ルールは、契約前に取り決めておくことが大切です。
コンペでエース級が出ても、実開発が下請けに流れる構図を体制図の要求やPM面談で見抜くことが、炎上を避ける防衛策になります。
見積もりや契約で起きやすい失敗の詳細は、関連記事「ECサイト/システムの必要機能や標準機能の一覧について」とあわせて確認してください。
- 見積総額：手法ごとの相場に対する提示額の水準
- 体制：実際に開発を担う会社と担当者が、体制図で示されているか
まとめ
ECサイト/システムのRFP・要件定義は、「目的・KGI設定→As-Is／To-Be作成→機能要件と非機能要件の洗い出し→RFP作成→ベンダー選定」という順に進めることが成功の前提です。そのうえで、発注側が業務を言語化し、必須機能・非機能要件・評価基準を明記すれば、各社の提案を同じ土俵で比べられ、見積もりの妥当性も判断できます。
ディレクション約10%やUI/デザイン20〜150万円といった業界水準を知っておくことが、ブラックボックスを解く武器になります。
要件定義で大切なのは、「ベンダーに考えてもらう」ことではなく、「発注側が要件の骨格を持つ」ことです。具体的には、現場ヒアリングでTo-Beを描き、見積もりの内訳を業界水準と照らせば、1億円のサイトが廃止されるような大失敗は避けられます。
手間を惜しまず要件定義に投資することが、結果的に追加費用と炎上を防ぐ最良の保険です。
riplaはフルスクラッチ受託と国内開発を組み合わせ、発注側の商習慣に踏み込んだ要件整理を一貫して支援します。
全体像の確認には、あらためて完全ガイドをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。