Slack Enterprise Gridを導入して世界を分割統治した話

タイトルの通りなのですが勤務先でSlack Enterprise Gridの導入担当になった時のお話です。
この時にいろいろとハマったり、考える要素が多かったので備忘録的に残しておこうと思います。

はじめに

今回のSlack Enterprise Grid（OrG環境）導入前と後の環境の変化についてですが、ひとつのワークスペース（以下、WS）を複数に分割するという部分が特徴的です。

Slack Enterprise Grid（OrG環境）導入前の環境
・ユーザー数、約500名程度（うちメンバーアカウントは200名弱、残りはゲストアカウント）
・パブリックチャンネル600/プライベートチャンネル1,000以上
・WSはひとつのみの運用

Slack Enterprise Grid（OrG環境）導入後の環境
・WSを事業部ごとに作成（既存WS含め合計5個のWS運用）
・チャンネルを事業部ごとのWSへ移動

チャンネルの移動をしても、ユーザーは移動されない問題

これはどう言うことかというと、移動元のWS(a)から新規作成したWS(b)へチャンネルを移動するときにユーザーは一緒についてきてくれません。
移動対象のチャンネルのユーザーを事前にWS(b)へ所属させておく必要があります。
もし、WS(b)に所属していないユーザーがいる状態でチャンネル移動を行おうとするとアラートが表示されます。ゲストアカウントが障害となる場合はチャンネルの移動自体ができません。

実際のエラー画面は以下のような感じです。

チャンネルの移動をしたらユーザーも一緒に移動されると思っていたのでこれにはびっくりしました。
このエラー内容ならアクセスできないアカウントを自動的に移動先のWSに追加してくれよ…
この問題に対する具体的な対応方法については長くなりそうなので別記事にします。

別記事書きました。長いです。

チャンネルを移動しても、関連するIncoming Webhookやアプリ連携が移動されない問題

これもユーザーと同様にチャンネル移動と一緒には移動してくれないので、手動で設定をやり直す必要があります。
こちらについてはチャンネル移動時には特にエラーなどは発生しません。
全社共通のアプリなどは情シス側で対応しました。
事業部側で設定しているものはチャンネル移動日に対応してもらうように事前コミュニケーションをしっかりと取る必要がありました。

そもそも移動できないチャンネルがある話

マルチワークスペースチャンネル、#general チャンネル、アーカイブしたチャンネル、現在または前の共有チャンネルは移動できません。

Enterprise Grid のワークスペース間でチャンネルを移動する

特に、過去の共有チャンネル（Slackコネクト）していたチャンネルについては事前に判断ができず移動しようとしたタイミングでエラーが発生し、はじめてわかることがありました。
しかも「うまくいきませんでした」みたいな抽象的なエラーメッセージだったので困惑しました。
ただし、最近になってマルチワークスペースチャンネルに設定することができるようになったようなので、擬似的に移動することが可能でした。

便利なマルチワークスペースチャンネルが逆に混乱する問題

マルチワークスペースチャンネルは、Enterprise Grid オーガナイゼーションで複数のワークスペースをつなぐ橋渡し役となります。

Enterprise Grid でマルチワークスペースチャンネルを作成する

マルチワークスペースチャンネル（以下、MWSC）の活用例としては、営業部と開発部という部門単位で区切った2つのWSがあった場合に、東京オフィス、大阪オフィスのような部門単位とは別の切り口でチャンネルを運用したい時に設定します。
これにより同じチャンネルを営業部WSと開発部WSそれぞれのWSからアクセスできるようになります。

イメージとしては下記のような感じです。

MWSC自体はとても便利で有用なのですが、いくつか注意する必要があります。

MWSCにおけるユーザーグループの運用しんどい問題

例えば、#help-itチャンネルではこれまで@itというユーザーグループ宛に投稿してもらうことで、ヘルプデスク対応を行っていたとします。
ユーザーグループはWS固有の設定のため、@itというユーザーグループは複数のWSで設定でそれぞれ設定する必要があります。
もし開発部WSで@itユーザーグループを設定していない場合は開発WSからは@itを利用できません。
ヘルプデスクメンバーが増えた場合は複数のWSのユーザーグループそれぞれに追加する必要があります。
これに対する解決策はまだ見えていませんが、Slack APIのEvents APIのsubteam_updated eventを利用して自動化するか、MWSCでユーザーグループを利用しない運用にシフトするかを検討しています。

MWSCと外部アプリ連携時にはどのWSと連携すべきなのか問題

外部アプリとMWSCを連携する場合に、外部アプリによってはどのWSのチャンネルとして連携しているかが重要になることがあります。

例えば、ピアボーナス制度を実現するUniposをSlackのチャンネルと連携し、Slack上で投稿内容に拍手というUnipos特有の機能を利用するには、連携時に選択したWSに所属している必要があります。

Uniposの投稿への拍手
Uniposと連携したワークスペースに属するユーザのみ可能です。
※マルチワークスペースチャンネルで複数のワークスペースが繋がっている場合はそれぞれのワークスペースからでも拍手が可能です。
例）ワークスペースA(Uniposと連携) 、ワークスペースB
・Uniposと連携したワークスペースAに所属しているメンバーのみ拍手が可能
・A、Bの両方に所属している場合は、A、Bの両方のワークスペースから拍手が可能
・ワークスペースBのみに所属しているメンバーは拍手できない

Slack Enterprise Gridについて

もし、開発部WSの#Uniposチャンネルとして、アプリ連携をしてしまった場合は、開発部WSに所属していない営業部WSのユーザーはSlackから拍手を行うことができません。
この場合は全員が所属する全社WSの#Uniposチャンネルとして、アプリ連携する必要があります。

その他の問題

入退社に伴うアカウント管理について（特にSSO連携していないゲストアカウント）
どのWSからも同じスラッシュコマンドを利用するためにOrg Level Appsの開発の必要に迫られるなど、話のネタは尽きませんがそれはまた別の記事にしようと思います。

結論

分割統治への道のりは遠い…
Slack側のドキュメントやネット上の情報も少なく、まさかコレができないの？や、これまでできていたことを同じように実現するにはかなり工数割かないといけなかったりと苦労しました。

ちなみに今回のSlack Enterprise Grid導入については、私が入社する以前に経営層にて意思決定されていたのですが、PMが決まらずになかなか進まなかったようです。
みなさんも、急に経営層からSlack Enterprise Grid導入するからよろしく！と言われる可能性ありますからその時はがんばりましょうね。

誰かに相談したい時は私も参加している情シスSlackへ投稿すると解決のヒントだったり、新しい考え方に触れられるのでおすすめですよ。

次回は「チャンネルの移動をしても、ユーザーは移動されない問題」に具体的にどう取り組んだかを記事にしたいと思います。