はじめに#
最近、様々な分野でチャットツールのビジネス利用が試行されていますね。 筆者の会社でも例に漏れず多くの部門が Slack を利用したり、Microsoft Teams の検証をしています。 筆者は 20 年近く様々なチャットツールを使ってきました。1:1 のチャットツールだけでなく、複数人で使うチャットツールも様々な状況で利用しています。 そもそもインターネットを利用する筆者の主たる目的の一つは確実にチャットです。 一方で、会社に本格的なチャットツールを導入する過程で分かってきたのは、多くの人は思ったよりチャットツールに慣れてない、ということです。
このエントリでは、最近 Slack や Teams のようなチャットツールを使い始めた組織に所属するみなさんに向けて、チャットツールをより快適に使うための考え方や Tips を紹介します。
ここで紹介する知識は、筆者からの提案であり何らかの理想やマナーではありません。 これらの知識の中には、あなたの考えや組織に合わないものが確実に含まれているでしょう。それらは単に無視して下さい。 もし、あなたのチーム内におけるルールや運用を見直すきっかけになるなら、それは大変素晴らしいことです。 筆者としては、このエントリを読んだ皆さんが、ここで提示した知識を自分なりに改良して利用して貰えれば良いと考えています。
全般的な使い方編#
多要素認証(MFA)を有効化しよう#
チャットツールは様々なレベルの情報を扱う場所です。あなたのアカウントをより強力に防護するため必ず多要素認証(MFA)を有効化しましょう。
Slack の場合、有償のワークスペースでは管理者が MFA をユーザに対して強制できますが、無償のワークスペースでは強制できません。 多くのユーザは強制されない限り MFA を有効化しない傾向にありますが、特に理由が無ければ有効化しましょう。
おすすめのアプリケーションはAuthyです。複数のスマホや PC で二要認証の鍵を共有しているので、一つくらいなら一時的に紛失しても対応できます。
定時の設定#
退勤したら仕事用のチャットツールを見たり使ったりするのは基本的にやめましょう。 どこに居ようが、仕事用のチャットツールを見ているなら、それは労働時間とみなされるべきです。稼働時間をむやみに増やすのは、望ましくありません。 そのためには、定時を過ぎたら通知が来なくなるように設定するのが簡単です。
チャットを一切見ない時間を作ろう#
チャットツールは、慣れてくると中毒のような状態になり易いものです。特に参加者が多く活気のあるチャットでは、常に誰かが発言しています。 そこで発信されるメッセージを全て出来るだけ早く確認しようとすると、それ以外のことが一切出来なくなってしまいます。 そうなる前に、チャットを見ない時間帯を自分で決めるのが良いでしょう。
8 時間拘束の仕事では、毎日合計して 2 ～ 3 時間はチャットを見ない時間を作ると仕事が捗りますよ。
情報のストックとフローという考え方#
チャットツールは、流動的な対話を行うための場所です。チャットツールでの議論の結果は、別途保存した上で探し易い場所に議事録としてまとめ直した方がいいでしょう。 後からチャットの中身を時系列に追って、その内容を順次理解していくのは非常に大変な作業です。 議事録はその時いなかった人が分かり易いように書きましょう。
一番簡単な議事録の共有の仕方は、markdown などのテキストファイルで議事録を書いた上で、チャットツールにアップロードしてしまうことです。
コミュニケーション効率について#
チャットツールによるコミュニケーションは、対面によるコミュニケーションに比べて効率のよい部分と悪い部分があります。
チャットツールは文字によるコミュニケーションツールなので、感情や雰囲気のような感情的な部分は伝わり辛いです。 語尾を工夫したり、リアクションアイコンや、画像を使うことである程度感情を伝えられますが、感情はあまり伝わらないものとしてやり取りした方が、トラブルの発生を未然に防げますし効率的です。
チャットツールを使うなら、対面によるコミュニケーションよりも、応答速度を少し遅めに見積もってやりとりする方がいいでしょう。 会議中や電話中に質問者側が、質問してその回答を聞く前に離席したり、他の会議に行くなどという事はありえませんが、チャットツールならそれができます。
メールマナー及びそれに類するものを排除しよう#
電子メールが普及し、20 年近くが経過するなかで、マナーのようなものが広く普及しています。 例えば、「○○ さん」や「お世話になっております」、「以上、よろしくお願いします」など、情報として意味のない文章がメールの中には多く含まれています。 チャットツールを利用するなら、そのようなマナーを一旦全て無視してコミュニケーションしてみましょう。コミュニケーションの効率が大きく改善することを実感できるでしょう。 情報として意味の無い部分を欠く相手に対して失礼さを感じ、コミュニケーション効率を改善するより礼儀を重視したいのであれば、チャットツールを使うのは諦めてメールを使えばいいでしょう。 本当に効率よりも礼儀が大切なら、毎朝おろしたての墨を使って筆で手紙を手書きした方がよりよいでしょう。
本来、礼儀や礼節というものは不要な争いが起こる可能性を低減することで、効率よくコミュニケーションするための手段であって、目的ではありません。 本来の目的を逸脱し、それ自体が目的化したマナーの類は極めて醜悪なものだと筆者は考えています。
お互い意味が無いと思いつつ、多くの人が受け取っても読み飛ばしている文字列を送付し合うことは、礼儀正しいと言えるのか今一度考え直してもいいんじゃないでしょうか？
リマインダーの使い方#
Slack では / で始まるメッセージを投稿すると、他のユーザには見えない特別な命令として解釈されます。
Slack には、標準で特別な命令がいくつか用意されていますが、 /remind はそういったものの一つです。
メッセージの入力欄に /remind と入力すると基本的な使い方は表示されます。
そこでは表示されないが個人的に有用だと思っている例を紹介します。
平日の 1200 にリマインド#
平日の 12 時になったら、自分にだけ Slack がリマインドしてきます。
/remind me "お昼休みです" at 12PM every weekday
終業時間をリマインド#
平日の 17 時になったら、 #kintai チャンネルにリマインドメッセージが自動投稿されます。
自動投稿されるメッセージ内で @here となっているので Slack にログインしており、#kintai チャンネルにいる人全員に通知が飛びます。
/remind #kintai "@here そろそろ退勤時間です。日報を書きましょう。" at 1700PM every weekday
メッセージ編#
ここからは、Slack を使ったメッセージのやりとりにおいて、筆者が気を付けていることを紹介していきます。
メッセージを小分けにする#
長文のメッセージの中には、全体として賛同できるものの個別には同意できないとか、個別には同意できるが全体としては賛同できないといったことはよくあります。 合意形成のためには主張を部分に分けた方が、それぞれに対してより精密な議論ができます。 チャットを使った議論では、文章を過度に装飾したり論理を敢えて曖昧にするようなやり方は合致しません。
長文で何かを主張するのであれば、markdown 等の読み易い形にまとめて配布する方がいいでしょう。 その場合には、ピクトグラムやダイアグラムなどの画像を適宜混ぜることで、読者がより理解し易い形にしましょう。
このようなことが出来るのは、Slack のワークスペース内において全てのメッセージを一意に特定できる ID が割当てられているからです。 Slack ではワークスペース内の全てのメッセージに対して一意になるような URL が付加されます。 その URL は、メッセージの右上にある「・・・」アイコンからクリップボードにコピーできます。
そのメッセージに言及する際に、自分のメッセージ内に URL を含めると、自分が書き込んだメッセージが表示される際に併せて、言及対象となるメッセージが表示されます。
また、個別のメッセージに対して返答できるスレッドという機能によって、個別具体的な議論を行えます。
Slack のチャンネル内でスレッドが多用されているなら、チャンネルを分けた方がいいかもしれませんよ。
メッセージをリマインドする#
Slack ではメッセージが次々と流れていくので、メールのように敢えて未読にしておくことが難しいことが多いですよね。 依頼されたことや、明確に自分に対して問いかけがあった訳ではないものの、反応しておきたいものの、今すぐには書き込めないという事はよくあります。
そういう時はリマインド機能を使いましょう。リマインド機能はメッセージの右上にある「・・・」アイコンから設定できます。
リアクションを積極的に使おう#
Slack を筆頭に最近のチャットツールには、簡単な応答を行うためのリアクションという機能が実装されています。 単純なお礼、同意や否定、賞賛などはメッセージとして書き込まずにリアクションすると気楽に応答できるようになります。
チャットツールで感情表現しようとするとコミュニケーションが煩雑になるのでオススメはしません。 しかし、常に感情を封じてコミュニケーションするというのも不健康な考え方ですので、リアクションで低コストに感情表現するのがいいでしょう。
ここでは、筆者がよく使っており、Slack に標準搭載されているリアクションアイコンを紹介します。 Slack にはリアクションアイコンを自分で作成して登録できるので、自分達のチームにあったリアクションアイコンを登録するとより愛着が湧きますよ。
肯定、賞賛、承認#
これは、英語圏における thumbs-up というアイコンで肯定や賞賛、承認を表すものです。
ポジティブな反応は、コミュニケーションを円滑にする効果がありますので、積極的に使っています。
類似するものとして、お祝いの要素がより強い tada もあります。クラッカーを鳴らしているイメージですね。
自分には無い考え方や発想に対する賞賛をおこなう際には cool を筆者は使っています。「なるほど！」や、「一本取られた」みたいな使い方です。
同意を表す際には、 ok も使い易いアイコンです。文字として表現されているので、文脈を共有していない相手にも理解され易いのが良いですね。
否定、却下#
ネガティブな反応をすることが、効果的な状況が少ないのであまり使いませんが、そういう時こそお互い精神に悪影響の少ない方法であるリアクションを使いましょう。
一方で、悲しみや辛さに同意することが、コミュニケーションを円滑にする状況もあるでしょう。そういう時に筆者は、cry や skull を使っています。
単純な否定や、同意できないことを表明する際には、 ng も ok と同じ理由で使い易いアイコンです。
確認済、完了済、チェック#
メッセージに対して終了状態を表す際に使うのが check です。
リマインダーに check でリアクションを付けておくと状況を管理し易くなります。
発展的には、Slack に自分で書いたメッセージに check を付けていくことで TODO リストとして使えます。
相槌#
オンラインコミュニケーションにおいては、相手が自分の書いたメッセージを読んでいるのかいないのかが重要な状況はあります。 特に連続してメッセージを送信している際には、誰も見ていないとしたら空回りしているような感じになってしまい辛いことがあります。
そういう風にならないよう、否定も肯定もしないけれどメッセージを見てはいることを相手に伝えるために、筆者は eyes アイコンをリアクションします。
LINE のように既読状況が自動的に管理されるツールは、便利ですが一方で圧迫感もあります。
筆者としては、仕事で使うチャットツールでは、自分に余裕がある時だけ能動的に既読をリアクションできる方がより使い易いなと感じています。
簡易アンケートの作り方#
Slack のリアクションは、同一のリアクションを複数回付けられないので、チャンネル内にいる人に対して簡易的な選択式アンケートを取れます。
メッセージとして選択肢を提示した後に、メッセージを書き込んだ人が one、two、three、four、などのリアクションを付けてしまいます。
アンケートの参加者は用意されたリアクションを選択するだけで回答できます。
デフォルトグループメンションの回避#
Slack では @here や @gruop を使うと、チャンネル内にいる人全てに通知を送信できます。しかし、これは出来る限り使わないようにしましょう。
理由は、邪魔だからです。当該チャンネルに参加していると言うことは、そこでの話題に興味があるということです。不特定多数へのメンションなど使わなくても見ている筈です。
特に興味があるわけではないが、チャンネルに参加しているという状態の人は、そもそも当該ワークスペースにログインしていません。
結局本来気が付いて欲しい相手には届かず、キチンとチャンネルを見ている人には、過剰な通知になってしまいます。
特に、本人の意志では退室できない #general チャンネルなどのデフォルトチャンネルでは、@here や @gruop を使うのはできる限り避けましょう。
とはいえ、複数のメンバーに対して一々ユーザ ID を指定して通知を送るのは面倒ですよね。 そういう時は、ユーザグループを作成して送信対象を少しでも限定しましょう。
メンションに対する応答の義務性について#
チャットツールで自分宛にきたメンションに対して、すぐに答えようとするのはやめましょう。 勿論、自分の仕事に余裕がある状況ならすぐに回答すればいいのですが、そうでない時にはメッセージを見るだけにして応答しないことを選ぶと楽になります。 また、メンションを送る側の気持ちとしても、すぐに応答があることを期待しない方が気持ちが楽になりますよ。
チャットツールの電話に対する明確な優位性は、相手の時間を強制的に拘束しないことです。 自分にとっての要件の優先順位と、相手にとっての要件の優先順位が常に一致しているとは限りません。 もし、要件の優先順位においてお互いが最優先事項であると合意できるなら、電話で話した方がより効率よくコミュニケーションできますよ。
プライベートコミュニケーションの回避#
チャットツールを導入すると、多くの人が Slack でいうところのダイレクトメッセージや、プライベートチャンネルを使いたがります。 開かれた空間でのコミュニケーションに対する漠然とした恐怖感のようなものがあるのではないかと筆者は考えています。 ちょっとしたお願い事や、単純な質問をするのに公開の場所でするまでもないと考える人もいるでしょう。 しかし、業務でチャットツールを使っているのであれば、そのお願い事に対する応答や質問に対する回答は、本来チームの共有資産となるべきものです。
もし、特定の個人にちょっとしたお願い事が集中しているのであれば、業務上の資源配分に失敗している可能性があります。 また、単純な質問が様々な人間から繰返し行われるのであれば、プロセスに問題があるかもしれません。 単純な質問が特定の個人に集中していれば問題の芽に気が付くかもしれませんが、質問者と回答者がそれぞれ複数いれば、見逃されてしまいます。 プライベートコミュニケーションは、こういった組織的な問題の気配を全て覆い隠してしまいます。
情報統制などと言って、重要でもない情報に高い機密レベルのラベルを付けるのをやめてみましょう。
引用のやりかた#
Slack には様々な記法があり、メッセージを装飾できます。 詳細な記法については公式のマニュアルを確認して欲しいのですが、議論する上で確実に覚えて欲しい記法が 1 つだけあります。 それが、引用記法です。メッセージの行頭に > (大なり) を使うと引用表現になります。
以下のようにメッセージを書くと
こういう風に表示されます。
チャンネル編#
ここからは、Slack のチャンネルについて筆者が気を付けていることを紹介していきます。
general チャンネル利用の回避#
Slack では、ワークスペースに入った際にデフォルトで参加するチャンネルがあります。標準では #general チャンネルです。
このチャンネルは、それぞれのユーザの判断においては退室できない特別なチャンネルなので、ワークスペース参加者全員が絶対に把握しなければならない情報だけをやりとりしましょう。
つまり、ワークスペース自体の運営に関わる話題だけを #general チャンネルでは実施すべきです。
新しい参加者が来たら、挨拶や簡単な情報共有用のチャンネルに誘導してあげましょう。
チャンネルを分類する方法#
Slack にはメールのように受信したメッセージやチャンネルを分類する機能はありません。 しかしながら、積極的に中身を確認したいチャンネルと、そうでないチャンネルはあるでしょう。 特に積極的に確認したいチャンネルは、チャンネルペインの左上にあるスターをクリックしてお気に入りにしましょう。 画面左側のチャンネル一覧ではスターを付けたチャンネルが上に優先的に表示されます。
スター済のチャンネルと入室済のチャンネルの双方において、チャンネルをミュートできます。 チャンネルをミュートすると、未読メッセージ数が更新されず、メンションが来ても通知が来なくなります。
ミュート済みのチャンネルは、チャンネル一覧において最下部に表示されるので、スターとミュートを組合わせるとチャンネルを 4 種類に分類できるのです。
ここでは、 zogzogとgeneralがスター付チャンネルになっています。加えて、generalとpiyopiyoが、ミュート済チャンネルです。
全てのチャンネルに参加しようとするのはやめよう#
Slack は話題毎にチャンネルを作ると効率よくコミュニケーションできるので、ワークスペース内のチャンネルは基本的に増加していきます。
新しく出来たチャンネルの全てに入室するのはやめましょう。 自分の知らない所で他の人が楽しくコミュニケーションしていると気になるかもしれませんが、そこはグッと我慢してください。 チャンネルに参加するからには、積極的に発言しましょう、そうする気にならないなら自分にとって余り価値の無い場所なのかもしれませんよ。
新しく出来たチャンネルに次々入っていると、未読メッセージがどんどん蓄積していき、それを読んでいるだけで一日が終わってしまいます。 これを防ぐために、自分にとってそれほど重要でないと感じたら、まずミュートしてみましょう。通知が来なくなります。
チャンネルを見ないまま一週間ほど経過したら、思い切ってそのチャンネルを退出しましょう。 自分にとって意味や価値の無いチャンネルに入室したままにせず、意味や価値のあるチャンネルでのコミュニケーションと本来の仕事に集中しましょう。
パブリックチャンネルを作ろう#
Slack でチャンネルを作るときは、基本的に誰もが参加できるパブリックチャンネルにしましょう。 パブリックチャンネルなら、その話題に興味がある人が誰でも参加できるし、開かれたコミュニケーションはチーム内に知識を蓄積します。
あらゆる意思決定は公開の場でなされるべきだとは考えてはいませんが、組織内の意思決定をフェアにしたいなら情報公開はその基盤になります。
多くの人が見ている前で、質問したり自分の意見を書いたりするのは、恥ずかしいと感じるかもしれません。 しかし、ダイレクトメッセージやプライベートチャンネルだけを使って狭い範囲でコミュニケーションするより、 多くの人が見ている場所でコミュニケーションする方が得るものが多くなり易いですよ。
チャンネル名の考え方#
Slack ではチャンネルを階層化する仕組みが無いので、命名規則をゆるく作って運用するとチャンネルを探し易くなります。 チャンネル名の接頭辞を工夫すると、そこから話題が類推できるようになります。
例えば、筆者が利用しているワークスペースには、master-git、 master-slackといった master-で始まる各種ツールのちょっとした便利情報を質問したり共有するチャンネルがあります。
似ているチャンネルでは、 qa-jira や qa-cloud といったより質問と回答に特化したチャンネルもあります。
他にも、 社内にある他の部門と協調作業する際にはclb-という接頭辞を付けたチャンネルを作って、そこに他の部門の人を呼んでいます。
併せて、自部門内で協調作業の内容について協議するために sprt- という接頭辞を付けたチャンネルも作ります。
チャンネルの設計パターン#
Slack では話題毎に新しいチャンネルを次々と作るのが望ましいのですが、最初のうちはチャンネルを分割する基準が分らないこともあるでしょう。 そこで、チャンネルを新しく作る際に参考にできるようなガイドラインを紹介します。 この基準は唯一絶対というものではなく、あくまでも参考情報として使って下さい。
筆者が利用しているワークスペースでも、これらの基準に当てはまらないチャンネルは日々増えています。
キーワード基準チャンネル#
一番分かり易いチャンネルの作り方が、特定のキーワードを話題にするチャンネルを作ることです。 恐らく誰もが一番最初にやるだろうから、特に例示などは必要ないでしょう。
例えば、筆者が利用しているワークスペースでは muscle や dinner、lunch といったチャンネルがあります。
他にも、Jira や GitHub のチケット番号をチャンネル名として使っているチームもあります。 議論が紛糾するような状況では、タスク管理ツールのコメント欄では機能性が不足していることが多いので、チャットで議論した後、その議事録をタスク管理ツール側に転記すると、迅速に状況を収束させられますよ。
話者基準チャンネル#
内容ではなく、誰が話すのかを基準にチャンネルを作ると、Slack を使い易くなることがあります。
例えば、筆者が利用しているワークスペースでは、 times_taichi のように times_で始まるチャンネルは、特定の誰か主たる話者として扱うチャンネルです。
ここでは、主たる話者が自分の考えていることや、今困っていることを誰となく垂れ流します。
みんなが見ている自分の庭のような感覚で使うと良いでしょう。筆者は社内向けの Twitter のような感覚で使っています。
また、Slack には様々な機能が増えたり減ったりしていますので、それを余り他の人に迷惑をかけずに試す場所を確保しておくと、Slack への慣れが早くなります。
他の人の話者基準チャンネルに入室しておくのは、その人がちょっとした困りごとに遭遇しているのを見つけた時に、自分が出来る範囲で手助けするためです。 また、本人とって余り重要でないことでも、他の人がそれを見た時に創発的なトリガーになることがあります。
情報共有チャンネル#
RSS フィードを流したり、気になったニュースの URL を貼るためのチャンネルは分けておいた方が良いでしょう。 ただ、何のフィルタリングもせずにニュースサイトの RSS フィードを流すのは、チャンネルの流量が増えすぎるため、参加者の負担になり易く余りよくないやり方です。 ニュースの URL をチャンネルにはる時は、200 文字以内程度のちょっとした意見を一緒に書く方が参加者にとって有意義なものになり易いでしょう。
例えば、筆者が利用しているワークスペースでは tech や gadget といったチャンネルが情報共有に使われています。
techは、かなり雑多なソフトウェア技術に関する話題が流れています。
自分一人だけで Twitter やはてなブックマークのようなサービスを使っていると情報の偏りが出来やすいので、それを是正する意味で非常に便利です。
gadgetは、もう少し趣味に寄ったチャンネルで、新しいスマートフォンや、タブレット、スマートウォッチの新商品やキックスターターの記事が話題になります。
現在はキチンとした研究開発対象として認識されている VR 用のヘッドマウントディスプレイは、最初このチャンネルで話題になりました。
依頼/承認チャンネル#
筆者の部門では、Slack を始め Jira や GitHub など様々な SaaS を利用しています。 当然ですが、ユーザ全員に管理者権限を割当てるような運用はしていません。それぞれの SaaS に対して、管理者を定めて特定の操作が限定されたユーザに集中するようにしています。
その時、管理者権限での操作を依頼するためのチャンネルが、依頼チャンネルです。
依頼者がチャンネルに依頼したい内容を書き込むと、それを確認した管理者が eyes リアクションを付けます。
作業が終わったら heavy_check_mark リアクションを付けるか、作業が終わった旨メッセージを書き込みます。
依頼者は、そのメッセージに pray アイコンを付けて依頼完了です。
これの変形として、管理職が所属員の依頼を承認するチャンネルも考えられます。
例えば、筆者が利用しているワークスペースでは kintai というチャンネルがあり、休暇や遅刻、テレワークの開始や終了などの報告を所属部員が書き込むと承認者たる部門長がリアクションを付ける事で承認しています。
このチャンネルの運用によって承認作業のコストが大きく低減しています。 一般に承認者は管理職であり、その作業時間は非常に貴重なので、この手の承認作業は出来るだけ少ない工数で処理できる事が望ましいでしょう。 また、部門の所属員は、このチャンネルをざっと見るだけで、誰が出社しており、誰がテレワークで、誰が休暇なのかすぐに分かるのでそれぞれの状態に併せたコミュニケーションツールを選び易くなります。
ボットチャンネル#
ワークスペースの中にいるプログラマの割合いが一定を越えている場合、多くのボットがワークスペース内に登録されるでしょう。 また、GitHub や Jira などのツールと連携する際に、無軌道に連携するとメッセージの流量が増えるため使い辛くなります。 そういったことを防ぐため、ボットの動作を一定期間確認するためのチャンネルを用意しましょう。
Slack のボットは権限次第で様々な情報を読み取れますし、そこで読み取った情報をユーザが想定しないサーバに送信することもあります。 機密情報を扱っているワークスペースにおいては、ボットがどんな動作をするのか確認しながら段階的に導入しましょう。
通知チャンネル#
電子メールからチャットツールへ移行する際には、通知先としてもチャットツールを使いたくなるでしょう。 Jira のタスク更新通知や、GitHub のコミット通知、利用している SaaS のサーバ状況を通知してくれるサービス等々。
チャンネル内のメッセージ流量が通知メッセージは、かなり気を付けてフィルタリングしないとメッセージが増えすぎます。 まずは、通知を受信するための専用チャンネルを用意して、そこに通知を流すようにしましょう。 通知対象を十分に絞り込んだ後に、その通知設定を他のチャンネルに適用しても遅くはありません。
リラックスチャンネル#
リラックスチャンネルは説明が最も難しいタイプのチャンネルです。 ここでは、ワークスペース内にいるユーザが息抜きすることを主たる目的にしたチャンネルです。 あらゆるチャンネルでリラックスしてコミュニケーションできることが望ましいのですが、仕事で使う以上、そうもいかないこともあるでしょう。
人数が多ければ、そもそもリラックスしているとは、どういう状態なのか合意を取るのは難しくなります。 そこで、いわゆるマジレス禁止を掲げるチャンネルを作成して、その中では、どのような発言も許容されるものとして運用するのです。
例えば、筆者が利用しているワークスペースでは poem というチャンネルがあり、擬音やオノマトペ、誰かに伝える気の無い思いなどを書き込んでいます。
アスキーアートもよく書き込まれています。
vogue というチャンネルでは、仕事中に発言された名言や迷言を記録しています。
面白さが強く状況に依存しますが、そういうチャンネルを作っておいて後で見返すと非常に楽しいですよ。
筆者が賛同はできないものの強い感銘を受けた発言を、少し古いのですが一つだけ紹介します。
別に Suica が使いたいから買うのではない。Apple が新しい時計を出すから買うのだ。
まとめ#
このエントリでは、主に Slack を念頭において、チャットツールの使い方やその考え方について説明してきました。
繰り返しますが、ここで書いたノウハウは絶対的な基準となるべきものではなく、 あなたにとって受け入れ易く都合のいい部分だけを、取り入れて貰うことを意図して書いています。
全くのゼロからルールを作り出すのは非常に困難な作業ですが、 基準となる文書がありそれを基準に議論するのであれば比較的容易にできるものです。
このエントリを読んだ今までチャットツールをあまり使ってこなかった人が、 出来るだけ早くチャットツールに慣れて使いこなせるようになることを願っています。