前回は、「なぜ統合されたID基盤が必要なのか」について特にビジネス的な側面での目的を明確にしてきました。今回は前回一覧レベルで掲載した、統合ID基盤導入を進めるにあたって注意すべきポイントを整理していきたいと思います。
統合ID基盤導入をご検討されている方はぜひご一読頂けると幸いです。
目次
デジタルサービス展開計画のスケジュール感を確認
まず大前提として、「統合されたID基盤」を導入する目的からして、複数のデジタルサービスがこの基盤を活用することになります。新規サービス、すでに作り始めているサービス含めて、今後どのようなスケジュール感で展開されていくかを整理してみることが必要です。
例えば新規サービスを作り始めてしまっている場合には、そのID管理機能の実装は独自で進めてしまい、その後移行が必要になることは統合ID基盤プロジェクトにおける重要なファクターです。移行が不要になるようにするために、フェーズを切って統合基盤を進化させていくことを前提に、はじめの統合ID基盤がどういう機能を提供すべきかの作戦を立てる必要があります。
＜ポイント＞
- 直近2−3年程度のウェブアプリ展開計画を確認
- 一番手前のウェブアプリの対応をどう考えるか？
- 移行／新規対応の作戦はどうするか？
また、スピード感を持ちつつ、継続的に開発していくためにはどのような技術／サービスが適切なのかを考える必要もあるでしょう。スピード重視かつ、機能をアップデートしていくことを考えた際には、OSSを活用した開発はブロッカーが多くあることがあり、SaaSを活用することでスピードアップや継続開発の手間を削減することが見込まれます。
既存サービスの移行の有無を確認する
前項にもある程度書いてしまいましたが、スケジュールと合わせて、既存サービスが複数ある場合にはそのサービスに登録したユーザーを移行していく必要があります。既存サービス向けのID関連（ユーザー管理、ログインなどの認証認可）の実装技術がなにかを明確にする必要があります。
詳細については要件定義フェーズで技術的な進め方を細かく定義していきますが、まずは移行有無と、その難易度の簡易的な評価をすることで求めるスケジュール感に無理がないかなどのフィージビリティ確認ができます。
＜ポイント＞
- 既存サービスからのユーザー移行は必要か？
- 必要な場合、そのサービスで使われているID関連の技術は何かを確認する
サービス提供形態や契約体系を把握する
提供事業者毎にサービスの提供形態は様々です。大きなくくりでいうと、B2CやB2Bのような言葉があるように、消費者向けサービスや、法人向けサービスのような分類があります。また、提供するサービスはB2B2Xのように、法人経由で個人に提供されるということもあるでしょう。あるいは、パートナー企業向けというサービスもあるでしょう。
更には、サービス利用が「個人」だけで利用するのか「組織」として同じサービスを使うのかなどの分類もあります。
それぞれのユーザーを単一として捉えるだけでよいのかは、個人に対して課金し、サービスを享受させるのか、チーム／部署／会社などの組織に対して課金し、利用させるのかで変わってきます。
開発観点ではこれらの内容を予め考慮しておく必要があります。これが整理されていない場合、ユーザー／組織の設計を変えることは大きな改修となる可能性がありますので要注意なポイントです。
また、複数サービスを提供する場合、サービスAでは ＜フリー＞と＜有償＞の2パターンのみ、サービスBでは＜Basic＞＜Standard＞＜Premium＞のような3パターンが提供され、パターン毎に利用できる機能が変わってくるなどのことがあったりします。ID管理とも密に連携する部分ですので予め決まっていることがあれば整理しておく必要があります。
＜ポイント＞
- 提供するサービスはB2B、B2Cなのか、提供する対象のイメージを明確化する
- 各サービスの契約形態などは広く調査しておく
アプリケーションのオンボーディング設計
オンボーディングという言葉は、新入社員やパートナー企業に対して自社のサービスを利用させることを想像するとわかりやすいかと思います。例えば、パートナー企業に対してMicrosoftのアカウントを発行し、SharePointのサービスを利用させるには、何らかの申請書に記載すると、管理部門が1〜2週間で発行してくれる、のようなイメージです。
このように管理者がユーザーを追加するのか、あるいは消費者向けサービスのようにユーザー自らがサービスにID登録をするのか、このあたりのイメージ感を明確にすると良いでしょう。
管理者がユーザーを追加する場合には、提供するサービスの業務管理ユーザーが使える画面を開発する必要がありますし（ほとんどの場合必要になります）、ユーザー体験とセキュリティ要件をどのレベルにするのかなども重要なポイントです。B2B、かつITリテラシの高い企業をターゲットにする場合には、Google Authenticatorなどの他要素認証を使うことでセキュリティ強化ができますが、一方B2Cで数多のユーザーカテゴリを対象にする場合にはソーシャルログイン、SMS認証、パスワードレス認証など様々な方法を提供することでユーザーが慣れ親しんだ手法を使ってもらう必要があったりします。
このようにオンボーディングを考えることで芋づる式に様々な検討項目が見つかってきます。
＜ポイント＞
- 提供するサービスはどのようにしてユーザーを追加するのか？
- ターゲットユーザーを明確にして、ユーザー体験（UX）とセキュリティのバランスをどのレベルに設定するのか？
ユーザー属性データの責任分界点の明確化
こちらはかなり技術的な内容になってきますので、要件定義フェーズで具体化することになるかと思いますが、それよりも上流工程で明確にするのは、サービス全体でどういうユーザー情報を獲得したいのか、それらはどこで獲得できるのかを明確にしておくことでしょう。
例えば、一般的なユーザー情報については、サービス全体を提供する入口となるポータルサービスで入手し、管理することが望ましいかもしれません。ポータルサービスがないのであれば、ID登録・ログインをする機能をIDサービスと位置づけ、そこで収集・管理することになるかもしれません。
このように全体としてどのようなサービスに仕立て上げていくかを明確にしなければ、重複したデータをユーザーに求めたりしてしまい、顧客体験の低下につながる可能性もあります。また、サービス間でデータのやり取りなども生じるでしょうから、サービス提供の企画として、どのサービスでどのデータを獲得するかなどの責任分界点の明確化はしておく必要があるでしょう。
また、これらのデータを統合管理し、なにかのダッシュボードで閲覧するなどの可能性もあると思います。データ利活用の具体的なイメージを改めて整理することで、次のステップとしての効果的な活用方法はなにかを明確にすることも大事です。さらには、CRMやMAとのシステム連携まで考慮が進んでくると思います（あまり広がり過ぎるとキリがなくなるため、プロジェクトとして別にし、何を受け渡すかの検討になるかと思います）。
＜ポイント＞
- サービス全体構想をもとに、どのサービスでどのユーザー属性データを獲得するのかを明確にする
- これらのユーザーデータはどのように活用するのか、受け渡すデータを明確にする
おわりに
TC3では『デジタル顧客接点トータルサービス』として、Okta Customer Identity Cloud（旧Auth0）の導入からアプリケーション開発までをトータルでご支援しております。トライアルの段階から、どのようにIDaaS/CIAMを導入するかについてもサポートさせていただきますので、お気軽にお問い合わせください。
●資料ダウンロード●
デジタル顧客接点トータルサービスに関する詳細のご紹介資料は以下からダウンロードいただけます！
