会員システム設計論

この連載では、３０年以上の会員システム設計・運用経験をもとに、AI時代に求められる新しい会員システムの設計思想を探究しています。一つひとつの「当たり前」を問い直しながら、未来の会員システムを読者の皆さまと一緒に考えていきます。

前回のおさらい

前回は、Google、Microsoft、Apple、AWSが、それぞれ異なる技術を提供しながらも、「状態」と「信頼」を管理していることを見てきました。

そこには、共通する設計思想がありました。

今回の問い

世界から学んだ設計思想を、私たちの会員システムに取り入れることはできないでしょうか。

目次 / OVERVIEW
メールは届いた。では、その人とは今もつながっていますか。送信成功・バウンスなし・SPF/DKIM/DMARCの認証も正常で、配信完了——システム評価は100点。それでも、受信トレイにない・迷惑メールに入っていた・気づかれていない・開封されていない、という理由で利用者体験は0点になりうる。よくある「届いたのに、届いていない」ケースは、迷惑メールへの分類、他のメールに埋もれる、開封されない、内容が伝わらない、行動につながらない。解決のカギは利用者視点の設計。システム視点（送信できたか・エラーはないか・認証は通っているか）という技術的な正しさから、利用者視点（本当に届いているか・気づいてもらえるか・理解してもらえるか・行動してもらえるか）というコミュニケーションの成功へ。これからの会員システムが意識すべきは、利用者の状況を想像する・伝わる設計をする・信頼される関係を築く・データで体験を見直す・改善を続ける文化を持つこと。
システムは100点でも、利用者体験は0点になりうる。「届く」はスタート地点にすぎない――第5回の全体像。

ある日、一件の電話がありました。「メールが届いていません。」——会員システムを運営していると、決して珍しい問い合わせではありません。

私はシステムを確認しました。送信成功。バウンスなし。SPFも正常。DKIMも正常。DMARCも正常。Gmailへの配送も正常。システムには、何一つ異常がありませんでした。では、何が起きていたのでしょうか。

第1章　メールは届いていた

会員の方と一緒に画面を確認しました。すると——「あっ……。」開いていたのは、別のGmailアカウントでした。

最近、このケースは本当に増えています。一人が複数のGmailアドレスを持つ時代です。仕事用、プライベート用、昔つくったGmail、Google Workspace。本人は「いつものGmail」を見ているつもりでも、実際には別のメールボックスを開いていることがあります。

メールは届いていた。
しかし、見ているメールボックスが違っていた。

会員システムが学ぶべきこと

「メールが届かない」のではありません。「利用者がどのメールボックスを見ているのか」が複雑になった時代なのです。

第2章　人は、自分が思っている以上に間違える

別の日。また電話がありました。「絶対にメールは見ていません。」私はログを確認しました。メール開封。URLクリック。ログイン。設定変更。——すべて、記録されていました。

後日、その方から「すみません。自分で操作していました。」というご連絡をいただきました。

私はこの仕事を長く続けていて思います。人は間違えます。私も間違えます。記憶も間違えます。思い込みもあります。だからログがあるのです。ログは、人を責めるためではありません。人を助けるためにあります。

会員システムが学ぶべきこと

人が間違えないことを前提に、システムを設計してはいけません。人は間違える。だからこそ、システムが支えるのです。

第3章　メールアドレスは、人が最も間違えやすい入力項目の一つである

システムを運営していると、メールアドレスの入力ミスには、驚くほど多くのパターンがあることに気付きます。

特に @ より前（ローカル部）が長く、英数字や記号を組み合わせた独自の文字列になっているアドレスでは、こうしたミスに遭遇する機会が比較的多いと感じます。しかし、問題は長いアドレスだけではありません。短いアドレスでも、人は同じように間違えます。

メールアドレスは、
人が最も間違えやすい入力項目の一つである。

名前や電話番号と違い、メールアドレスは「正しいかどうか」を人間が見ただけでは判断しにくい情報です。一文字違っても、それらしく見えてしまう。だからこそ、本人も間違いに気付けないのです。

会員システムが学ぶべきこと

メールアドレスを保存するだけでは足りません。人が間違えることを前提にした入力支援や確認の仕組みも、会員システムの重要な役割です。

第4章　システムは正しい。でも利用者体験は失敗している

私はこの仕事を長く続けていて、何度も同じ場面に出会ってきました。送信成功。バウンスなし。SPF認証も正常。DKIMもPASS。DMARCもPASS。Gmailへの配送も正常。システムから見れば、100点です。しかし、電話の向こうでは「届いていません」という会員がいます。

システムは正しく動いていた。
しかし、利用者体験は失敗していた。

ここには、見落とされがちな、しかしとても大切な区別があります。

送信が成功することは、システム上の成功です。ログには「送信成功」と記録され、認証もすべて通っています。技術的には、何一つ間違っていません。

しかし、その会員がメールを見つけられない、内容を理解できない、安心できないのであれば、コミュニケーションとしては失敗しています。届けたつもりが、その人には届いていない。そして、それはシステムログには決して現れません。

システムログの成功と、
利用者体験の成功は、同じではない。

私は、この違いこそが、これからの会員システムに最も重要な視点だと思っています。会員システムの目的は、メールを送ることではありません。人とつながることです。

会員システムが学ぶべきこと

システムの成功と、人とのコミュニケーションの成功は、同じではありません。

第5章　私は、メールの話を書いていたのでしょうか

ここまで読んでくださった方は、もしかすると、この連載を「メールの記事」だと思われているかもしれません。実際、私はずっとメールの話を書いてきました。少し、振り返ってみます。

こうして並べると、たしかに、メールの連載に見えます。

しかし、違います。

私は、メールの話を書いていたのではありません。
人との関係——Relationshipを書いていたのです。

メールアドレスは変わります。会社も変わります。連絡手段も変わります。それでも、会員との関係は続いていきます。だから、会員システムが管理すべきものは、メールアドレスではありません。人との関係です。

第6章　管理したいのは、メールアドレスではなくRelationship

もう一度、整理します。私たちが本当に管理したいのは、メールアドレスという文字列ではありません。その人との関係——Relationshipです。

では、目に見えないRelationshipを、どうやって継続的に把握すればよいのでしょうか。その一つの考え方が、Relationship Score（関係性スコア）です。例えば——

項目スコア（例）
メール開封+5
クリック+10
ログイン+20
イベント参加+30
購入+50
半年、反応なし−40
ハードバウンス−100

ここで大切なのは、これがマーケティングの点数ではない、ということです。誰が「優良顧客」かを選別するための数字ではありません。その人との関係が、今どれくらい健全かを見るための、状態指標です。第2回で提唱した「メールアドレス・ヘルスチェック」は、ここへつながります。メールアドレスの健康状態だけではなく、人との関係そのものを継続的に見ていく。それが、これからの会員システムだと私は考えています。

まとめ

私はこの仕事を長く続けていて、思うことがあります。人は間違えます。メールアドレスを入力し間違える。違うGmailを開く。「見ていない」と思っていたら、実は昨日開いていた。転送設定が変わったことに気付かない。

だから、システムは、人が間違えないことを前提に設計してはいけません。人が間違えることを前提に、人との関係を守るために設計する。それが、私の考える会員システム設計論です。

メールは、人とつながるための一つの手段にすぎません。しかし、Relationshipは、メールよりもずっと長く続きます。メールアドレスは変わる。連絡手段も変わる。それでも、人との関係は続いていきます。

だから、管理すべきものは、メールではありません。
Relationshipです。

THE CORE IDEA
管理すべきは、メールアドレスではない。人との関係である。

メールアドレスは変わります。連絡手段も変わります。それでも、人との関係は続いていきます。システムの成功は、ゴールではありません。会員を管理する時代は終わりました。これからは、人との関係を設計する時代です。

会員システム設計論 ― 人との関係を、設計する。連載ロードマップへ 連載ロードマップを見る

エビデンス・参考資料

本連載は、公表されている技術仕様や各社の公式ドキュメントを参考にしつつ、筆者が長年にわたり会員システムを運営・設計してきた現場での経験と考察をもとに構成しています。

前回 ── 第4回
認証されても、信頼されるとは限らない。
前の話を読む
次回 ── 第6回
会員マスターは、住所録ではない。
次の話を読む
NEXT ── 次回予告
会員マスターは、住所録ではない。

メールアドレスではなく、Relationshipを管理する。では、その目に見えない関係を、継続的に育て、動かし続けるには、何が必要なのでしょうか。次回・第6回では、人を中心に据えた次世代の会員システムの土台——「Relationship OS」という考え方をご提案します。従来の会員マスターは単なる「住所録」に過ぎませんでした。これからの会員マスターは、複数のメールアドレス・複数のデバイス・複数の接点を持つ「一人の人間」を中心に、その人との関係の歴史と現在地を記録・管理する、Relationshipの地図になるべきです。

第6回 会員マスターは、住所録ではない。Relationship OSという設計思想の概要図。 第6回を読む
「人との関係」を設計する会員システムへ

複数アカウントの名寄せ、メール不達のケア、エンゲージメントの可視化まで。PayAI NEXTでは、メールアドレスを単なる文字列ではなく「人との関係」として捉え、Relationship Score やメールアドレス・ヘルスチェックを核とした会員システムの設計・運用プランをご提案しています。お気軽にご相談ください。

岸本 健志
岸本 健志
会員ビジネスLab 主任研究員 / ハートランドITイノベーション代表

1997年よりインターネット業界に従事。2007年の創業以来、EC、メディア、SaaS、コミュニティサイトなど数多くの会員ビジネスの立ち上げと成長を支援。

30年近く会員システムの設計・運用に携わる中で、システムは「会員を管理するもの」から「人と人との関係（Relationship）を育てるもの」へ転換すべきだと確信。現在は、AI時代における次世代のシステム設計思想として「Relationship OS」を提唱しています。

また、自身も宿泊施設の運営で現場に立ち続け、『起きている時間はすべて仕事であり、システムへの探求』という圧倒的な熱量で、会員ビジネスの未来に向き合っています。

「人との関係は設計できるのか」という問いに、これからも人生をかけて愚直に向き合い続けていきます。

← 会員システム設計論 連載一覧へ