結論：Slackはコミュニケーションのために使い、タスクは別の場所で記録することで、依頼が流れる問題と「誰が何をやっているか見えない」問題の両方が解消できる。

マーケティングディレクターの高橋さんは、月に4〜5本のコンテンツを外注ライターやデザイナーと並行して動かしている。依頼はSlackのDMかチャンネルに送る。「先日お伝えした件、今週中にお願いできますか?」というメッセージを送って、既読になったのを確認して、次の仕事に移る。

ところが金曜の夕方になると、何かが足りない感覚が来る。あの記事の初稿はどうなったか。デザイナーの藤岡さんに頼んだバナーは確認できているはずだが、修正指示を出したスレッドがどこだったかを探すのに時間がかかる。Slackのチャンネルを遡り、スレッドを開き、「あ、ここで止まっていたか」と気づく。依頼した側が見つけられないのだから、受けた側が混乱するのは当然だ。

Slackは速い。その速さが武器でもあり、盲点でもある。メッセージは流れる。スレッドは別の話題に埋もれる。タスクはその勢いとともに、視界の外に消えていく。

Slackスレッドにタスクを書くと何が起きるか

Slackのスレッドはチャットのために設計されている。会話を続けるために生まれた構造であって、タスクの状態を記録するためのものではない。それでも多くのチームがSlackの中でタスクを完結させようとする。理由は単純で、「みんなSlackを開いているから」だ。

問題は積み重なるうちに見えてくる。

あるスレッドに「お願いします」と書いたとき、それは依頼なのか確認依頼なのか、期日はいつなのか、誰が承認するのかが、スレッドのコンテキストの中にしか存在しない。3日後にそのスレッドを見返したとき、前後の会話を読み直さないと状況がわからない。担当者が変わったり、案件がひとつ増えたりすると、スレッドの外から全体を俯瞰する方法がなくなる。

ライターの中村さんが月3本の記事を書くケースを考えてほしい。依頼は3つのスレッドに分散し、修正指示は別のメッセージ、納品確認はまた別のスレッドにある。高橋さんが「3本とも今月どこまで進んでいる?」と確認したいとき、その答えをSlackの中から拾い集めるのにどれだけの時間がかかるか。

催促の非対称性という問題

Slackのタスク管理が壊れていくもうひとつの理由は、送る側と受ける側の認識のズレにある。

高橋さんが「お願いします」と送った瞬間、彼女の頭の中にはその案件の締め切りと期待値がある。しかし受け取った藤岡さんの画面には、ほかにも複数のプロジェクトの通知が流れている。「確認しました」という返信をしたとしても、そこからが作業の始まりで、進捗はSlackには現れない。

高橋さんが3日後に「どうなっていますか?」とメッセージを送るとき、彼女は催促しているつもりはない。ただ状況を知りたいだけだ。しかし受け取る藤岡さんには、「追われている」という圧力として届くことがある。この非対称性は、ツールの設計から来ている。Slackは今この瞬間の会話に最適化されていて、「3日前に依頼したタスクの今日の状態」を可視化する機能を持っていない。

その結果、確認するためのメッセージが飛び交い、それ自体がノイズになる。確認メッセージが増え続ける構造的な問題は、Slack固有のものではなく、チャットでタスクを管理しようとするすべてのツールに共通している。確認のためのSlackを処理するために、本来の仕事の時間が削られていく。

外注先がSlackに入っていない問題

外部のフリーランサーやベンダーを使うチームには、もうひとつの壁がある。相手がSlackのワークスペースにいない場合、そもそも共有の場所がない。

デザイン事務所に制作を依頼しているが、先方はSlackを使っていない。メールでやり取りしながら、社内チャンネルには「デザイン事務所さんからラフが来たので確認してください」と投稿する。社内の返答はSlack内に積み上がり、外部への連絡はメールで別途進む。どこかで情報が分断される。

クライアントにプロジェクトの進捗を共有する場面でも同じことが起きる。SlackのゲストアカウントはEnterpriseプランでないと制限があり、外部の人を自由に招待できる構造になっていない。外部の人が増えるたびに、共有の方法を個別に考えなければならない。

こういった構造的な問題に直面したチームが取る解決策のひとつが、タスクをSlackから切り離すことだ。

「Slackは残す、タスクは別で持つ」設計

Slackで会話は続ける。通知も来る。やり取りの速度は変えない。ただし、タスクとその状態は別の場所に置く。

この設計のポイントは、Slackを捨てることではなく、Slackが得意でないことを別のツールに任せることだ。Slackは今この瞬間のコミュニケーションに強い。タスクの記録・担当者の割り当て・ステータスの追跡・期日の管理は、その設計の外にある。NotionやChatworkなど他のツールにも同様の限界があり、Notionをタスク管理に使い続けると生じる問題も根は同じ構造にある。

PaqutはSlackと役割を補い合う設計で作られている。タスクを登録し、担当者を決め、期日を設定する。外部のフリーランサーやクライアントを無料で招待できるので、Slackのワークスペースに入っていない相手とも同じタスクボードを共有できる。そして、タスクの更新や完了はSlackに通知できる。Slackを開いたまま、タスクの状態が流れてくる。

高橋さんの場合、ライターの中村さんへの依頼をPaqutに登録することで、「3本の記事が今どの状態か」がボードを開けば一目でわかる。催促のメッセージを送る必要がなくなる。中村さんは自分のペースで作業し、ステータスを更新すれば、それがSlackの通知として高橋さんに届く。

業務フローの比較

Slack単独で動いているチームと、Slack+Paqutで動いているチームの実際の流れを並べてみる。

場面Slack単独Slack + Paqut
依頼の発生チャンネルかDMにメッセージを送るチャットで相談しつつ、タスクをPaqutに登録する
担当者の確認スレッドを遡って確認タスクに担当者が紐づいているので即確認
進捗の把握「どうなっていますか?」と送るボードを開けばステータスで把握できる
外部メンバーの参加ゲスト招待の制限や設定が必要人数無制限で無料招待できる
期日の見落とし通知がほかのメッセージに埋もれる期日ごとのリストで一覧できる
完了の確認「完了しました」メッセージを探すステータス変更がSlackに通知される
振り返りスレッドを手動で遡るタスクのコメント履歴として残る

この比較が示しているのは、どちらが優れているかではなく、それぞれが何を得意としているかだ。Slackは速い。その速さを活かしながら、タスクの構造はPaqutが持つ。両者が補い合うことで、どちらかひとつに無理をさせなくて済む。

タスクが「見通せる」ことが働く人を楽にする

藤岡さんのような外注デザイナーは、複数のクライアントと並行して仕事をしている。それぞれのクライアントから異なるチャンネルや方法で依頼が来て、自分でスプレッドシートや手帳に書き写して管理している人も多い。

タスクが整理されている環境に招待されると、それだけで仕事のしやすさが変わる。期日が明確で、修正指示がタスクのコメントとして残っていて、何が完了していて何が残っているかが一目でわかる。「確認のための連絡」に使う時間が減り、その分を実際の作業に使える。Chatworkでタスク機能を使いこなしているチームが設計していることも、この「見通せる構造」を意図的に作る点では共通している。

これは道具の話ではなく、働く環境の話だ。デザイナーがデザインに集中できる時間を作れるかどうかは、依頼する側のチームの設計にかかっている。Slackだけで全部をやろうとするとき、その負荷の一部は必ず、働く人の認知コストとして積み上がっている。

スレッドの外に置く勇気

「今までSlackだけでやってきたから」「チームの人数が少ないから大丈夫」という声をよく聞く。少人数のうちは確かに回る。問題が見えにくいだけで、コストは静かに積み上がっている。

外注メンバーが増えたとき、案件が並走するようになったとき、クライアントへの報告頻度が上がったとき、Slackだけの設計は一気に限界を迎える。そのタイミングで慌ててツールを入れようとすると、移行コストと混乱が重なる。

今の規模で仕組みを整えることは、将来の自分たちへの投資だ。スレッドの外にタスクを置くと決めたとき、チームは初めて「追いかけなくても回る」状態に近づく。それは担当者が楽になるということであり、外注メンバーが力を発揮しやすくなるということでもある。

壁を越えて働く人たちが、それぞれの仕事に集中できる構造。チャットとタスクの分離は、その第一歩になる。

Slack と Paqut の連携設定（/paqut コマンド・通知の種類・OAuth 手順）については、Slack × Paqut 連携ページでまとめています。