Slack Enterprise Grid導入してチャンネル移動に苦しんだ話

前回、Slack Enterprise Grid（OrG環境）導入の時にいろいろあったよという事を書きました。

今回、予告していた『チャンネルの移動をしても、ユーザーは移動されない問題』についてどのような対応を行なったかを記事にします。

課題のおさらい

今回やりたいことは下記です。
1.新しいワークスペース（以下、WS）を作成
2.新規作成したWSへ既存のWSから必要なチャンネルを移動する

課題としては2.の段階で移動するチャンネルのユーザーを事前に新規WSへ所属させておく必要があります。
所属させておかないとチャンネル移動時に警告がでて移動ができません。

言葉だとわかりづらいので図にするとこんな感じです。

警告はこんな感じです。
このすべて表示をクリックすると具体的に障害となっているゲストアカウントが表示されます。

対応方法

チャンネル移動前に新規WSへ所属させる状態を実現するために、対象者を洗い出し、ダミーチャンネルへ所属させるという手法を取りました。

ただ今回移動する対象チャンネルが、最低でも100以上あり、チャンネルを個別に調べて対象者を洗い出すことは現実的ではありませんでした。
そこで、Slack API（Slack App）をGASから呼び出すことでなんとか実現させました。

このSlack API（Slack App）はパブリックチャンネルで有効です。
プライベートチャンネルに対しては、チャンネルにSlack Appを追加しない限りは利用できません。

1.移動対象チャンネルのユーザーをSlack APIを使って抽出します。
2.抽出したデータを元に重複するユーザーを除くなどデータ加工を行います。
3.チャンネル移動先WSにダミーチャンネルを作成します。
4.ダミーチャンネルに2.で抽出したユーザーを招待します。

これで事前に移動先WSに所属させることができます。

Slack APIを利用してチャンネルユーザーを抽出取得

コアな部分は下記にまとめました。

このあとのデータの活用方法は人それぞれ好みがあるかと思います。
自分の場合はシート名：Channelをベースに表示名やメールアドレスなどのユーザー情報をマッチさせたシートを別に作り、そのデータを元にピボットテーブルを作成したり、重複するユーザーを削除したりする作業を行いました。

ダミーチャンネルへの追加

チャンネルの移動先WSに対して適当なダミーチャンネルを作成します。
ダミーチャンネルへの招待はチャンネル移動の前日にメールアドレスを利用してGUIから行いました。

ダミーチャンネルについてはチャンネル移動作業が終わったら削除を行うため投稿権限を「管理者以上」にしておき、一般従業員がチャンネルを利用開始しないようにしておきましょう。

チャンネルへの投稿権限を管理する

従業員向けには以下のようなアナウンスを実施しておくとよいでしょう。

明日n月n日10:00からxxx関連のチャンネルを新規ワークスペースへ移行します。
移行の前準備として、本日n月n日 19時ごろから、対象アカウントを新規ワークスペースへ招待いたします。
※移行前準備のため投稿権限のないダミーチャンネルへの招待となります。

新規WSがSlackアプリでどのような表示がされるかや、WEBブラウザからアクセスしている場合を考慮した内容などアナウンスとして盛り込む要素がありますがここでは割愛しています。

プライベートチャンネルについて

今回のSlack API（Slack App）を利用した方法ではプライベートチャンネルについては洗い出しができません。
また、弊社のOrG環境ではプライベートチャンネルの情報へのアクセス権限はOrG管理者（私）にはなく、OrGオーナー（少数の役職者のみ）にだけ権限付与されている設計となっています。

実際のチャンネル移動時のほとんどの場合、プライベートチャンネルにだけ所属しているユーザーがいなかったため、あまり障害にならなかったようです。
プライベートチャンネルにだけ所属しているユーザーがいた場合は移動時に都度、ダミーチャンネルへ追加してからチャンネル移動するという手段を取るしかありません。

避けられないシングルチャンネルゲストの問題

その名の通りですがシングルチャンネルゲストはひとつのチャンネルにしか所属できませんので、ダミーチャンネルへの招待が行えません。

このため、チャンネル移動前にシングルチャンネルゲストは移動元WSから削除します。
シングルチャンネルゲストが所属していない状態でチャンネル移動を行い、移動後のWS配下のチャンネルに対して、改めてシングルチャンネルゲストを招待する必要があります。

なぜか移動できない場合がある問題

事前にユーザーをダミーチャンネルへ追加済みなのに、特定のユーザーが障害となってチャンネル移動ができないことがありました。
移動できない障害はすべてクリアしたはずと思い、最初は理解ができませんでした。
詳しく調べるとユーザーにとって移動するチャンネルが移動元WSの唯一のチャンネル（ラストワン状態）になっている場合に発生します。
どのチャンネルにも所属しない状態ではWSに所属することができないためだと推測されます。

この唯一のチャンネル（ラストワン状態）にはマルチワークスペースチャンネル（以下、MWSC）は含まれせん。

この問題の対応はシングルチャンネルゲストと同じ対応を基本としました。
但し、1つのチャンネルで多くのユーザーが唯一のチャンネル（ラストワン）になっている場合は作業効率が悪くなる問題がありました。

そこで、移動元WSにもダミーチャンネルを作成し、ユーザーを所属させることで唯一のチャンネル（ラストワン）にならない状況を作り問題が発生しないように改善しました。

対象チャンネル移動後には移動元WSダミーチャンネル内のユーザーをWSから削除する作業も行う必要があります。

ちなみにこのことが後に先日の記事の『MWSCと外部アプリ連携時にはどのWSと連携すべきなのか問題』につながるとは思っていませんでした。

まとめ

このようにチャンネル移動は事前準備や考慮することが多く、利用環境によってはあちらを立てればこちらが立たずの状態となり、かなりの手間がかかるというのが感想です。

今回は新設WS4つに対して合計6回にわけてチャンネル移動を行いました。
6回それぞれ関連する部署と調整を行いながら移動日を決めて、Incoming Webhookやアプリ連携の件についてしっかりとコミュニケーションをとりながら実施しました。
最初は規模が小さくなにか問題が起きてもリカバリーが効きやすいWSから取り組むのがオススメです。

作業に慣れてくるとチャンネル数100程度でも2名で分担することで1時間程度でチャンネル移動作業を終えることができました。

おそらく人生で何度も経験する作業ではないので、なかなか知見が溜まりにくいのかなと思います。
この記事が誰かの参考になれば幸いです。

次回はすべてのWSから同じスラッシュコマンドを利用するために、Org Level Appsを作ってみた話を記事にしてみたいと思います。