Slackで仕事をしているのに、なぜ仕事をいつも取りこぼすのか

こんな経験、ありませんか。

「先週、これ決めたはずだよね……?」

会話は終わり、みんな頷いて、ウィンドウは閉じた。一週間後、誰かが「これ誰がやるんでしたっけ?」と聞く。検索欄にキーワードを入れる。結果47件。決定が書かれたメッセージは、そのどこかに埋もれている。

これはチームが怠慢だからではありません。道具がこの仕事のために作られていないからです。

チャットツールは「会話」のために作られた

Slack、Discord、WhatsApp。毎日使っているこの3つ、出発点は違いますが、共通点があります。すべて「会話の流れ」のために設計されているということ。

• Slack. 社内のチャンネル型メッセージング。
• Discord. ゲームコミュニティの音声とテキスト。
• WhatsApp. 個人の1対1メッセンジャー。

中核のメタファーは同じです。「メッセージは流れる」。新しいメッセージが古いメッセージを画面外に押し出し、チャンネルは無限スクロール、検索はタイムスタンプ基準。

流れるものが「会話」であれば問題ありません。問題は、その上に「仕事」を乗せた瞬間に起きます。仕事は流れません。仕事は固定されなければならない。誰が、何を、いつまでに。この情報は流れの上を漂ってはいけないものです。

Slack. チャンネルが100を超えると、通知はノイズになる

デザインエージェンシーを6年やりました。Slackは私たちの神経系でした。チームが15人を超え、プロジェクトが20件を超えたあたりから、Slackは神経系ではなくノイズ発生装置になりました。

いつも同じパターンです。

• チャンネルが記憶よりも速く増える。
• @channelが乱発され、本当に重要な通知が偽の通知に埋もれる。
• スレッドが増え、どのスレッドに決定があるのか分からない。スレッド自体が見つからない。
• 「AI要約」? 「誰が、何を、いつまでに」の精度は30%台。

一番もどかしい瞬間はこれです。

クライアントとの通話が終わり、Slackで「今日決まったこと整理しよう」となる。1時間後、4人の記憶が食い違う。同じ通話に出ていたのに。何も固定されていなかったのです。

Slackのせいではありません。Slackはメッセージの流れの問題を見事に解決するためのツールです。決定を固定する仕事はSlackの仕事ではないし、そう振る舞わせようとしてもうまくいきません。

Discord. ゲーミングのDNAは仕事に追いつかない

小さなスタートアップやクリエイターチームがDiscordで仕事をしているのをよく見かけます。軽い、音声がいい、無料。仕事道具として使い始めると、すぐに限界が来ます。

• 権限モデル。 サーバー → ロール → チャンネル。一つのギルドなら自然ですが、複数のクライアント、社員、業務委託、外部監査がいる事務所には不自然です。
• 検索。 メッセージのインデックスが弱い。1か月前の会話を探す? 健闘を祈ります。
• ビデオ通話。 自動録画も自動要約もなし。ミーティングが終わると、そこで話されたことは蒸発します。
• コンプライアンス。 エンタープライズSSO、監査ログ、データ保持ポリシー。標準機能ではありません。外部監査の義務がある会社なら、最初から無理です。

Discordは悪い道具ではありません。ただDNAが「一緒に遊ぶ場所」であって「一緒に働く場所」ではないのです。

WhatsApp. 個人の携帯に仕事が乗るとき

WhatsAppで仕事をする会社も少なくありません。特に東南アジア、中南米、中東。WhatsAppが事実上ビジネス標準の市場ではなおさらです。日本ではLINEのグループチャットで仕事をしているチームも多いでしょう。同じパターンです。

ここで生じる問題は少し微妙です。

• 会社のデータが社員個人の携帯に残る。 退職時にデータ回収は不可能。
• 検索とアーカイブが事実上ない。 1年前のメッセージ? 携帯のバックアップを復元して探してください。
• グループが50人を超えるとカオス。 通知を切れば見逃すし、つければ眠れない。
• ビジネス版も結局「1対1の顧客対応」が限界。 社内の協業ツールではありません。

最大の隠れたリスクは法的責任の曖昧さです。社員がWhatsAppでクライアントと合意した内容は、会社の公式記録なのか? 会社はそのメッセージにアクセスする権限を持つのか? 会社はそのデータをどこまで保管すべきか? 会社も社員も守られません。

WhatsAppのせいでもありません。WhatsAppは個人メッセンジャーとして優れた作りです。その上に会社の仕事が乗った瞬間、道具の設計と仕事の要求が噛み合わなくなるだけです。

共通の診断. 会話は成立するが、実行が漏れる

3つの道具はすべて、同じ失敗のパターンに収束します。

メッセージを流すには最適。決定を固定し、実行を追跡するには不向き。

Harvard Business Reviewの調査では、リーダーの71%が「ミーティングは非効率」と答えています。McKinseyは、ナレッジワーカーが業務時間の28%を情報検索とメッセージ整理に使っていると分析しています。これに、専門職チームでの私たち自身の観察を重ねると、会議で合意された内容の40%は、実際の作業に反映されないことがわかります。

この40%はどこへ行くのでしょう。漂います。Slackのスレッドのどこかへ。Discordのチャンネルのスクロールのどこかへ。LINEグループの通知の山のどこかへ。明示的なチケットも、明示的な担当者も、明示的な期限もないからです。

これはチームに規律がないからではありません。道具が助けてくれないからです。

私たちに必要なもの

会話の終わりが実行の始まりになるように設計された道具です。

ミーティングが終わる瞬間に「誰が / 何を / いつまでに」がすでにボードのチケットになっている。そのチケットが会話の一部であり続け、別の場所に手作業でコピーする必要がない。

「チャットツール + 別のプロジェクト管理 + 別のノートアプリ + 別の議事録要約ツール」を4タブで往復するのではなく、ひとつの流れに束ねられた道具。

これがSlack、Discord、WhatsAppが答えではない理由であり、新しいカテゴリーが必要な理由です。

だから私たちは

私たちはこの問題を解こうと Markhub を作っています。会話が終わる瞬間に実行が始まるメッセンジャー。Slack、Discord、WhatsAppがチャットのための道具なら、Markhubは実行のために設計されたメッセンジャーです。

チームの仕事のための道具を選んでいるのなら、私たちが何を違うふうにやっているか、一度見てください。

出典: Harvard Business Review ミーティング有効性調査、McKinsey「social economy」レポート(ナレッジワーカー生産性)。現場パターンは6年間50件以上の専門職プロジェクト観察に基づく。