いろいろな会社を経験しましたが、だいたい、Slack の使い方として
パブリックチャンネルばかりの会社、プライベートチャンネル（もしくはDM）ばかりの会社におおむね二分されます。
パブリック・プライベートが半々という会社は少なく、どちらかに寄っていく傾向にあると感じています。
今日はそこについて考察していきます。
1. 何も方針を出さないとDM率が上がる
会社として明確な Slack の運用指針を作らない場合、
DMが作られる方にどんどん寄っていきます。
これにはいくつかの理由があります。
- 1-1. メール文化に慣れていたので、やり取りは個人に対してするものという認識でいる
- 1-2. 「こんなことチャンネルに書いていいのかな？」「みんなが見るところに書いていいの」という恐れ
- 1-3. その話題をするべきチャンネルが見つからない
1-1. メール文化に慣れていた
そもそも Slack の文化に慣れていないパターンです。
Slack はチャットベースで気楽なやり取りをしつつ、オープンに情報交換をおこなうことで
社内の部署間のコミュニケーションを円滑にする目的や、
他部署でなにがおこなわれているかの情報を拾いやすくすることで部署間の連携を強くし、
連係ミスによる失敗を少なくし、かつ業務のスピードアップを図る目的があります。
ベンチャーを何度も経験している人などは Slack のこの目的を理解しているため、
説明しなくてもたいていの人がパブリックチャンネルでバンバン書いてくれますが、
世の中まだまだそうでない人の方が多いです。
よって、最初はパブリックチャンネルでのやり取りが多かった会社だとしても、
社員が50名を超えてくるあたりで
新しく入ってくるメンバーがそういうのに疎かったりすると、しだいに DM が多くなっていきます。
これを解決するには、
- 社内の Slack 利用規定を作成する
- また、規定の中でどういうメリットがあってその規定なのかを述べる
- 入社メンバーにみっちり定期的に説明する
以上のことが必要になります。
1-2. パブリックに書くことの恐れ
人間は大部分の人が心配性で自意識過剰です。もちろん私も。
メールやLINEの返信が相手から返ってこないと、「なにか私が悪いこと言ってしまったんじゃないのかな…」と不安になりがちです。
そのような恐れを持つ人が多いので、
「この書き込みは誰かを傷つけないか」とか「なにか書いたことが誤解されるんじゃないかな」とか不安を持ちます。
そんなに一人一人のメッセージを気にしてるほど暇な人や、悪意を持った書き込みと捉える心の狭い人は会社に入社させていませんので、
それは杞憂であることが多いのですが、やはり不安に思う人が多いのは事実です。
これを解決するには、
- まずは書いてもらう（社内の Slack 利用規定に従ってもらう）。そして、パブリックチャンネルで書くことが怖くないとだんだん慣れて気付いてもらう
- 誰かのコメントが強く注目されないくらいに、チャンネルが常ににぎわっている
これらのことがおこなわれていると良いでしょう。
1-3. 話題をするべきチャンネルが見つからない
これは２通りあります。
1-3a. 単純にチャンネルがない場合
『単純にチャンネルがない場合』は単純で、チャンネルを作ってもらえばいいです。
ただ、ここで規定がしっかりないと、上の 1-1. , 1-2. で説明した理由により
プライベートチャンネルが作られてしまう傾向に陥りやすいので注意です。
あとでもう一度書きますが、プライベートチャンネルはパブリックチャンネルに後から変更できないので、
「ここパブリックチャンネルで良くね？」って気付いてからの変更がしにくいです。
『顧客情報を扱わない限りはパブリックチャンネル』などと、基本はパブリックチャンネルである旨の規定があるといいと思います。
1-3b. チームのチャンネルで書いていいことなのかわからない
『チームのチャンネルで書いていいことなのかわからない』ということもよく起こります。
例えば、「チームメンバー数名での飲み会の写真をチームのチャンネルに上げていいか？」とか、
「○○さん個人あての相談をチームチャンネルに書いていいのか」とか。
チームリーダーからしてみれば、どちらもチームチャンネルに書いてOKです。
いえ、「まだ仕事中のメンバーがいるかもしれない中で、チームのチャンネルに上げるのはいかがなものか。雑談チャンネルに上げるべきだ」という考えのリーダーもいるかもしれませんが、
個人的には、チームチャンネルであれこれ雑に書きやすい空間作りのために、なんでも書いてOKな雰囲気でありたいです。
後者の「○○さん個人あての相談をチームチャンネルに書いていいのか」という考えでチームメンバーにDMされるのはマジで困るやつで、
チームメンバーが知らぬうちにタスクを抱えていた、ってなるので本当にやめてほしいですね……。
というわけで、
「チームの話題やチームメンバーへの相談はチームチャンネルでしてもらって、それで困ることが起きてきたなら新規チャンネルを立ち上げる。DMはおこなわない」
の方針が Slack 利用規定としてあるといいと思います。
2. なぜ DM がダメか
2-1. 通知が飛ぶ
Slack で通知を飛ばしていいのは緊急のときだけです。
とりわけエンジニアは、Slack の通知が飛んで来たら「障害が起きた？！」ということを念頭に置き、あせって Slack を開きます。
ですのでグループDMなんかが作られて話が続くとけっこう地獄で、
イラッとするだけでなく大事な通知を見落としてしまいかねませんから、
グループDMで会話が続くものであれば、プライベートチャンネルにした方がマシです。
実は Slack には「Convert to a private channel...」という機能もあります。
2-2. あとからメンバーの追加が出来ない
グループDMをしてる途中で「これ、○○さんも知っていた方がいいよね？」ってなったときに
DMの場合は途中からメンバーを追加することができません。
また、グループDMのメンバー数には限界があります。
上で書いた「Convert to a private channel...」の機能を使えば、
会話の内容をチャンネル化してからメンバーの追加がおこなえますので、現在はあまり大きな問題ではなくなりました。
（……が、グループDMを使っているような人は上の機能を知らないので、結果的に「○○さんも知っていた方がいいよね？」の○○さんには伝わらないことの方が多いです）
3. なぜ DM やプライベートチャンネルがダメか
3-1. 情報が拾えない
最初の 1-1. で書いたように Slack の大きな利点は、
オープンに情報交換をおこなうことで社内の部署間のコミュニケーションを円滑にする目的や、
他部署でなにがおこなわれているかの情報を拾いやすくすることで部署間の連携を強くし、
連係ミスによる失敗を少なくし、かつ業務のスピードアップを図る目的にあります。
DMやプライベートチャンネルで情報のやり取りをおこなうのは、
これと正反対のことが起こるデメリットを持っています。
他部署や他プロジェクトでおこなわれていることがわからないし、
部署間で重複することをやって無駄が生じることなどが起こるわけですね。
また、現在働いている人はもちろん、より大きく影響を受けるのは新入社員（特に中途雇用）です。
開かれていない情報は、新入社員のオンボーディングのスピードを大きく下げる効果があります。
優秀な社員であれば、過去の Slack の流れを見ることで、
今走っているプロジェクトの生まれた背景、各部署にどんな人間がいるか、社内の人間関係やパワーバランス、を教えることもなく理解してくれ、
自分がどうプロジェクトを回していけばいいのかをだいたいは理解してくれて、すぐに力を発揮してくれます。
プライベートチャンネルや DM での会話が多いと、これらの情報は拾えず、
誰かが教えてくれるまではわかりません。（それにたいてい、これらを教えてくれる人はいません）
また、本来その新入社員の人が知っておくべき情報のあるプライベートチャンネルに招待されていないことがわかって、
入社１ヵ月してからようやく招待されるなんてことがあります。
3-2. マネジメント層が新たに生まれにくい
チーム内での情報の格差は、新たなマネージャーを生みにくい環境を作ります。
優秀な人材は、情報が充分に与えられればそれ相応の判断ができます。
チームリーダーと同じ分だけ情報が与えられていれば、最大、チームリーダー相応の判断ができます。
そういう判断を出来る人を、マネージャーは次のチームリーダーにするべく育てていけばいいわけです。
一方で、情報の非対称性があって、
チームリーダーが知ってる情報をメンバーが知らないのであれば、その情報量の差が大きいほどに、判断は稚拙なものになります。
その稚拙さをもって「こいつは稚拙な判断しかできないな」となってしまうのなら本当に理不尽な話です。
次のマネジメント層を育てるために、情報はできるだけチームリーダー含めたチーム内でフラットにし、
その上で「あなたがリーダーだったらどうするか」をメンバーには 1 on 1 などで問いかけ考えさせる癖をつけさせると良いでしょう。
メンバー全員がリーダー候補になると、チームはとても上手く回ります。
（参考: フォロワーシップとリーダーシップの違いや関係性とは？ ）
3-3. 個人の仕事量が大きくなることがある
1-3b. でも書きましたが、プライベートチャンネルやDMでタスクを依頼されていることは
周りからはわかりません。
DMでのタスクの依頼が常態化すると悲惨で、
Aさんに仕事を依頼するBさん、Aさんに仕事を依頼するCさん、Aさんに仕事を依頼するDさん、が発生したときに、
Aさんは3名それぞれとチャットをすることで時間を取られるし、
そのようなタスクが発生していることを知らないEさんがAさんに仕事を依頼して……とさらにタスクが発生してAさんがパンクします。
チームが形成されていなかったり、チームがあっても 1on1 や KPT などのチーム行事の成熟度が足りていない場合、
こういった問題にはなかなか気付きにくいです。
チームチャンネルでの相談に一元化されていれば、
Aさんがわからない質問やAさんが忙しいときに他のチームメンバーが答えてくれたり、
B/C/D/Eさんからしたら、明らかにAさんに仕事が集中してることはわかるので、
レスが遅くてもイライラしませんし、Aさん以外のチームメンバーに相談した方がいいという可能性にも気付くことでしょう。
正当な人事評価や退職リスク防止のために、個々人の仕事量が見えなくなる状態を作ることは避けましょう。
3-4. 「この情報を○○さんに伝えていいですか？」の確認タスクが増える
情報をオープンにするかプライベートにするかの基準が決まっていない場合、
この確認タスクが増えます。
DMやプライベートチャンネルを使うことが当たり前になっている組織ではこの確認タスクが多いです。
しかも、その決定権を持っているのが誰かわからず、最終的にはマネージャーが社長に確認し……までのフローをたどります。
ベンチャーでこの遅さは致命的ですし、なにより、「自分で決めて判断する」というベンチャー企業にとって必要な精神が損なわれ、
「誰かに決めてもらうまで待つ」という精神が社員に蔓延します。
3-5. あとからパブリックチャンネルに出来ない
上記の問題を鑑みて、「じゃあパブリックチャンネルにしよう！」と思っても、
Slack の仕様上プライベートチャンネルをパブリックチャンネルにすることはできません。
つまりプライベートチャンネル時代のメッセージを残したままパブリックチャンネルにすることができないので、
移行後、過去のメッセージを探すことに苦労するようになってしまいます。
改革には痛みが伴うとは言いますが、なかなかの痛みです。反対の声も多く出るでしょう。
いったんプライベートチャンネルで作ってしまうとこのような苦労が生まれるので、
「とりあえずプライベートチャンネルで作る」でなく、
「とりあえずパブリックチャンネルで作る」 という習慣を早い段階で根付かせておく必要があります。
4. 結局のところ
パブリックチャンネルでのオープンなやり取りが前提となるよう、
Slack 利用規定を従業員（Slack参加者）が2桁になり始めたころまでには作り、
業務委託など含む Slack 参加者全員には自社の規定をしっかり案内し、
利用規定が運用されているか管理したり、相談を受けるための人を1人は決めて置き、その相談用のチャンネルも用意しておく。
このようなことが肝要です。
遅くなればなるほどエネルギーが必要な作業になりますので、
創業後は、技術顧問や、ベンチャー慣れしているエンジニアなどに早めに策定してもらうと良いでしょう。
利用規定の参考:
