プロジェクトのチャットは別のアプリにあるべきではない

タスクは一つのツールに。ファイルは別のツールに。会話はさらに別のツールに。それでも何とかチームは連携を保つことになっています。 これがほとんどの小規模チーム、フリーランサー、学生グループのデフォルトの状態です。TrelloやAsanaで作業を追跡し、Google DriveやDropboxでファイルを共有し、SlackやDiscordでコミュニケーションします。最低でも3つのツール、それぞれが独自の通知システム、独自の検索、そして独自の「真実のバージョン」を持っています。 結果として、プロジェクトのコンテキストがプラットフォーム間で断片化されます。Slackで決定が行われます。その決定を反映したタスクはプロジェクトボードにあります。タスクに関連するファイルはDriveにあります。全体像を把握するには、3つの異なる場所を確認しなければなりません。そしてSlackのメッセージが送られたときにオンラインでなければ、見逃してしまうこともあります。 これは単なる不便さではありません。誤解、重複した作業、抜け落ちた事項の本物の原因です。タスクを説明する会話が見つからないと、人々は推測するか、誰かに割り込んで尋ねます。どちらも効率的ではありません。

SlackとDiscordは優れたコミュニケーションツールです。しかし、プロジェクトレベルのコミュニケーションではなく、組織全体のコミュニケーションのために設計されています。その違いは重要です。 Slackでは、トピック、チーム、またはプロジェクトのためのチャンネルを作成します。時間が経つにつれてチャンネルが増えていきます。会話がチャンネル間で漂います。重要な決定がミーム、ランダムなリンク、関係のないスレッドの下に埋もれます。検索はそれなりですが、正しいキーワードと正しいチャンネルを覚えている場合に限ります。 Discordも同じ構造的な問題を抱えています。サーバーはチャンネルで溢れ、プロジェクト固有の会話がノイズの中で失われます。ゲームコミュニティや開発者グループにとってはそれで構いませんが、実際のプロジェクト作業の管理には、すぐに積み重なる摩擦をもたらします。 根本的な問題は、これらのツールがプロジェクトではなくチャンネルで会話を整理することです。プロジェクトにはタスク、ファイル、タイムライン、マイルストーンがあります。それらについての会話は、まったく異なる構造を持つ別のアプリではなく、それらと並んで存在すべきです。

IndieDevBoardにはすべてのプロジェクト内にチームチャットが含まれています。プロジェクトを開き、チャットをクリックすると、カンバンボード、タイムライン、ノートブック、ファイルと並んで会話がすぐそこにあります。 即時のメリットは、メッセージが関連する作業と繋がり続けることです。誰かがタスクについて質問するとき、タスクはワンクリックで確認できます。誰かが決定を共有するとき、それは関連するマイルストーンとメモが存在する同じワークスペース内にあります。コンテキストが別のアプリに蒸発してしまうことはありません。 これはオンボーディングの問題も解決します。新しいチームメンバーがプロジェクトに参加するとき、コンテキストの中でチャットの全履歴にアクセスできます。実際の作業と並んで、プロジェクトを形成した会話を見ることができます。Slackでは、複数のチャンネルを検索しても関連する議論の半分を見逃してしまうでしょう。 もう一つの過小評価されているメリットはプロジェクトのアーカイブです。プロジェクトが終了すると、チャットもそれと一緒に保存されます。誰もアーカイブしようとしないゾンビSlackチャンネルが残ることはありません。プロジェクトは完了し、会話は保存され、メインのコミュニケーションツールに何も散らかりません。

小規模チームはしばしば同期コミュニケーションをデフォルトにします。誰かが質問を持ち、Slackに投稿し、今すぐ答えを期待します。これは全員が同時にオンラインのときは機能しますが、タイムゾーンの違い、フレキシブルなスケジュール、深い集中時間が必要なメンバーがいるとすぐに崩れます。 毎日のスタンドアップと常時のSlack通知の不都合な真実は、それらが深い作業を中断するということです。すべての通知はコンテキストスイッチです。研究は一貫して、中断後に完全に集中力を取り戻すのに約23分かかることを示しています。チームが互いに1日6回通知を送ると、一人あたり2時間以上の生産的な時間が失われます。 非同期コミュニケーションは異なる動き方をします。更新や質問を投稿し、人々は準備ができたときに応答します。会話はまだそこにあります。何も失われません。しかし誰もリアルタイムで参加するために作業を中断する必要はありません。 小規模チームに最適なのは、デフォルトで非同期、必要に応じて同期というセットアップです。即座の回答を必要としない更新、質問、決定にはプロジェクトチャットを使いましょう。リアルタイムの議論が本当に必要なときに通話します。このバランスが、深い作業への集中能力を破壊せずに人々に情報を提供し続けます。 プロジェクトワークスペース内にチャットがあることで、これは自然にサポートされます。メッセージは永続的でプロジェクトに紐づいています。人々はプロジェクトを確認するときにチェックインします。コンテキストが保存されていつでも確認できるため、すぐに返信しなければならないプレッシャーはありません。

ツールが多すぎることには実際のコストがあります。ワークフローに追加されるアプリごとに、別のログイン、別の通知、別の確認すべきもの、別の情報が隠れている可能性のある場所が増えます。 「ツール疲れ」という言葉はよく使われますが、実際の問題を表しています。3人のチームがタスク、チャット、ファイル、ドキュメント、カレンダーに別々のツールを使うと、5つの異なるインターフェースを管理することになります。そのオーバーヘッドは、専任のITスタッフとオンボーディングプログラムを持つ大きな組織と比べて、小規模チームには比例的に重くのしかかります。 統合とは、すべてを完璧にこなす一つのツールを見つけることではありません。チームが確認しなければならない場所の数を減らすことです。タスク、チャット、ファイル、メモがすべて同じプロジェクトワークスペースに存在するなら、注目を奪い合うタブが4つ、通知セットが4つ少なくなります。 これは特に、すでに授業、クライアントの仕事、個人プロジェクトを掛け持ちしている学生チームやフリーランサーに当てはまります。彼らが最後に必要なのは、管理すべき別のアプリです。プロジェクト管理とともにチャットが含まれるワークスペースは、すでに混雑した一日のコンテキストスイッチを一つ減らします。

プロジェクトレベルのチャットは、すべてのチームコミュニケーションの代替ではありません。組織に数百人がいるなら、会社全体のコミュニケーションプラットフォームはまだ必要です。Slackはアナウンス、ソーシャルチャンネル、チーム横断の議論、リモートチームを人間らしく保つ気軽なやり取りに最適です。 主張はSlackが悪いということではありません。Slackはプロジェクト固有の、作業と繋がり続ける必要がある議論に適した場所ではないということです。会社にはSlackを使いましょう。プロジェクトにはプロジェクトチャットを使いましょう。 同様に、オープンソースコミュニティやゲームグループに参加しているなら、Discordは別の目的を果たします。それはコミュニティツールであり、プロジェクト管理ツールではありません。両方は共存できます。 目標は会話を相応しい場所に置くことです。会社全体のことは会社全体のツールへ。プロジェクト固有の会話はプロジェクトへ。二つを混在させなくなると、どちらもよりクリーンになります。

プロジェクト外に存在するプロジェクトに関するすべてのメッセージは、失われたコンテキストの一片です。後から検索で見つかることもあります。見つからないこともあります。いずれにせよ、誰かがそれを追跡するための時間とエネルギーを費やす必要があります。 最もシンプルな解決策は、作業がすでにある場所に会話を置くことです。チャットがタスク、タイムライン、ドキュメントと並んでプロジェクト内に存在すれば、何も失われません。情報がすぐそこにあるため、人々の連携が保たれます。 チームが小さければ小さいほど、これはより重要になります。全員に情報を提供し続けることを専任の仕事とするプロジェクトマネージャーはいません。あなたがプロジェクトマネージャーであり、開発者であり、デザイナーでもあります。調整のオーバーヘッドを減らすものはすべて、実際の作業のための時間を返してくれます。それがすべての目的です。