Overview
僕の担当してるプロジェクトの Slack チャンネルで1週間限定で スレッド利用原則非推奨 というルールを作って運用してみた振り返りです。
プロジェクトに関わるメンバーに協力してもらって以下のルールで1週間 Slack を利用してみました。
- 全ての投稿はチャンネルへの投稿する。ある依頼への返事やMTGに遅刻してる人を呼ぶDM的な使い方も含む。
- Slack の流量が多くなることが想定されたので、気づいて欲しい時は臆せずメンションをつけること。
他部署や他プロジェクトの人に実験を強制するわけにはいかないので、その場合は例外的にスレッドの利用を許可しました。ただし、プロジェクトメンバーがスレッドで発言するときは also send to $Channel を必須にしてもらい、回答がチャンネルに流れるようにしてもらいした。
背景
そもそもこんな実験をしようと思った背景についてですが、僕は Slack に「スレッド機能」が登場した当初から Slack には不要な機能だなと思っていました。この点に関しては、もしかしたら同じような考えを持ってる人が一定いるかもしれません。
Slack (に限らず、こういったチャットベースのコラボレーションツール) に対しての僕の基本的な考えは以下です。
- Slack は情報のフローであって情報をストックするツールではない。
- スレッドは通常のチャンネルから UI 上 1 階層深いところにあるため、大量のチャンネルに入っていたり、プロジェクトを跨いで仕事をしてる人（要は忙しい人）ほど、深いところの情報を追うのが億劫になって見なくなりがち（僕はできることなら見に行きたくない）
- 見るのが億劫になることで、意思決定する人が検知しないところで話が進んでしまう、みたいな潜在的なリスクを孕んでいる。
- スレッド内で話される内容は当たり前だがコンテキストが高い内容が多くただでさえ、自身の意識を奪われがち、かつ会話の開始タイミングから間が空いてるものを急に掘り返されたりするケースがあるとコンテキストスイッチが変えるコストに加えて思い出しコストが乗ってきて、マジでキツい。
- 「情報は流れていってしまうもの」という認識をチームで統一することで、ドキュメントに残す（情報を別の場所にストックする）インセンティブ(※)をより働かせる。
※ 僕が担当してるプロジェクトではプロジェクト間で共有するべき情報はコンフルに、プロジェクト内の開発に関係するメンバーは Figma(or Whimsical) に仕様・議論の経過などを一元的にストックするようにしています。
振り返り
3/4~12 までの1週間、このルールを回してみて、昨日ちょうど振り返りをしたので、協力してくれたメンバーのフィードバックをまとめると大体以下のような感じでした。
Good
- プロジェクトに関連する情報がチャンネルのファーストビューに流れるので、拾い読みがしやすく、ながら時間でのキャッチアップがしやすい。
- ハイコンテキストな会話が他部署とのやり取りに制限されて負担は減った。
- 考察とかの会話重ねて練度上げていく投稿がスレッドじゃなくてチャンネル上に存在するので、チャンネル閲覧者の情報理解度が上がった。
- ざっと、他の人が何しているかわかり透明性が高くなった。
- スレッドに潜らなくても主要なやりとりは可視化された。
etc...
More
- スクロールが長い。
- チャットがあるアジェンダで盛り上がってるときに別の話題で投稿しづらい。
- 数往復程度のやりとりや単一のアジェンダであればスレッドにするまでもないが、議論の足が長かったり、複雑な内容の会話になる場合はスレッドの方が向いてる。
- 他部署絡むとスレッド作った方が効率的な場合がある。
- Slack の機能的な制約により厳しい側面がある（発話元リンク投下しても見づらいし、検索機能がいけてないので後追いに時間がかかるなど...）
etc...
以上が振り返りです。
個人的な所感
Good/More を元にして個人的に想定していたこと、想定していなかったことについて記載します。
まず振り返りをして思ったのは、期間限定とはいえコミュニケーションの仕方をある種変えることを強制することになるので、反発やストレスがあるかなと思ったんですが、プロジェクト内のメンバーから概ねポジティブなフィードバックが多かったのが意外でした。
この辺はもしかしたら普段から大量の情報に触れてたり、ある程度今何がどうなっているのかを主体的にキャッチアップしようとするメンバーが多いという恵まれた状況にあったからかもしれませんが、多少の混線やUI的な見づらさはあれど、致命的にネガティブなものはなく、キャッチアップコストの低減と透明化の観点からはスレッドに使わずチャンネルにどんどん投稿した方がいいのかなと思います。事実、チャンネル投稿を推奨しても生産性が大きく削がれた、というフィードバックはありませんでした。
スレッド自体も機能の1つなので、発話者が使った方が良い、と思えば使うことはいいと思います。あえて強制力のあるルールを作る意図もありません。 ただ、迷ったらチャンネルに投稿しておく方が無難だし、公開したい範囲を狭める必要がないならチャンネルに投稿しておくのがいいと思います。
こういうコミュニケーションについて考えているとやたら関係者や話題と絞りたがる欲求が強いなと感じる場面が多いのです。ただ、情報の取捨選択は受け取る側でやるべきことなので、とりあえず迷ったら垂れ流しておいてくれる方が助かる場面は多いです。
Good にも記載してますが、「拾い読み」の効用は大きいなと感じるケースは多いです。たまたま気になるトピックを見つけたことから話が広がってアイデアに繋がることや、逆に事前にブロッカーを取り除けたり、リスクに気づけたりする機会も生まれたりすることは、僕は貴重だと思います。
何よりリモートが前提となってる今だからこそ、チャンネルを賑やかにさせる空気感？みたいなものを作るためにも、どんどんチャンネルに投稿した方がいいのでは？という気すらしてきます。
そういえば、この実験してる最中に Slack を作ってる Slack 社では Slack をどのように使っているのか？とナイスタイミングでまとめてくれてるエントリがありました。
なお、エントリの中で引用されているメルカリのガイドラインは本当に秀逸で、Slack を使う場合は全てこのガイドラインが最低ラインであり基準になると思っています。
コミュニケーションコストについて
ここで改めてコミュニケーションコストというところについて考えてみたいと思います。
チャンネルへのそのまま投稿にしろ、スレッドにしろ、目指したい姿は 実行のスループットを上げるためのコミュニケーションコストの低減 であるべきです。
ハイコンテキストな内容であれば、関係者間で話を進めた方が早いでしょう。それは事実だと思います。ただし、それはともすると公開される場所に置いて意図的に部屋を分ける行為(言い方を変えるとある種の密室状態)になります。Slack のスレッドは密室じゃない、という意見もありそうですが、1階層深いところで話されている時点で本来知るべきメンバーにも公開されていない or 自分で取りに行かないといけないわけで、それが密室でないとは僕自身は思いません。
ある程度話が進んだ段階で、あとから部屋に呼ばれた時の「いやそれは聞いてねーよ」みたいなことが発生する可能性を孕んでることが、本当に目指したかったところに繋がってるのかは個人的には疑問です。
僕自身もそこまで多くはないですが、全然違う仕事をしていたときに、いきなりかなり会話の進んだスレッドに巻き込まれて、話について行くのに時間がかかったことが、この1年だけでも何回かあります。
こういうことが起きそうだなーと考えたとときに、「誰でもみれる場所に大量に流れている情報から必要なものを取り出し整理する状況」と「準密室でコンテキストが限定された会話の内容を自分で取りに行かないといけない状況」を比較したときに、僕自身は前者に振る方が全体としてはコミュニケーションコストが減ると考えています。
最後に
個人的には全ての情報がチャンネルに垂れ流されてるという状態は、情報のキャッチアップコストの低下、及びプロジェクト内の透明性の観点からありがたかったのですが、一方で大量の情報から必要な情報をぱっとピックアップして、整理できるというのは、それ自体が個人の能力に依存したスキルの1つと捉えるようになりました。
ありがたいことに、スキルは後天的的につけることが可能です。
そしてこの大量の情報の流れの中から自分に必要な情報や気になる情報をパッと取り出すスキルの習得にうってつけなのは 間違いなく Twitterです。
仕事の生産性向上のために、業務中とか関係なく全力でTwitter をやって行きましょう。Twitter するのも仕事のうちです。
osimai
