システム化構想のフェーズにおけるID統合の進め方｜2024年 | NRI Digital Consulting Edge

執筆者プロフィール

産業ITコンサルティング二部　塚原千紘：
2022年NRIシステムコンサルティング事業本部入社。
業務変革を伴うシステム上流工程・システム導入時のユーザ側活動支援に従事。

はじめに
ID統合の進め方
ID統合の4つのタスク
おわりに

はじめに

近年、顧客ニーズに対応し、より良い顧客体験を提供するために、企業はサービスや購入手段（店舗やネットなど）を多様化させてきました。一方で、顧客の情報はサービスやチャネルのシステムやデータベースにバラバラに存在しており、統一的な管理や効果的な活用ができていないのが現状です。そこで、顧客個人を識別する顧客IDを全社で統一し、サービスや組織の垣根を超えて利活用できるようにする“ID統合”に取り組む企業が増えています。企業が、ある顧客のデータを、サービス横断で管理することが出来るようになれば、サービスの垣根を超えて、その人に合ったより良い提案を行えるようになります。その結果、顧客は自分のニーズや好みに合ったサービスやコンテンツの提供を受けられるようになります。加えて、顧客はサービスごとにIDやパスワードを管理せずとも、一つのIDだけを覚えておけばよく、IDやパスワードを忘れた場合の再発行の手間が少なくなります。ID統合は、企業のみならず、顧客にもメリットをもたらします。
しかし、ID統合を知識不足のまま進めると、プロジェクトの途中で後戻りの手間・追加費用が発生してしまうことが起こりえます。また、統合IDの仕組みは出来たとしても、いざ使い始めてみたら各サービスで利活用できず、失敗に終わってしまうこともあるかもしれません。そこで今回は、ID統合プロジェクトの方針やプロセスを明確化するシステム化構想フェーズに焦点をあて、その進め方とよく直面する課題について詳しく解説します。

ID統合の進め方

ID統合は単なるシステムの効率化の話ではなく、ビジネスや業務プロセスにも影響を与えるため、その進め方の戦略が成功のカギとなります。ID統合プロジェクトの最大の目的は、「データを組織・サービス間で共有・活用できるようにすること」です。そのために、まず「統合IDの仕様検討」を行い、その後「プロセスの検討」を実施します。

統合IDの仕様検討

ID統合プロジェクトの初期段階で取り組むべきは、統合IDの導入目的を定め、それを達成できるような統合IDの基本ポリシーを策定することです。以下の順でタスクを実施することで、費用をかけて作り上げたID統合の仕組みが、目的とずれていた・使い物にならなかったという事態を避けることが出来るようになります。
①統合IDの目的設定
②基本ポリシーの策定

プロセス検討

統合IDを導入した際に、各ユースケース（登録/移行、ログイン/ログアウト等）において、ユーザーがどのようなプロセスを辿るのかを検討します。プロセスには、統合IDのシステム上で実施されるものと、各サービスのシステム上で実施されるものがあるので、その境界線をはっきりさせておくことも必要です。
具体的には以下の順でタスクを実施します。
③統合IDユースケース別標準プロセスの検討
④各サービスのユースケース別プロセスの検討

これら4つのタスクの進め方について、次の図に示します。

図3.1　 ID統合プロジェクトの進め方（一例）

組織・サービスの現場との連携がカギ

こうした取り組みを進める際、大切なのは「ID統合プロジェクトチームからの一方的な指示」ではなく、現場の声をしっかりと取り入れることです。組織やサービスごとに独自の事情やニーズがあるため、それを無視した統合プロジェクトは実務での採用が進まず、各現場で個別最適に走ってしまうリスクがあるからです。

そのため、プロジェクトチームは、組織・サービスの担当者と密接に連携し、それぞれの事情やニーズを尊重しながら、統合IDの仕様やプロセスを策定していくとよいでしょう。こうすることで、統合IDの採用がスムーズに進むだけでなく、実際の業務でのデータの共有や活用が効率的に進められます。

ID統合の4つのタスク

ID統合の進め方を理解したところで、4つのタスクそれぞれにおいて、実施すべき内容や起こりうる課題、その対策についてお話します。

①統合IDの目的の設定

まず、統合IDの目的を設定します。目的設定では、マイルストーン、スコープの認識合わせを行い、ID統合で目指す姿を関係者間で共有します。
関係する部門の間で目的の認識にズレがあった場合、ID統合プロジェクトの方向性が不明確になり、計画が遅れてしまうことにもなりかねません。

ID統合自体は、目的ではなく、手段にすぎません。「IDを統合することで、何を実現したいのか？」という目的を明確化しておくことが重要です。

②統合ID基本ポリシーの策定

次にID統合の目的に照らして、サービス共通の「統合ID基本ポリシー」を策定します。
基本ポリシーでは、通常、IDのつけ方や、管理対象となるデータ項目、ユーザー登録フロー（手順）の方針、個人情報の扱い方などを既定します。IDを統合する際、どのような方針・ルールにするかをサービス側と話し合い、「サービス側の要請」と「全体最適の観点」を擦り合わせて落としどころを探りながら、策定するのが良いでしょう。

基本ポリシーを検討するにあたり課題となるのは、共通ルールを作る側（ID統合推進側）とサービス側で主張のギャップが生じてしまうことです（図3.2）。主張にギャップがあると、話し合いで上手く折り合いがつかず、サービス側の個別事情を多く取り込まざるを得ないこともあります。

ただし、その場合でも、全体統制/最適化の観点から当初のビジネス目的に沿わないルールとなる可能性が高くなってしまうので、注意が必要です。設定した目的に立ち返り、何のために共通化しているかの観点から取り入れる/取り入れないの基準を明確化し、それぞれの個別事情について判断していきます。

図3.2　共通側とサービス側の主張ギャップの例

ポリシーは、サービス側に統合IDの意図・仕様を伝えるためのものです。そのため、図表を用いたドキュメントにすることが望ましいでしょう。暗黙知は認識ズレの原因になるため、「当たり前」のことでも言語化・可視化しておきましょう。また、ルールを崩すときにどういう影響があるのかを把握するため、「ルールの策定理由」も明確化しておくことがポイントです。

③統合IDユースケース別標準プロセスの検討

ポリシーを設計したら、ユースケース（登録/移行、ログイン/ログアウト等）ごとにサービス共通の標準プロセス（手順）を定義していきます。このようにすることで、どのサービスでも同じような流れで操作でき、使いやすさを保つことができます。標準プロセスが出来たら、それをもとに、それぞれのサービスに合わせて具体的な対応を検討しますが、その結果、必要に応じて標準プロセスを見直すこともあります。

統合IDのユースケース別標準プロセスを検討するにあたり、ID統合を推進するチームがぶつかりうる課題は、3つあります。

1つ目は、ユースケースが網羅されていないことです。
すべてのユースケースを抽出するには、あらゆる利用シーンを想定する必要があります。図3.3にあるように、「誰が」「何を」するのかを場合分け・整理し、それぞれのプロセスを検討していきます。しかし、十分検討したつもりでも、プロジェクトメンバーは個々のサービスの手順について詳しくないため、特に例外的な利用シーンを見落としがちです。その結果、ユースケースの検討漏れが起こり得ます。
ユースケースの検討漏れを防ぐためには、各サービスの担当者に対する個別ヒアリングに加えて、複数の関係部門を集めたワークショップを開催して多角的に検討することが効果的です。また、将来のビジネス環境や技術革新の状況を見据えて、潜在的なユースケースを定期的に予測することも有効だと考えられます。

図3.3　ユースケースの洗い出し例

2つ目は、個別サービス特有のケースに対する検討が漏れてしまうことです。
個々のサービスに最適化されている手順や業務フローへの影響についての確認が不十分だと、導入後に様々な混乱が生じる可能性があります。例えば、一部のサービスでは、セキュリティの観点から二要素認証が必須であるが、別のサービスでは顧客の利便性を重視しシングルサインオンにしたいと考えるかもしれません。
検討漏れがないようにするには、サービス担当部門への十分なヒアリングが不可欠ですが、それ以外の部門の異なる視点からの意見も重要です。例えば、カスタマーサービス部門やユーザインタフェース（UI）デザイナーから顧客視点に立った意見をもらうことでユースケースの検討漏れを防げる可能性があります。

3つ目は、社内の別部門の担当者に関する検討が漏れてしまうことです。
統合IDの導入には、マーケティングやコールセンター、法務など複数部門の協力が必要ですが、事前確認や情報共有が不十分だと、導入後の運用に支障をきたす可能性があります。
別部門の担当者に関する検討漏れを防ぐには、プロジェクトチームが単独で進めてしまうのではなく、プロジェクトの初期段階から、様々な部門を代表するステークホルダーに参加してもらい、定期的なミーティングを通じて部門間の情報共有や調整が円滑に進むような体制づくりも重要です。

④各サービスのユースケース別プロセスの検討

サービス共通の標準プロセスを策定した後、個々のサービスについて、誰が何をするかを整理し、ユースケースを洗い出し、標準プロセスと比較検討していきます。（図3.4）

この時にポイントになるのは、標準プロセスに沿わないケース（イレギュラーケース）の有無の確認です。後からイレギュラーケースの存在が発覚した場合、基本ポリシーの見直しにつながり、ID統合に向けたシステムの移行や改修が難しくなる可能性が高くなります。そのため、仮に統合IDに取り入れないことにした場合でもプロセスを具体化し、「スコープ外としても問題はない」「プロセスの拡張で対応できる」といったレベルの確認が必要です。

図3.4　個々のサービスにおけるユースケース検討

また、現在の仕様と統合後の仕様で、各サービスのセキュリティレベルを比較検討することも必要です。なぜなら、セキュリティレベルとユーザビリティは基本的にトレードオフの関係にあるからです。総合的に検討した結果、セキュリティレベルの低下を許容するケースもあり得ますが、どの程度のセキュリティレベルが必要かに関する検討は、忘れてはならない重要なタスクです。

各サービスのユースケース別のプロセス検討で、起こりうる課題として2つ考えられます。

1つは、イレギュラーケースを十分に洗い出せないことです。ID統合の経験値がない場合、イレギュラーケースの洗い出し観点すらわからない、といったことになりかねません。
これを防ぐためには、ID統合の経験が豊富な外部の専門家を活用することが有効です。過去の類似プロジェクトで生じたイレギュラーケースを共有してくれるので、自社だけでは気づきにくいケースを網羅的に洗い出すことができるでしょう。

もう1つはセキュリティレベルの問題です。セキュリティレベルの比較のやり方がわからない、セキュリティレベルが低下してしまうことがわかっても、対処法がどうすればいいかわからないといった課題にぶつかることもよくあるのです。

IT部門など情報セキュリティを担当している部門に協力を仰いだり、外部の専門家を活用することが有効です。彼らがセキュリティ水準を評価し、リスク分析を行って、必要な対策をアドバイスしてくれます。低下が避けられない場合は、代替措置を提案してくれるでしょう。

おわりに

本記事では、ID統合の進め方と、直面しうる課題、その対策について説明しました。
ID統合で避けなければならないことは、統合IDの仕組みだけを用意し、運用を各サービス側にゆだねてしまうことです。サービスごとの個別最適に陥る可能性が高くなってしまいます。そうならないためには、ID統合を推進するプロジェクトチームと各サービス側で、継続的に協議と調整を進めていくことが重要です。
弊社は、お客様のID統合プロジェクトをご支援し、成功まで伴走させて頂いた実績が多数ございます。ID統合を推進するチームの方々が直面しうる課題の解決に向けての知見も持ち合わせており、円滑なプロジェクト推進にお力添えできますので、お困りの際は是非ともご相談ください。