クーポン発行システムの成否は、技術力や予算よりも、要件定義書とRFP（提案依頼書）をどこまで的確に書けたかで決まります。クーポンは、割引率や配信といった目に見える部分だけでは成り立ちません。併用制御のルールや不正対策、会員・ポイント・決済との連携まで要件に含める必要があります。さらに、会計上の計上方法も要件として明確にしておきます。
RFPに書くべき要件は、割引と併用のルール、SLAや不正対策、周辺システムとの連携、契約条件の四つです。費用相場や選び方をまだ把握していない方は、まずクーポン発行システムの完全ガイドから読むのがおすすめです。
▼全体ガイドの記事
・クーポン発行システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
機能要件として定義すべき割引・併用ルール
RFPの機能要件で最初に詰めるべきは、クーポンの割引ルールと併用ルールです。ここが曖昧なまま開発に進むと、リリース後に「想定した割引が組めない」「併用してはいけない組み合わせが通ってしまう」といった致命的なトラブルが起きます。だからこそ、自社の販促で使う割引のパターンを洗い出し、要件として明文化しておくことが、手戻りを防ぐ第一歩になります。
割引タイプと適用条件の網羅的な列挙
割引ルールの要件定義では、自社が使う割引タイプを網羅的に列挙します。定率割引、定額割引、送料無料のほか、特定商品プレゼントやまとめ買い割引もあります。想定するすべてのタイプを、RFPに記載します。
適用条件も、同じように具体化します。最低購入金額、対象商品・カテゴリ・除外商品、対象店舗やチャネルの限定を決めたうえで、有効期限を絶対期限・相対期限・曜日時間帯のどれで設計するかまで書き込みます。要件は、現状の販促だけでなく、今後やりたい施策まで見据えて書くことが大切です。
要件定義は現場ヒアリングを起点にすべきで、現状（AsIs）の運用を書き出し、あるべき業務の姿（ToBe）を描いて要件に落とすのが定石です。
理想に寄せすぎると現場に使われず、現状をなぞるだけだと将来の拡張で作り直しになります。割引タイプと適用条件は、現場の実態と将来構想の両面から列挙することが、過不足のない要件定義の出発点になります。
- 割引タイプ：現場の販促と今後の施策の両面から、想定する割引を挙げる
- 適用条件：最低購入金額、対象範囲、有効期限を、数値とルールで具体的に決める
併用可否・優先順位・上限の明記
併用ルールは、要件定義で最も漏れやすく、後の損失につながりやすい論点です。併用ルールをRFPに書かずにベンダー任せにすると、各社が独自に解釈して見積もるため、提案を比べられなくなります。反対に、併用ルールを明確に示せば、ベンダーは実装範囲を正確に見積もれ、提案の精度も上がります。
併用ロジックは一見地味ですが、過剰割引による利益の損失を防ぐ要です。機能要件は、割引が作れるだけでなく、正しく制御されるところまで書き切ることが肝心です。
- 併用の判定：クーポン同士やポイントとの組み合わせを、判定マトリクスで一つずつ示す
- 上限と優先順位：利用枚数、割引合計、1人あたりの利用回数を数値で定め、優先順位も決める
組み合わせの判定を要件定義の段階で整理しておくと、開発でもテストでも認識のずれが起きにくくなります。セール商品に適用するかどうかも、この判定に含めて書きます。
優先順位は、複数のクーポンが使えるときにどれを先に適用するかを決めることです。1会計あたりの利用枚数と割引合計の上限は、数値とロジックで定義します。
非機能要件としてのSLA・不正対策の要件化
機能要件と並んで、RFPでは非機能要件も明確にしておく必要があります。クーポンは決済やレジと連動するケースが多く、システムが止まれば会計そのものが止まりかねません。
可用性（SLA）やセキュリティ、不正対策といった非機能要件を数値で定義することが、安心して運用できるシステムの条件になります。
稼働率99.99%などSLA水準の契約条件
可用性の要件は、具体的な数値で示すのが基本です。リサーチでは、決済まわりの業界水準として、稼働率99.99%以上（月間のダウンタイム約4.3分以下）が示されています。
クーポンが決済・レジと連動する以上、同等の可用性をRFPで求めるのが妥当です。そのうえで、稼働率の目標値と障害時の復旧目標時間を、契約レベルの数値として定めます。メンテナンス時間の扱いや、障害発生時の連絡体制と責任分界も、あわせて明文化します。
SLAは目標値を掲げるだけでなく、未達時の取り扱いまで定めておくことが大切です。稼働率が目標を下回った場合の料金減額や対応義務を契約に盛り込めば、ベンダーが品質を保つ動機になります。決済の冗長化に関するリサーチの知見も参考になります。複数の経路で処理を続けられる構成や、障害時に処理を切り替える設計を要件として検討しておくと、繁忙期の販促でシステムが止まるリスクを下げられます。
SLAは、お願いではなく契約条件として書き切ることが肝心です。
- 未達時の扱い：料金減額や対応義務を、契約書の条項として明記する
- 障害時の役割：連絡体制と責任分界を、発注側と開発会社の双方で決める
不正対策・個人情報保護の非機能要件
セキュリティの要件も、非機能要件として明記します。決済の領域では、カード情報の非保持化、PCI DSS準拠、3Dセキュアが重視されています。また、EMV 3-Dセキュア2.xは2025年3月末で原則義務化されています。そのため、クーポンが決済と連携する場合は、これらの基準を満たす構成を要件に含める必要があります。
会員情報や購買履歴を扱う以上、個人情報保護の要件も欠かせません。
リサーチでは、非保持化（トークン決済）によってPCI DSSの準拠範囲を縮小でき、開発・セキュリティコストを50〜70%削減できると示されています。さらに、クーポンの設計でも、保持する情報を最小限にする考え方を要件に反映すると、対応コストとリスクの両方を抑えられます。
非機能要件は、運用を始めてからでは直しにくいため、RFPの段階で具体的に書き切ることが大切です。
- 不正対策：固有コード、利用回数の上限、使用済みコードの無効化を、要件の一覧にして管理する
- 個人情報の扱い：権限、暗号化、ログ、保管期間を、非機能要件の項目ごとに定める
使用済みコードは即時に無効化し、不審な利用パターンは検知してアラートを出す要件も含めます。利用ログは取得して監査の対象にします。
会員・ポイント・決済・会計との連携要件
クーポンは単体で完結することはほとんどなく、会員・ポイント・決済・会計といった周辺システムとつながって運用されます。だからこそ、連携要件をRFPで明確にすることが、実装範囲と費用を左右します。
どのシステムと、どのデータを、どの方式で連携するかを具体的に書くことが、見積もりの精度と後の安定運用を決めます。
連携先・連携データ・連携方式の特定
連携要件では、まず連携先のシステムを特定します。会員管理やポイント、決済やレジ（POS）に加えて、ECカートや会計システムも含め、自社のどのシステムとつなぐかを列挙します。
次に、それぞれとやり取りするデータを定めます。たとえば、会員IDと属性、ポイント残高、クーポン利用結果があります。割引額、決済結果、売上計上データについても、項目を具体的に書き出します。
連携方式も要件に含めます。リアルタイムのAPI連携か、一定間隔のバッチ連携か、CSVなどのファイル連携かによって、開発の工数も運用の性質も変わります。リサーチでは、ECカート互換や販売・会計APIとの連携が開発要件の論点として挙げられています。
会員・ポイント・決済の利用を一つの顧客IDで結ぶために、IDの設計と連携キーをRFPで明示しておきます。そうすれば、後から名寄せに苦労せずに済みます。
連携先、データ、方式の三点を特定することが、連携要件の骨格になります。
- 連携データ：会員IDや割引額など、システムごとにやり取りする項目を一覧にする
- 連携方式：API、バッチ、ファイルのどれで連携するかを、システムごとに決める
クーポン値引きの計上と収益認識の要件
連携要件の中でも見落とされがちなのが、会計・収益認識との連携です。リサーチでは、収益認識・会計実務として、新収益認識基準への対応、総額/純額表示の処理、トランザクションのAPI連携による自動仕訳・入金消込が挙げられています。これらは競合の提案で抜けやすく、欠落度が高いと指摘されています。
クーポンの値引きを売上から控除するか、販促費として処理するかは、月次決算や税務に直結する論点です。経理まで含めた業務としてクーポンを要件化しておくと、運用後の手作業や修正を防げるうえ、隠れた工数が見えて、見積もりの妥当性も高まります。
会計連携の要件は後から付け足しにくいため、必ずRFPの段階で組み込んでおくべきです。
- 計上ルール：クーポン値引きやポイント付与の会計処理を、経理部門と早い段階で決める
- 仕訳と入金消込：決済トランザクションとの連動の仕方を、要件の段階で固める
契約要件とベンダーロックイン回避
RFPで機能・非機能・連携の要件を固めたら、最後に契約面の要件を詰めます。
導入後に「やめたくてもやめられない」「データを持ち出せない」という状況に陥らないよう、契約要件も要件定義の段階から織り込んでおく必要があります。これは長期のリスク管理にあたります。
データポータビリティと移行可否の契約要件
契約要件でとくに重要なのが、データポータビリティ、つまり自社のデータを取り出せる権利の確保です。会員情報、クーポンの設定や利用履歴、ポイント残高といったデータを、標準的な形式でエクスポートできることをRFPで求めます。
リサーチでは、決済の分野で、乗り換え時にトークンの移行を拒否されるとロックインにつながるため、移行可否を契約交渉のポイントにすべきだと示されています。クーポン、会員、ポイントのデータも、解約時の扱いを決めておくことが、将来の選択肢を守ります。
これらを最初に取り決めておかないと、いざ乗り換えを検討したときには交渉力を失い、不利な条件を飲まざるを得なくなります。データを取り出せる権利は、契約要件の中核として明文化しておくべきです。
- 返還の条件：返すデータ、形式、期限を、契約で定める
- 所有権と移行：データの所有権が発注側にあるか、移行支援がどこまで含まれるかを確認する
解約時の違約金や最低契約期間も、あわせて確認しておきます。
保守費用・隠れコスト・責任分界の取り決め
契約要件では、保守の範囲と費用もはっきりさせておきます。リサーチでは、保守費用は月額で初期開発費の5〜10%（初期500万円なら月25〜50万円）が目安と示されています。
RFPでは、保守に何が含まれるか（障害対応、機能改修、問い合わせ対応など）と、含まれない作業の単価を確認します。そうすれば、運用後に「これは別料金です」と言われる事態を防げます。
リサーチでは、返金や失敗時の費用が、契約後の落とし穴として挙げられています。こうした契約要件を要件定義の段階から織り込むことで、総保有コストを正しく見積もり、長期にわたって主導権を保てます。RFPは機能の発注書であると同時に、リスクを管理する契約の設計図でもあります。
- 隠れコスト：取消手数料やオプション課金、違約金を、見積もりの段階で洗い出す
- 責任分界：障害やトラブルが起きたとき、誰がどこまで責任を負うかを契約に書く
追加開発の単価も、あわせて確認しておきます。
まとめ
クーポン発行システムのRFPや要件定義書で書き切るべき内容は、大きく四つに分かれます。
機能要件では割引タイプと併用・優先・上限のルールを、非機能要件ではSLA（稼働率99.99%水準）と不正対策・個人情報保護を書きます。連携要件では会員・ポイント・決済・会計とのつながりを、契約要件ではデータポータビリティや保守、隠れコスト、責任分界を扱います。
とりわけ併用ルール、会計連携、データ移行可否は、競合の解説では手薄な一方で、後から直すのが難しい論点です。RFPの段階で具体的に定義しておく価値が高い領域でもあります。
要件定義で大切なのは、現場ヒアリングを起点に現状（AsIs）の運用を書き出し、あるべき姿（ToBe）を描いて要件へ落とすことです。この順番を崩さなければ、現場に使われ将来も拡張できるシステムの要件になります。
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を創業。