💬

SlackのHuddleを使うなら、チャンネルを分けよう

に公開

こんにちは、ハコベル開発チームの坂東です。この記事は「Hacobell Developers Advent Calendar」4日目の記事です。

私たちのチームでは、日常的にSlackのHuddle機能を使ってミーティングを行っています。手軽に音声通話を始められて便利な一方で、ある課題に悩まされていました。

それは「Huddleの通知でメインチャンネルが埋まってしまう」という問題です。

この記事では、会話専用チャンネルを作るというシンプルな工夫で、この課題をどう解決したかを紹介します。

メインチャンネルがHuddle通知で埋まる問題

私たちのチームは3つのサブチームで構成されており、それぞれが活発にコミュニケーションを取っています。Huddleを使う頻度も高く、便利に使っていたのですが、次のような課題がありました。

課題1:Huddle通知で重要なメッセージが埋もれる

Huddleを開始すると、必ず「ハドルミーティングが発生しました」という通知がチャンネルに投稿されます。ミーティングのたびにこの通知が流れるため、重要なメッセージが埋もれてしまい、見逃しが発生していました。

課題2:同時にHuddleしたい時のチャンネル競合

3つのサブチームが同時にミーティングをしたい時、「どのチャンネルでHuddleするか」で迷う場面がありました。メインチャンネルは1つしかないため、複数のチームが同時に使うことができません。

フロー情報とストック情報の混在が原因だった

ここで少し視点を変えて、Slackの特性について考えてみます。

Slackは本来、リアルタイムのコミュニケーションを目的としたツールで、フロー情報(流れていく情報)を扱うのに向いています。一方で、実際に使っていると、重要な決定事項や議事録、リンクなど、後から見返したいストック情報(蓄積していく情報)も自然と溜まっていきますよね。

Huddleでの会話は典型的なフロー情報です。「これますか?」「今行きます」といった、その場限りのやりとりが中心になります。でも、これがメインチャンネルに流れてしまうと、ストックしておきたい重要な情報が埋もれてしまうんです。

この「フロー情報とストック情報の混在」が、私たちの課題の本質でした。

解決策:Huddle用の会話専用チャンネルを作る

解決策はシンプルでした。Huddle用の会話専用チャンネルを複数作成し、MTGごとに使い分けることにしたんです。

私たちは #team名_◯◯部屋 のような名前でチャンネルを作り、チームメンバー全員を参加させました。このチャンネルは「気軽に会話するための場所」として位置づけ、Huddleの履歴が溜まっても問題ない場所としています。

メインチャンネルにはHuddle通知が流れなくなるため、重要なメッセージが埋もれることがなくなりました。

運用のポイント:カレンダーに部屋名を記載する

導入時は「このチャンネルでHuddleしてください」とアナウンスしました。最初は慣れが必要でしたが、すぐに違和感なく使えるようになりました。

運用上のポイントは、カレンダーの予定に部屋名を記載することです。Google Meetの場合はリンクが自動で紐づきますが、現時点ではその機能がありません。そのため、カレンダーの件名や説明欄に「#team名_◯◯部屋でHuddleします」と明記することで、参加者が迷わないようにしました。

導入初期は部屋を覚えるまで、間違えてメインチャンネルでHuddleしてしまうこともありましたが、次第に定着していきました。

導入してみて感じたメリット

この取り組みによって、次のようなメリットが得られました。

1. 見逃しが減った

メインチャンネルがHuddle通知で埋まらなくなったため、重要なメッセージを見逃すことが減りました。

2. 複数のサブチームが同時にHuddleできる

会話専用チャンネルが複数あるため、3つのサブチームが同時にミーティングを開催できるようになりました。

3. フロー情報とストック情報を区別できる

これが一番大きなメリットです。Huddle中のスレッドでは「これますか?」「今行きます」といった情報量の少ない会話が行われますが、これらはメインチャンネルに混ざりません。重要な連絡や決定事項はメインチャンネルで共有するという使い分けができるようになりました。

4. チャットが流れないので快適

会話専用チャンネルはHuddleの履歴で埋まりますが、それで問題ありません。逆に、メインチャンネルは本当に必要な情報だけが流れるようになり、快適になりました。

運用上の課題

もちろん、課題もあります。

1. 新メンバーへの周知が必要

会話専用チャンネルの存在を知らないと、新しく入ったメンバーは参加できません。オンボーディング時に説明する必要があります。

2. チャンネルが増える

ただでさえチャンネルが多い環境では、「チャンネルが増えすぎて管理が大変」と感じる人もいるかもしれません。

3. 導入初期の混乱

慣れるまでは、どの部屋でHuddleするか迷ったり、間違えてメインチャンネルで始めてしまうこともありました。

どんなチームにおすすめか

この方法は、特に次のようなチームに向いていると感じています。

  • 会話量が多いチーム:Slackでのやり取りが少ないチームでは、そもそもこの問題が気にならないかもしれません。
  • 複数のサブチームがあるチーム:同時にミーティングしたいニーズがある場合、特に有効です。なお、そもそもサブチームごとにチャンネルを分けるという選択肢もあるでしょう。ただ、私たちのチームではサブチーム間でも連携が発生するので、今のまま1つのチャンネルで活動しています。
  • Huddleの頻度が高いチーム:頻繁にHuddleを使うチームほど、メリットが大きくなります。

一方で、次のようなチームでは分けない方がよいかもしれません。

  • 長時間Huddleを繋ぐチーム:モブプロなどで半日以上繋ぎっぱなしにする場合、Huddleスレッドにもストック情報を書くことがあります。この場合、チャンネルを分けると検索性が落ちてしまいます。
  • Huddle中であることを周囲に伝えたいチーム:メインチャンネルでHuddleすることで、「今ミーティング中なので対応が遅れます」という状況が自然と伝わります。透明性を重視するなら、分けない方がよいでしょう。

開発スタイルによって最適な運用は異なるので、チームの状況に合わせて判断してみてください。

まとめ

チャンネルを分けるという小さな工夫で、「会話が流れてしまう」という課題を解消できました。

Slackはフロー情報を扱うツールですが、同時にストック情報も蓄積されていきます。この二面性を意識して、フロー情報とストック情報を区別することで、チームのコミュニケーションがより快適になります。

もしSlackのHuddle運用で悩んでいる方がいれば、会話専用チャンネルを試してみてください。

Hacobell Developers Blog

Discussion