定期購入・サブスクECのRFPと要件定義書は、事業目標からの逆算が成否を分けます。普通のネットショップであれば、「商品を並べて、カートで決済できればよい」と要件はシンプルですが、定期購入は違います。
定期購入では、毎月の自動課金や解約導線などを曖昧なままRFPに書くと、ベンダーごとに解釈がばらつき、見積もりを比べられません。また、完成後に「思っていた機能と違う」という事態を招きます。全体像が未把握の方は、まず定期購入・サブスクECの完全ガイドから読むことをおすすめします。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
事業目標から要件を逆算する進め方
定期購入ECの要件定義は、まず「この事業で何を達成したいのか」という目標を定めることから始めます。そこから必要な機能を逆算していくのが、正しい順番です。
定期購入は単発ECと利益構造が異なり、初回購入で赤字になっても、継続によって回収するモデルです。そのため、目標も「初月の売上」より「継続率」や「LTV」で設定する必要があります。目標設定が曖昧なまま要件定義に進むと、機能だけが立派でも、事業として成り立たないサイトができあがります。
継続率・LTVのKGI/KPIの定義
定期購入ECの要件定義の出発点は、KGI（重要目標達成指標）とKPI（重要業績評価指標）を定期購入の文脈で設定することです。これらのKGI/KPIが定まると、必要な機能が自ずと見えてきます。
RFPには、こうした事業目標を冒頭に明記し、その達成に必要な機能として要件を構成します。そうすることで、ベンダーは「なぜその機能が必要か」を理解した提案を返せるようになります。
要件に落とすときは、目標の数値と、その目標から出る機能を分けて書きます。
- 目標の数値：3回目継続率、6カ月継続率、LTV、LTV:CACの比率
- 目標から出る機能：ステップメール、解約前の休止・周期変更の提示、媒体別の分析
たとえば「3回目継続率を高める」という目標があれば、初回から定期へ引き上げる施策や、解約の前に続けやすい選択肢を示す導線が要件として浮かび上がります。「媒体別にLTVを最大化する」という目標があれば、広告媒体ごとに継続率とLTVを分析できることが必須要件になります。
ここでいうLTV（顧客生涯価値）とCAC（顧客獲得コスト）は、それぞれ顧客1人あたりの生涯価値と獲得コストです。
健全指標として「LTV:CAC=3:1以上」が知られています。顧客獲得コストの3倍以上の生涯価値を回収できてはじめて、ビジネスが成立します。さらに、CACは既存顧客の維持コストの約5倍高いため、新規獲得だけでなく継続率の目標設定も不可欠です。
現状業務とToBeモデルの言語化
事業目標を定めたら、次に現状の業務（As-Is）と、あるべき姿（To-Be）を言語化します。
定期購入ECでは、注文の受付や出荷指示、決済といった一連の運用フローが、毎月繰り返し発生します。さらに、問い合わせ対応や解約処理も、毎月続く業務です。
現状はどう回しているのか（手作業か、既存システムか）、新システムではどこを自動化したいのかを洗い出します。そうすると、必要な機能要件と外部連携要件がはっきりします。
現状の整理を怠ると、「うちの運用フローではこの機能は使えない」という手戻りが、後になって発生します。
To-Beモデルの作成は、発注側が主体になって行うべき作業です。ベンダーに丸投げすると、自社の商習慣や運用実態を反映しない一般論のシステムになりがちです。
定期購入特有の論点は、お届け周期をどこまで柔軟にするか、初回割引や回数縛りの条件をどう設計するか、解約時にどんな代替を提示するかです。
「与信失敗時の再試行を何日後に何回行うか」といった運用ルールは、発注側が業務の言葉で書き出しておくと、精度の高いRFPにつながります。
riplaは、フルスクラッチ受託と国内開発の立場から、As-IsとTo-Beの整理を発注側と一緒に進め、要件の抜け漏れを防ぐ支援を行っています。
As-IsとTo-Beの整理では、現状の把握と新システムの範囲を分けて考えます。
- 現状の把握：業務ごとの手作業と既存システムの区分
- 新システムの範囲：自動化したい箇所と、外部連携の要件
機能要件と非機能要件の洗い出し方
事業目標とTo-Beモデルが固まったら、それを機能要件と非機能要件に分解します。機能要件は「システムが何をするか」、非機能要件は「どれだけ速く・安全に・止まらず動くか」を定めるものです。
定期購入ECでは、毎月決済が走り、顧客のカード情報や個人情報を長期間扱うため、非機能要件、とくにセキュリティと可用性の重要度が単発ECより格段に高くなります。そのため、定期購入特有の要件は、機能と非機能のそれぞれで洗い出しておく必要があります。
定期購入固有の機能要件チェックリスト
定期購入ECの機能要件は、単発ECにはない固有の項目を漏らさず書き出すことが肝心です。
フロント側では、フォーム一体型LPや、初回割引・回数縛りの設定が必須です。
バックオフィス側では、自動継続課金と、与信失敗時の自動再試行が要件になります。与信に失敗した場合には、カード更新を依頼する通知も必要です。
解約導線では、休止・周期変更・数量減の代替を提示する仕組みが求められます。さらに、解約理由の収集も要件になります。
マーケティング側では、購入回数や経過日数に応じたステップメールの自動配信と、広告媒体別のLTV・継続率分析が欠かせません。
機能要件は、「実現したい」だけでなく「どこまで柔軟にしたいか」まで具体的に書きます。
たとえば、「毎月・隔月・3カ月ごとの3パターンから、顧客がマイページで周期を選べる」や「初回のみ50%オフ、2回目以降は10%オフ」といったレベルです。「3回目までは解約不可」のような条件まで書いてはじめて、ベンダーは正確に見積もれます。
一方で、曖昧な要件は見積もりのブレを生み、後から追加費用がかかる原因になります。なお、これらの要件を機能としてどう実装するかは、機能の詳細を扱った関連記事もあわせてご覧ください。
機能要件は、顧客が操作するものと運営側で動くものに分けて確認します。
- 顧客が操作する機能：マイページでの周期・数量・お届け日・配送先・決済方法の変更、解約時の代替の選択
- 運営側で設定・運用する機能：初回割引と回数縛り、自動継続課金、与信失敗時の再試行、ステップメール、媒体別の分析
決済の堅牢性・個人情報保護の非機能要件
定期購入ECの非機能要件で最も重要なのは、決済の堅牢性とセキュリティです。毎月自動で決済が走るため、二重請求や決済漏れが起きない正確さが求められます。
定期購入では、可用性も欠かせません。特に、決済日にシステムが止まると、その月の売上を丸ごと取りこぼします。
継続会員が増えるほどデータ量と決済件数も増えるため、将来の会員数増加に耐えるスケーラビリティも要件に含めるべきです。
これらの非機能要件は、IPA（情報処理推進機構）の非機能要求グレードなどを参考に定めます。そのうえで、定期購入の決済とセキュリティの重みを反映することが、トラブルを未然に防ぐうえで欠かせません。
非機能要件は、決済・個人情報と、稼働・拡張の観点で押さえます。
- 決済・個人情報：非保持化、PCI DSSへの準拠、個人情報保護の体制
- 稼働・拡張：稼働率、障害時の復旧時間、バックアップ、スケーラビリティ
継続会員のカード情報を長期間扱うため、決済代行会社のトークンを用いて、カード情報を自社で保持しない非保持化が必要です。また、目標とする稼働率は、たとえば99.9%以上のように数値で示します。
PCI DSS（クレジットカード業界のセキュリティ基準）と、カード情報・個人情報の保護を欠くと、情報漏えいの際に事業継続が困難になるほどの損害を被ります。
RFP（提案依頼書）に盛り込むべき項目
機能要件と非機能要件が固まったら、それらをRFP（提案依頼書）としてまとめ、ベンダーに提案を依頼します。
RFPは機能の一覧にとどめず、ベンダーが自社の事業を理解して最適な構成と見積もりを返せる情報まで盛り込むことが大切です。定期購入ECのRFPには、一般的なEC案件にはない固有の項目も必ず含める必要があります。
移行時の会員資産引き継ぎの要件
定期購入ECのRFPで特に見落とされやすいのが、既存システムからの移行（リプレイス）時の「会員資産の引き継ぎ」要件です。定期購入には、単発ECにはない致命的な難所があります。
移行時の会員資産の引き継ぎは、定期購入ECのリプレイスで最大のリスクになるため、RFPの段階で要件として明確に書いておく必要があります。
データ移行やURLリダイレクト、再登録の告知といった隠れコストは、新規構築と比べて20〜50%の追加費用になることもあります。そのため、見積もりに含めるよう明示しておくと、後のトラブルを防げます。
移行では、決済トークンと会員資産を分けて要件にします。
- 決済トークン：引き継ぎの可否と、引き継げない場合の再登録の進め方
- 会員資産：会員データ、購入履歴、定期スケジュール、ポイント残高の扱い
継続会員のクレジットカード情報（決済トークン）は決済代行会社に紐づいているため、別システムへそのまま移せないことが多くあります。さらに、移行時に顧客へカードの再登録を求めると、その手間を嫌った継続会員が大量に解約してしまうのです。
そのため、現行と同じ決済代行を新システムでも使えるかを明記し、移行期間中に新旧システムを並行稼働させるかどうかも含めて、移行方式の提案をベンダーに求めます。会員への依頼の設計と離脱の抑え方も、その提案に含めてもらいます。
運用体制・保守範囲・連携の明記
RFPには、構築だけでなく公開後の運用体制と保守範囲を明記することが欠かせません。
定期購入ECは、公開したあとも、継続率の改善やステップメールの調整、解約導線の見直しを運用で回し続けるモデルです。
運用費の目安としては、「構築費用の3倍の年間運用費」か、「制作費と同額以上の運用予算」を想定すべきとされています。だからこそ、RFPの段階で保守・改修の範囲と費用を確認しておくべきです。
決済代行・基幹・物流など外部システムとの連携範囲も要件に含めます。障害時のサポート体制と改修の対応スピードも、あわせて書いておきます。
riplaは、フルスクラッチ受託と国内開発の立場から、RFPの項目立てを発注側と一緒に整理し、移行リスクや運用体制まで含めた精度の高い提案依頼書づくりを支援しています。
RFPでは、体制・実績・条件と、保守・連携を分けて書きます。
- 体制・実績・条件：開発メンバーの担当範囲、定期通販の構築実績、予算とスケジュール
- 保守・連携：保守・改修の範囲と費用、外部システムとの連携範囲、障害時のサポート
体制図は、提案に出てくるエース級のメンバーが実開発でも担当するのか、下請けに丸投げされないのかを見抜く材料になります。定期購入は決済と継続率という繊細な領域を扱うため、この領域での実績があるかどうかも、ベンダーを選ぶうえで重要な判断材料です。
まとめ
定期購入・サブスクECのRFPと要件定義で成否を分けるのは、「継続率とLTVという事業目標から要件を逆算する」ことです。KGI/KPIを定期購入の文脈で定め、As-IsとTo-Beを言語化したうえで、固有の機能要件と非機能要件を漏れなく書き出します。
機能要件では、自動継続課金や与信再試行、解約導線を押さえます。加えて、媒体別LTV分析も外せません。非機能要件では、決済の堅牢性とカード情報保護が欠かせません。
発注側が移行時の会員資産引き継ぎと運用体制をRFPに明記すると、ベンダーから精度の高い提案を引き出せます。
要件定義で大切なのは、機能を一覧にすることよりも、事業目標から逆算する視点です。とくに移行時の決済トークン引き継ぎは、軽視すると継続会員の大量解約という致命傷になります。
要件を具体的に書き込むほど、見積もりの精度は上がり、専用カートか独自開発かの判断もはっきりします。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、事業目標から逆算した要件整理、RFP作成、見積もりの妥当性の判断を、発注側の伴走者として支援しています。
全体像を確認するには、あらためて定期購入・サブスクECの完全ガイドをご活用ください。
▼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を創業。