AdventCalendarな時期がやってきました。
AdventCalendarの記事を書くと、もうすぐ一年が終わるんだなーと感じますね。
ちなみに自分12月は師走ならぬ死走(デスマーチ)です。
概要
昨今、チャットツールを開発に取り入れていないプロジェクトの方が少なくなってきたのではないでしょうか？
自分のプロジェクトでもチャットツールにはSlackを利用しています。
チャットツールは便利で自由な反面ある程度ルールがないとカオスになる傾向にあります。
今回は自分の中で心がけるようにしているルールを紹介したいと思います。
※利用するチャットツールとしてSlackを基準に話しています。ただそんなに技術的な話ではないので他のチャットツールでも使えるかと思います。
結論
ドキュメントとして使わない
もちろん議論をする場所としてチャットは適切ですが、その結果はチャット上ではなくwikiやissueに書いて残した方が良いです。
チャットツールはタイムライン形式でバンバン流れていってしまうので遡るが大変です。
検索やピン留等の機能はありますが、記録を残すという意味で使うには少し使いづらいかと思います。
自分がよくやるのは議論したチャットのリンクをwikiやissueに貼っておき、こんな感じで決まったんだなーというのをわかるようにしています。
↓議論してた箇所、始まりの議論からリンクをコピー
文書としてはesaに記載
複数の議論が走らないようにする
例えば
- パターン1
- Zプロジェクトについて話している時に、別の人がXプロジェクトの議論を始めてしまい複数の会話が始まる
- パターン2
- Aさん、Bさんがある不具合についてチャットで議論している時に、Cさん、Dさんが違う不具合の議論を始めてしまい複数の会話が始まる
パターン1について
チャンネルで話す内容の粒度(ジャンルとか)が決まっていないことで起きる問題です。
この問題はある固有のチャンネルを作ることで解決できます。
今回の場合であれば、XプロジェクトチャンネルとZプロジェクトチャンネルを作ることでこの問題は回避できます。
当然、それぞれのチャンネルではそのチャンネルにあった内容のみを発言するようにします。
パターン2について
これはチャンネルで話す内容はあっているが複数の内容が走ってしまうことで起きる問題です。
自分はこう言う場合はスレッド機能を使い回避しています。
こんな感じで議論が長くなりそうなものはスレッドで議論するようにしています。
通知と議論が混ざらないようにする
ここでいう通知はクラッシュ通知やインフラエラー通知など、監視通知をさしています。
通知のチャンネルではあくまで通知を見るだけにしています。
議論等はIssueトラッカーを使いそちらで対応するようにすることで、通知と議論が混ざらずみやすいチャンネルになります。
ただ対処したのかどうかわかるようにリアクションをつけたり対応するissueのリンクをスレッドに貼ったりはしています。
まとめ
チャットツールは便利で自由な反面ルールがないとカオスになりがちです。
ここであげたルールあくまで自分たちのプロジェクトではうまくいっているという話なので、各プロジェクト、環境に合わせて運用していきましょう。
いいコミュニケーションで良い開発を！