迅速なパスキー導入に必要な変更管理
パスキーのサポートを実装するエンドツーエンドのプロセスには、慎重な変更管理が必要です。最初からこれを予測しておくことで、作業のやり直しやフラストレーションの原因となる障壁を取り除くことができます。このプロセスでは、エンジニアリング、IT、法務、製品、ユーザーエクスペリエンス、コンテンツ戦略、マーケティングの各分野のリーダーが変更管理を行う必要があります。例えば、変更管理の取り組みには、部門間や分野間に存在するコミュニケーションサイロの橋渡し、部門間や分野間の依存関係の理解と定義づけのサポート、部門間の予算編成、および部門間連携が含まれます。
組織の賛同
「展開ガイド：迅速なパスキー導入」は、既存のエンドユーザーをパスキーに迅速に移行させ、新規アカウントではパスキーをデフォルトとして使用できるようにすることを目的に策定されました。これには組織全体の同意、さまざまな地域における複数部門とのプレゼンテーションやフォローアップが必要となります。具体的に言うと、この戦略では、パスキーの開始に伴うマーケティングキャンペーンを調整するマーケティングチームからの賛同と協力が必要になります。他にも、カスタマーサクセス・サポート部門からの賛同や参加も必須です。
多くの組織では、この戦略を最初に検討する個人が、パスキーに関する議論を上級リーダーにまで報告する業務を管理する必要があります。その後、上級意思決定者、または意思決定者らで構成される委員会がプログラムについてさらに調査を行い、最終的に複数の部門と世界中の地域にわたる実装プロジェクトを承認することになります。
組織横断的な計画
本戦略では、この統合に必要なタスクを完了するために、複数部門にまたがる複数チームの調整が必要となります。迅速な展開戦略には、組織横断的な計画が膨大に必要です。例えば、製品チームとエンジニアリングチームの場合、リスクと不正行為、マーケティング、およびユーザーサポートを担当する部門との連携が必要です。
この戦略は、複数の地域に適用されます。そのため、組織が異なる地域で活動している場合は、それらの地域間で協力する必要があります。
コンプライアンスと法的事項
パスキーは組織の環境に新しい認証方式を導入します。そのため、デジタルアイデンティティと認証に関するコンプライアンス、リスク、および法的変更を管理するのに必要となるタスクが存在します。プロセスの早い段階で、組織がパスキーの使用を検討していることをコンプライアンスチームと法務チームに伝えます。パスキーに関して十分な知識を持ち合わせていない場合は、参考資料として米国の国立標準技術研究所 (NIST) によるパスキーのガイダンス「NISTデジタル ID ガイドラインの強化」を通読するよう提案してください。NISTガイダンスによると、同期パスキーは当人認証保証レベル 2 (AAL2) を満たすと記載されています。すべての組織がNISTのガイダンスに従う必要はなく、またNISTは米国の政府機関ではありますが、世界中の多くの地域とさまざまな業界の企業が、信頼できる情報源としてNISTを定期的に参照し、意思決定の参考にしています。
一般的に法務チームは、ユーザーが自分のアカウントからパスキーを削除できる機能を持つことを要求します。FIDOアライアンスはこれを認識し、デザインパターン「サービスプロバイダーのアカウント設定からパスキーを削除する」を作成しました。このデザインパターンはユーザーエクスペリエンスの調査によって裏付けられており、必要に応じてこの法的要件を満たす、信頼性の高いユーザーエクスペリエンス・モデルであることが証明されています。このデザインパターンは法務チームからの一般的要件を満たすだけでなく、ユーザーがセキュリティ設定を制御し、パスキーを削除できるようにすることで、ユーザーからの信頼と満足度も向上させます。それにより、パスキーを忘れた場合やパスキーの紛失・侵害が発生した場合のお問い合わせ処理に必要なサポート費用とリソースも削減できます。
情報技術 (IT)
技術要件を特定する際は、パスキーを使用した認証アーキテクチャの長期的ビジョンを考慮します。例えば、パスキーとともに既存の認証方式を一定期間継続して使用することも1つの案です。その後、既存の認証方式は段階的に廃止できます。また別の検討事項として、パスキーが特定のドメインに限定される仕組みを理解することが挙げられます。初回リリ ースが少数のドメインに限られていても、長期的には複数のドメインへの対応が求められる可能性があります。例えば、マーケティング活動ではサブドメインを使用してマイクロサイトを立ち上げたり、時には新しいドメインを立ち上げたりすることがありますが、このような一部のマイクロサイトでパスキーを使用した認証サービスが必要になる場合があります。これはパスキーを実装する際に考慮すべき、数あるIT関連の検討事項の1つに過ぎません。
認証方針
一部の組織では、認証イベントのリスクを評価する技術を採用しています。IPアドレス、認証デバイスのオペレーティングシステムのバージョン、Wi-Fiフィンガープリントなど、サインインを試みるアイデンティティのテレメトリー情報は、エンドユーザーの次のステップを決定する一連の業務方針によって処理されます。この技術によりサインインが許可されたり、サインインの追加手順の実行が要求されたり、またはサインインがブロックされたりしますが、同時にこれらのデータはさらなる分析のために記録されます。一般的に、この作業実行に使用される一連の技術とシステムを「リスクエンジン」と呼びます。
パスキーにはフィッシング耐性などの独自のセキュリティ特性があるため、企業はパスキーとリスクエンジン方針の統合を選択することもできます。例えば、エンドユーザーがパスキーを作成した後に、リスクエンジンによって当該エンドユーザーによる使用歴がないと認 識されたデバイス上でパスワードを使った認証を試みた場合、リスクエンジンは当該エンドユーザーがアカウントの正しい所有者であると識別されるまで、トランザクションの種類に制限を設ける可能性があります。これはあくまでも、パスキー導入によって実現されるリスクエンジンの方針強化の一例です。採用するアプローチによって、方針強化にはさまざまな形態があります。
組織がリスクエンジンを活用している場合、この展開戦略では、初回リリースに向けてリスクエンジン方針への初期強化が行われることを前提とします。初回リリース後はさらにパスキーを登録したユーザーアカウント向けに、追加のリスク方針が強化できます。
ユーザーエクスペリエンス
迅速な展開戦略に向けたユーザーエクスペリエンスの最適化に必要な変更管理には、膨大な労力が伴います。適切に管理されない場合、ユーザーエクスペリエンスに悪影響を及ぼす可能性もあります。
例えば、エンジニアは理解しているものの、UXデザイナーやコンテンツストラテジストは理解していないパスキーのワークフローがあるかもしれません。またエンジニアには、ワークフローのユーザーエクスペリエンスを最適化するための十分な時間、ユーザーエクスペリエンスに関する知識、またはユーザーエクスペリエンスの調査による知見が不足している可能性があります。
別の例として、認証方針 や技術アーキテクチャに関する決定への変化が、ユーザーエクスペリエンスに影響を及ぼす可能性もあります。他にも、オペレーティングシステムが異なるとパスキーを使用したエクスペリエンスも異なる可能性があり、結果として、ユーザーエクスペリエンスに影響を与えます。
そのため、製品、エンジニアリング、コンテンツ戦略、IT、法務、およびユーザーエクスペリエンスのデザインを担当する各チーム間の連携が必要なユーザーエクスペリエンスのトピックを理解し、文書化して、解決する役割を検討することが重要です。この作業には十分な時間を費やし、慎重に検討する必要があります。ユーザーエクスペリエンスの決定を組織に伝え、組織全体で適切に解決する必要があります。
パスキーに取り組むチームメンバーは「デザインガイドライン」を読んでこれに従い、本作業に役立ててください。
ビルドとテスト段階を進めていくにつれて、ブラウザ、オペレーティングシステム、クレデンシャル・マネージャー（パスワードマネージャー）間で一貫性のない技術が見つかるかもしれません。パスキーに関する一部のユースケースで障壁に遭遇し、ユーザージャーニーにおいて好ましくない出来事に直面する可能性もあります。これらの課題を事前に理解するために、本フェーズの前後、およびフェーズ中には「トラブルシューティング」を参照してください。「トラブルシューティング」セクションには、FIDOアライアンスのメンバー企業によるパスキーのサポート実装から得られた知識とガイダンスが含まれており、実装に費やす時間を短縮できます。
ユーザーへの教育
この展開戦略は、エンドユーザーがパスキーを迅速に導入することを目的に策定されています。この目標を達成するには、組織とのやり取りを通じた様々な場面でパスキーをユーザーに紹介する必要があります。組織はこれらの各場面でエンドユーザーに十分な情報を提供し、パスキーを採用するよう誘導する必要があります。ほとんどのエンドユーザーがパスキーの採用を迅速に決定しますが、 なかには決定を下す前にパスキーについて詳しく知りたいと思う人も一定数います。
そのため、これらのユーザージャーニーを具体的に描き、役立つコンテンツを作成する必要があります。この参考として、パスキーのユーザー向けサポート資料の作成について詳し く知りたい場合は「ユーザーとのコミュニケーション」を参照してください。
