リモートワークの時間割とSlackの運用 後編
リモートワークではSlackの頻度や量を下げる事で生産性が上がるのでは？という記事を書いたのですが、今回はその記事↓の結果報告（後編）です。
試みた対策内容
試みた対策内容は以下です。
- 必要性が薄いチャンネルから外れる or ミュートする
- メンションやスレッドの通知がない限りSlackは開かない
- Rescue Time で日々何に時間をかけているかの計測
それぞれの結果を記載していきます。
必要性が薄いチャンネルから外れる or ミュートする
結局のところ外れたチャンネルは無かったのですが、ミュートはいくつかしました。体感的にも負担が減り、単に読み流すだけでも負担だったのだと思います。
ミュートして、その後そのチャンネルを全く見ないなら、チャンネルから外れる。
という順序にすると問題は起きなさそうです。
また、会社としては社員が必ず参加すべきチャンネル（そこで流れる情報は必ず認識している必要のあるチャンネル）を決定しておくと、キャッチアップのためにチャンネルに入り過ぎるという事も無くなりそうです。
メンションやスレッドの通知がない限りSlackは開かない
これまでの癖で開いてしまう。といった場面もあったのですが、なるべく作業が一区切りついてからとメンションやスレッドの通知が確認出来ない限り開かないようにしていました。
未読メッセージは溜まるのですが、想定通り即自分が関わる必要の無いものなので、即確認しない事による問題はありませんでした。
マルチタスクの割合も減り作業効率が上がるので、今後も続けたいなと思うのですが、デメリットとしては溜めすぎると、まとめて見る際の情報量が増えるので見逃しのリスクが上がりそうです。
メンションやスレッドへの通知という条件はありつつ、30分に一度とか作業の一区切り段階で全部確認するとかのルールを設けた方がバランスが良いかもしれません。
（補足：緊急性の高いやりとりの場合は即座に反応していく必要があると思います。複数人が集中して物事を進めているとしたら尚更で、自分の返答待ちになってしまうと、自分がボトルネックになって複数人の時間を無駄にしてしまうためです。）
Rescue Time で日々何に時間をかけているかの計測
前述の対策の実行前後をRescue Timeで見た結果です。
先週の結果（対策実行前）
今週の結果（対策実行後）
- 平日の9:00~19:00の間だけの集計になります
- 先週途中から始めたので、先週の計測は2日分足りないです。
- 青は生産的、赤は非生産的な時間で、真ん中に割合が productivity pulse として表示されます
青は生産的な時間と定義したもの（定常のオペレーションや資料作成など）、ピンク色の部分はほぼSlackの利用と思ってもらってよくて、赤はSNSの利用などによる非生産的な時間と定義しています。
Communication & Scheduling は主にはSlackで、Business には主に定常のオペレーションや資料作成などが入るようにカスタマイズしています。
比率結果は Communication & Scheduling が先週比9%抑制、Business が6%増加、という結果になりトータルの生産的な比率も61→64へ上昇したため、一定の効果はあったように思います。
肌感としても「もうこんな時間？？」みたいな事は少なくなりました。
（補足：実際は相互の色にそうとは言えない内容も含まれます。先週は Social Networking に1%時間を使っていますが、主にはリファラルの採用活動をLINEでしてたみたいな事だったりします。Business に対応する業務をしていたとしても、アイドル時間がどれぐらいあるか等は計測出来ないので、アイドル時間と手を動かした時間の割合がどれぐらいあるかというところを集計出来ないと本質的では無い気がしてます）
結果から考える有効な対策
Slackで自分と関連の薄い情報に触れるのを控えた方が良いと感じます。
ただ、情報のキャッチアップやコミュニケーションはスタートアップや入社初期段階では積極的に参加した方が良い期間があると思っています。
これは会社やメンバーが自分を利用出来ない状況になる事を防いだ方が良いためで、ある程度社内の状況が見えたり、自分のスキルを見せれた段階では減らして問題無いのでは考えます。
特に新しい施策をする際の情報伝達や認証の流れが決まっていない組織の場合、自分は何の専門家なのかを認識してもらわないと、知らない間に何かが出来ていて、後々自分が作り直す事になるという事も発生しかねません。
これを防げるような関係性が出来た状態であれば、自分からはあまり首を突っ込まなくて良くなります。
（補足：だからといってガチガチに認証のフローを固めるとどこかでボトルネックが発生し大企業的な遅さが発生するのがあるあるです。この辺りは施策毎にスピードと安全性どちらに比重を置くかが大きく変わるところだと思います。）
また、作業効率を大きく下げるのは抱えている業務数では無く、作業途中に発生するミクロなマルチタスクだと思うので、いかに作業中に他の作業をするのを控えれるかが生産性向上には大事だと感じます。
このあたりは組織単位でも何かしらの取り組みが必要かもしれません。例えば、以前いたCS組織では口頭でのエスカレーションを禁止にした事がありました。これも受け手側のマルチタスク発生を防ぐ意図です。
勿論口頭でやり取りした方が早い内容もあるので、その場合はまずチャットで口頭確認の時間を確保して進めるイメージです。とにかく他人の思考をさえぎる事による生産性低下に配慮した結果です。
最近リモートになって生産性が上がったという会社の多くは必然的にこの状態になり生産性が上がったのでは？と個人的には思ってたりします。
ただ、これを全社レベルでやるとなると個人や組織の努力で行うのは厳しいと思うので、Rescue Timeがめちゃパワーアップするとかのシステムが必要そうです。
（補足：noteはCEOやCXOをはじめ、CTO、CFO、その他経営レイヤーにも気軽にメンションを飛ばしたり、口頭相談して良い社風です！みんなバンバン相談してます。どういうエスカレーションルールにするかはする側のクオリティと受け手のキャパシティに大きく依存するところだと思います。）
Rescue Timeの活用について
Rescue Time をチームで使用して、各メンバーの作業時間を管理する事も可能だと思いますが、個人的にはこの使い方は弊害が出そうだなと思います。
集計の仕方としてアクティブなウィンドウの滞在時間を集計しているだけなので、いくらでも細工出来てしまうからです。
あくまでも自己管理の一環として、自分が何に時間をかけているかを把握するために個人やチームで使用するのは有効だと思いました。逆に考えると個人を特定しない状態でチームの動向が見えるとかだと良さそうです。
・・・
Google Calendarと Slack を連携すると、予定が入っている時間にSlackのステータスに表示できるという機能があります。
これと似たような機能としてRescue Time でも特定の作業をしている時にSlackのステータスにアイコンを表示するという機能がありました。
リモートワーク中は相手がどのような状況であるか不明な事が多いので、チームによってはうまく活用できる場面もありそうです。
その他にも、Focus Time という特定サイトにはアクセス出来ないようにしたりで集中した時間を作りやすくする機能もあるようです。（調べたらteamsにも似たような機能があるみたいです）
ここら辺は探せば良さげなSlackアプリもあるかもですね。
まとめ
- 本当に必要な情報を見極める
- 生産的な作業にマルチタスクは敵、一つの作業に集中するための工夫が必要
- 最新のベストプラクティス、テクノロジー情報は積極的に拾う
というのが生産性向上のためには大事なのかなぁと思いました。
息子のおもちゃ代になる予感です