Slack Enterprise Grid 移行を開始する

学習の目的

この単元を完了すると、次のことができるようになります。

• 移行プロセスのしくみを説明する。
  
• Slack Enterprise Grid の目的を説明する。
  

Slack Enterprise Grid 移行

クライアントがなぜ Grid 移行を希望するかを理解することは有用です。組織内のさまざまなチームが必要に応じて独自の Slack ワークスペースを作成するのは比較的よくあることです。組織がそうしたバラバラのワークスペースを 1 つにまとめたいと考える場合、それらのワークスペースを Enterprise Grid プランに移行する必要があります。

Grid 移行が必要になる一般的なシナリオとして次のようなものがあります。

• クライアントが Grid 環境外でのワークスペースの作成 (および乱立) を許容していたが、それを Grid に取り込むことを決めた場合。
  
• クライアントが買収した企業にも Slack の既存のワークスペースがあるが、それが Grid には含まれていない場合。
  
• 所有しているワークスペースすべてを共通のポリシーと設定を持つ 1 つの Grid インスタンスに集約する場合。
  

クライアントが Slack Enterprise Grid を導入する際に、特に重要な側面の 1 つが準備です。Grid 移行プロセスのしくみを理解し、Grid 移行の概要を提示し、クライアントの移行前アクティビティを定義する必要があります。この作業をしっかりと行うことで導入を成功させることができます。

Slack Enterprise Grid を定義する

Slack Enterprise Grid は、オーガナイゼーションというコンテナの内部で連携する無制限のワークスペースを提供することで、企業の構造をそのまま反映できるように設計されています。通常、ワークスペースはビジネスユニット、部署、子会社に対してプロビジョニングされますが、組織固有のニーズにも対応できる柔軟性を備えています。Enterprise Grid は、Slack のオーガナイゼーション内に複数のワークスペースを含めることができる唯一の Slack プランです。

Enterprise Grid では、複数の既存の Slack ワークスペースを 1 つの統合された Grid にまとめることができます。

このプロセスの最初のステップは、複数のワークスペースを 1 つの Grid オーガナイゼーションに統合することで、これは Grid 移行または移行と呼ばれています。

移行プロセス

ほとんどの場合、クライアントがプラットフォームとして Enterprise Grid への投資を決定する前に、すでに部分的に 1 つ以上のワークスペースで Slack 使用されています。通常、このようなワークスペースには貴重なデータが含まれており、クライアントはこのデータを保持し、移行プロセスを通じて Enterprise Grid に取り込みたいと考えています。

では、グリッド移行とは具体的にはどのようなものなのでしょうか? 移行中、移行するワークスペースのデータは、コピーされたり部分的に移行されるのではなく、そのまま完全に Grid に移されます。ただし、オーガナイゼーション (OrG) レベルに移行されるデータとワークスペースレベルのままのデータがあります。

ワークスペース URL はそのままで、Enterprise Grid OrG にリダイレクトされます。

OrG レベルデータとワークスペースレベルデータの要素を理解する

「データがどこにあるかがなぜ重要なのか?」と疑問に思われるかもしれません。 よい質問です! Enterprise Grid には多くのメリットがあり、たとえば複数のワークスペースがある場合に、ユーザーはワークスペース内でコラボレーションすることも、クライアントの大規模なオーガナイゼーション内の複数のワークスペースにまたがってコラボレーションすることもできます。複数のワークスペースがある Grid 構造ではデータの場所によるメリットがあります。

次のグラフィックは、2 つの別個のワークスペースから統合された Enterprise Grid への移行プロセスを表しています。

OrG レベルデータ

Grid への移行において、デフォルトでは特定のデータはオーガナイゼーションレベルに保存されます。クライアントは Grid 内に複数のワークスペースを持つことができます。クライアントのユーザーはすべてのワークスペースをまたいでコラボレーションでき、一貫性のあるポリシーやアセット (ファイルや絵文字など) の恩恵を受けることができます。

たとえば、ユーザーは所属しているワークスペースに関係なく OrG 内の誰にでもダイレクトメッセージ (DM) を送信できます。

ワークスペースレベルデータ

OrG レベルに移行されなかったすべてのデータはそのままワークスペース内に保存されます。ワークスペースレベルに留まることで、これらの Slack 要素は OrG の他の部分と連携して機能することができます。

たとえば、チャンネルは 1 つのワークスペース内でのみ使用可能にすることも、OrG 内の複数のワークスペースで共有することもできます。

Grid 移行についての 1 つの考え方は、移行するワークスペースは家であり、Grid 環境は引っ越し先のゲート付きコミュニティであると想像することです。この比喩をさらに続けると、家の中にあるすべてのものは引っ越し中も保持されますが、ゲート付きコミュニティに属することになり、そのルールに従うことになります。引っ越してくる人が増えれば、この成長しているコミュニティのニーズに合わせて、より多くの家を建てることができます。それと同じように、組織が進化すれば、組織の構成を反映するように Grid 環境にワークスペースを追加できます。

Grid 移行のフェーズ

Grid 移行はデータの移動であるため、ワークスペースの移行に要する時間は移動する必要があるデータの量によって異なります。Grid 移行には 3 つの主要フェーズがあります。

• 完全なダウンタイム: カスタム絵文字、ユーザープロフィール、設定の移行中はエンドユーザーはワークスペースを使用できません。
  
• オープンフェーズ (ワークスペースは制限付きで使用可能): すべてのチャンネルが使用可能でエンドユーザーはワークスペースにアクセスできますが、ダイレクトメッセージやファイルなどの一部のメッセージ履歴が一時的に使用できなくなることがあります。
  
• 再インデックス付け: これは移行後のフェーズです。移行したワークスペースからのすべての新しいデータは Grid インスタンスに対して再インデックス付けされ、検索結果が一時的に不完全になることがあります。
  

Slack と連携してダウンタイムや総移行時間を推定し、ダウンタイム計画のためにクライアントに伝える必要があります。

まとめ

Slack Enterprise Grid 移行の概要として、移行を行う理由、そのしくみ、どのデータがどこに移動されるかを学習しました。次は、移行の基本的な準備アクティビティを詳しく見ていきましょう。

リソース

• Slack ヘルプ: Slack Enterprise Grid 入門
• Slack ヘルプ: ワークスペースを Enterprise オーガナイゼーションへ移行する