移行の準備をする
学習の目的
この単元を完了すると、次のことができるようになります。
- 移行前アクティビティを定義する。
- 移行前アクティビティを実行する。
効果的にクライアントを Enterprise Grid に移行する前に行う必要があるアクティビティを見ていきましょう。Grid 移行チェックリストは、クライアントと共有し、移行準備中に参照できる便利なドキュメントです。
クライアント向けの移行概要プレゼンテーションを計画する
移行概要プレゼンテーションは、Grid 移行に対してクライアントの準備を整えるために不可欠で、プロセスの早い段階で行う必要があります。移行前、移行中、移行後に何が行われるかを把握してもらうためのものです。次の項目を含めます。
役割と責任
- プロジェクトチーム
- 移行前に SSO 設定とデータクリーンアップを行う主要なステークホルダー
- 変更管理を担当するプロジェクトチームマネージャー
プロセスの概要
- 移行の基本
- 移行の準備
- 移行中に想定されること
- 移行後に想定されること
アクティビティのタイミング
このセッションでは Grid 移行プロセスの概要を説明し、移行前アクティビティを開始するため、通常、このセッションはプロジェクトの比較的早い段階で行う必要があります。
目標日を選択したら、Slack と連携して移行をスケジュールします。移行は事前に十分余裕をもってスケジュールすることが重要です。
概要レベルで、移行前アクティビティには次のものが含まれます。
- Grid OrG の設定
- 移行前計画
- 移行前クリーンアップ
以降のセクションでは、Grid 移行チェックリストの各アクティビティを完了するためのステップとベストプラクティスについて詳しく説明します。
Grid OrG の設定
ワークスペースを Grid 環境に移行する前に、Grid OrG を設定する必要があります。これには、移行先組織の作成と、設定プロセスを実行する OrG のプライマリーオーナーの選択が含まれます。クライアントが初めて Grid を使用する場合は、ライセンス署名によって、初期設定を実行するように招待するメールがトリガーされます。すでに Grid を使用中の場合は、この Grid OrG 設定はすでに完了しています。このアクティビティには Enterprise Grid の移行先とシングルサインオン (SSO) が含まれています。
移行前に Grid で SSO を設定することは必須です。これは、Grid 環境ではユーザーがサインインする方法が SSO であるためです。
Enterprise Grid の移行先
移行を計画する前に、Enterprise Grid の移行先 (org.enterprise.slack.com) が設定されていることを確認します。そのために、OrG のプライマリーオーナーを選択するようにクライアントにアドバイスします。OrG のプライマリーオーナーは Grid OrG を設定するためのメールを受信し、クリックによって初期設定を完了します。OrG のプライマリーオーナーがサービスアカウントを使用してこの設定を完了することをお勧めします (slack_service_account@company.com など)。
さらに、Slack チームと連携して、クライアントが移行するすべてのワークスペースの請求を Enterprise Grid OrG にリンクします。有料ワークスペースは、請求書が Grid にリンクされていなければ移行をスケジュールできません。請求リンクによって、移行するワークスペースが全体的な Grid ライセンスにまとめられ、クライアントはスタンドアロンワークスペースに対して請求されなくなります。合併や買収の場合は特にこれが重要です。
最後に、クライアントが移行前にテストの実施を計画している場合は、Slack と連携して Grid サンドボックス環境を設定します。
シングルサインオン (SSO)
上記の前提条件を完了したら、移行する前に、クライアントが移行先の Grid に SSO を設定していることを確認します。Grid 環境にログインするメンバーは Okta などの ID プロバイダー (IDP) を通じて認証する必要があるため、SSO の設定は必須です。ただし、ゲストについては、お客様が該当オプションを有効にすれば SSO を回避できます (ほとんどのお客様はゲストに SSO を義務付けていません)。
それ以外で SSO を回避する必要があるユーザーがいれば、SSO 除外リストに追加することで特定のメンバーに対する SSO を回避するオプションがあります。この機能によって特定のユーザーに柔軟性を提供できますが、全体として SSO を回避するスケーラブルなソリューションとして使用すべきではありません。
クライアントが移行前にユーザーを事前プロビジョニングすることはお勧めしません。そうすると、プロフィール照合のために移行プロセスの所要時間が長くなるためです。
移行前計画
Grid OrG を設定したら、移行前計画で次に行う一連のステップでは、ユーザーに移行についての適切な情報を提供し、スケジュールされたタイミングで移行するために適切なワークスペースの準備を整えます。
ヒント: クライアントはチーム内の人材にプロダクトオーナーや管理者などのさまざまな Slack メンバー種別を割り当てます。このようなメンバー種別には、移行前計画ステップでの責務があります。
指定されたメンバー種別についての詳細は、「リソース」セクションの Slack ヘルプ記事を参照してください。
エンドユーザーコミュニケーション
Grid 移行は Slack ユーザーのエクスペリエンスとデータに影響するため、移行前に組織のほかのユーザーにコミュニケーションを送信するようクライアントに促す必要があります。移行の中で最も大きな影響を及ぼすのは、従業員が Slack にアクセスできなくなる完全なダウンタイムです。
クライアントはコミュニケーションテンプレートを出発点として、次のことを実行できます。
- 移行が行われるタイミングについての詳細を提供する。
- 移行に協力するワークスペース管理者に想定される事項を確実に伝える。
- エンドユーザーがデスクトップとモバイルアプリを確実に最新バージョンに更新するようにする。
- 今回初めて SSO を実装する場合は、移行後にログインする手順を提供する。
大規模な移行を行う場合は、変更管理の取り組みとして、移行後の専用サポートチャンネルの作成、オフィスアワーの開催、ほかのユーザーのサポートに協力してくれるパワーユーザーの特定などを推奨することを検討します。
ヒント: 長時間の移行 (完全ダウンタイムが 12 時間以上) の場合は、ユーザーの日常業務の中断を抑えるために夜間や週末の時間帯に移行を行うことを強くお勧めします。
ワークスペース監査レビュー
通常、移行対象のワークスペースは SOW に記載されていますが、移行計画の一環としてこの情報をクライアントと確認しておくのが賢明です。また、Slack アカウントチームと連携してワークスペース監査を取得し、クライアントのドメインに関連付けられたすべてのワークスペースの全体像をクライアントに提示することもできます。こうすることで、移行対象のワークスペースを確認し、残りのワークスペースについての計画を作成するのに役立ちます。
移行スケジュール
移行対象ワークスペースを確認したら、Slack が移行をスケジュールできます。このステップでは Slack の担当者と連携する必要があります。この担当者は、移行カレンダーで時間枠を予約し、システム内での Grid 移行をスケジュールできます。
移行をスケジュールする際の推奨ステップは次のとおりです。
- 移行時間の初期推定値を決定する。
- クライアントの Slack CSM と連携して、移行を実施可能な時間枠を見つける。
- 複数の候補日を確保するが、使用しない日付は忘れずに解放する。
- 日付を伝え、確認する。
- CSM に連絡して、Slack システムでの Grid 移行を確認してスケジュールする。
移行設定
移行のスケジュールを実行するには、移行設定を選択する必要があります。この設定には、自動コミュニケーションやカスタムプロフィールフィールドの設定などが含まれます。お客様に選択肢 (下図参照) を提示し、その選択を移行のスケジュールを行う Slack の担当者に伝えます。
デフォルトでは、[Skip SSO token migration (SSO トークンの移行をスキップする)] はオフのままにします。ただし、ユースケースによっては SSO トークン情報を移行すべきでない場合もあります。たとえば、クライアントがアップグレードに伴って別の IDP に切り替える場合や、合併や買収の場合などです。
Slack が送信する移行の招待を承認する
Slack が移行をスケジュールしたら、スケジュールされた日時までにお客様による承認が必要です。移行のコミュニケーションは次のようになります。
- すべての OrG オーナーと OrG プライマリーオーナーは Slackbot 通知を受信する。
- 移行対象ワークスペースのプライマリオーナーは Slackbot 通知とメールを受信する。
複数の人が招待を受信できますが、移行を実行するには 1 人が承認すればよいだけです。同様に、移行前であればいつでもいずれかの受信者が招待を却下できます。お客様が複数の移行を管理している場合、Enterprise Grid のオーガナイゼーション設定ダッシュボードを通じて移行を一括で承認することもできます。
招待が原因で移行が実行されないシナリオが 2 つあります。
- Grid の OrG プライマリーオーナーまたはワークスペースプライマリーオーナーが却下した場合、移行は実行されません。
- 移行日をスケジュールする場合は、申請日から 30 日以内である必要があります。招待が 30 日を超えて保留中になると有効期限が切れます。将来の日付に移行をスケジュールする場合は、これが特に重要です。このようなシナリオでは、ワークスペースを移行するための招待を再送信するように Slack に依頼してください。
ドメイン申請
ドメイン申請は、誰が会社のメールアドレスを使用してワークスペースを作成できるかを OrG プライマリーオーナーが制御できる Enterprise Grid 機能です。以前は Grid OrG に属する従業員が Slack を使い始めたばかりのときに、会社の Slack インスタンスに参加しようとして誤って何十ものワークスペースを作成してしまうことがありました。また、会社が Enterprise Grid プランにする前にユーザーが会社のメールアドレスを使用して追加ワークスペースを作成していたために不正なワークスペースが発生することもありました。
ドメイン申請が既存のワークスペースやそのワークスペース内のユーザーにさかのぼって影響することはありません。ドメインを申請するには、カスタマーエクスペリエンスチームにメールでリクエストするようにクライアントに案内します。
ドメインが申請されると、ユーザーが会社のメールアドレスを使用して新しいワークスペースを作成しようとすると OrG にリダイレクトされます。よくあるシナリオは、従業員が新しいワークスペースを作成するために slack.com にアクセスするというものです。従業員はメールアドレスを所有していることを確認するために 6 桁の確認コードが記載されたメールを受信します。確認すると、OrG 内に新しいワークスペースを作成するアクセス権がないことを通知するメッセージを受信するか、組織ですでに Slack が使用されていることを通知するメールを受信し、SSO でサインインしてアカウントを作成するように促されます。
まとめ
これで、オーガナイゼーションの設定、コミュニケーションの計画、ユーザーデータの処理などの Slack Enterprise Grid 移行の各種の重要な準備作業について理解できましました。次は、移行ポータルについて見ていきます。