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