ポイントカードシステムの要件定義は、目的と原資を決め、ポイントルールを固め、連携要件を整理してRFP（提案依頼書）にまとめる順で進みます。この順で進めると、見積りを比べやすくなります。
各工程の詳しい全体像は、ポイントカードシステムの完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・ポイントカードシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ポイントプログラム設計を要件の起点にする進め方
ポイントカードシステムの要件定義は、自社のポイントプログラムをどう設計するかという事業判断から始めます。
欲しい機能を並べるのは、その判断が決まってからです。
まず導入目的と、原資に見合う再来店につながる付与率を決めます。プログラムの骨格と狙いの数字を固めてから、機能要件に進みます。
導入目的とKGIの言語化
ポイントカードの目的とKGI（重要目標達成指標）を言葉にし、その数値目標を要件定義の判断基準にします。「とりあえず導入」のままでは、成功の基準が曖昧になり、効果も検証できません。
目的が変われば、必要な機能と付与設計も変わります。そこで、目的ごとに優先する機能を整理します。
- 再来店率の向上：有効期限の通知、ランク制度、クーポン配布
- 客単価の向上
- 休眠顧客の呼び戻し
- 購買データの蓄積：会員ID統合と分析機能
目的とKGIを先に言語化しておけば、予算が超過したときも、目的に直結する機能を残してそれ以外を削れます。
目的とKGIを起点にすることが、ぶれないプロジェクトの土台になります。
ポイント原資のシミュレーションと要件への織り込み
付与率を決める前に、年間の付与額と利用・失効の見込みを試算します。利用されたポイントは値引きとして利益を削り、使われずに残ったポイントは負債として積み上がります。
ポイントプログラム設計では、特に原資シミュレーションが重要です。試算せずに付与率を決めると、再来店が増えても利益が削られることがあります。
原資の試算は事業設計であると同時に、必要な機能を逆算する作業でもあります。
原資管理に必要な機能は、試算の結果を踏まえて要件に含めます。
- 付与率設定：付与率や有効期限を運用画面から変えられる
- 失効ルール：処理の自動化と、その記録の会計への連携
- 負債管理：ポイント負債の残高の随時確認
事業の状況に応じて条件を柔軟に変えられなければ、収益の悪化に気づいても対応が遅れてしまいます。
原資の制御は、要件定義の中核にあたります。
付与・利用・失効ルールと会員ランクの要件化
プログラムの骨格が固まったら、付与・利用・失効のルールと会員ランクを機能要件に落とし込みます。
この工程は要件定義のなかでも特に作り込みが必要で、曖昧な要件は想定外の付与などリリース後のトラブルにつながります。
付与・利用・失効ルールの定義
付与ルールを要件にするには、自社の付与の考え方をすべて洗い出します。各取引に付けるポイントを明確にするため、条件を分けて一つずつ確認します。
- 基本条件：基本付与率と対象外の商品・サービス
- 計算条件：端数処理と、曜日・商品・会員ランク別の付与率
- 特別条件：キャンペーン時のボーナス付与
条件を一つずつ言葉にして、「どの取引に、いくらのポイントを、どう付けるか」を定めます。ここが曖昧なままだと、対象外の取引にもポイントが付いたり、店舗ごとに端数処理が食い違ったりします。
利用と失効の要件には、利用可能な最低単位と上限、クーポンとの併用可否を含めます。
失効の起算日は、最終利用日か付与日のどちらかに決めます。そのうえで、有効期間を何か月にするか、期限切れの前にどう通知するかも明記します。
失効はポイント負債の取り崩しにも関わるため、処理のタイミングと記録方法まで要件に含めます。そこまで定まると、システムの中核が固まります。
会員ランク・クーポン併用の要件化
会員ランクとクーポンの条件は、運用後に変えることも想定して具体化します。
- ランク判定：段階数、購入額か来店回数か、判定期間と頻度
- 維持と特典：維持・降格条件、付与率・限定クーポン・誕生日特典
- 併用条件：クーポン値引き前後のどちらにポイントを付けるか、同時利用の可否
基準や特典を運用画面から変えられる要件にしておくと、事業の成長や顧客構成の変化に合わせやすくなります。併用条件が曖昧だと、値引きが重なって利益を損なうこともあります。
リサーチノートでは、ポイントやクーポンなどの販促・利便性が来店動機を左右すると示されています。ランクと併用ルールを丁寧に定めることが、設計したポイントプログラムを動かす条件になります。
連携要件と非機能要件の整理
要件定義書には、機能要件に加えて連携要件と非機能要件も盛り込みます。連携要件では接続先と方法を、非機能要件では品質の水準を定めます。
ポイントカードシステムは、POSや会員データ、会計システムとつながって初めて業務で機能します。そのため、連携要件が品質を左右します。
POS・会計・会員データとの連携要件
連携要件は、技術的な検討が最も必要になる部分です。見積りの前提になる連携範囲を明確にするため、接続先ごとにデータの流れを決めます。
- POS：製品と連携できるAPI、CSV、ファイル連携の方式
- EC・会員：会員データの管理方法と、名寄せ・ID統合の方法
- 会計：付与・利用・失効データの連携の可否
各システムのあいだで、どのデータを、どの方向へ、いつ連携するかを定めます。そのうえで、タイミングがリアルタイムかバッチかも明記します。
POS連携は、会計時のポイント付与と利用を支える根幹です。接続方式を事前に確かめておかないと、ベンダーは正確な見積りを出せません。
会計連携は、ポイント負債の計上と取り崩しに関わるため、経理の正確性と効率を左右します。
実店舗とECの会員IDを統合する場合は、既存データの名寄せ方法も詰めておきます。連携は効果を高める一方で、技術的な難易度が高く、費用もかさみます。このため、連携の範囲を先に決めることが、見積りの精度と妥当性の判断を左右します。
非機能要件（可用性・性能・個人情報保護）
非機能要件では、稼働、処理性能、個人情報保護の水準を具体的に定めます。
- 可用性：目標稼働率と障害時の復旧手順
- 性能：想定会員数・同時アクセス数と、検索・計算の応答
- 個人情報保護：アクセス権限、暗号化、退会者データ、開示・削除請求への対応
ポイントの仕組みは店頭会計に連動しているため、システムが止まると、ポイントの付与・利用だけでなく会計も滞ります。決済・販促系の業界水準では、稼働率99.99%以上（月間ダウンタイム約4.3分以下）が一つの目安になります。自社の業態に応じて目標を決め、障害時の復旧手順も要件に含めます。
会員数が増えても会員検索やポイント計算が遅くならず、来店が集中する時間帯も処理が滞らないよう、想定規模とあわせて記述します。
また、氏名・連絡先・購買履歴を扱うため、関連法令やIPA（情報処理推進機構）のガイドラインを参照しながら要件を定めます。曖昧な要件のままでは、リリース後に停止・遅延・漏えいを招き、会員の信頼を一気に損ないます。
機能要件と同じ程度に非機能要件を詰めることで、ポイントカードシステムの品質を担保できます。
RFPに盛り込む項目と見積り妥当性の判断
要件定義書をもとにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPが曖昧だと見積りも曖昧になり、各社を横並びで比べられなくなります。
ポイントカードシステムは、連携の範囲によって費用の幅が変わります。そのため、RFPで条件を揃えておくことが、見積りの妥当性を判断する前提になります。
RFPに盛り込む必須項目
RFPには、提案の条件を揃えるために、次の項目を記載します。
- 目的とプログラム：KGI、付与率・有効期限、会員ランクの考え方
- 機能要件：必須、優先、将来の分類を付けた一覧
- 接続・品質：非機能要件、POS・EC・会計システム名と連携範囲
- 実施条件：予算・スケジュールの目安、開発・運用体制の要求
KGIには、再来店率のように数値で測れる目標を記します。機能要件には、付与・利用・失効やクーポン併用のルールも具体的に含めます。
運用・保守の体制要求は見落とされがちですが、リリース後も付与率の変更やキャンペーン設定、不具合対応が続きます。保守費用は一般に初期開発費の5〜10%程度が目安です（出典：ripla）。初期費用だけで判断すると、運用の段階で想定外のコストが生じます。
RFPでは、保守の範囲と体制、費用を示したうえで、開発と運用の担当者を体制図で確認します。
見積りの妥当性の判断基準
見積りは内訳を確かめ、機能や工程ごとの費用と単価を比べます。ポイントカードシステムでは、費用は機能の領域ごとに積み上がります。
- ポイント・会員：ポイント管理の中核機能と会員管理
- 販促・分析：クーポン・販促と分析機能
- 接続・保護：POS・会計連携と不正対策
「一式」とだけ書かれた見積りには、機能・工程ごとの工数と単価を求めます。連携部分は費用が膨らみやすいため、接続先ごとの金額と追加要件の単価ルールも確かめます。
見積りが安すぎる場合は連携や非機能要件に漏れがないかを、高すぎる場合は不要な要件がないかを調べます。要件定義書とRFPが詳細であれば、ベンダーも精緻な見積りを出さざるを得ません。その結果、見積りの中身が見えてくるうえ、ブラックボックスになりがちな部分も解明できます。
riplaは、フルスクラッチ受託と国内開発の立場から、設計、要件の整理、内訳の明示を重視しています。要件定義の精度が、見積りの妥当性を判断できるかどうかを左右します。
まとめ
要件定義では、まず目的とKGIを言葉にし、原資を試算してから先へ進みます。そのうえで、付与・利用・失効のルール、会員ランク、クーポン併用の条件を機能要件に含めます。
連携では、POS・会計・会員データの範囲を決め、可用性・性能・個人情報保護も詰めます。RFPには目的、連携要件、運用保守の体制要求を明記します。
条件を揃えると、提案を横並びで比べられ、見積りの内訳から妥当性も判断しやすくなります。
ポイントは、将来の値引きを約束する負債です。そのため、要件定義の質は、システムの動作に加えて、収益と会計の健全性にも直結します。
プログラムの狙いと数字を反映した要件が、利益を生むポイントカードシステムにつながります。
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を創業。