自分が業務をする上でのSlackの使い方を公開してみる
ツール・サービス
Slack
エンジニア業界では、業務を行うにあたって Slack を活用している方が多いのではないでしょうか。
以前、自分の Slack の使い方を展開したところ好評をいただけたので、今回思い切って記事にしてみました。
Slack とは？#
Slack（スラック）は、スチュワート・バターフィールド（英語版）によって開発されたチームコミュニケーションツール。 Slackという名称は”Searchable Log of All Conversation and Knowledge”のアクロニムである。
Slackはグループチャット、1対1のメッセージング（Direct Message）、音声通話をWebサービスとして提供している。
引用
Slack を知らない方だと、これを言われたところでイメージしにくそうなので実際のワークスペースの画像を貼っておきます。
このブログを公開するにあたって、先輩に加勢していただいていた時期のやり取りなので、だいぶ前ですね(笑)
Slack を使うためにはまずワークスペースを作ります。
そしてそのワークスペースに参加したい人がアカウントを作成して参加する感じです。なお、複数のワークスペースに参加もできます。
ワークスペースでは上の画像のようにチャンネルがあり、チャンネルごとにグループチャットができるようになっています。
例えば、この案件についてはこのチャンネル、雑談はこのチャンネルとかですね。
その他、ユーザ間で直接 DM を送ってやり取りしたり、音声通話をしたりできます。
自分はこの業界入ってから Slack を使うようになりました。
これまでいちいち電話とかメールでやり取りしていたのをチャットでパパっと済ませられるので、時間も節約できますし何より楽だなと思ったのを覚えています。
自分の使い方・気を付けていること#
※一応、最初に書いておきますが、あくまで自分の使い方・気を付けていることなので、これが正解だとか言うつもりは全くありません。
概要#
大まかに書くとこんな感じです。
- 以下の内容を積極的に書き込む
- 進めているタスクで困ったことや懸念点
- 進捗や状況
- 確認事項
- なるべくパブリックチャンネルでやりとりする
- 素早く返信もしくはリアクションをする
- リマインダーを活用する
積極的に書き込む・進めているタスクで困ったことや懸念点#
詰まったこと・困ったこと#
進めているタスクで詰まったり困ることは往々にしてあります。
技術的な内容であれば自分で調べて解決できることもありますが、自分で解決できない問題であったり調べてもわからない問題の場合は、一人でずっと悩むのでなく早めに共有するよう心がけています。時間がもったいないので。
書き込む際は、ただ「困ってます」とだけ書いてもしょうがないので、こんな感じのことを一緒に書きます。長くなりそうなときはスレッドにして付け加えていくこともあります。
- どこで詰まったり困ったりしてるのか
- 結局、何ができれば OK なのか
- 自分が試したことと、試してどうなったか
- 問題の再現方法
- 自分の考え（あれば）
- エラーの場合はスタックトレース
ちなみに自分は、よっぽどこの人に聞きたい！って時以外はメンションつけずに書いてます（ここら辺はその案件の環境にもよるかなと）
もし問題の解決方法をわかる人がいれば助けてもらえるかもしれませんし、Slack に上記のことを書くにあたって自分の頭の中でまとめる必要があるので、そこで整理されて自然と答えが出ることもあります。
人によっては相手の時間を奪ってしまうと考える方もいるかもしれませんが、一人で悩み続けた結果遅れが出て加勢をお願いするとかの方が、よっぽど時間を奪うと思います。
無事問題解決に至った場合は、その解決方法も書いておきます。
そうすることで、もし同じ問題に直面したメンバーがいたとき参考にできるからです。
懸念点・心配事#
懸念点や心配事に関しても、一人で考え続けてもしょうがないので早めに共有します。
もし自分でこうした方がいいかな？というものがあったとして、それが必ずしも正しいとは限らないので、ちゃんと共有して確認しておいた方が無難です。
書く内容としてはこんな感じ。
- どういう懸念点や心配事なのか（～すると、こういう問題が生じそう など）
- 問題に対する代替案（あれば）
積極的に書き込む・進捗や状況#
特別この時間に書くと厳密に決めてやっているわけではないですが、作業開始時にまずやることをリスト化して書きだしておいて、そのスレッドに進捗を書いたりしています。
書いた時点で完了しているもの、残っているものがわかるように書きます。
あまり進めてないならないで、正直に書いた方がいいです。
見栄張って嘘ついても何の意味もないですし、余計迷惑かけるだけなので。
あと、途中経過の成果物の共有もなるべくやるようにしています。
フロントエンドの内容だったらスクショや動画（重たくなりがちなので GIF がいいかも）を「こんな感じで作っていってます」とアップして確認してもらったり。
ちょっとした改修程度ならやらなくていいかもしれませんが、新しい機能であったり、やることが多いタスクだったりすると認識違いが発生することもあります。
はじめから100％のものを作るのは無理だと思ってますし、自分の中で100%であっても他の人やお客さんからはそうじゃないというのもざらにあります。
もし認識違いをしていた場合に下手すると最初から全部やり直しとか、余計なところまでやってたとかになると目も当てられません…。
途中経過を共有することでこういったことを防ぎやすいです。
また、こまめに進捗や状況を書いておくと、プロジェクト管理する側にとってもいくらかやりやすくなるのではないかと思っています。遅れが出ているなら出ているで、早めにリカバリーできるからです。
期限ギリギリで遅れが…と言われたところで、カバーのしようがないです。
また、リモートで仕事をしている場合、より状況が見えにくくなるので積極的に共有した方がいいと思います。
とはいえ自分も、作業見積もりが下手くそなので、前に参加していた案件ではよく迷惑をかけていました…。今はいくらかマシになったかと思いたいです。
積極的に書き込む・確認事項#
確認する相手が近くにいると対面で確認しがちですが、対面で確認したとしても記録が残るように確認事項とその回答をなるべく書くようにしています。
もしその確認事項について忘れてしまっても後からさかのぼって確認できますし、仮に認識違いがあったら早めに気付けるからです。
それと、あまりないかもしれませんが、後から言った言ってないという無用のトラブルになるのを避けられます。
メリットをまとめるとこんな感じですかね。
- 自分の状況や思考を他のメンバーと共有できる
- Slack で書くにあたって頭の中が整理できる
- 認識違いがあった時、早めに気付けるかも
- 遅れが出た時などに早めにリカバリーしやすくなる（プロジェクト管理しやすい）
- もし問題の解決方法をわかる人がいれば助けてもらえるかも
- 他の人が同じ問題に遭遇した時、参考にできる
- 記録が残るので後から振り返ることができる（当人だけでなく、他のメンバーも）
なるべくパブリックチャンネルでやりとりする#
質問をする時などに直接その相手に DM をする方がいるのですが、内容によっては自分と相手だけでなく、いろんな人にとって有益な情報になりえますし、パブリックなところでやり取りした方がいいと思っています。
詰まったこと・困ったことのところでも書きましたが、同じことを聞きたい人がいた場合、パブリックなところでやり取りしていればその人も一緒に解決できるからです。
（決して DM を使うなということを言いたいわけではないです）
素早く返信もしくはリアクションをする#
自分宛てのメンションがついた書き込みには、なるべくすぐに回答するようにしています。
返信に書く内容が多いなどして時間かかりそうなときは、とりあえず読んでいることがわかるようにリアクションつけたり、「ちょっと待ってください」とかをまず返したり。
ただ、会議に参加していたりしてすぐ返せないときもあると思いますので、そういう時は無理にやらなくていいかなと思っています。（もちろん会議に参加するといった旨はちゃんと共有しておくこと）
全体宛てのメンションだった場合は、必ずしも回答書き込みまでは必要ないと思いますが、同様に読んでることがわかるようにリアクションをつけます。
リマインダーを活用する#
リマインダーを設定することで、設定しておいた時間に設定した内容を通知してくれます。
自分は忘れやすい予定やタスクがある時などにリマインダーを活用しています。
コマンド例としては/remind 宛先 通知内容 to 日付 at 時間みたいな感じ。
ちなみに小ネタとして、宛先にチャンネルを指定+全体にメンション飛ばしたい時は、通知内容に@hereなどの全体メンションをいれるとよいです。
コマンド生成のツールもあるので構文覚えづらい方は活用されてはどうでしょう。
書き出すと意外と長くなってしまいましたが、これ全部ちゃんとやれてるの？って言われると、正直完全に定着出来ているとまではいかないです（苦笑）
ただ、このやり方自体は好評をいただけたので、これからより洗練して業務に取り組んでいきます。
今回の内容が他の方に何かの参考になれば幸いです。