【ITニュース解説】Building a Restaurant Loyalty App That Talks to Your POS

ロイヤリティアプリの基本的な仕組み、例えば顧客が買い物をすればポイントが貯まり、一定のポイントで特典と交換できる、友達を紹介すればボーナスがもらえるといったロジックは比較的シンプルで、システムとして構築するのもそれほど難しくない。しかし、実際にそのようなアプリを開発するプロジェクトの多くが直面し、停滞してしまう大きな問題が、店舗のレジシステム、つまりPOS（Point of Sale）システムとの連携である。この連携部分で、開発が進んだ段階になって初めて、POSシステムがデータを1時間ごとのバッチ処理でしか出力しないことや、ポイントの交換といった双方向の通信には特定のベンダーとの契約が事前に必要であることが判明するなど、予期せぬ制約に直面することが少なくない。

システムエンジニアを目指す上で、このような実践的な課題にどう対処するかは非常に重要である。コードを一行も書く前に、どのような技術的決定を下すべきか、そのポイントを理解することは、プロジェクトを成功に導くために不可欠だ。

まず、最も重要なことは、店舗のPOSシステムがどのようなデータを提供し、どのようにそのデータにアクセスできるのかを正確に把握することだ。これを「POSの表面積」と呼ぶ。例えば、現在主流となっているクラウドベースのPOSシステム（ToastやSquare、Lightspeedなど）は、通常REST APIというWebサービスを介したデータ連携の仕組みを提供し、認証にはOAuthといった標準的な方法を用いる。また、開発者が試行できるサンドボックス環境や、詳細なドキュメントも用意されていることが多く、これらのシステムとの連携は比較的予測しやすく、スムーズに進む傾向がある。一方で、店舗内にサーバーを置くオンプレミス型のPOSや、古いレガシーシステムの場合、データへのアクセス方法が限られることがある。たとえば、ローカルデータベースへの直接アクセス、POSベンダー独自のSDK（ソフトウェア開発キット）の利用、あるいはCSVファイルとして決まった時間にデータをエクスポートする、といった方法しか提供されていない場合がある。このようなケースでは、データを変換したり、連携を仲介するための「ミドルウェア」と呼ばれる追加のシステムが必要になることが多い。さらに、フランチャイズチェーンのように本部が管理するPOSシステムでは、APIへのアクセスが特定の開発者やパートナープログラムを通じてのみ許可されることもあり、その申請に時間がかかったり、アクセスが保証されなかったりする場合があるため、事前の確認が非常に重要となる。

そのため、POS連携プロジェクトの最初の技術検証では、まずサンドボックス環境で認証を行い、POSから実際の取引記録を一つ取得し、そのデータ形式（データモデル）を確認することが推奨される。もしこの作業が1日以内に完了できない場合、それは重大な制約であり、本格的な設計に入る前にこの問題を関係者と共有し、解決策を検討する必要がある。

次に、ロイヤリティシステムとPOSの間で発生するデータの流れ（データフロー）を一つ一つ明確に特定し、設計する必要がある。これには少なくとも四つの主要な流れがあり、それぞれデータのリアルタイム性（遅延要件）や、問題が発生した場合の影響が異なる。

一つ目は「トランザクションイベント」で、POSからロイヤリティシステムへ、顧客の購入情報が流れる。これはほぼリアルタイムか、顧客のセッション単位で処理されることが求められ、遅延すると顧客にポイントが正しく付与されない問題につながる。二つ目は「リワード交換」で、ロイヤリティシステムからPOSへ、顧客がポイントを使って特典を交換する情報が流れる。このデータフローはチェックアウト時にリアルタイムで処理される必要があり、もしシステムがタイムアウトしたり、POSが特典の適用を確定できなかったりすると、顧客が特典を二重に利用できてしまったり、レジでの処理が滞ったりする。特にこのリワード交換は運用上最もデリケートな部分であり、システムが一時的にダウンした場合などに備え、手動での処理コード、オフラインでの交換処理のキューイング、あるいは機能が部分的に低下しても使えるような「フォールバック」の仕組みを、本番稼働前に必ず設計しておく必要がある。三つ目は「メニュー・商品データ」で、POSからロイヤリティシステムへ、メニューや商品の情報が流れる。これは通常、日次での同期で十分だが、遅延するとアプリに表示される情報が古くなる可能性がある。四つ目は「顧客識別」で、ロイヤリティシステムとPOSの間で、取引を行った顧客が誰であるかを特定するために双方向に情報が流れる。これは取引発生時に行われるが、失敗するとポイントが誤った顧客に付与されるなどの問題が起こる。

この「顧客識別」は特に注意すべき問題である。ロイヤリティアプリは登録された顧客を認識しているが、POSシステムは単に取引内容を記録するだけで、その取引を行ったのが特定のロイヤリティ会員であるとは自動的に判断しない。両者を結びつけるには、いくつかのアプローチがある。例えば、レジで顧客の電話番号を入力してロイヤリティ会員を検索する方法は、技術的な複雑度は低いが、店員の作業に依存するため、入力ミスや入力忘れが発生しやすく、かなりの割合で顧客が正しく識別されない可能性がある。ロイヤリティアプリから表示されるQRコードをレジでスキャンする方法は、カウンターサービスのような環境で特に有効だ。顧客自身がQRコードを提示するため、利用されれば信頼性は高いが、チェックアウトのプロセスに一手間加わることにはなる。最もスムーズなユーザー体験を提供するのが、クレジットカード情報とロイヤリティ会員情報を紐づける「カードファイル連携」だが、この方法は決済処理システム側のサポートも必要であり、すべてのPOSシステムや決済環境で利用できるわけではない。

どの方法を選んだとしても、システムエンジニアは、その方法が現実的にどれくらいの頻度で失敗するか（誤認識率）を考慮して、設計を進めるべきだ。もし15〜20%の取引が顧客に紐づけられないと予想されるなら、顧客のポイント残高表示、ポイントに関する問い合わせへの対応、キャンペーンの実施ロジックなどは、そのギャップを考慮に入れた設計にする必要がある。

また、レストラン環境ではネットワーク接続が不安定になったり、完全に失われたりすることが珍しくない。フードトラック、地下の店舗、イベント会場の屋台など、ネットワーク接続が常に保証されない環境も存在する。このようなオフライン状況で、ロイヤリティ連携システムがどのように振る舞うかを明確に決めておく必要がある。一般的なアプローチは、POSシステム側でオフライン中に発生した取引データを一時的に保存し、ネットワークが再接続されたときに一括してロイヤリティシステムに同期するというものだ。この場合、ポイントはリアルタイムではなく、同期が完了した時点で付与される。ほとんどのユースケースではこれで十分だが、時間制限のあるプロモーションや、リアルタイムでのポイント交換認証が必要な場合には、この方法は使えない。複数店舗やフランチャイズ展開の場合、オフライン時の挙動が店舗間で一貫していることが重要である。もし店舗ごとに挙動が異なると、大規模展開においてサポートや顧客の信頼に関わる大きな問題に発展しかねない。

さらに、複数店舗でのビジネスルールがデータモデルに与える影響も考慮すべき点である。例えば、顧客が店舗Aでポイントを獲得し、店舗Bでそのポイントを交換する場合、ロイヤリティシステムのデータモデルは、どのポイントがどの店舗で発生し、どの店舗で利用されたかを明確に表現できる必要がある。もし紹介プログラムが店舗をまたいで有効であるなら、すべての取引イベントに「この取引はどの店舗で発生したか」という店舗属性が必要になる。これらは一見するとビジネス上のルールに見えるが、実はデータベースのスキーマ、つまりデータの構造に直接的な影響を与えるのだ。後から「複数店舗にまたがる属性を追加しよう」とすると、それは単なる機能追加ではなく、大規模なデータ移行作業を伴うことになる。だから、このようなビジネスルールは、データベースのスキーマを設計する前に、必ず文書化して明確にしておくことが、プロジェクト成功のための重要な制約となる。

このように、開発が始まる前に、統合に関する詳細な仕様書を作成することが非常に重要である。この文書には、使用するPOSプラットフォームの種類、APIのバージョン、認証方法、サンドボックスへのアクセス状況といった基本的な情報から、各データフローの方向性、データを送受信するタイミング（トリガー）、必要なリアルタイム性（遅延要件）、そして障害発生時のフォールバック戦略までを網羅すべきだ。また、顧客識別方法と予想される識別成功率、各連携ポイントでのオフライン時の挙動、複数店舗でのデータ所有権や店舗横断的なロイヤリティルールの詳細、そしてレジでのリワード交換時のユーザー体験がPOSのAPI機能とどのように連携するか、といった具体的な内容も含まれるべきである。このような事前の綿密な準備がないと、開発チームは時間的なプレッシャーの中で、コードを書きながらこれらの重要な決定を下さざるを得なくなる。そして、その場で下された決定は、後から変更しようとすると非常にコストがかかるものとなるのだ。事前の調査と計画は地味な作業に見えるかもしれないが、これこそがプロジェクトがスムーズに進行し、実際に完成品を世に出せるか、それとも途中で停滞してしまうかを分ける決定的な違いとなるのである。