Slack社はSlackをどう使っているのか - Slack利用ガイドラインの話

[GitLab社のGitLab Handbookと徹底した文書化](https://qiita.com/e99h2121/items/ea5822922d83d00ebc4a)、組織的なオープンネス（？）を先日調べたのだが、じゃあ同じように見える化、透明性をアピールしているツールが何か？と考えた際ににSlackがあると思っている。SlackといえばDM禁止！オープンな職場が良し！風通し良し！なやつである。

しかしそれを実際会社で根付かせようとした時に、Slackの使い方を説くだけでは足りなくて、むしろ皆の意識改革みたいなものが必要だな～とひしひし感じさせられる。オープンな会社が良いかクローズドが良いか、「チームの風通しは良いほうが良いのか？」

世の中ひねた人も居るもんで風通しだけ良くてもこんなデメリットが有るなんて言われる
>意見は増えても、内容が浅い
意見の浅い深いを確認する手間がかかる
浅い意見でも対応しなければならない
多数派の浅い意見に流されがちになる
https://factory-learn.com/open-door-policy/

そうではなくとも、こんな意見もTwitterで見つけた。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">なぜか密室で進めたがる人って一定数いるんだけど、情報の流量をコントロールすることで自分の存在価値を高めるみたいな邪な考えが動機になることより、「混乱しないように」「話をまとめてから」みたいな一方通行な善意が動機になっていることが多いからたちが悪いのではないだろうか。</p>&mdash; TAKAKING22 (@TAKAKING22) <a href="https://twitter.com/TAKAKING22/status/1367213573622001666?ref_src=twsrc%5Etfw">March 3, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

確かに **オープンネス** と **生産性** が単純に、完全に比例するかはまた別の議論かもしれない。
しかし何をオープンにして何を例外的にクローズドにするか **共通認識を皆で作る** はしたほうが良いのかもしれないと考えた。


## Slack社はSlackをどう使っているのか を知る

前置きが長くなったが当のSlack社は、Slackをどのように使っているのか。どう使うことを勧めているのかを調べた。[Slack 社内での Slack 活用法](https://slack.com/intl/ja-jp/resources/why-use-slack/how-slacks-own-developers-use-slack)。

結論から書くとSlack社は曰く、**Slackの使い方は1000社あれば1000通り**、と言っているようで、やはり**皆で考える過程が大事なのだと思う**。以下は記事サマリ。DeepL翻訳を利用してのポストエディット文です。


### 1. アライグマ
まず「アライグマ」という用語を初めて知ったのでメモ。
「その話は別のチャンネルでやると良いよ」という時に使うらしい。

http://slack.com/intl/ja-jp/blog/productivity/slack-%E3%81%A7%E7%B5%B5%E6%96%87%E5%AD%97%E3%82%92%E6%B4%BB%E7%94%A8%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95

> さらに、もっと適したチャンネルに移動した方がいい話題には、アライグマ を使っています。その話題に特化した別のチャンネルがある場合や、ノイズの少ないチャンネルで雑談が行われている場合は、チームでカスタマイズした :raccoon: 絵文字を使って、誰でも会話を別の場所にリダイレクトできます。これは否定的なことでも恥ずかしいことでもなく、単に会話を整理し、他の人の時間と労力を節約するための方法です (嬉しいことに、米国政府のデザイングループは職員の Slack ハンドブックに「アライグマ」方式を導入してくれました)。

https://handbook.tts.gsa.gov/tools/slack/guidelines/

> :raccoon: ==> #channel	“Please consider moving this conversation to a different channel.”	Slack

https://medium.com/@mathowie/yeah-it-started-with-someone-finding-this-funny-image-of-a-raccoon-looking-super-helpful-and-once-971e7c901e8e#.ka1cy355g

> "おい、多分あなたの会話は他の場所でされるべきだ "

https://www.itmedia.co.jp/business/articles/2001/21/news032_2.html

> アライグマはごみをあさる習性があることから、不必要な発言を適正化する意味で、用いているのだとか。

### 2. ”[How Slack uses Slack](https://www.protocol.com/how-slack-uses-slack-products)”

本題、Slack社員の話。読んでみると意外と柔軟である。

- 開発チームはすべてが一元化されており、デプロイに参加している人は、自分のコードが問題になっている場合に備えて、自分のコードがどうなっているのかを確認する。

- BizTechチームも同様、ITサービスリクエストを自動化するためにAskBotと呼ばれるツールを使用している。Slack内で、社員はチケットを開いて、プラットフォーム内で対応することができる。

- 時には昔ながらのアプローチも利用できる。例えば、営業チームは、よりローテクなソリューションを使用して、昔ながらの方法で、実際の人間関係を通じて、利用可能な情報量を最大化している。

- Slackは、営業、法務、エンジニアリングの各チームで働く人々と、顧客とも、チャンネル上でやりとりできる。

- ローテクかハイテクかにかかわらず、Slackの社内での製品の使用は組織全体で、「Slackがどのように利用できるか」そのものを示している。スマートなインフラストラクチャの使用、手元のツールやリソースからパフォーマンスを絞り出すこと、そして顧客からの定期的なフィードバックを収集する。

- Slackに、社内で自社製品に大きく依存することで付加的なメリットがあるのは明らか。もしSlack自身が社内のユーザーに新しい機能を採用してもらう方法を見つけられなければ、よりリソースの少ない組織はSlackを使う方法を見つけられないことを意味する。逆に言えば、社内で感じている問題点は、顧客のために優先的に修正すべき問題点である。

- Slackには、ソフトウェアの経験がないままスタートしたり、むしろ電話の使用に慣れている社員もいる。会社の非公式なポリシーやコツの多くは入社時に説明されているが、常にセーフティネットを持つことも推奨されている。「信頼できる人、助けてくれる人、理解してくれる人を持つ」。パブリックチャンネルに投稿するのが不安な場合も助けを求められる。


### 3. ”[How we use Slack at Slack](https://productcoalition.com/how-we-use-slack-at-slack-932336494991)”

別の記事。

- 筆者が何十年もメールで仕事をしてきた中、最大の変化の一つは、コミュニケーションの主要な手段として毎日Slackを使うことを学んだこと。チャンネルを使って仕事をすることで情報がより透明になり、チームがより俊敏になり、同僚とリアルタイムでつながりを保つことができる。

- 現在Slackは100%リモートワークとして運用されている。世界中の人々が完全なリモートワークへの移行を進める中で、お互いのつながりを維持する必要性は最重要課題となっている。SlackはSlackを使ってつながりを維持している - 現在、10カ国にまたがる18のオフィスから2000人以上の社員が全員リモートで仕事をしている。

- 筆者は長い間、技術系のチームを率いてきたが、人々をまとめ、共通の目標に向けて調整することは、常に最大の課題。情報を適切な人に、適切なタイミングで確実に届けることこそが、組織の効率を左右する。Slackでは、すべての作業がチャンネルで行われる。社内の誰かからメールが届くことはない。

- チャンネルを使って、発表、チーム、プロジェクト、カルチャー、集中的で検索しやすい会話に仕事を整理している。開発したすべての機能に対して公開チャンネルを設けており、社内の誰もが内部を覗き見して最新のステータスや更新情報を確認することができる。エンジニアチームだけでなく、組織全体のすべての部署がチャンネルを使用している。

- 人事チームは採用（面接とオファーのチャンネル）から再編成の調整、オフサイトの計画に至るまで。一時的なチャネルをスピンアップして、不要になったらアーカイブしておくこともよくある。

- 文化的ガイドラインにより、チャンネルを最大限に活用することができる。筆者のチームは、チャンネル内で @mention もするが、全メンバーに一度にメッセージを送る @channel は控えめに使用する。全員が話題をメンテナンスする責任があり、誰かが別のチャンネルに話題を移すことを提案するときには、:raccoon: (アライグマ) の絵文字を自由に使う。

- 誰もが情報を入手できるように、できるだけ公開での会話をする。例えば週に一度、少人数のグループで製品レビューを行い、不必要な会議からを省くよう時間を節約してから、公開チャンネルでメモを「ピン留め」する。アイテム（ファイルやメッセージなど）をピン留めする。

- メンションは、誰に向けられているのかを明確に示すのに役立つ。

- すべてのチャンネルが会話のためにあるわけではない。多くの「フィード」チャンネル、他のソースからの更新情報や情報を投稿するチャンネルもある。カスタマーエクスペリエンスチームは、すべてのツイートを @SlackHQ に送信し、レビューやディスカッションのためのチャンネルにしている。Jiraを使って、今週次週に何が発売されるかのレポートを送信するなども設定している。

- "reacji channeler" も使う。特定の絵文字を使ったメッセージに反応した人がいると、そのメッセージを指定したチャンネルにコピーしてくれる。例えば、エンジニアリングチームは関連記事や文書を #announce-postmortems に転送してふりかえりをしている。

- プロダクトチームとエンジニアリングチームは、「Slackを人生で最高の仕事ができる会社にする」という目標を掲げている。目標を達成するためには、優秀な人材の採用、優れたエンジニアリングツールの構築、高品質の維持、マネージャーのトレーニング、お客様との距離を縮めることなど、やるべきことがたくさんある。アジャイルな状態を維持し、情報を素早く見つけ、刻々と変化する状況に対処するためのツールやシステムも必要。

- すべての作業はただの会話だけではできない。サードパーティ製のツールをSlackに接続して、少しでも早くタスクをこなすことをサポートする。Slackのプラットフォームには2,000以上のアプリがある。エンジニアリングチームは、インシデント管理のためにPagerDutyやGitHub等を用い、インシデントに対して適切な者が迅速に作業できるようにしている。

- ワークフロービルダーは、誰でもタスクを自動化できる。コードの書き方を知らない人でもシンプルなオンボーディングワークフローを追加して、新しい人をチームに迎えるようにできる。

- Slackのワークフローを使ってリモートからの質問を集めている。人々は #all-hands-and-events で「質問があります」というワークフローを起動させる。提出された質問はチャンネルに投稿され、社内のコミュニケーションチームが優先順位をつけて発言者に割り当てる。結果、すべてのSlackオフィスとリモートチームのメンバーが参加できるオープンなフォーラムが実現する。会社全体がリモートである中、ワークフローは、適切な相手に明確な回答を迅速に提供するのに役立つ。

- コミュニケーションは文字だけではない。絵文字もまた重要な要素である。チームメンバーが大きな勝利や発表をチャンネルで共有した場合、お祝いの気持ちを共有するために「🎉」のような絵文字を使ったりする。相手がどこのオフィスにいても、メッセージにリアクジをつけることができる。顧客からは "Slackはより人間味のあるコミュニケーション方法だ" との声もあるようだ。

- 会社のミッションやリーダー、チームメイトとつながっていれば、より良い仕事をすることができる。Slackはチーム内での仕事上の関係を構築し、強化するのに役立つし、パートナー、顧客など、組織という壁の外にいる人たちともより緊密な関係を築ける。

- 共有チャネルを使用することで、顧客をSlackに呼び寄せて、パイロットしている新機能について早期にフィードバックを求めることができる。エンジニアやプロダクトマネージャーが社内でのコミュニケーションと同じように顧客と直接コミュニケーションをとることで、自分たちも一つのチームの一員であるような感覚になれる。

- 共有チャネルは、最近Slackインターフェースを大幅にアップグレードした際に特に重要な役割を果たした。100社以上の顧客と共有チャネルで緊密に連携し、フィードバックを得て、迅速にプロトタイプを作成し、リアルタイムでアップデートや新機能の改良を行うことができた。

- このパンデミックの間、ソーシャルディスタンスを保つ必要があるにもかかわらず、顧客とのつながりを維持するためにも共有チャネルを活用している。顧客と直接つながることで、賞賛、感謝、励ましのメッセージやヒントを共有することができ、行き詰ったときには助けになることができる。

筆者は「昔のメールボックスが恋しくないとは言い切れない」が、組織の規模拡大や成長から、Slackの製品イノベーションのペースを押し上げることまで、チャンネルでの仕事がもたらす俊敏性と連携の向上のおかげで、すべてが少しだけシンプルに、より快適に、より生産的になる、とまとめている。







## まとめ
[Slackに“謎マナー”が発生「重要なことはメールで送る」「絵文字は2個まで」――Slack Japanの公式見解は](https://www.itmedia.co.jp/business/articles/2001/21/news032_2.html) にも以下のようなことが書いてある。

- ある導入例では「社長のつぶやきチャンネル」を設けた。ふだん現場の社員とコミュニケーションが取れないことから、より風通しを良くするためにメッセージ性の強い投稿を行っている。
- 「**Slackの使い方は1000社あれば1000通り**。プロジェクトをまわす、会議をする、といった基本的な使い方はもちろん、Twitter的な使い方もできる」。


冒頭に書いたように、**オープンネス** と **生産性** が単純に、完全に比例するかはまた別の議論かもしれない。しかし何かを禁止！ルール！と言うだけでない **共通認識を皆で作る**、肩肘張らないように見える Slack社のごくフツーの姿勢はなんだか逆に好感もある。大事なのは自社、自チームなりのSlackガイドラインを皆で作っていくということなのかもしれないなとおもいましたと、そういうまとめです。



### 参考: ガイドライン例

公開されているOrganization的Slackガイドライン
[SmartHR Slack の歩き方【完全版】運用ガイドライン / マニュアル / ルール](https://qiita.com/yamashush/items/a401bcf6b02e86b8a58b)
[メルカリ社内Slack利用ガイドラインを一挙公開しました〜！！#メルカリな日々](https://mercan.mercari.com/articles/23325/)

https://github.com/mercari/mercari-slack-guidelines/blob/master/Slack_Guidelines_Ja.md#%E5%89%8D%E6%8F%90

https://github.com/mitene/slack-guidelines/blob/main/Slack_Guidelines_Ja.md

[KyashのSlack運用ルールをGitHubで公開しました](https://blog.kyash.co/entry/2020/12/23/165623)

https://github.com/Kyash/recruitment/blob/master/slack_rules.md

[note社版！Slackの歩き方ガイド](https://note.jp/n/ne659d97c1b32)

https://trello.com/b/RJ2rWIbS/slack-guidelines

https://github.com/cto-a/community-guidelines/blob/master/slack-guidelines.md

https://github.com/caffisenna/dx_slack_guideline/blob/master/guideline.md


### 参考: Qiita記事
[SlackでDMを使わない方がいい理由をGIFにして説明してみた](https://qiita.com/walkers/items/8c1b63694de4f5617cee)
[slackアンチパターン](https://qiita.com/karashi39/items/7d33cf65317d4a11989d)
[SlackのDM比率が高くなる理由](https://qiita.com/satoshiyoshinaga/items/7a6f6f4fcea7fbee3a28)

蛇足だが、DMも監視されていることはあるのでそもそもSlackでひそひそ話などは元々、本当の意味ではできないようだよ (しらんけど、というかあまり興味ないけど)。[Slack(スラック)DM・チャンネル等が監視されていないか確かめる方法](https://best-cloud.jp/slack-monitoring/)

以上お役に立てばさいわいです。