この記事は『Slack Advent Calendar 2018』の19日目の記事です。
更新：本稿で触れている「マルチチャンネルゲストからシングルチャンネルゲストへの自動降格」について、 @will_meaning さんがAPIを用いた対応に関する記事を書いてくださいました。
マルチチャンネルゲストからシングルチャンネルゲストへの変更可能なSlackユーザーを洗い出す
はじめに
2017年に企業向けプランである「EnterpriseGrid」が開始され、その年9月には日本法人も設立されたSlack。
エンジニア界隈では単なるチャットツールに留まらず、API連携や多数のシステム連携が可能なインテグレーションなどなど、特に現場の声に押されて企業向け採用を検討しているみなさまも多いのではないでしょうか。
国内でもDMMやYahooでの大規模な採用事例、MercariやDeNAでの素敵な活用事例など、導入事例も増えてきているようです。
僕自身、個人的にSlackの大ファンで、シャドーITを防ぐ立場の情報システム部員でありながらひそかに勝手にSlackを使っており（コラ）、さらにちょうど社内でもSlackを使いたい（なんなら使ってる）というケースもぼちぼち出始めて、ようやくちゃんと社として契約を考えねばならぬという空気感がでてきたこともあり、自社へのSlack導入の推進を担当し、今年からPlusプランでの契約を開始することができました。
当たり前ですが、いくら便利なツールであっても、導入して終わりではありません。その後も運用は続きます。
現在自分たちでも社内での運用ポリシやルールを絶賛アップデートしながら策定中ではありますが、そんな中で気付いた点を何点かこの場で共有できればと思います。また、一部内容はヘルプなどを通じてアップデートリクエストも行っています。
情報システム部員として考えなければならないこと
社内ルールの策定と明文化
社内ユーザに利用してもらうにあたり、いくつかの取り決めが必要になります。例えばアカウントの発行やゲストの招待、チャンネルのプライベート化やインテグレーションの追加など。
これらのルールをまとめ、また利用申請や必要な手続きをフローに起こしドキュメント化、利用希望ユーザへ配布を行えるようにしました。
セキュリティやコンプライアンス
なんらかの情報流出やセキュリティインシデントがあった場合に、迅速にログイン中のユーザ追い出し（強制ログアウト）や、調査/監査ができなければいけません。また、二段階認証を必須にしたり、デバイスコントロールなども行いたいです。便利なツール、スマホデバイスで使えるツールは、それ自体が情報流出の危険性を孕んでいます。適切なデバイス管理、アクセス元の管理が必要です。
残念ながら、デバイス管理は現時点ではEnterpriseGridでしか使えません。今回はここは断念しました。
社外ユーザをゲストとして自社Slackへ招く場合、そのゲストユーザがアクセスできる情報レベルも適切にコントロールできる必要があります。会社単位でNDAを結んでいても、無関係なプロジェクトの情報にアクセスできることは防がねばなりません。
アカウントの管理、棚卸
一つは費用の問題。予算は無限ではないので、不要な費用は発生しないように、使われていないアカウントは定期的に棚卸、不要であれば削除を行わなければありません。この点に関しては フェアビリングポリシーがとても有効でした。
もう一つはセキュリティ。使われておらず放置されたアカウントはそれ自体がセキュリティホールになる危険性を孕んでいます。
上記2点の観点より、定期的に全アカウントの利用状況の確認と、使われていなければ解除、削除を実施する必要があります。
SLA/緊急対応体制
何%のダウンタイムを社として許容するか？またそれをユーザにどう伝えるか？
実際にダウンがあった場合に、どういう対応が必要になるか？
たとえば夜間メンテ作業時に、コミュニケーションに使っていたSlackが突如使えなくなった！という場合情シスへは緊急連絡がかかってくる可能性があります。であれば、そういった事態に備えた体制づくりも必要になります。
ちなみに結論的には何もできません。おとなしくSlack Statusを確認して復旧することを祈りましょう。
※SLAに応じた返金はありますが、返金ではなくてクリティカルなタイミングのダウンタイムを回避したい。。
ちょっと困ったことや改善してほしいこと
本題。いくら今流行りのチャットツールだからといってすべてが完璧なわけではありません。
気付いたところは是非サポートやヘルプへ投げて、ユーザの声を伝えましょう。
プライベートチャンネルの監査
これは厳密には「できないこと」ではありません。
Slackではプライベートチャンネルやダイレクトメッセージで会話される内容は、たとえそのSlackのプライマリオーナーであっても確認することはできません。監査したい場合は、コーポレートエクスポートを利用する必要があり、これはPlusプラン以上でないと利用できません。
この、「プライベートチャンネルの利用状況の確認ができない」ということを発端に、問題が生じることになりました。
マルチチャンネルゲストからシングルチャンネルゲストへの自動降格
Slackのフェアビリングポリシーでは、要するに「14日以上使ってないユーザの費用は発生しないよ」っていうことを説明しています。
Slackでは「通常メンバー」と「マルチチャンネルゲスト」の場合1ユーザとしての費用が発生しますが、「シングルチャンネルゲスト」は無料です。なので、なるべく費用を抑えるためには、ゲストはなるべくシングルチャンネルゲストにしたいし、マルチチャンネルゲストで参加していてもその後不要なチャンネルが廃止/アーカイブされ利用チャンネルが1チャンネルだけになった場合は、マルチからシングルへ降格させたいです。
ところが、上記のケースにおいて、残念ながら自動降格はしてくれず、ユーザ（つまりぼくたち）で作業を行う必要があります。自動化しましょう。
Aさんをマルチチャンネルゲストへ招待し、チャンネル1とチャンネル2へ参加させる
↓
チャンネル2は不要になったためアーカイブされる。Aさんはチャンネル1のみに所属するマルチチャンネルゲストとなる
上記を情シスが正しく捕捉できていないと、本来シングルチャンネルゲスト（＝無料ユーザ）であったはずのAさんの分の費用が発生することになります。そして、チャンネル1やチャンネル2がプライベートの場合、情シスはこれを監査できません。
使われていないチャンネルの棚卸し
上記のケースと同様に、不要なチャンネルであれば積極的にアーカイブし、マルチチャンネルゲストはシングルへ降格させたいですが、こちらもプライベートだと棚卸ができません。実態として使われているかどうかわからないプライベートチャンネルにマルチチャンネルゲストが参加していた場合、不要な費用が発生するケースが想定されます。
上記の対応策
今回は対策として、以下の運用ルールを制定しました。
- 一般ユーザのプライベートチャンネル作成権限をはく奪
- プライベートチャンネル作成（チャンネルのプライベート化）はすべて情シスの担当者が行う（依頼はSlackの専用チャンネルで @admin 宛てに呟くだけ）
- 情シス担当者は、作業時にプライベートチャンネルへ情シス管理用アカウントを参加させる
- 情シス管理用アカウントを通じて、プライベートチャンネルの把握と棚卸を行う
実際、プライベートであるにも関わらず情シス管理用みたいな気持ち悪いアカウントに参加されるのは気持ち悪いという意見はありましたが、これは正直止む無しでした。もしよい解決方法をご存じの方いたら教えてください。。
あるいは、手続きが必要ですがコーポレートエクスポートを活用するという手もあると思います。これは僕たちはまだ試せていませんが、いざというときに必要なものなので確認はしておこうと思います。
グループ機能
ゲストがグループ関連機能を使えない
これめっちゃ不便。。
Slackには任意のユーザグループを作りメンションを飛ばせる機能がありますが、ゲストについては
- グループへの参加
- グループ宛てのメンション
がどちらもできません。 参考：マルチチャンネルゲスト & シングルチャンネルゲスト
グループへの参加だけでなく、グループへのメンションもできないのです。ちょっとびっくり。
ユースケースとして、外部協力会社のメンバーを招待し、会社単位でのグループを作成することができないことや、ゲストとして参加しているメンバーはこちらのチーム宛てのメンションが使えない（メンションとして@をつけて発言しても、メンション扱いにならない）という状況になります。
これについては暫定的な対応として、メンションの文字列を@込みでキーワードに登録することで自分のチームとしては対応しましたが、グループ機能は使えてほしかったなぁ。。
ユーザグループの削除
しかも、グループは削除ができません。無効化はできます。
外部会社のメンバーをいれるグループを作ってみたものの、参加させることができず、むなしく無効化されたグループが永遠に残り続けることになります。。
アカウントの削除がけっこう大変
Slackではアカウントを無効化する場合に、解除と削除の2段階で明確に内容を分離しています。
解除
通常無効化はこちらで十分。解除されたアカウントはログインができなくなりますが、発言したチャットやアップロードしたファイルには影響ありません。また、解除されたアカウントは簡単に有効化することで、再度利用可能になります。
削除
こちらはより重たい処理になります。説明にも記載がありますが、GDPR等のデータ保護、プライバシー保護の観点から実装されている機能で、管理者でも実行できずSlackへの処理リクエストになります。日常運用でここまでを対応するのはちょっとつらいでしょう。
削除されたユーザは @deactivateduser と表記されますが、発言内容までは削除されないようです。
想定される問題
これはレアなケースだとは思いますが、Slackはワークスペース毎にユーザのメールアドレスをユニークな識別子として登録されます（実際にはSlackが自動で割り当てるIDがユニークな識別子ですが、同様にメールアドレスもユニークである必要があります）。
ここで、不要になった解除済みメンバーと同じメールアドレスを持つメンバーを登録する必要が生じた場合（例えば退職済みで社内アカウントは抹消されたが、その後入社したメンバーがシステムにアカウントを再割り当てされたケースなど。あまりないとは思いますが。）、やはりSlackアカウントは削除する必要があります。
これはまぁあっても極めてまれなケースだと思うので、1年に1回、解除済みのアカウントを一斉に削除申請するなどでよいでしょう。
ファイル操作
ファイルの一括削除
Slackのチャンネル上にアップロードされたファイルは、「そのチャンネルにアップロードされたファイル」ではなく、「そのワークスペースに（パブリック/プライベートで）アップロードされたファイル」になります。なにが言いたいのかというと、チャンネルを削除しても、チャンネルにアップロードされたファイルは削除されないということです。
files.listやfiles.deleteで「指定チャンネルのタグがついたファイルを一括削除」できるようにしておきましょう。
ファイルの公開範囲
ファイルが「チャンネル」ではなく「ワークスペース」に対してPOSTされる、というのは上記の通りですが、これに関連してもう一つ。
パブリックチャンネルへファイルをアップロードしたあと、そのチャンネルをプライベート化しても、アップロードされたファイルはパブリックのままになります。 これほんと重要。
パブリックチャンネルをプライベートチャンネルに変換するにも記載がありますが、
パブリックチャンネルで変更以前に共有されたファイルは、変更後に非公開になるということはありません。これらのファイルへは、引き続きワークスペースのメンバーによるアクセスが可能です。
いやいやいや、ファイルがアップロードされたチャンネルがプライベート化されたら、そのファイルもあわせてプライベートにしてほしいよ！ってのが後から気づいたことでした。。
表記ゆれ（？）
気になったので。
Slackでは、作成できるチャンネルの区分に、「パブリックチャンネル」「プライベートチャンネル」の2種類があります。また、任意のユーザをグループ化するグループ機能があります。
WebAPIでは：
パブリックチャンネルの操作 → channels.*
プライベートチャンネルの操作 → groups.*
ユーザグループの操作 → usergroups.*
SCIM APIでは：
ユーザグループの操作 → /scim/v1/Groups?
というエンドポイントに対するAPI実行で操作します。どうしてこうなった。
WebAPIでプライベートチャンネルを操作するMethodがgroups.*なのはなにかの悪い冗談だと思いますので、これはきっといずれ修正されるでしょう。
ちなみに、workspaceの情報が知りたければ、 team.*というWebAPIが使えます。
このteam.*におけるteamはワークスペースそのものを指しているようですが、その一方でSlack って何？という文書では
ワークスペースのオーナーが Slack ワークスペースを作成し、チームの管理を手伝ってもらうために管理者を任命します。
と記載されており、ワークスペースとチームは別の概念として捉えられているようです。
また、ワークスペース上で「課金が有効」なユーザ一覧は、team.billableinfoというWebAPIで取得できます。users.*では確認できません。
ちなみに、SCIM APIは管理を自動化したいのであればかなりオススメです。
フェアビリングポリシーで「非アクティブ」となったユーザ検出や、APIでのアカウントの無効化などのインテグレーションは、運用の自動化、運用工数の削減に大きく貢献してくれるでしょう。
まとめ
大規模な導入事例や、いれてよくなった！系の記事はよく見ますが、その一方で当たり前ですがツールとしてはまだまだブラッシュアップが必要な面もあるとは思います。それでも、素晴らしいアプリケーションだと思うので、企業導入で興味ある方は是非営業へコンタクトを取ってみたり、イベントへ参加するなどしてみてください。ぼくは今年SlackFrontiers@SFOに参加しました
missionの買収、機能の公式実装はおそらく2019年には何らかのアナウンスがあるでしょう。
EG導入が前提であれば、Customer Success Managerという特別な営業担当がサポートしてくれるケースもあるようです。※CSM、ポジションは募集してるみたいですが特に存在の説明はないみたい。
情シスの運用担当のみなさま、よいSlackライフを！ 