チーム規模が大きくなってくると、メンバーでコミュニケーションを取る際のストレスがだんだん上がってきます。特にSlack上でのやりとりは関係者が増えると複雑になりがちです。この点に関してここ最近、明らかにコミュニケーションの質が向上したチームの取り組みがあったのでシェアします。
中規模チームにおけるSlackコミュニケーション課題
プロダクトチームはPM、デザイナー、エンジニア、データサイエンティスト含めて30人弱。同じスプリントを回すチームとしては少々大きいサイズです。結果としてチームとしては1単位ですが、あらゆるその中でタスクが並行して走っており、それぞれが色々な粒度のタスクを掛け持つような形になっています。
チームで使っているSlackのチャンネルは以下のような感じで分かれています。
- product-channel: プロダクト全般の仕様
- dev-channel: 開発レベルの仕様
- design-channel: デザイン系
- dev-*-channel: 各プラットホーム(Android, iOS, サーバーサイド)の技術検討
その他リリースやアラート専用のチャンネルもありますが大体上記が全てです。
ここで発生していたコミュニケーション問題が、複数のタスクの内容が並行する問題です。
- AさんとBさんがXの仕様を話していて、一方でCさんとDさんがYの仕様を話すと混線する。スレッドを使うと、議論が埋もれてしまう(Xに関係しているEさんが気付かない)
- 一つのタスクに関しての議論が飛び飛びになる。例えばSlack上だと
(Aの内容の議論1) (Bの内容の議論) (Cの内容の議論) (Aの内容の議論2)
と言ったように話し合いがとぎれとぎれになるので、あとでもう一度確認したい時にとてもストレスフルになる。
小タスク単位でチャンネルを個別に作る
上記のような状況に対して、小さなタスク単位でSlackチャンネルを作ってみました。具体的にチャンネルを作る基準としては、1スプリント単位で完了するタスク(機能)レベル以上にしています。現チームのスプリントは2週間なので、その期間で完了する見込みなタスクがスタートするとチャンネルを作ります。
pj-A-channel pj-B-channel ...
チャンネルに招待されるのはそのタスクのステークホルダーです。うちの場合ですと、エンジニア(クライアント、サーバー)、PM、QA、デザイナーで平均6人程のチャンネルになります。チャンネルのトピックにはConfluenceの仕様リンクを貼っています。ここで行われる議論はどう機能を作っていくかにフォーカスします。
- 進捗共有
- 仕様の詳細な認識合わせ
- リリーススケジュールの共有
毎日のスタンドアップは全体で行い、小チーム単位では行いません。その他、直接会話した方が早いような話ではもちろん対面で話したり、メンバーがリモートにいればハングアウトなどを行います。その内容もSlackのチャンネルに議事録的に貼ったりします。↓
チャンネルは機能のリリース完了後には閉じます。
このSlack運用に変えた結果以下のような効果がありました。
- 議論がスレッド上でクリアになるのでコミュニケーションの負荷が下がる
議論はそのチャンネルに集約されるので、どこで話しあったっけ、という問題はなくなります。 - 自分のタスクに関する集中力があがる
今までは自分と関係ないタスクに関するポストも全てdev-channel
やproduct-channel
に投稿されていたので、通知に煩わされたり、あるいは重要なポストを見過ごすということがしばしばありました。一方で今はタスクチャンネルはアサインされたメンバーしかいないので、何かコメントがあれば必ず自分に関係する内容になります。結果として必要な時に必要な情報が得られるので、タスクに対する集中力が上がりました。
チャンネル増えすぎる問題
一方で発生する問題として、Slackでありがちなチャンネル増えすぎ問題があります。コレに関してはトレードオフな部分もあるのですが、なるべく関係ない人は招待しないことで少しは緩和できるのかなと考えています。例えばトラッキング等メンバーとちょっと会話できれば済むようなことはpj-チャンネルに呼ぶことはせず、devで済ますようにするなどの配慮をするようにしています。
まとめ
結局のところ、Slackにおけるコミュニケーションの問題はいかに粒度を小さく出来るかが重要なのかなという感じです。もちろん1to1のコミュニケーションが一番良いですが、それだとチームとしてスケールしません。なので、適切なサイズを見計らってチャンネルを動的に作っていくのが大事なのかなと思いました。