リモートワークの非同期コミュニケーションのルールを決めた話

こんにちは！スマートキャンプでインサイドセールスに特化した SaaSである BALESCLOUDを作っているエンジニアの井上です。

昨今の状況下で、最近リモートで働きはじめた人は多いのではないでしょうか

弊社でもこの状況でリモートで働いており、slackでのコミュニケーションがほとんどになりました。

今回この記事では、そんなslackなどで行うテキストのコミュニケーションの改善についての取り組みについて一部ご紹介します!

非同期コミュニケーションとは？

非同期コミュニケーションは相手が即時に返答する必要がないコミュニケーションのことを指しており 冷蔵庫のメモのように、その場に相手がいなくてもコミュニケーションが完結するものです。

それに対して、同期コミュニケーションは対面での会話やZoom等での会議など、相手が同じ時間に居ることで成立するコミュニケーションのことです。

なぜ改善する必要があったのか？

同期のコミュニケーションはその特性上その場に相手が必要ですが、これは相手の時間を一定時間拘束することにもなります。

BALES CLOUDチームは小さいチームということもあり共通認識出来ている部分が多いので、一般的なサイズのチームよりも非同期のコミュニケーションで事足りるシーンが多く 不要な同期によるコミュニケーションにより開発時間が削れられることもありました。

小さいチームであるということは、１人あたりの開発時間が削られることに対するチームの開発量や速度への影響がとても大きいので この改善に取り組むことを決めました

開発チームの抱える課題

通常のコミュニケーションや共有が同期的に話すのがめいんだったため、コミュニケーションに時間が多く取られ 開発できる時間が削られてしまうという課題がありました。

目指した理想の状態

目指した状態としては、通常のコミュニケーションや共有をほぼ非同期に移していことで開発できる時間を増やすことです。

実際に行った施策

実際に非同期にするとコミュニケーションのパターンごとに伝える情報が足りないなどの問題が発生しました。 その問題に対してノウハウを蓄積していき、蓄積された内容が今回の記事になります。

改善の取り組み方

改善の取り組み方としては、毎週の振り返りの時間に、チームのノウハウやルールを蓄積していくような動きにしました。

これはチームとしての共通認識をもたせたいという意味と、チームで暗黙知になっている部分を明示化することにありました。 自分たちの当たり前を明示化することにより、どのような考えでコミュニケーションをとっているのかドキュメントにもなると考えたからです。

実際の改善内容を紹介

ここからは実際に取り入れた改善内容をご紹介します。

進捗を共有する

進捗系ではタスクの完了・未完了であったり、予定した進捗から変更された点の共有などがあります。 予定した進捗からの変更では、主に遅くなりそうな場合に共有します。 想定外に詰まったり、作業量が増えたりなどで進捗が遅くなる場合に共有することでチームでタスク進捗の共通認識をとります。

例)

• このタスク完了したので、次これやります！
• この開発でライブラリのアップデートをする必要があり、リリースは木曜くらいになりそうです。

相談をわかりやすくする

相談系では「悩んでるので相談したいです！」だとアクションとしてどのような相談になるのかが分かりにくいこともあるかと思います。 このような場合に非同期で完結したいのか、それとも同期でやりたいのかをはっきりさせる必要がありました。 私たちは非同期を基本としたうえで、同期でやりたいときにだけ相談の手段を明示しています。

例)

• 同期
  • この実装のロジックがどうすれば簡潔になるか悩んでるのでペアプロお願いできますか?
  • この設計悩んでいるので15:00から30分くらいZoomで相談できますか？
• 非同期
  • 調査内容を記事にまとめましたので、FBなどあったら記事にコメントお願いします！
  • このUIをAとBパターンでどちらが理解しやすいか悩んでいるので、このスレッドで意見ほしいです！

調査内容を記事化して共有する

調査内容を共有するとき、Zoomを使った口頭での共有では説明がしづらく感じることが多くがありました。 これをドキュメントサービス（弊社ではkibela）にまとめることにより、内容が理解しやすくなり、もう一回聞き直すなど口頭で起きていたコミュニケーションのコストも減ったかと思います。

また、わからない場合はslackのスレッド・記事へのコメントで話すことで疑問に思った内容も残せます。 一方で、本当に難しい内容の場合もあるので、その際にはZoomでの会議を設定し口頭や画面共有でのコミュニケーションも取り入れます

コードレビューをいつしてほしいかを伝える

コードレビューを依頼される側は、依頼された瞬間にレビュータスクが積まれた状態になります。

しかし、障害対応や急ぎでリリースしたいもの以外のほとんどのコードレビューは、今すぐに取り掛からなくても良いものでした。

また、レビューの際に重点的にレビューしてほしい箇所があったり、実装の背景を説明しておいたほうがいい時もあります

そのため、レビューを依頼する時に適用する下記のルールを追加しました。 - レビューの期限・タイミングを明記する - PRの内容を理解してもらうために口頭で説明する必要があるかどうかを明記する

例)

• こちらのレビューはnot 急ぎでお願いします！
• 急ぎでリリースしたいバグ修正のため、レビュー今お願いできますか？
• こちらのレビューの前に5分くらい実装の共有させてください、レビュー自体はnot急ぎです。

同期のコミュニケーションはいつ使う？

同期のコミュニケーションは難しい課題の議論やアイディア出しなどのブレストなどで使用します。

難しい課題やブレストの場合、テキストのみですと議論の開始から完了までやり取りが多くなり時間がかかります。 このような場合は同期でコミュニケーションを取ったほうがやり取りがその場で行えるので、効率が良かったです。

まとめ

いかがでしたでしょうか？

今回はチームの非同期コミュニケーションの改善事例を紹介しました。

この中の1つでもリモートワークのコミュニケーションの参考になれば幸いです。