以前は電話とFAX、そこにメールが加わり、そして今、チャットを中心としたコミュニケーションが活発化してきています。ミーティングだけに限定すれば、対面やビデオ通話が中心ですが、日常的なコミュニケーションに何かしらのコミュニケーションツールを導入しているところも多いのではないでしょうか。SlackやChatWork、TeamsやLINEWORKSなどのチャットツールに、GitHubやGitlab、BitbucketのようなGitツール、BacklogやZOHO、Basecampのようなプロジェクト管理ツールなど、国内外問わなければ、本当に多種多様なコミュニケーションツールが存在しています。

このいずれかを使っている方の中でも、最初は良かったものの、結局情報の確認漏れや、管理コストの増大など、また違う問題を抱えている会社も多いのではないでしょうか。運用規模が大きくなると新しい問題が発生したりもするため、当初の想定と違った、というケースもあると思います。

結局は使うツールだけが変わって、根本的な社内コミュニケーションの改善は果たせていないというケースもよくある話です。このような状況下で、社内のコミュニケーションをどう最適化すべきか、そのツールの選び方、組み合わせ方と理想型について考えてみましょう。

Point.1 フロー型とストック型を理解する

コミュニケーションツールを一本化、というのは非常に聞こえが良いですが、実際には不可能です。もちろん、一本化自体は可能ですが、結局はそのツールの限界によって社内の効率性は下がり始めます。その原因は、コミュニケーションツールにはフロー型とストック型があるということに尽きます。

フロー型というのはチャットツールに代表されるような、時間軸にそって流れていくコミュニケーションに適したツールです。ChatWorkはタスク機能によって単純なフロー型ではありませんが、スレッド機能を持つ、持たないにかかわらず、放っておくと情報の確認漏れが頻発し、複数のプロジェクトに関われば関わるほどカオスになるというのがフロー型の宿命です。情報を追っていくだけで1日が終わるというのも珍しくありません。Slackでも基本的には同様です。Microsoft Teamsでもそうですし、これは不具合というよりは性質と呼ぶほうが適切でしょう。

一方でプロジェクト管理ツールやGitツールのように、「何をするか」を軸にコミュニケーションが発生し、その課題が解決するとそのコミュニケーションの塊が終了する・削除されるのがストック型です。課題ベースのため整理しやすいですが、基本的には受け身では情報が獲得しにくいため、一部の熱心な人だけが利用するツールになりがちなのがストック型の宿命です。通知機能をうまく駆使したり、メンション機能でうまく知らせるようにしないと、能動的なアクションが生まれにくいデメリットがあります。

基本的には、フロー型だけでも、ストック型だけでもうまくいきません。ルーティンワークばかりの業務であればフロー型だけでの運用をお勧めしますが、日々、何かしらの企画をし、それのPDCAを回していく組織であれば、フロー型とストック型の併用をお勧めします。

Point.2 フロー型とストック型を断絶させない

フロー型のコミュニケーションツールと、ストック型のコミュニケーションツールを導入したからといって終わりではありません。両者は独立したツールであるため、放っておくと、「情報を両方に取りに行かないといけない」という状況が発生します。ツールばかり増えてもう嫌、という声が社内からあがり始めるのも仕方ありません。

これを避けるために、フロー型とストック型のコミュニケーションツールをつなぎましょう。Slackを中心にGitHub等と連携するなどが有名ですが、インテグレーション（統合）という概念で、ストック型の更新内容をフロー型のコミュニケーションツールに通知するようにしましょう。有償のものも含めれば、さまざまなインテグレーションツール・サービスが登場してきており、組み合わせるだけでかなり高度なことまで実現できます。Slackを使用していないのであればZapierのような連携に特化したサービスもあるので使えないか検討してみてください。

こうして情報をフロー型に集約することで、常に確認するのはフロー型のみ。必要に応じてストック型からの通知がくるので、その時にリンクをクリックして該当のトピックを確認して、必要であればコメントや作業を行う、という一連のフローが完成します。重要なイベントは自動的にコミュニケーションツール間をまたいで情報が行き交うようにすれば、関係者の負担を高めずに注意をひくことができます。

この統合の考え方は、複数のツールをまとめあげることもできます。SlackやChatWorkを中心におきつつ、その周囲にGitツールやタスク管理ツール、スケジュール管理ツールを配置して、それぞれが中心にあるチャットツールに通知を送ってくるというかたちができあがります。WebhookやAPI連携等、様々な言葉で呼ばれますが、お使いのツールがこうした連携に対応しているか確認してみてください。

Point.3 エコシステムを重視する

一昔前までは、サービス間の連携が行われることは無かったため、サービスを選定する際はそのサービス自体の機能やその会社の信頼性が非常に重要な指標になっていました。現在もそうした指標は重要ですが、それ以上に重要なのがエコシステムです。

検討しているサービスがアドオンやプラグインというかたちで他の機能とどう連携するのか、連携した結果、どういった効果があるのかを重視してください。先の例で言うと、Slackはチャットツールの機能がメインですが、その広範囲のインテグレーション機能により巨大なエコシステムを構築しています。それがSlackが急速に成長した理由でもあるのですが、こうした連携に消極的なサービスも残念ながら多くあります。単体でツールを使う時代では無くなりました。このことを意識した上で、総合的な判断力が求められていると言えます。

また、サービスの安定性や、外部との連携の可能性も検討してください。頻繁に連絡をとるクライアントがどういったツールを使っているかも影響します。同じコミュニケーションツールであれば組織をまたいだコミュニケーションチャンネルの作成も容易なため、業界内や取引先内でのデファクトスタンダードのツールを選定するという視点もありでしょう。

社内が活性化するコミュニケーションデザインを

リモートワークも含め、社内のコミュニケーションが多様化してきています。チャットツールにしろ何にしろ、重要なのは社内が活性化することです。もし、部署毎に使っているツールが違うのであれば、そこにチャンスがあります。もし、社内で使っているツール同士の連携が不十分なのであればそこにチャンスがあります。そもそものツールの利用率が低いのであればそこにチャンスがあります。

社内コミュニケーションの問題はツールの導入だけで解決する話ではもちろんありませんが、ツールの導入をうまく組み合わせることできれいにデザインできる可能性はあります。ツールの切り替え等、大変な部分はありますが、その価値があるほど重要なのがコミュニケーションでもあります。もし、社内コミュニケーションに不安や不満を抱えているのであればお気軽にご相談ください。