http://martinfowler.com/bliki/CustomerLoyaltySoftware.html

先週、カナダのカルガリーオフィスでJohn Kordybackと楽しい会話をすることができた。 彼は最も信頼できる技術リーダーの1人だ。 彼は、旅行関係のロイヤルティソフトウェアシステムに従事（というか、どっぷり漬かって）いる（たとえば、Frequent FlyerやSleeperなどだ）。 我々は、これらのシステムの本質について、 そして、 より実りある方法で考えるにはどのようにすればよいか、 といったことについて話し合った。

ロイヤルティシステムの肝は、ポイント（やマイル）の記録にある。 顧客は自分のポイントを参照できなければならないし、会社はまだ引き換えられていないポイントを管理できなければならない。 多くの人はそうは思わないかもしれないが、実はこれはお金がポイントに換わっただけで、本質的には会計システムと同じなのである。 Johnによると、会計の視点から見れば簡単なものでも、そう思わないがために難しい問題だと捉えてしまう光景に何度も直面したことがあるそうだ。

たとえば、アドホックな変更の取り扱いがそうである。 自動化されたルール処理がどんなに優れていても、対応できないケースは必ず起こるものであり、その場合は手動で調整する必要がある。 その結果、多くのシステムではあらゆる箇所にアドホックな変更が入ってしまい、 目が行き届かないエラーの温床となっている。 しかし、会計の考え方をすれば、こうした変更は会計調整（accounting adjustments）として考えることができるし、このパターン自体はよく知られたものである。

ロイヤルティプログラムと会計システムの大きな違いは、ロイヤルティプログラムは資産ではなく負債を管理する点である。 つまり、税金、利益報告などよくある項目以外に、 リスク管理などのようなものにも焦点をあてているということだ。

多くのロイヤルティシステムには、複数の種類のポイントがある。 たとえば、通常のマイルとエリート会員資格マイル、といった具合だ。 これはよく複雑だといわれるところだ。 会計の考え方をすれば、これは複数通貨だと考えることができる。 そうすれば、簡単にこれらを記録することができるだろう。

ちょっと変わったものとしては、見越ポイント（potential points）という面白いものがある。 たとえば、私が来月の飛行便を予約したら、航空会社は私が来月稼ぐであろうマイルをその時点で知る必要がある（これが見越マイルだ）。 この見越マイルは会社の負債につながる。 私が飛行機に乗って実際にマイルになったときに負債になるのである。 またかと思うが、ここでも会計の考え方をすればいい。 複数通貨あるいは買掛債務の考え方ができる。 このメカニズム自体はよく知られたものなので、 この状況にこのモデルを適用しさえすればよい。

私たちはこの考えを肉付けして現場に投入してみた。 そこでは、テスト駆動開発が非常に役に立つということも分かった。 あるグループが、計画的設計で数週間かけて見越マイルを整理した。 コア部分については、数日間に分割してTDDで行った。 難しかったのは、問題を具現化するために実例に焦点をあてることだった。

会計の例えは、ある行動に対してマイルをどのように付与するかを決めることにも適用できる（そのまま適用できるわけではないが）。 あらゆるロイヤルティプログラムには行動ルールがあるが、 それはロイヤルティプログラムの頻繁な変更に対応できるように柔軟でなければならない。 これは勘定記入（エントリ）のトリガとなるAgreement Dispatchersを使ったドメインイベントのモデルとして捉えることができる。 これはJohnと私が何度も使ったパターンで、 こうしたルールの変更にうまく対応できるものである。 基本的に参加者のクラスについての全般的なプログラムのルールを示した協定（agreements）があり、各協定はイベントのタイプと日付範囲がキーになった転記ルールから成り立っている。 ドメインイベントが発生したら（たとえばホテルに泊まったら）、この顧客のAgreement Dispatcherを参照して、イベントから転記ルールを取得する。 転記ルールを実行して、イベントに対応したマイルを示す適切な勘定記入を作る。 イベントを指す日時があるので、あとから転記ルールを変更できるが、 それでも古いイベントは操作できるし、 自動化された調整処理も正しく行うことができる。 （ これらのパターンについては、いずれ書き上げようと思う。ただ、これまでにWebに書いた内容を読んで、あなたが何らかかのアイデアを思いついてもらえれば幸いだ ）

ロイヤルティシステムのもうひとつの側面は、顧客の行動を追跡することである。 会計でも顧客の活動をシステムに記録する必要があるので、 ロイヤルティシステムは顧客の会社とのやり取りを記録する下地となる。 ほとんどの場合、これはデータマイニング（新しい製品やプロモーションにつながる顧客の行動パターンを見つけるもの）となる。 顧客の行動履歴を使って、プロモーションの成否を見積ることもできる。 たとえば、もしマイレージボーナスをつけたらその反応はどうなるか？といった具合だ。

私同様、JohnもReportingDatabaseの強い支持者である。 そして、この方式は上記のような問題にうまく適合している。 会計の側には様々なデータ構造が必要で、アクティビティが発生したときに定期的に更新されるデータを使用する。 一方、顧客行動分析の側のデータはすべて読み取り専用なので、 会計の側からやってくるあまり正規化されていないデータ構造が使える。 ただし、リアルタイムである必要はない。

さらに事を進めていくと、会計と顧客行動分析を完全に切り離したほうがよいと思えてくる。 通常、同じイベントを追跡するために、両者は同一の顧客ロイヤルティシステムに同梱されている。 しかし、内部では多くの点で違いがあるため、 同じイベントストリームを扱う2つの別々のシステムとして扱うのが 当然のように思えてくる。 （ 会計の側は、顧客行動分析の側に渡すイベントをいくつか生成することになるだろう ）

顧客行動分析では、新しい分析をサポートするためにシステムを頻繁に変更することがよくある。 我々は、顧客行動を記録した単一のイベントログを使って、「データマイナー（miner）」に渡すことができないかと考えた。 データマイナーは、分析のためにイベントログから情報を選択し、特定のデータ構造に変換する。 データマイナーはお互いに比較的独立しているため、構築は簡単である。

以上のように、我々の議論はJohn1人の経験から、 このようなシステムはこれからどのように作られるべきかといった2人の考察へと移っていった。 我々が今言えることは、 このようなビジネスアクティビティをよりよくサポートするシステムへとつながる新しい抽象化のセットを導入できるこの分野には、新しいアイデアを調査する余地はまだ多く残されているということだ。 このところ、ますます注目が集まっている。 我々にとって取り組むに値する実りある領域となっているようだ。