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