結論: 外部にSlackを開くときは「読むだけ・1チャンネルだけ・いつでも止められる」に絞ります
外部の協力者にSlackの中を見せる必要が出たとき、弊社が最初に決めるのは見せ方です。渡す前に3つを満たす形にします。読むだけ・1チャンネルだけ・いつでも止められる。この3点に絞れば、相手に必要な情報は届き、それ以外は閉じたままにできます。逆にここを曖昧にしたまま「とりあえずメンバーに追加」をやると、見せるつもりのなかった場所まで開いてしまう。私たちはこの線引きを、実際に外部の人と連携するときに決めました。
Slackを社内でどう使うかという通知側の設計は通知の宛先を役割で分ける記事で書きました。今回はその外側、社外の人に一部だけ開くときの話です。
「とりあえずメンバーに追加」は、なぜ避けるのか？
答えを先に言うと、通常のメンバーに追加すると見える範囲と費用の両方が一気に広がるからです。Slackの通常メンバーは、招待された時点でそのワークスペース（社内のチャットの箱全体）が視界に入ります。1つのチャンネルだけ見てほしいのに、他の社内の会話まで開いてしまう。しかも有料プランでは、メンバーを1人増やすたびに料金が乗ります。外部の人を1つの用事のために通常メンバーにすると、見せすぎと払いすぎが同時に起きる。私たちはここを分けて考えます。見せる範囲は用事の分だけ、費用は増やさない。この2つを両立させる入口だけを渡します。
外部に見せると情報が漏れる、というのは本当か？
これは相手の立場によります。すでにその人がゲスト（1つのチャンネルだけに招かれた外部参加者）として中を見られる立場なら、そのチャンネルを仕組みで自動で読み取っても、新たに増える露出はありません。人が目で読むか、相手の仕組みが読むかの違いしかないからです。私たちが警戒するのは「読み取ること」そのものではなく、見せる範囲が用事より広がることです。だから判断の順番はいつも同じです。まず相手が本当に見る必要のあるチャンネルはどれかを1つに絞る。その1つの中だけを、読むだけの形で開く。ここさえ固定すれば、読み取りを自動化しても心配する対象は増えません。
弊社が外部の協力者と連携したときの話
実際にこの線引きを決めたのは、ある外部の協力者から相談を受けたときでした。作業を自動で受け取りたいので、Slackの内容を仕組みから読めるようにしてほしい、という依頼です。方法は2つ浮かびました。1つ目は相手を通常メンバーにする案。これは費用が増える上に、必要のない社内の会話まで見える。2つ目は、相手に社内のアプリ（自動でやり取りする専用の小さなプログラム）を作る権限を渡す案。これは外部の人に強い権限を渡すことになり、避けたい。どちらも「用事の分だけ開く」から外れていました。
そこで私たちが取ったのは、会社側で読み取り専用の入口を1つ用意し、対象の1チャンネルだけに結びつけて渡す形でした。相手のメンバー種別は変えないので費用は増えない。渡した入口は読むだけで、書き込みはできない。開いているのは相談で決めた1チャンネルだけ。そして、いつでも会社側から無効にできる。**用事が終われば止める、を最初から組み込んでおく。**結果として、相手は必要な情報を自動で受け取れて、こちらは見せる範囲を1つに閉じたまま連携できました。
渡すときに、人が必ず自分でやっている一点は？
入口を作る操作と、それを止める操作は、私たちは自動化せずに人の手に残しています。理由はシンプルで、外部に何をどこまで開くかは後戻りの効かない判断だからです。読み取りの中身（新しい依頼が来たら受け取る、など）は仕組みに任せてよい。ですが「誰に・どのチャンネルを・いつまで開くか」は、鳴った通知に反応して自動で決めてよいものではありません。ここは人が画面を見て決めます。私たちはAIや自動化に任せない操作をあらかじめ決めており、外部への公開もその1つに入れています。権限を絞ったうえで人が要所だけ関わる設計は、承認を絵文字1つで回す仕組みとも同じ考え方です。できないことを正直に線引きしておくほうが、後から慌てずに済みます。
明日からできる一歩
まず、いま外部の人に開いているチャンネルを棚卸ししてみてください。確認するのは3点だけです。**1つ目はその人が本当に見る必要のある1〜2チャンネルに絞れているか、2つ目は書き込みまでできる状態になっていないか、3つ目はやめたくなったときにすぐ止められるか。**このうち1つでも「いいえ」があれば、そこが見せすぎの入口です。範囲を1つに戻し、読むだけに絞り、止め方を先に決める。順番はこれだけで十分です。
