コラム サービス 組織

Slackに使用規則を策定した話

2024年12月6日

Slackの運用課題に気づいたのは、社内で200〜300メッセージを超える長大なスレッドが多数存在することに衝撃を受け事からでした。

Slackのスレッド機能自体は優れていますが、適切に使用する必要があります。

200〜300メッセージに及ぶやり取りを全て追うことは非効率的です。

このような長大なスレッドの兆しがある場合、新しいチャンネルを作成するか、直接会議を開き、Google DocsやNotionなどの外部ドキュメントにまとめる方が生産的です。

ほとんどの社員があらゆるチャンネルに参加しており、かつ会話をまとめず、情報を無秩序に投稿し、整理したつもりになっているのが実情でした。

Slackは纏めるツールでは無いため、ここでの問題は社内文化とのミスマッチにあります。

社内では「一対多(ここでは三人以上)の場合だけスレッドの使用を極力非推奨」にし、「長期に渡りそうなやり取りは最初から別途チャンネルを作成し、やり取りが終了したらアーカイブする」事にしました。

一対多のコミュニケーションに制限を設けることは、情報工学的な視点から効果的な戦略といえます。

本稿では、ユーザー視点での「見づらさ」に焦点を当て、情報工学的な観点から説明します。

一対多のスレッドが見づらくなる理由(情報工学的視点)

階層構造による情報の埋もれ

スレッドは「階層構造(ツリー構造)」で情報を整理しますが、一対多のスレッドでは分岐が多すぎると、全体像の把握が困難になります。

情報がサブメッセージとして深く埋もれるため、ユーザーがどこに重要な情報があるかを視覚的に見つけにくくなります。

視覚負荷の増加

長大なスレッドでは、すべてのメッセージを展開しないと内容を把握できないため、スクロール操作や展開操作の負担が増えます。

これにより、ユーザーの視覚的負荷が大きくなり、情報の流れを追うのがストレスになります。

2週間以上(実際は1か月以上)経過し、100件以上の返信(実際は200件以上の返信)があるスレッドに、招待されて一から他人の文章を追うのは強いストレスになります。

文脈の分断

一対多のスレッドでは、「複数のトピックが同時進行」することが多く、ユーザーは各返信ごとに異なる内容を追わなければなりません。

結果として、前後の文脈を把握しづらくなり、思考の断続が発生し、情報の理解や判断のスピードが低下します。

視覚的な一貫性の欠如

メインのチャンネルとスレッドの情報が別々に存在するため、ユーザーは「視線を頻繁に切り替え」る必要があります。

これにより、重要な情報が隠される可能性が出てきます。

更に、「視覚的な一貫性」が損なわれ、どこを見れば良いか迷いやすくなります。

フラットな構造との比較(見やすさの違い)

フラット構造(1:1のやり取り or チャンネルでの直接投稿)

フラットな構造では、メッセージが直線的にしか並ばないため、ユーザーは一目で情報の流れを追いやすくなります。

すべての情報が「同じレイヤー上」にあるため、スクロールだけで文脈を把握できます。

一対多のスレッド

情報が階層的に分かれるため、「どのメッセージが肝になったのかを視覚的に判断しづらい」です。

メッセージを展開・折りたたむ操作が必要になるため、情報へのアクセスが直感的ではなくなります。

結論|「見づらさ」の本質と改善の方向性

一対多のスレッドは、視覚的な情報の分断や文脈の断絶を引き起こし、「ユーザーが情報を俯瞰しにくい構造」になります。

これに対し、フラットな情報構造は「情報の一貫性を保ちつつ、直感的な操作で情報を把握しやすい」ため、ユーザーが感じる「見やすさ」が向上します。

一対多のスレッドを極力非推奨にし、チャンネルを別途作成させる方針は、ユーザーが必要な情報に素早くアクセスし、何より全体の流れを理解しやすくするために有効です。

ここでは書いていませんが、通知的な負担もあります。メンバーが特定の投稿を気にするかどうかを自分で決められるようになる必要があります。

あとがき

ツールの是々非々はよく見かけますが、正直に言うと環境次第なので取るに足らない議論です。

ただ、スレッドは後天的に追加された機能のため、実装時に良いUI/UXを考えなかったSlackに責任があると考えています。

Slackの使用方法の決め事とトレーニングは割と重要です。

  • スレッド使用の是非
  • 特定のトピックについて短期間の公開チャンネルを作成し、完了したらアーカイブしつつ、チームチャンネルで特定の会話を行う
  • @channel と @here など広範囲メンションの使用について

発生する全ての問題は、ルールとトレーニングの問題である事が多く、必ずしも現場だけのせいではありません。彼らはただ、より良い方法があることを知らないため、使用方法を規定したり指導する必要があります。

全てのコンテンツでそうですが、特定の事が出来ない人向けには「〇〇してはいけない」という制約を設けると効果的です。

ちなみにスレッドが長くなった場合に、何らかの催促を促す機能改修の要望は運営に送っています。

  • この記事を書いた人

朝倉卍丸

シングルモルトスコッチなどのお土産を持ってきた人を助けるのが好きです。サービスの分割が重要ですが、まあ昔ながらの方法でやりたいこともありますよね。

よく読まれている記事

条件の0=0は全てが正であるを意味するSQL 1

SQLの条件に0=0のような記述を見かけます。 変わった書き方の条件ですが、これは「全てが正である」事を意味しており、結合条件の場合はCROSS JOINと同じです。 下記の例で言えば、結合するsub ...

DISTINCTを使わないで重複排除を考えるSQL 2

SQLのDISTINCTはEXISTSとかGROUP BYでなんとかする事もできます。 DISTINCTは暗黙的なソートがされますが、何のDBを使うにせよ過去のバージョンならともかく、最近のバージョン ...

RFC 5322に準拠させた正規表現言語別 3

RFC5322で定義されている正規表現を、各言語の正規表現に変化させた形になります。 完全な電子メール正規表現は存在しないので、結局のところ何かの公式基準に従っていたとしても、自分が携わるサービスのル ...

-コラム, サービス, 組織