ゴルフ場の
ゴルフソフトウェア・システム工学
まず答え
各システムで変わりにくい「共通の顧客ID」を軸にし、予約・会員・決済側の個別IDをその顧客IDへ対応付けるのが基本です。氏名・メールアドレス・電話番号だけを本人識別のキーにすると、変更・重複・表記揺れで別人化や誤統合が起きやすくなります。
詳しい解説
予約、会員、決済を別々のシステムで運用すると、同じ人が「予約側ではAさん、会員側では別のAさん、決済側ではさらに別の顧客」として増殖することがあります。これを防ぐ中心は、システムをまたいで参照する共通の顧客IDを1人に1つ持たせることです。
認証の標準仕様OpenID Connectでは、利用者を識別する値としてSubject Identifier（sub）を定義し、発行者内で一意かつ再割り当てしない識別子としています。さらに仕様は、メールアドレスや電話番号、表示名などは変更されたり再利用されたりし得るため、利用者の一意な識別子として使わないよう求めています。この考え方は、ゴルフ場の顧客台帳を統合するときにも重要です。
実務では、中央の顧客IDに対して「予約システムの顧客ID」「会員システムの会員番号」「決済側の顧客ID」を対応表として保持します。氏名、メール、電話番号は検索や照合の補助には使えますが、それだけで自動的に同一人物と確定しません。候補が複数ある場合は、生年月日や登録履歴など追加情報を確認し、誤って別人同士を統合しない手順を設けます。
また、連携処理を再実行したときに同じ顧客や予約を二重作成しない仕組みも必要です。Google CloudやStripeの公式資料が説明する「冪等性」は、同じ処理を複数回送っても結果を一度だけ反映させる考え方です。共通顧客IDと合わせて、連携ごとに一意な処理IDを持たせれば、通信障害後の再送で重複レコードが増えるリスクを減らせます。
つまり、必要なのは①共通顧客ID、②各システムIDとの対応表、③メールや電話だけに依存しない照合ルール、④統合履歴を残す仕組み、⑤再送しても重複を作らない連携設計です。単に氏名を一致させるだけでは、長期運用ほど同一人物の分裂や誤統合が起こりやすくなります。