ポイントアプリの成否は要件定義で決まり、RFP（提案依頼書）と要件定義書にどこまで具体的に書けるかが、運用初日からのトラブルの有無を左右します。
本記事は、要件定義の進め方を発注企業の視点で解説します。全体像はポイントアプリ開発の完全ガイドで確認できます。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
目的・KPIの設定と原資の試算
要件定義は、機能の話に入る前に「何のためにポイントを発行するのか」を言葉にすることから始まります。目的の例は、リピート率の向上、ポータルやグルメサイト依存からの脱却と自社顧客データの蓄積、休眠顧客の掘り起こしなどです。目的が定まらないまま機能だけを並べると、付与率や失効方式を判断する拠り所がなく、結局はベンダー任せの設計になってしまいます。
ポイント運用の指標（KGI・KPI）の設定
目的を定めたら、それを測定できるKGI・KPIに置き換えます。さらに、ポイント利用率といった指標も設定します。
KPIを明確にすると、RFPに「このアプリで達成したい数値目標」を書けるようになり、ベンダーも目的に沿った提案をしやすくなります。また、これらのKPIは、後の機能の優先順位と効果測定（分析機能の要件）を決める基準にもなります。
逆にKPIがないRFPは、機能の網羅性だけで比較されがちで、本当に成果を出せる提案かどうかを見極めにくくなります。そのため、要件定義で最初に決めるべきなのは、機能一覧ではなく「目的とKPIの合意」です。指標は目的ごとに変わるため、例を挙げます。
- 来店の繰り返しを狙う場合：会員のリピート率（アプリ会員は非会員の約1.5〜2倍とされます：出典ripla）、来店頻度、客単価
- 自社の顧客データを増やす場合：会員登録率、アクティブ会員数、プッシュ通知の開封率（メルマガの3〜4倍とされます：出典ripla）
原資（販促費）と会計上の負債の試算
ポイントアプリの要件定義で、他のアプリにはない最重要の論点が原資（販促費）の試算です。購入金額の何%をポイントで還元するかを示す付与率は、そのまま販促費に直結します。この試算を要件定義の段階で行わないと、リリース後に「思ったより還元負担が重い」という事態に直面します。
付与されたポイントは、利用される分だけ実質的な値引きとなり、利益を圧縮します。さらに、発行済みで未利用のポイントは、会計上「ポイント引当金」などの形で負債として計上されます。失効方式（固定期限か・利用都度延長か・一斉失効か）によって、この負債の積み上がり方が変わります。原資と負債を試算したうえで、付与率・失効方式・上限設定を決めることが、経営を圧迫しないポイント設計の前提になります。
この試算結果は、システムに必要な集計・レポート機能の要件にも直結します。なお、原資設計を疎かにした失敗は、『ポイントアプリ開発・導入の失敗・課題・リスク』でも詳しく触れています。
- 年間の発行総額：想定売上に付与率を掛けて求める
- 失効方式ごとの負債の積み上がり：固定期限、利用都度延長、一斉失効の方式で比べる
付与・失効・不正対策の要件化
目的・KPI・原資が固まったら、ポイント特有の業務ルールを機能要件に落としていきます。ここで曖昧さを残すと、開発の後半やリリース後に重大な手戻りが生じます。とくに、付与・失効・不正対策は、いずれもポイント運用の根幹なので、要件定義書で最も丁寧に書き下すべき部分です。
なお、各機能の詳細は『ポイントアプリの必要機能・標準機能の一覧』でも体系的に整理しています。
付与ルールと失効方式の漏れない要件化
付与ルールの要件化では、通常の還元率だけでなく、例外パターンまで列挙します。誕生月特典や端数の丸め方（切り上げか切り捨てか）も、そこに含めます。ここを曖昧にすると、ベンダーが想定する付与ロジックと自社の運用がずれ、リリース後に付与漏れや二重付与が頻発します。
「いつ・誰に・どの取引で・何ポイント付与されるか」を表で網羅し、現場担当者が改修なしでキャンペーンを設定できるか、都度開発が必要かといった運用面の要求も明記します。
失効方式の要件化も、付与と並んで重要です。とくに「期限がまたがるポイントの利用順序（古いものから使うか）」のような細部は、決めておかないと開発時に手戻りが起きる典型箇所です。このため、付与と失効は、要件定義書の中で最も具体的に、表とフロー図で書き下す価値のある領域です。
- 付与の例外：ボーナスポイント、ランク別還元、キャンペーン付与の扱い
- 失効の決め方：固定期限、利用都度延長、一斉失効のどれにするか。失効の時期（日次か月次か）、予告通知、会計処理も含む
不正対策と前払式支払手段の法務要件
不正対策は、原資リスクと照らして「どこまでやるか」を要件定義で決めます。初回特典の不正取得を防ぐSMS認証を必須にするか、端末IDのブロックや同一IPからの大量登録の監視まで入れるかが論点になります。これらは後付けが難しいため、初期要件に含めるかどうかを明確にしておきます。
また、会員データの名寄せも、同じ段階で要件に含めます。複数の会員ID（POS会員・EC会員・アプリ会員）を統合するため、突合キー（電話番号・メール等）と、突合できなかったデータの扱いを決めておく必要があります。
ポイントアプリ固有の法務要件は、資金決済法上の「前払式支払手段」に該当するかどうかの判断です。自社のポイントがどちらに当たるかで、必要な集計・報告機能や利用規約・プライバシーポリシーの整備が変わります。そのため、要件定義の段階で専門家を交えて決め、RFPに法務要件として明記しておくことが欠かせません。
- チャージ型：購入や入金で残高を積み増すもの。前払式支払手段に該当し、未使用残高に応じた供託義務や利用者への情報提供義務の対象になる場合がある
- 無償付与型：購入のおまけとして無償で付与されるもの。原則として対象外とされる
連携要件・非機能要件・データ移行
ポイントアプリは、店頭のPOS、ECサイト、既存の会員データベース、共通ポイント基盤など、多くの外部システムと連携して初めて機能します。
連携要件・非機能要件・データ移行は、要件定義で軽視されがちです。しかし、ここの精度が、見積りの正確さとリリース時のトラブルの有無を決めます。
既存POS/EC/会員DB連携とAPI要件
連携要件では、まず「どのシステムと、どの方向に、どのタイミングでデータをやり取りするか」を明確にします。たとえば、POSの会計をリアルタイムでポイント付与に反映するのか、夜間バッチでまとめて取り込むのかを決めます。EC購入をどう連動させるかも、明確にしておきます。
連携先システムが提供するAPIの有無と仕様、提供されない場合の代替手段（CSV連携等）まで調べます。また、共通ポイントを使う場合は、その事業者の連携仕様に従う必要があります。そのうえで、RFPに「既存システムの一覧と連携方式の希望」を書きます。
非機能要件も見落とせません。ポイントは金銭価値を持つため、可用性とデータ整合性の要求は一般的なアプリより厳しくなります。連携と非機能の要件を明確にすることが、ベンダー見積りのブレを抑える近道です。
- 性能とセキュリティ：セール時などの会計のピーク時にも付与が遅れない性能、プライバシーポリシー策定やPCI DSS等のセキュリティ要件
- 障害と保守：障害時の復旧目標、保守・運用体制の要求
既存ポイント残高のデータ移行と名寄せ要件
既存の紙カードや旧システムからポイントアプリへ切り替える場合、既存ポイント残高のデータ移行は避けて通れません。残高は金銭価値を持つため、1ポイントの誤差も許されません。さらに、移行リハーサルと検証の段取りまで、RFPに記載しておくべき重要事項です。
移行と密接に絡むのが、複数システムに散らばった会員データの名寄せ要件です。名寄せを甘く見積もると、移行後に「同一人物が複数の残高を持つ」「特典が二重に出る」といった事故が起き、運用が混乱します。
データ移行と名寄せは、要件定義書で工数とリスクを率直に見積もるべき、手間のかかる領域です。ここを明記できているRFPほど、ベンダーの見積り精度が上がります。
- 残高の移行：現行会員の残高をどう引き継ぐか、移行時点の有効期限をどう扱うか、移行途中の取引をどう処理するか
- 名寄せの進め方：表記ゆれや重複をどう解消するか、突合ルールと人手による確認フローをどう組むか
まとめ
ポイントアプリの要件定義は、ポイント運用の目的とKPIを定め、原資（販促費）と会計上の負債を試算するところから始まります。そのうえで、付与ルールと失効方式を表で書き下し、不正対策と前払式支払手段の法務要件を初期から要件に含めます。また、既存POS/EC/会員DBとの連携、非機能要件、データ移行と名寄せは、実態に即して見積もります。
この順序で要件定義書とRFPをまとめれば、ベンダーの提案を横並びで比較できます。さらに、相場（スクラッチ開発で200〜1,000万円以上、SaaS/MVPで50〜150万円：出典ripla）に照らせば、見積りの妥当性も判断できます。
要件定義は、ポイントアプリの成否を最も左右する工程です。とくに原資設計・失効・名寄せ・法務というポイント特有の論点は見落とされやすく、それらを漏れなく言語化できるかが分かれ目になります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、目的起点・原資起点の要件整理と、見積りの妥当性判断までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。