サブスクリプション管理システムの開発や導入を外部のベンダーに依頼するとき、成否を分けるのが要件定義とRFP（提案依頼書）の質です。継続課金ビジネスは、決済を回すだけでなく、解約防止、収益認識、セキュリティ、外部連携といった複数の論点が絡み合います。これらをRFPで曖昧にしたまま発注すると、見積りがベンダーごとにバラバラになり、開発が始まってから「その機能は要件に入っていなかった」という認識のズレが噴出します。
本記事は、サブスクリプション管理システムのRFP・要件定義書・提案依頼書をどう書くべきかを、発注企業の視点から整理する「要件定義特化」の解説です。非保持化アーキテクチャの要件、収益認識・会計連携の要件、SLA（稼働率99.99%）やチャージバック負担の契約条項、データポータビリティ（トークン移行）の要件化まで、RFPに盛り込むべき項目を具体的に掘り下げます。なお、継続課金ビジネス全体の設計をまだ把握していない方は、まずサブスクリプション管理システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・サブスクリプション管理システムの完全ガイド
RFPに盛り込むべき基本構成と前提
RFPは、ベンダーに「何を作ってほしいか」を正確に伝え、各社から比較可能な提案を引き出すための文書です。サブスクリプション管理システムのRFPでは、事業背景と目的、対象となる課金モデル、必須機能と任意機能の切り分け、予算と納期、評価基準を明記することが基本です。ここを曖昧にすると、提案の前提がベンダーごとに食い違い、正しい比較ができなくなります。
課金モデルと業務フローの要件を言語化する
RFPでまず固めるべきは、自社の課金モデルの定義です。月額・年額の周期、従量課金の有無、トライアル期間、プラン変更時の日割り計算（プロレーション）、休会の扱いなど、課金に関わる業務ルールを言語化します。ここを「サブスクの一般的な機能で」と丸投げすると、ベンダーは標準機能の範囲で見積もり、後から自社固有のルールが要件に追加されて、追加費用と納期遅延を招きます。
あわせて、現状（AsIs）の業務フローと、あるべき姿（ToBe）の業務フローを整理しておくと、RFPの説得力が増します。今どんな手作業が発生していて、新システムで何を自動化したいのかを示せば、ベンダーは課題に即した提案をしやすくなります。継続課金スクラッチ開発は、都度課金のみの場合より開発費が1.5〜2倍かかるのが相場です。だからこそ、課金モデルの要件を精緻に言語化し、見積りの前提をそろえることが、後の手戻りとコスト膨張を防ぐ第一歩になります。
規模感の目安として、決済・課金システムのスクラッチ開発費は、シンプルなもので50〜200万円、複数手段やAPI連携、管理画面を備えた中規模で150〜400万円、サブスク・多通貨・外部連携を伴う大規模で300〜500万円以上、フルスクラッチなら500〜2,000万円超に達します。RFPでは、こうした相場観を踏まえて予算レンジを示し、その範囲で何を優先するかを伝えると、現実的な提案を引き出せます。予算を一切示さずに「最適な提案を」と依頼すると、ベンダーは規模感をつかめず、提案がぼやけてしまいます。
必須機能と任意機能を切り分けて優先度を示す
RFPでは、機能要件を「必須（Must）」「推奨（Should）」「任意（Could）」のように優先度づけして示すことが重要です。すべてを必須にすると見積りが膨らみ、すべてを曖昧にすると提案の質が下がります。サブスク管理システムでは、継続課金、洗替・ダニング、非保持化、収益認識といった売上と信頼性に直結する機能を必須に置き、分析やポイント連携などは段階導入の任意機能として整理するのが現実的です。
優先度を示すことには、予算に応じてスコープを調整できるという実務的なメリットもあります。ベンダーは必須機能だけのミニマム構成と、推奨機能まで含めたフル構成の二段階で提案でき、発注側は予算と効果を見比べて意思決定できます。RFPで優先度を明確にすることは、単なる機能の羅列ではなく、限られた予算で最大の効果を得るための戦略的な設計図を示すことだと言えます。
非保持化・セキュリティの要件化
サブスクリプションはカード情報を継続的に扱うため、セキュリティ要件はRFPの中でもとくに厳密に書く必要があります。曖昧な「セキュリティに配慮すること」では不十分で、非保持化のアーキテクチャ、PCI DSSへの準拠範囲、3Dセキュアの対応を、具体的な要件として明文化します。ここを要件化しておくと、見積りの前提がそろい、後からセキュリティ対応の追加費用が発生する事態を防げます。
非保持化アーキテクチャを要件に明記する
RFPには、カード番号を自社システムで保持しない非保持化のアーキテクチャを採用することを、明確な要件として記載すべきです。非保持化により、PCI DSSという国際的なセキュリティ基準への準拠範囲を縮小でき、開発・セキュリティコストを50〜70%削減できるとされます。逆に、非保持化を要件に入れずに進めると、後から準拠範囲が広がり、PCI DSS対応のコンサル数十万〜数百万円、QSA審査年間数百万円規模といった想定外のコストが発生します。
要件として記載する際は、トークン化の方式、決済代行との連携方法、カード情報がどの経路を通るか（通過型か非通過型か）まで踏み込むと精度が上がります。継続課金では、トークンを使って毎月の自動課金を回すため、トークンの保管と管理をどう設計するかが、セキュリティ要件の中核になります。非保持化を要件化することは、セキュリティとコストの両面で、プロジェクト全体の前提を健全に保つ意味があります。
3Dセキュア・チャージバック対応を要件化する
3Dセキュアの対応も、RFPで明示すべき要件です。EMV 3-Dセキュア2.xは2025年3月末で原則義務化されており、対応していないとカード決済が使えなくなる可能性があります。RFPには、3Dセキュア2.xへの準拠と、リスクベース認証によって低リスク取引では認証を省略する設計を要件として盛り込みます。これにより、セキュリティと顧客体験を両立させた提案を引き出せます。
あわせて、チャージバック（不正利用による売上取消）への対応も要件化が必要です。AIによる不正検知の有無、ディスピュート（異議申立）への証拠提出フロー、チャージバック率が一定水準（例として0.9%超）を超えた場合の対応方針を、RFPで問うべきです。チャージバック率の超過は、決済代行からの違約金や決済停止につながるため、誰がどう対応し、その負担を誰が負うのかを契約条項として明確にしておくことが、後のトラブルを防ぎます。
収益認識・会計連携の要件定義
サブスクリプションのRFPで、競合があまり踏み込まないのに最も差がつくのが、収益認識と会計連携の要件です。年額一括で受け取った代金を、サービス提供期間にわたって月割りで売上計上する処理を、システムでどう実現するかを要件化します。ここを曖昧にすると、運用開始後に経理が手作業で按分し続けることになり、決算の遅延とミスを招きます。
前受金・売上振替の要件を定義する
収益認識の要件では、前受金（繰延収益）の計上と、月次での売上振替をシステムでどう自動化するかを定義します。新収益認識基準への対応、総額表示と純額表示の処理、途中解約時の残期間分の前受金取り消しと戻し仕訳まで、シナリオを具体的に書き出すことが重要です。とくに、年額プランを途中解約した場合の返金と会計処理は、手作業ではミスが起きやすいため、システムで自動化する要件として明記します。
要件定義の段階で、自社の会計方針や監査対応の要求を整理しておくと、後の手戻りを防げます。どの勘定科目に、どのタイミングで、いくら計上するのかというルールを、経理部門と合意してからRFPに落とし込むことが大切です。収益認識の要件は、決済機能の要件以上に自社固有の論点が多いため、ベンダー任せにせず、自社主導で言語化する姿勢が求められます。
この収益認識まわりは、多くの決済システム解説で手薄になっている領域です。だからこそ、RFPで丁寧に要件化できると、競合製品との差別化を図りつつ、自社の管理部門の生産性を大きく引き上げられます。要件定義の段階で経理・財務部門を巻き込み、月次・四半期・年次のどのタイミングでどんな帳票が必要かまで具体化しておくと、開発後に「決算で使えない」という致命的な手戻りを避けられます。収益認識は、開発の終盤ではなく、要件定義の初期から設計に織り込むべき論点です。
会計・基幹システムとのAPI連携要件
収益認識を自動化するには、課金データを会計システムや基幹システムへAPIで連携する要件が欠かせません。RFPには、連携先のシステム名とバージョン、連携するデータ項目、連携の頻度（リアルタイムかバッチか）、入金消込の自動化範囲を具体的に記載します。連携先のAPI仕様を事前に確認しておくと、ベンダーは実装の難易度を正確に見積もれます。
API連携の要件では、エラー時のリカバリーも定義しておくべきです。連携が一時的に失敗した場合に、データの整合性をどう担保し、再送をどう行うかを要件化しておかないと、運用後にデータ不整合のトラブルが起きます。決済トランザクションのデータと会計データを突き合わせる入金消込の自動化は、月次決算の早期化に直結する要件です。連携要件を精緻に書くことは、運用フェーズの安定性を設計段階で確保する意味を持ちます。
SLA・契約条項とデータポータビリティの要件
サブスクリプションは決済が止まると売上が止まるため、稼働率を保証するSLAと、将来の乗り換えを見据えたデータポータビリティの要件が、RFPの締めくくりとして重要です。これらは機能要件ではなく、非機能要件・契約条項として書く必要があります。ここを軽視すると、運用後の障害対応や、ベンダーロックインのリスクに直面します。
稼働率SLAと保守体制の要件
SLA（サービス品質保証）では、稼働率の目標水準を要件として明記します。決済システムの業界水準は稼働率99.99%以上、つまり月間ダウンタイム4.3分以下です。RFPには、目標稼働率、障害発生時の復旧目標時間、サポートの対応時間帯、未達の場合のペナルティを盛り込みます。定期課金日に決済が集中するサブスクでは、その集中タイミングでの安定性が特に重要になるため、その点も要件に含めると良いでしょう。
あわせて、保守・運用の体制と費用も要件化します。保守費は初期開発費の月5〜10%が相場で、初期500万円なら月25〜50万円が目安です。RFPでは、保守の範囲（障害対応、機能改修、問い合わせ対応）、対応窓口、エスカレーションのフローを問います。エンジニアの人月単価は60〜100万円、セキュリティやアーキテクトは120〜200万円が目安であり、こうした単価感を踏まえて見積りの妥当性を判断できるようにしておくことが大切です。
データポータビリティ・トークン移行の契約条項
見落とされがちですが、極めて重要なのがデータポータビリティの要件です。将来、別の決済代行やシステムへ乗り換える際に、顧客データやトークン情報を外部へ持ち出せるかどうかが、ベンダーロックインを避ける鍵になります。RFPには、契約終了時のデータ提供義務、提供フォーマット、トークン移行の可否を契約条項として明記すべきです。トークンが移行できないと、乗り換え時に全顧客にカードの再登録を求めることになり、大量の離脱を招きます。
あわせて、隠れコストや違約金の条項も、要件定義の段階で確認しておきます。取消手数料、オプション課金、中途解約時の違約金などが後から判明すると、総コストが想定を超えます。トランザクション費用は1回数円〜数十円、振込手数料は無料〜数百円といった周辺コストも、RFPで内訳を問うておくべきです。データポータビリティと隠れコストの要件化は、契約後の自由度を守り、長期的な総コストを健全に保つための、発注側が主導すべき交渉ポイントです。
提案評価とベンダー選定の基準づくり
RFPを出した後に控えているのが、各社からの提案を評価し、発注先を選定するプロセスです。ここで評価基準が曖昧だと、価格の安さだけで選んでしまい、後から要件を満たせないと判明する失敗に陥ります。RFPの段階で評価軸と配点を設計しておくことが、論理的で説明可能なベンダー選定につながります。
評価軸と配点を事前に設計する
提案を比較するには、評価軸を事前に定義しておく必要があります。機能要件の充足度、非保持化やSLAといった非機能要件への対応、継続課金やサブスク領域の実績、保守体制、そして総コストといった軸を立て、それぞれに重みづけ（配点）を設定します。価格だけに偏らず、解約防止や収益認識といった自社が重視する論点に高い配点を置くことで、本質的に必要な提案を選べます。
評価軸を数値化しておくと、社内の稟議や経営層への説明もスムーズになります。なぜこのベンダーを選んだのかを、配点の根拠とともに示せれば、意思決定の透明性が高まります。サブスク管理システムは長期にわたって事業の根幹を支えるため、初期費用の安さより、継続課金特有の論点への理解と実績を重く見る評価設計が、結果的に総コストを抑えることにつながります。
提案で確認すべき質問とPoCの設計
RFPには、ベンダーに答えてもらいたい具体的な質問リストを盛り込むと、提案の深さを見極められます。たとえば「インボランタリーチャーン対策として洗替・ダニングをどう実装するか」「収益認識の途中解約シナリオをどう自動化するか」「トークン移行は技術的に可能か」といった、継続課金の急所を突く質問を用意します。これらへの回答の具体性が、ベンダーの実力を測る指標になります。
大規模な開発では、本契約の前にPoC（概念実証）や要件定義フェーズを切り出し、小さく検証してから本開発に進む設計も有効です。決済代行との連携や、既存の会計システムとのAPI連携が想定どおり動くかを先に確かめておけば、本開発での手戻りリスクを減らせます。RFPの段階で、こうした段階的な進め方を許容するかどうかを示しておくと、堅実なベンダーほど現実的な提案を返してくれます。要件定義は一度書いて終わりではなく、提案評価と検証を通じて精度を高めていくプロセスだと捉えることが大切です。
まとめ
サブスクリプション管理システムのRFP・要件定義を整理すると、課金モデルと業務フローの言語化を土台に、非保持化・3Dセキュア・チャージバックのセキュリティ要件、前受金・売上振替・API連携の収益認識要件、そしてSLA・保守・データポータビリティの非機能要件と契約条項を、漏れなく書き込むことが成否を分けます。とくに、競合があまり踏み込まない収益認識の自動化と、ベンダーロックインを避けるトークン移行の要件化は、発注側が主導して書くべき差別化のポイントです。
RFPを書くときに大切なのは、機能を網羅することではなく、自社固有の課金ルール・会計方針・運用体制を起点に、譲れない要件と段階導入できる要件を切り分けることです。要件が曖昧なまま発注すると、見積りがそろわず、開発後に認識のズレが噴出します。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を創業。