ポイントカードシステムを開発・導入するうえで、プロジェクトの成否をもっとも大きく左右するのが要件定義です。とくにポイントカードは、付与率や有効期限といったポイントプログラムのルールが企業ごとに千差万別で、しかもPOSや会員データ、会計システムとの連携を伴うため、これをいかに正確に要件として整理し、RFP（提案依頼書）や要件定義書に落とし込めるかが、利益を生むシステムになるか、原資ばかり膨らむシステムになるかの分かれ目になります。ポイントは将来の値引きを約束する負債でもあり、設計の甘さがそのまま収益と会計の問題に直結します。
本記事は、ポイントカードシステムのRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。ポイントプログラム設計を要件の起点に据える進め方、付与・利用・失効ルールと会員ランクの要件化、POS・EC・会計連携と非機能要件の整理、そしてRFPに盛り込むべき項目と見積りの妥当性を判断する軸まで、ポイント運用の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まずポイントカードシステムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ポイントカードシステムの完全ガイド
ポイントプログラム設計を要件の起点にする進め方
ポイントカードシステムの要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。出発点は、自社のポイントプログラムをどう設計するかというビジネス側の意思決定です。何のためにポイントを導入するのか、付与率をいくらにすれば原資に見合う再来店が生まれるのか、というプログラムの骨格を先に固めなければ、機能要件は宙に浮きます。機能を決める前に、まず狙いと数字を決めるのが鉄則です。
導入目的とKGIを言語化する
最初に行うべきは、ポイントカードを導入する目的とKGI（重要目標達成指標）の言語化です。再来店率を高めたいのか、客単価を上げたいのか、休眠顧客を呼び戻したいのか、購買データを蓄積して顧客分析の基盤を作りたいのか。目的によって、必要な機能も、付与の設計も変わります。「とりあえずポイントカードを作る」では、何をもって成功とするかが曖昧なまま開発が進み、効果検証もできません。目的を数値目標に落とし込み、それを要件定義の判断基準に据えます。
目的が定まれば、機能の優先順位も自ずと決まります。再来店率の向上が主目的なら、有効期限通知やランク制度、クーポン配布が重要になりますし、購買分析が主目的なら、会員IDの統合と分析機能が中核になります。目的とKGIを最初に言語化しておくことで、後で見積りが予算を超えたときにも、目的に直結する機能を残し、そうでない機能を削るという冷静な取捨選択ができます。要件定義の出発点を、機能ではなく目的とKGIに置くことが、ぶれないプロジェクトの土台になります。
ポイント原資のシミュレーションを要件に織り込む
ポイントプログラム設計でとくに重要なのが、原資のシミュレーションです。付与率を何パーセントにすると、年間で何円のポイントを付与することになり、そのうちどれだけが利用され、どれだけが失効するのか。利用されたポイントは値引きとして利益を削り、未使用のポイントは負債として積み上がります。この収支を試算せずに付与率を決めると、再来店は増えても利益が削られる、という事態に陥ります。原資の試算は、ビジネス設計であると同時に、システムが備えるべき機能（付与率設定・失効ルール・負債管理）を逆算する作業でもあります。
原資シミュレーションを要件に織り込むとは、具体的には「付与率や有効期限を運用画面から変更できること」「失効処理を自動化し、その記録を会計に連携できること」「ポイント負債の残高をいつでも確認できること」を機能要件として明記することです。プログラムの設計は事業の状況に応じて見直すものなので、付与率や条件を柔軟に変えられる作りにしておかないと、収益悪化に気づいても手が打てません。原資の制御こそ、ポイントカードシステムの要件定義の心臓部です。
付与・利用・失効ルールと会員ランクの要件化
プログラムの骨格が固まったら、いよいよ付与・利用・失効のルールと会員ランクを具体的な機能要件に落とし込みます。ここがポイントカードシステムの要件定義でもっとも作り込みを要する工程です。ルールが複雑で例外も多いため、曖昧なまま要件にすると、リリース後に「想定と違う付与がされる」という重大なトラブルにつながります。
付与・利用・失効ルールを漏れなく定義する
付与ルールを要件化するには、自社の付与の考え方をすべて棚卸しする必要があります。基本の付与率はいくらか、対象外の商品やサービスはあるか、端数はどう処理するか、特定の曜日・商品・会員ランクで付与率を変えるか、キャンペーン時のボーナス付与をどう扱うか。これらをひとつずつ言語化し、「どの取引に、いくらのポイントを、どう付けるか」を明確に定義します。この付与ルールの定義が曖昧だと、「付与してはいけない取引に付与された」「端数の扱いが店舗ごとに違う」という事故につながります。
利用と失効のルールも詳細に要件化します。ポイントを使える最低単位や利用上限、ポイントとクーポンの併用可否を定めます。失効については、最終利用日起算か付与日起算か、有効期間は何か月か、期限切れ前の通知をどう出すかを明記します。失効は会計上のポイント負債の取り崩しにも関わるため、失効処理のタイミングと記録の残し方を要件に含めることが欠かせません。付与・利用・失効のルールを漏れなく要件化できれば、ポイントカードシステムの中核は固まったと言えます。
会員ランク・クーポン併用の要件化
会員ランクを要件化する場合は、ランクの段階数、ランクの判定基準（累計購入額か来店回数か）、判定の期間と頻度、維持・降格の条件、ランクごとの特典（付与率・限定クーポン・誕生日特典）をすべて定義します。ランク制度は事業の成長や顧客構成の変化に応じて見直すものなので、ランクの基準や特典を運用画面から変更できることを要件に明記しておくと、後の機動力が確保できます。
クーポンとポイントの併用ルールも、要件として明確にします。クーポン値引き後の金額にポイントを付与するのか値引き前か、ポイント利用とクーポン利用を同時に認めるか、といった併用の可否を定めなければ、想定外の値引きが重なって利益が削られます。リサーチノートでも、ポイントやクーポンといった販促・利便性が顧客の来店動機を左右することが示されており、併用ルールは収益と顧客満足の両面に直結します。会員ランクと併用ルールを丁寧に要件化することが、ポイントプログラムを設計通りに動かす条件になります。
連携要件と非機能要件の整理
要件定義書は、機能要件だけでなく、連携要件と非機能要件の両方を網羅する必要があります。連携要件は「どのシステムと、どうつなぐか」、非機能要件は「どれだけの品質で動くか」を定めるものです。ポイントカードシステムは、POSや会員データ、会計システムとつながってはじめて業務で機能するため、連携要件の整理が品質を大きく左右します。
POS・会計・会員データとの連携要件
連携要件の整理は、もっとも技術的な検討を要します。既存のPOSは何か、ECサイトの会員データはどう管理されているか、会計システムは何かを把握し、それぞれと、どのデータを、どの方向に、どのタイミング（リアルタイムかバッチか）で連携するかを定義します。とくにPOSとの連携は、会計と同時のポイント付与・利用の根幹なので、連携可能なインターフェース（API・CSV・ファイル連携）を事前に確認しておかないと、ベンダーが正確な見積りを出せません。
会計連携も見落とせない要件です。ポイントの付与・利用・失効は会計上のポイント負債の計上・取り崩しに関わるため、これらのデータを会計システムに連携できるかどうかが、経理の正確性と効率を左右します。実店舗とECで会員IDを統合するなら、既存の会員データをどう名寄せして一つのIDに統合するかも、連携要件として詳細に詰めます。連携はポイントカードシステムの効果を最大化する一方、技術的難易度が高く費用もかさむため、要件定義の段階で連携範囲を明確にすることが、見積りの精度と妥当性判断を左右します。
非機能要件（可用性・性能・個人情報保護）
非機能要件では、可用性・性能・個人情報保護を定義します。可用性は、ポイントカードシステムが店頭の会計と連動する以上、極めて重要です。システムが止まればレジでポイントを付与・利用できず、会計そのものが滞ります。決済・販促系の業界水準では稼働率99.99%以上（月間のダウンタイム約4.3分以下）が一つの目安とされており、自社の業態に応じて稼働率の目標や障害時の復旧手順を要件化します。性能では、会員数が増えても会員検索やポイント計算が遅くならないこと、来店ピーク時に処理が滞らないことを、想定会員数・同時アクセス数とともに記述します。
個人情報保護は、会員の氏名・連絡先・購買履歴という機微な情報を大量に扱うポイントカードシステムでは外せません。誰がどの会員情報にアクセスできるかの権限管理、通信と保存データの暗号化、退会者データの取り扱い、本人からの開示・削除請求への対応を、関連する法令やIPA（情報処理推進機構）のガイドラインを参照しつつ要件化します。非機能要件を曖昧にすると、リリース後に「止まる」「遅い」「漏れる」というトラブルが起き、会員の信頼を一気に失います。機能要件と同じ熱量で非機能要件を詰めることが、ポイントカードシステムの品質を担保します。
RFPに盛り込む項目と見積り妥当性の判断
要件定義書がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。ポイントカードシステムは連携範囲によって費用幅が大きいため、RFPで土俵を揃えることが、見積りの妥当性を判断する大前提になります。
RFPに必ず盛り込むべき項目
RFPには、最低限以下の項目を盛り込みます。プロジェクトの目的とKGI（再来店率向上や購買分析基盤の構築など）、ポイントプログラムの設計方針（付与率・有効期限・会員ランクの考え方）、機能要件（必須・優先・将来の分類付き）、非機能要件（可用性・性能・個人情報保護）、既存システムとの連携要件（POS・EC・会計システム名と連携範囲）、予算とスケジュールの目安、そして開発・運用の体制要求です。付与・利用・失効ルールやクーポン併用ルールといったポイント固有の要件は、RFPの機能要件の中核として具体的に記述します。
とくに見落とされがちなのが、運用・保守の体制要求です。ポイントカードシステムは、リリース後も付与率の変更やキャンペーン設定、不具合対応が継続的に発生します。保守費用は一般に初期開発費の5〜10%程度（出典ripla）が目安とされ、これを見込まずに初期費用だけで判断すると、運用フェーズで想定外のコストに直面します。RFPで保守の範囲・体制・費用を明示させ、誰が実際に開発・運用するのかを体制図で確認することが、ベンダー選定の防衛策になります。
見積りの妥当性を判断する軸
集まった見積りの妥当性を判断するには、内訳を精査することが第一です。ポイントカードシステムの費用は、ポイント管理の中核機能、会員管理、クーポン・販促、POS・会計連携、不正対策、分析機能といった要素ごとに積み上がります。「一式」でまとめられた見積りには、機能ごと・工程ごとの工数と単価の開示を求めます。とくに連携部分は費用が膨らみやすいため、どのシステムとの連携にいくらかかるのかを明示させ、追加要件が出たときの単価ルールも事前に取り決めます。
見積りを比較するときは、安すぎる場合に連携や非機能要件が漏れていないか、高すぎる場合に不要な要件が含まれていないかを確認します。要件定義書とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ず、ブラックボックスを解明しやすくなります。riplaはフルスクラッチ受託と国内開発の立場から、ポイントプログラムの設計から要件の透明な整理、見積り内訳の明示までを重視しています。要件定義の精度が、見積りの妥当性判断の精度を決めるのです。
まとめ
ポイントカードシステムの要件定義・RFP・提案依頼書は、機能の列挙からではなく、ポイントプログラムの目的とKGIを言語化し、原資のシミュレーションを行うことから始めるのが鉄則です。そのうえで、付与・利用・失効ルールと会員ランク・クーポン併用を漏れなく機能要件に落とし、POS・会計・会員データとの連携要件と、可用性・性能・個人情報保護の非機能要件も詰める。これらを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を創業。