顧客ID統合の失敗、なぜ起こる？ 企業が陥りがちな2つの落とし穴（1/3 ページ）

[丹下雄太, 宮澤夢実, 塚原千紘，ITmedia]

丹下雄太・宮澤夢実・塚原千紘

野村総合研究所

前回の記事：CXは「経営のミッション」だ──顧客の期待値を“良い意味で”裏切るための戦略は？

　近年、顧客ニーズに応え、より良い顧客体験を提供するために、企業はサービスや購買チャネルを多様化させてきました。それに伴い、各サービス・チャネルで取得した顧客情報を“一つのID”で管理し、サービスや組織の垣根を超えて利活用する企業が増加しています。

写真はイメージ、ゲッティイメージズ

　例えば、多岐にわたるサービスを展開するリクルートは、「SUUMO」「Hot Pepperグルメ」「じゃらん」など、生活に密着した多種多様なサービスを提供しています。かつては独立していた顧客基盤を、2014年頃から段階的に統合を進め、現在では45以上のサービスが共通のID（以下、共通ID）でログイン可能になりました。

　サービス間の移動がスムーズになり、サービス利用時の利便性が大幅に向上。また、サービスの利用履歴や顧客行動データを横断的に分析・活用することで、よりパーソナライズされた情報提供・レコメンドを実現し、顧客体験を向上させています。

　他にも、日本経済新聞（日経ID）、三菱地所（MachiPassアカウント）など、ID統合で新たな顧客体験を提供する企業は多数あります。楽天グループ（楽天ID）など、新たな“経済圏”を築く企業もあります。

　今回の記事では、ID統合に実際に取り組むうえでのポイントや難しさなどを、詳しく紹介します。

顧客ID統合の失敗、なぜ起こる？　実行時の6つのポイント

　そもそも、「なぜID統合が必要なのか」「ID統合をしない場合、どのような課題に直面するか」について、まず確認してみましょう。

　多角的な事業展開・サービス提供を行う大企業ほど、共通IDが各サービス・部門で個別に取得・管理され、マーケティング施策や各種取り組みを検討・実施していますが、課題が多いのが現状です。

　図1-1では、その課題を「ビジネス」「CX（顧客体験）」「業務・システム」「コンプライアンス・セキュリティ」の4つの観点で整理し、確認します。

図1-1：顧客ID統合をしない場合に直面しがちの課題

　顧客情報が分断されていると顧客の全体像（購買履歴、行動履歴など）を正確に把握することが難しく、顧客一人一人に合わせてパーソナライズされたサービス・コンテンツを提供することもできなくなります。これにより、顧客は「自分に合わない情報ばかり届く」と感じ、顧客満足度・ブランドへのエンゲージメントの低下につながります。また、事業横断での相互送客が困難になり、事業間シナジーを創出しづらく、ビジネス成長の鈍化・競争力の低下も招きかねません。

　ID統合は、CX向上に不可欠な取り組みであり、多くの企業がその実現に向けてプロジェクトを推進しています。しかしながら、ID統合を知識不足のまま進めると、プロジェクトの途中で後戻りの手間や追加費用が発生する可能性が高くなります。

　また、共通IDの仕組みができたとしても、いざ使い始めてみると、各サービスで利活用できず、失敗に終わってしまうことも少なくありません。次は、事業者主体のタスクを中心に、ID統合プロジェクトの進め方についてご説明します。

図2-1　ID統合の進め方

（1）ID統合の目的設定

　プロジェクト初期段階で最も重要なのは、ID統合の目的を明確に設定することです。ID統合はあくまで手段であり、目的ではないことに注意しなければなりません。関係者間でマイルストーンやスコープの認識合わせを行い、「ID統合で何を実現したいのか」という共通の目指す姿を合意しておくことが重要です。

（2）共通ID基本ポリシーの策定

　設定した目的を達成するために必要なサービス共通の「共通ID基本ポリシー」を策定します。ID統合は全体最適化のための活動となるため、現状のシステムや組織の事情を考慮しつつ、全社方針としてサービス側に守ってもらいたい事項を明確化し、ポリシーとして取りまとめる必要があります。

　一般的にポリシーとして定義すべき項目は、以下の通りです。

• IDの単位（例：1個人1ID（複数個人間の使いまわしはNG）
• IDの形式（例：共通のログインIDはメールアドレス）
• 共通データ項目（例：共通データ項目は、氏名・生年月日・電話番号）
• ユーザー動線（例：情報入力後に、仮登録メールの確認が完了したら、登録完了）
• 規約方針（例：マーケティング目的で、グループ間での情報共有は可とする）

　この段階で重要なのは、多様なサービスが持つ個別事情を考慮しつつも、ID統合の本来の目的を見失わない、バランスの取れたポリシーを策定することです。加えて、策定したポリシーは図表で可視化し、策定理由も明確にしておくことも大切です。将来的にポリシーの見直しが発生した際にも、影響範囲を把握しやすくなります。

（3）ロードマップの策定

　統合の対象となるサービスが数多く存在する場合、一度にID統合を実施しようとすると失敗に終わることがほとんどです。膨大なリソースが必要となることに加え、多様なシステム間の連携や関係部門間の合意形成を一度に行うことが極めて困難となるためです。

　1stスコープとすべきサービスは、ID統合の効果・難易度の2軸で評価した結果、効果が大きく、難易度の低いサービスです。加えて、プロジェクト推進上の制約事項や、サービス間の親和性なども踏まえ、ID統合のロードマップを策定します。

（4）要求事項整理

　1stスコープの決定後、業務・システム観点の要求事項整理に着手します。

　この段階では、まず登録、移行、ログイン、ログアウトといった主要なユースケースについて、サービス共通の標準プロセスを定義します。これにより、顧客へ一貫した操作性を提供し、CXの向上を目指します。

　その際、「誰が」「何を」するのかという観点からユースケースを網羅的に洗い出すことが重要です（図2-2参照）。また、ユーザーだけでなく、コールセンターやマーケティング運用者など、関連する全てのステークホルダーを考慮する必要があります。

図2-2　ユースケースの洗い出し方（例）

（5）移行・運用準備

　開発が始まれば、ユーザ側では運用開始に向けた対応を進めます。主な項目としては、以下の通りです。

• 知財・法務関連の対応：共通IDの名称検討、商標登録、規約文章検討
• 新業務運用開始に向けた対応：業務マニュアル作成、教育実施
• ユーザー周知・移行に向けた対応：ユーザー周知方法検討、関係者周知方法検討、移行促進施策検討

　これらの項目は、単にシステムを構築するだけでなく、実際にID統合を成功させ、ユーザーに共通ID利用してもらうために不可欠です。開発と並行してこれらの準備を進めることで、サービスイン後の混乱を最小限に抑え、円滑な運用開始を実現します。

（6）移行促進・運用

　共通IDへの移行は、既存ユーザーの利便性を考慮し、主に「任意移行」と「強制移行」の2段階の期間を設けて実施されます。任意移行期間では、既存のIDと共通IDが並行して利用できる状態とし、ユーザーが自身のペースで新しいIDへの切り替えを進められるようにします。

　この期間では、既存ユーザの共通IDへの移行状況を継続的にモニタリングすることが極めて重要です。移行率が目標に達しない場合は、その原因を分析し、移行キャンペーン内容の見直しや新たなインセンティブの導入、ユーザー周知方法の改善など、適宜施策の改善を図ります。

　改善を繰り返して目標の移行率に達したら、強制移行期間へと移行し、共通IDへの完全な切り替えを促します。