SlackとEmail：この議論が見落としている本当の問題

午後4時。木曜日。営業担当者が同僚の最新のLinkedIn投稿—またしても「Slack対メール」の比較記事—を読んでいる途中で、最重要クライアントの名前が受信トレイにポップアップ表示される。そのメールは緊急で、返信する前にチームメイト二人の意見を聞く必要があるタイプのものだ。彼女のチームはSlackで仕事をしている。彼女が読んでいた記事は「内部はSlack、外部はメール”」を推奨している。しかし、今この会話に巻き込む必要がある人々が外部のステークホルダーではなく同僚である場合、そのモットーはどれほど実用的だろうか’？

これは、すべてのSlack対メールの記事が提起しながら、決して埋められない問題だ。そのアドバイスは、あなたがチャネルを選べることを前提としている。しかし、クライアント対応をするほとんどのプロフェッショナルにとって、それは絶対にできない。

Slack対メールの議論は、あなたが持っていないコントロールを前提としている

内部対外部について誰もが繰り返すこの経験則は、Slackとメールをいつ使うかという選択を、あなた自身が下せる選択として枠組み化している。タスクごとに適切なチームコミュニケーションツールを選び、ワークフローを最適化し、どのプラットフォームが何を扱うかをチームに教育するというものだ。これは、コミュニケーションを取る相手全員が自社内にいる場合にはうまく機能する。

しかし、あなたが営業、サポート、コンサルティングを行ったり、外部との関係を管理したりしている場合、コミュニケーションチャネルはあなたに押し付けられるものだ。見込み客に「Slackで連絡して」とは言えない。そして、Slack組織に外部メンバーを追加することは可能だが、多くのクライアントは外部アカウントや別のアプリの手間を望まない’。彼らは自分たちの好みに従ってベンダーと仕事をしたいのだ。だから仕事は受信トレイに届く。なぜならそこがクライアントが送る場所だからであり、どんな社内ポリシーもそれを変えることはできない。

つまり、多くの組織が直面する本当の問題は、どちらのツールが優れているかではない’。それは’、人間関係によって使用が決定されるチャネルを通じて届く仕事をどう管理するかということだ。すべてを断片化させずに、どうやってチームに情報を共有し続けるか？

実際にこの問題と向き合っているのは誰か

Slack対メールのメリット・デメリット議論の真ん中に立たされている人々は、LinkedInの記事で語られるきれいな仮定の話ではなく、日々それを実感している。それは次のような人たちだ：

営業担当者。パイプラインはメールにあり、チームのコラボレーションはSlackで行われる。
カスタマーサポート。チケットは共有受信トレイに届き、調整はSlackチャネルで行われる。
コンサルタントと代理店。クライアントは成果物や質問をメールで送り、社内コミュニケーションはSlackスレッドを行き来する。
アカウントマネージャーとパートナーシップリード。外部のステークホルダーはメールを書き、社内の調整はまったく別の場所で行われる。

あなたの役割が、チームの好むコミュニケーションツールを使わない外部の人々と関わるものであれば、あなたはすでにそのコストを知っている。あなたは二つのチャネルを同時に監視し、それらの間を翻訳し、何も漏れないことを祈っている。

コンテキストが分断されると実際に何が起こるか

これが、どの比較記事も説明しない失敗パターンだ。クライアントが質問をメールで送ってくる。回答する前に意見を聞く必要があるので、次の三つのうちのいずれかを行うことになる：

メールを三人のチームメイトにそれぞれ個別に転送する。 すると、同じクライアントの要求について四つの返信チェーンが発生する。
スクリーンショットをSlackに貼り付ける。スレッドはヘッダー、添付ファイル、返信履歴を失う。後から参加した人は、本当のコンテキストを持っていない。
メールの内容をSlackチャネルで要約する。あなたの要約はニュアンスを覆い隠し、最終的な返信はクライアントには見えない議論を参照することになる。

その後、すべての分散型チームが耳にしたことのある質問が出る：「誰かこれに返信した？」チームの半分はメールをチェックした。半分はSlackをチェックした。誰が何を見たか、何が聞かれたか、誰も確信が持てない。二日が経過し、クライアントから催促が来る。

これはツールの問題ではない。これはコンテキストの問題だ。仕事についての議論が仕事自体から切り離されており、その両者を縫い合わせ直すために費やされる一分一秒が、クライアントを待たせている時間だ。

なぜ比較記事はこの点を見落とすのか

ほとんどのSlack対メールガイドは、この問題を純粋な最適化の問題として扱う。機能を並べ、メリットとデメリットをリストアップし、「両方のツールをうまく使う」ことを推奨する。そのアドバイスは、あなたと同僚が何を使うかを決められる閉じたシステムを暗黙のうちに前提としている。

外部対応の仕事では、閉じたシステムは存在しない。クライアントがチャネルを選ぶ。あなたのチームはSlackを選ぶ。その両者の架け橋になる負担は、毎回、手動であなたにのしかかる。 なぜメールではなくSlackを使うのか と問うことは、メールがすでに受信トレイで返信を待っている時には役に立たない。

標準的なアドバイス—「もっと短いメールを送れ」「議論はSlackに移せ」「コミュニケーションのルールを設定せよ」—では、これは解決しない。どれもまだ、プラットフォーム間でコンテンツをコピーし、何か重要なものが移動中に失われないことを祈ることになる。仕事が実際に行われている場所でチームと一緒に作業するほうがよい’。

問うべきもっと良い質問

Slackとメールの間に誤った選択を作り出すのではなく、こうした状況に直面しているプロフェッショナルは、次のように問うことで自分自身により良く役立てることができる：

なくなることのないメール—これはなくならない—に対して応答性を保ちながら、仕事が実際に行われている場所でチームとコラボレーションするにはどうすればよいか？

この再構成は、探すものを変える。 Slack対メールをいつ使うかを議論するのではなく、別のアプリでメールの周りを回るのではなく、チームの議論をメール自体に紐付けたままにできるSlackとメールの統合を探し始めることになる。

いくつかの実用的な原則が役立つ：

メールをクライアント対応のチャネルとして受け入れる。それは選択肢ではない。それと戦うのは、より速く返信するために使えるエネルギーの無駄遣いだ。
チームの議論をメールのコンテキスト内に保つ。チームメイトがクライアントのメールに直接コメントできるとき—@メンション、クライアントには見えないプライベートメモ、会話の共有ビューを使って—ツール間で翻訳する必要がなくなる。 Sparkの’共有スレッドがそれを可能にし、同僚とのやり取りを内部用に保ちながら、クライアントのメッセージの隣にコンテキストを保ったまま表示できる。
チームと明確な期待値を設定する。クライアントとのコミュニケーションはメールスレッドの中に留める。そのコミュニケーションに関する内部の質問は、並行するSlackチャネルではなく、同じスレッドの中で行う。 Spark for Teamsのようなツールは、これをうまく管理するのに役立つ。
クライアントを自分のスタックに引きずり込まない。見込み客が別のアプリをインストールしたくないなら、その会話はそこで終わる。相手のいる場所で対応しよう。

ポイントは勝者を選ぶことではない

Slack対メールの議論は、あなたが選べる場合にのみ意味を持つ。クライアント、見込み客、または外部パートナーと取引するほとんどのプロフェッショナルには、その選択肢はなかった。受信トレイは彼らにとってなくなることはなく、どんな生産性記事もその存在を議論で消し去ることはできない。

本当の仕事は、避けられないチャネルをより扱いやすくすること—チームのコラボレーションをメッセージの近くに保ち、別のアプリに散らばらないようにすることだ。そのつながりが保たれていれば、クライアントがどんなツールを選んでも安心していられる。適切なメールアプリは、コンテキストをそのまま保ち、チームを足並みそろえ、クライアントを満足させる。それは’、複数のメール返信チェーンとSlackスレッドではとても実現できないほど、はるかにすっきりしている。