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