Slackのゲストアカウントをどうにかしたいので、どうにかする。管理や棚卸、考え方を整理したいので書いてみる。

good-sun（a03）

Slack管理者の立場として、やったこと、やっていきたいこと、考えたことなどをつらつらグダグダ書き連ねていたら4,000字を超えてしまった……。

だいぶ端折って、都合よく書いてる部分もあるが、ご容赦ください。

なお、本記事は筆者の独断と偏見に基づいている。本記事の内容は、筆者の所属する組織・団体を代表した意見では無い。加えて、組織の方針や状況によって、本記事の内容がそぐわない場合があることも、賢明なる読者諸氏は大変よく理解されていることと思う。


なぜどうにかしたいのか、する必要があるのか

目的は大きく次の３つである。

  1. セキュリティリスクの低減

  2. 運用管理コストの低減、効率化

  3. コスト削減、最適化

契約期限後や退職後のアカウントがいつまでもワークスペースにアクセスできる状態であることは情報管理の面から望ましくない。

運用ルールが明確でないと、場当たり的な対応になり、目的不明なアカウントが発生する一因にもなる。ISMSやPマーク取得、認証関係で体制の説明を要求される場合もある。

シングルチャンネルゲストは費用が発生しないが、マルチチャンネルゲストはメンバと同様の費用が掛かる。アクティブ判定などの詳細は割愛する。


ゲストアカウントの一生（アカウントライフサイクル）

ここで言うゲストアカウントとは、シングルチャンネルゲストとマルチチャンネルゲストを指す。

ゲストアカウントのライフサイクルは、概ね次のようになる。

  1. 招待の検討

  2. 招待処理

  3. 招待後のフォローアップ

  4. 棚卸、更新

  5. 停止、削除

1.招待の検討

本来、ゲストアカウントを招待する際には、次のような点を考慮する必要がある。

  • それは本当にゲストアカウントである必要があるのか

  • メールなどのやり取りで完結しない継続的コミュニケーションがなぜ必要なのか

  • コネクトではあかんのか？

  • ゲストではなく、メンバーアカウントである必要があるかどうか（後からメンバーにしてくれ、の場合もある。ゲストとメンバーはワークスペース内のチャンネルへのアクセス可能範囲が大きく異なるので注意が必要。）

これらを検討し、確認する必要がある。この検討が不十分なまま、あるいは見切りで、とりあえず招待することもままある。特にスタートアップやSlack導入初期は、まずは連絡を取れる状態になることが優先されるだろう。検討不十分であったゲストについては、棚卸や更新で改めて対応したい。

このあたりについては、以下のつよつよ先輩の記事を参考にされたい。

2.招待の処理

多くの場合、ワークスペース内のすべてのメンバーがゲストをそのまま招待できてしまうと管理上問題があるので、招待できる者を絞ることになる。（Kajinariさんの記事では「ゲストを除く全員がメンバーを招待できる」体制ついて言及されているので、そういった体制がフィットしているところはそちらをぜひ）

次のような申請承認フローを経ることが望ましい。

招待の申請
（ゲストの管理責任者（情シスではなく、ゲストを招待したいと考えている者）とゲストとの関係性、ゲストの役割、誰が何の目的で招待するのか、どのチャンネルに呼ぶか、シングルかマルチか、ゲストの有効期限、など）
↓
承認
↓
招待処理
（Slack管理者が指定のゲストを、指定のチャンネルに、指定の期限で、招待する）

フローの実装はなんでも良い。Slackワークフローでも、Googleフォームでも、キックフロー、kintone、バクラク、などなど……。このあたりは、承認フローや組織体制は、内部統制として、別スコープとしても検討と実装が必要だが、ここでは割愛する。（Slackワークフローは本来の承認者以外もポチッと承認ボタン押せてしまう。誰が押したかはわかるけど。）

ゲストの招待時に、ゲストの有効期限を設けておくことが肝要だ。
無期限ゲストは情報漏洩リスクおよび無駄なコストの発生源になる。
招待日から最長1年などの期限設定が良いだろう。

3.招待後のフォローアップ

すべてのゲストがSlackに慣れているわけではない。必要に応じて、フォローアップが必要かもしれない。この点に関しては、情シスとしは対応せず、ゲストを招待した者の対応になる（組織が大きれば大きいほど、情シスがゲストひとりひとりにきめ細やかな個別対応を取ることは難しい。情シス体制としてできるところ、やりたいところはやればいい）

使い方という意味では、あまり丁寧にフォローアップしているところは少ないと思われる。使い方は、ネット上にいくらでもある。現代では、職種にもよるが、テキストコミュニケーション（ビジネスチャット）を使えない者には仕事を依頼することは少ない≒ゲストとして招待することも少ないと思われる。

他方で、Slackに招待する側がメールのやり取りが面倒なのでSlackを使いたいと思っている時、招待される側はメールとは別に新たにSlackを使わねばならない（デスクトップアプリのインストールはせずにブラウザだけでSlackを見ている、もしくはメールに通知が飛んでからSlackを見る場合もある）ので面倒と思っていることもある。これは当人の普段の環境や、リテラシ、スキル、キャッチアップ具合や考え方にもよる。

単なるメールの代替として、メッセージのやり取りだけをしている場合も多くある。それも間違いでは無いが、Slackではハドルで音声やビデオ、画面共有も行えるのに、それを活用していない/できないケースもある。Slack上にアップロードされたファイルの帰属や閲覧、削除などはまた別のお話。

シングルチャンネル、マルチチャンネルゲストの場合、メンバと違ってワークスペース内の他のチャンネルに自由に出入りすることができない。このあたりは　The world around you is not what it seems って感じ。

ゲストはグループメンションについても注意が必要。以下のようなカスタムレスポンスを用いて擬似的に対応する場合もあるかもしれない。

4.棚卸、更新

現状のゲストアカウントが何件なのか、それらは本当にactiveなのか、停止する必要はないかを定期的に確認する必要がある。

期限が近いゲストを知らせるbotは既につよつよ先輩諸氏の記事があるので参考にされたい。


これらのbotはあくまで手段であるので、組織によっては必要ない場合もある。
例えば、招待者（not情シス）がそのゲストの期限についても管理監督責任があるものとすれば、期限通知はあくまで親切的なものであるので、この通知があろうがなかろうが期限コントロールは招待した者本人の管理責任ということになる。

極論すれば、期限が切れてアクセスできないゲストアカウントがあったとしても、そこで問題があれば誰かが何かを言ってくるはずである。誰も何も言ってこないのであれば、そのアカウントは無用だったということだ。

とはいえ、現実には、ゲストとの関係性や力関係などの事情や、招待者は退職するがゲストへの業務は引き続きあるなど、様々なケースがある。

そして、期限が切れたあとに、やっぱ期限更新しといて！といったやり取りが煩雑になるのであれば、それを見越して通知botが有効となる。

偉そうにごめんなさい🙇

5.停止、削除

ゲストについては、期限を設定しておけば、自動的にdeactivateになる。
なので、招待時および棚卸の段階で期限を設定しておくことが肝要となる。

厳密に言うと、Slackではアカウントのdeactivateと削除は異なる。

AsIs,ToBeの整理

※招待者＝情シスではなく、招待者＝ゲストアカウントを招待したい社内の者を指す

AsIs（現状課題）

整理前はだいたいこんな感じになる。

  1. 有効期限のないゲストがいる

  2. ゲストアカウント招待時に有効期限の設定をしていたり、していなかったりする

  3. ゲストアカウントの有効期限を招待者が把握できていない

ToBe（打ち手、ありたい姿）

  1. すべてのゲストアカウントには有効期限を設ける

  2. ゲストアカウント招待時には必ず有効期間を設定する

  3. （オプション）ゲストアカウントの有効期限を招待者が確認できる状態とする

有効期限を設けることで、セキュリティリスクや運用管理、コスト面の対応を図る。

AsIs現状把握（棚卸）

現状のゲスト情報を取得する

CSVでもAPIよい。
今後、定期的に確認するとか、スプレッドシートに書き出すとかするとAPIを叩いて情報を得ることが多いのではないかと思う。

とりあえずざっくり数を知りたけれは、管理画面からCSVをダウンロードでもよい。

ToBeを目指して

すべてのゲストアカウントには有効期限を設ける

そのために、現状で有効期限が設定されていないゲストに一定の有効期限を設定する

数件なら手動でいいが、数百件となると脳筋ポチポチはつらいのでGASなりPythonなりで対応したい。結果が得られるならば、コードを作るのが難しいときは気合いポチポチでもいいんじゃね、とも思っている。

Enterprise Grid ならば、以下のAPIが使える。

Usage Infoにあるとおり、Appは個別のワークスペースではなくorgに対してインストールしておく必要があるので注意。

有効期限を設けることについて、社内通知や関係者との認識、景色を合わせておくことも同時にやっておきたい。

ゲストアカウント招待時には必ず有効期間を設定する

そのために招待フローを改善する。また、棚卸しなどで有効期限のチェックを行う。

だいたいこんなフローになる。

  1. 招待者が、被招待者（ゲスト）のメールアドレス、有効期限、招待事由、招待するチャンネルを申請

  2. 承認者が申請内容を承認する

  3. 承認されたら、Slack管理者がゲストを招待する

Googleフォーム、Slackワークフロー、kintone、バクラクなどなど、ツールは何でも良い。

（オプション）ゲストアカウントの有効期限を招待者が確認できる状態とする

申請者は、申請時にゲストの有効期限を申請する。なので、申請者はゲストの有効期限を認識できている（はず）。とはいえ、現実的は申請したあとは期限のことは忘れている者が大半だろう。

先に述べたbotで通知させるなり、なんなりで適宜対応する。

SaaS管理ツールの検討

自前でゴリゴリとコード書いたり内製システム、内製ツールで管理してもいいし、以下のようなサービスもあるので検討するのもよい。

  • ジョーシス　https://jp.josys.com/

  • Bundle(バンドル)  https://bundle.jp/

  • Admina https://admina.moneyforward.com/jp

筆者はこれらのサービスからお金をもらっているわけではないです。念の為。

人事マスタ、人事DBとの連動でオートマチックにできる姿を目指していきたい。

そのためには人事マスタ、人事DBの整備が必要だったり、そもそも組織体制の構築、組織のありたい姿、目指す姿の話も必要だったりして、そっちはそっちで大変なのでここでは話を広げないでおく。

まとめのようなもの

Slackのワークスペース内、チャンネル内で行われていることを、すべて公にできるのであれば、管理だなんだと気にしなくてよいだろう。しかし、ビジネスでSlackを用いているところは、現実としてそれは難しいだろう。

ユーザからすれば、単に外部の人とやり取りしたいだけ、かもしれない。それなのに、なにをこんなにグダグダ言っているんだ、と思われるかもしれない。そもそも、ユーザはこんなnoteを読まないだろう。このような駄文を読んでいるのは意欲のある情シスだと思う。お付き合いいただき、ありがとうございます。このnoteには過不足が多くあろうかと思いますので、忌憚なきご意見をお寄せいただければ幸いです。


あわせて読みたい参考情報

再掲しているものもあるが、改めて先輩方の記事等をまとめておく。

そもそもの考え方編

それ、ゲストじゃなくてコネクトでよくない？みたいなことも往々にしてある。



ゲストアカウント管理・棚卸編


ひとまず、今日はこんなとこです。

#Slack
#Slack管理
#ゲストアカウント

いただいたサポートで、書籍代や勉強費用にしたり、美味しいもの食べたりします！