はじめに
この記事は #Backlog アドベントカレンダー2022 by #JBUG の12/18分の記事として執筆しています。
コミュニケーションコストとは?
現在勤めている会社は渋谷にオフィスがあり、この記事を書いている直近ではだいたい50%くらいの社員がリモートワークをしています。僕もそのうちのひとりで、オフィスに出社するのは1週間から2週間に1回くらい。その他は主に自宅で仕事をしています。コアタイム制ですが、多くの社員の勤務開始時間は割と遅めな感じな一方で、朝早めの時間から勤務を開始しているメンバーもいます。
そういう環境の中で、ほとんどオフィスに出社しているメンバーの人からちょくちょく「リモートワークだとコミュニケーションコストがかかるから」という言葉を耳にすることがあります。具体的な例としては、オフィスに出社していればちょっとした相談事でもその人の席まで行って話をすればすぐに解決できることが、リモートワークだとタイムラグややり取りに関する時間的なコストが発生して、解決に至るまでのスピードが遅くなる、といったところが代表的でしょうか。そこにコストがかかることに課題を感じているようです。
いや、仰っていることはよくわかるんですよ。確かにオフィスの中をとことこ歩いていって相談相手と対面で話すことの方が、時間的なロスは少ないし、相手の表情を見ながら話すことができるので、解決までの道のりは、もしかしたら早いかもしれません。
だがしかし待てよ、「コニュニケーションコスト」って果たしてそういうものなのかしら? というところに個人的には疑問を感じてしまいます。
コミュニケーションにかける手間暇についての僕の思うところ
上記に関する「コミュニケーションコスト」というのを時間的な価値だけにフォーカスするのであれば、確かにそれはスピード感を持って意思決定をする上ではみんなが同じ場にいて同期的に話を進めていけばいいかもしれません。その方が手間暇は全然かかりませんし。
ただ、「コミュニケーションコスト」は、逆に手間暇というか、ちょっとした工夫を使いながらかけるべきでもあると僕は思うのです。
ここでは例としてBacklogとSlackを挙げてみましょう。
Backlogを通じたコミュニケーションに対してかける手間暇
この記事を読んでいる皆さんの中には何かしらのチケット管理ツールを使用してプロジェクトを進めている方が比較的多いのではないかと思います。僕の会社でもBacklogを使ってプロジェクト管理を行なっています。なんですけれども、Backlogの機能を十分に使いこなせていないなと思ってしまう事例が少なくないのです。ひとつひとつの起票された課題(親課題や子課題を含めて)に対して、それがなんのために起票されているのかという意味合いを持たせていないケースが散見されるのです。結果としてどういうことが起こるかというと、後から見返したときに「このBacklogの課題って何のために起票されたんだっけ?」という「コミュニケーションコスト」が発生してしまうわけです。これはあまり建設的なコストではないですよね。
もちろん、Backlogにはこれが鉄板というルールブック的なものはないわけですけれども、起票された課題に対して意味合いを持たせ、その課題が結果としてとのような状態になったかを育てていった方が、ツールを使っていく上での価値がダントツに上がるわけです。少なくとも、課題の本文やコメントに、
- なぜこの課題を起票したのか (= 課題が示している目的を明確にする)
- どういう状況になっていればその課題はクローズできるのか (= 課題の完了条件を明確にする)
- 課題のステータスを変える時には、その理由 (= 完了に向けて具体的にどのようなアクションをとっているのかを明確にする)
これらが書かれていれば、課題に対する活動の履歴がはっきり残るため、「この課題って何だっけ?」状態は確実にクリアできると思っています。逆に言えば、「コニュニケーションコスト」を軽減するための材料を、少し手間暇をかけることで用意することができるわけです。これは明らかに建設的な手間暇であると考えることができると思うのです。
Slackを通じたコニュニケーションに対してかける手間暇
同じように、日常の仕事の中での課題の共有や調整などを、Slackのようなチャットツールでやり取りしている例も多いのかなと思います。
SlackはBacklogのようなストック型のツールではなく、フロー型のツールとも言えます。フロー型である以上は、短いスレッドで完結させる方が良いに越したことはないのですが、必ずしもその通りにならないことが往々にしてあるのは皆さんもよく経験されているのではないかと思います。その原因として考えられるのが、やはり書き込まれている最低限の情報が網羅されているか、なのかなと考えています。網羅すべき情報は、Backlogの場合とほぼ同じで、
- そのスレッドを通じて共有したいことや質問したいことは何か (= 目的を明確にする)
- 情報共有の場合、伝えたい相手に対して何を理解してもらいたいか (= 完了条件を明確にする)
- 質問の場合、結果としていつまでにどんな情報が欲しいのか (=完了条件を明確にする)
これらが書かれているだけでも、情報を伝えたい相手に対して余計な「コニュニケーションコスト」を発生させることなく、建設的に物事を進めたり、調整したりすることができるわけです。そのための手間暇としても建設的なのではないかなと思います。
時間的なコストを削減するためにも手間暇を少しかけよう
ここでは2つの例を書いてみましたが、「コミュニケーションコスト」というのは、単純に時間だけで評価できるものではなく、その人の持っている情報がどれだけ多くの人に対して正しく共有できるかというのも重要な評価軸なのではないかと思います。オフィスにいて、ちょっと誰かと相談すれば、2者間では情報の共有がすんなりいくかもしれませんが、そこで得られた情報を多くの人に共有できるかと言えば、実は共有できなかったりしますよね。その結果、「これって何だっけ?」「確かこういうことだった気がする」というようなやりとりに発展して逆に時間的なコストをかけてしまうことになることもあったりするわけで。
それを補完するのがプロジェクト管理ツールやコミュニケーションツールの役割であるわけで、そこに少しだけ手間暇をかけてあげることで、有益な情報共有の手段として育てていくことができるのだと思います。そして育てることによって、いつかプロジェクトや会社の事業にとっても大きな資産となり得ます。
非同期的なコミュニケーションが主流になっていく中で、まずはほんの少しだけでもいいので、手間暇をかけてみませんか? その一歩を踏み出すだけでも、案外「コミュニケーションコスト」の罠から抜け出すことができるかもしれませんよ。