結論：所属が違うメンバー全員が同じタスクボードを見られる状態にするだけで、「確認のための会議」の大半はなくなる。

複数社が絡むプロジェクトには、独特の重さがある。自社の中だけで動くプロジェクトと比べて、意思決定に時間がかかる。メールの返信が遅い。誰が何を担当しているのかが、会議の場でしか全員に見えない。そのくせ会議の頻度だけは増えていく。

プロジェクトが重くなる本質的な理由は、「情報が組織の壁で止まっている」ことにある。自社の担当者はSlackで動いているが、パートナー会社への連絡はメールで、外注の制作会社へはチャットワークで、クライアントへは週次の定例会議で——という状況が普通に起きている。それぞれの場所で話が進んでいるが、全体像を持っている人間が一人もいない。あるいは、プロジェクトリーダーの頭の中にしか全体図がない。

これは情報ツールの問題ではなく、設計の問題だ。どのツールを使うかより前に、「誰が何をいつまでに」という情報を、関係者全員が同じ場所で見られる構造になっているかどうかが問われる。

複数社横断プロジェクトの典型的な構造

一般的なBtoB案件で複数社が関わる場合、登場する役割はおおよそ次のように分類できる。

役割典型的な立場情報へのアクセス要件
自社PMプロジェクト全体の調整・進行全体を把握する必要がある
パートナー制作会社デザイン・コンテンツ・技術など専門領域自分たちの担当領域と、隣接する工程の状況
外注スタッフライティング・コーディング・撮影など単工程自分のタスクと納品条件
クライアント担当者発注者・最終意思決定者進捗全体と、承認が必要な箇所

この4者が揃うと、情報の流れが複雑になる。自社PMは全員と連絡を取れるが、パートナー制作会社とクライアントは直接やり取りしていない場合も多い。外注スタッフはクライアントの意図を知らないまま作業していることもある。

問題はこの「知らないまま」が積み重なることだ。外注スタッフが納品したものをパートナー会社がチェックし、自社PMがクライアントに確認して差し戻す——という往復が発生すると、1回の修正ループで1週間が消えることもある。

「速度が違う」問題の正体

複数社が関わるプロジェクトで最も消耗する場面のひとつは、優先度のずれだ。

自社にとって今週最重要のタスクが、外注先にとっては複数ある案件のひとつに過ぎない。これは相手が怠慢なわけではない。単純に、相手の優先度は相手の事情で決まるからだ。

リブランディングプロジェクトを例に考えてみる。広告代理店の田中さんが自社PM、パートナーのデザイン会社が制作リード、フリーランスのコピーライター・佐々木さんが文章担当、クライアントが飲食チェーンの企画部長・吉田さんという構成だ。

田中さんは毎週月曜の朝に「今週のタスク」をSlackに書いて送っている。しかし佐々木さんのSlackにはその通知が来るだけで、タスクとして管理されているわけではない。デザイン会社には別途メールで依頼が送られているが、担当者が変わった際に引き継ぎが漏れた。吉田さんには週次の定例会議でしか進捗が共有されないため、月曜に起きたことが金曜の会議まで見えない。

このプロジェクトで遅延が起きたとき、「誰かのせい」にはならない。構造的に、全員が部分的にしか状況を見えていなかったのだから。

情報設計の基本：全体層と限定層を分ける

複数社横断プロジェクトでの情報共有には、ふたつの層が必要になる。

ひとつは、関係者全員が見る全体層。プロジェクトの大きなマイルストーン、現在のフェーズ、直近の承認待ち事項——これは関係者全員がいつでも確認できる必要がある。

もうひとつは、特定のグループだけが見る限定層。自社とデザイン会社の間でやり取りする制作ディレクションの詳細、クライアントには見せる必要がない社内の見積もり調整、外注スタッフが自分のタスクだけを確認できる場——これらは全員に見せる必要がない。

この2層を意識せずに「全員同じ場所に情報を置く」をやると、クライアントが見ていない場所で話が進んでいる、あるいはクライアントに見せてはいけない情報まで流れてしまう、という事態が起きる。

Paqutのグループ機能はこの設計に対応している。プロジェクト全体を俯瞰するグループをひとつ作り、そこに全員を招待する。制作工程の詳細管理は別グループに分け、デザイン会社と自社のメンバーだけを入れる。外注の佐々木さんには自分のタスクが含まれるグループだけへのアクセスを渡す。こうすることで、全員が「自分に関係する情報の全て」を見られる状態を保ちながら、余分な情報が混在しない状態を作れる。

会議依存プロジェクトからの脱却

「会議でしか進まないプロジェクト」は、情報が人の頭の中にしかない状態から生まれる。

週次の定例会議で議事録が作られ、翌週の会議でその議事録を参照して「あの件どうなりましたっけ」と確認する。タスクではなく議事録で進捗を追う構造だ。

この構造を変えるのは、ツールより先に「タスクで状況を表現する」習慣の設計だ。会議が終わったあと、その会議で決まったことをタスクに変換して、担当者と期限を明示してボードに置く。次の会議が来たとき、ボードを見れば何が完了していて何が止まっているかが一目でわかる。会議はその確認のためではなく、判断のためだけに使えるようになる。

田中さんのリブランディングプロジェクトに戻ると、週次定例をこう変えることができる。会議の前日までに、全員が自分のタスクの状況をボード上で更新しておく。会議ではボードを画面共有して、「完了」「進行中」「ブロック中」の状態を見ながら話す。ブロック中のタスクについてだけ議論して、決定事項を即座にタスクに変換する。吉田さんは金曜の会議でなくても、月曜から木曜の間に進捗を確認できる。

これが「会議前にすでに状況が共有されている状態」の実際だ。

Paqutを使った複数社プロジェクトの組み立て方

リブランディングプロジェクトを例に、具体的なグループ設計を示す。

グループ1：プロジェクト全体（全員参加）

田中さん・デザイン会社担当・佐々木さん・吉田さんの全員が入るグループ。ここに置くのは、マイルストーンタスクだけにとどめる。「第1フェーズ：ブランドコンセプト決定」「第2フェーズ：ビジュアルガイドライン完成」「第3フェーズ：媒体展開」といった単位だ。各マイルストーンタスクに、詳細コメントや承認状況を記録する。吉田さんはここを見れば、今プロジェクトがどのフェーズにいるかがわかる。

グループ2：制作ディレクション（田中さん・デザイン会社のみ）

デザイン方向性の議論、素材の受け渡し、フィードバックのやり取りを行う場。クライアントに見せる必要がない制作上の試行錯誤はここに置く。

グループ3：コピーライティング（田中さん・佐々木さんのみ）

佐々木さんが受け取るタスクはここに集約される。「TOPページキャッチコピー 3案 6/27まで」「商品説明文 5点 7/4まで」のように、具体的な成果物と期限が書かれたタスクが並ぶ。佐々木さんは他のグループを見る必要がなく、自分の仕事だけに集中できる。

グループ4：クライアント確認（田中さん・吉田さんのみ）

吉田さんに承認を求める案件だけを置く場。「ブランドコンセプト案 確認・承認依頼」「ビジュアルガイドライン最終版 確認」のように、吉田さんのアクションが必要なタスクだけをここに積む。

この設計で、4者がそれぞれ「自分に関係するボードだけ」を見て動ける状態になる。

外部メンバーの招待設計

複数社横断プロジェクトでツール選びが難しくなる理由のひとつが、「相手に新しいアカウントを作らせるコスト」だ。

デザイン会社は自社でBacklogを使っている。佐々木さんはNotionに慣れている。吉田さんはデジタルツールにあまり慣れていない。こういう状況で、全員に新しいツールのアカウントを作って覚えてもらうのはハードルが高い。

Paqutは外部ゲストをURLリンク1本で招待できる。相手側に特定のアカウント体系を強制しない設計になっているため、「このプロジェクトのためだけに使う」という入り方ができる。吉田さんはアカウントを持っていなくても、送られてきたリンクからプロジェクトの進捗を確認できる。

自社がプロジェクトのハブになる場合、この招待の簡易さが実務の負荷を大きく左右する。

「同じ絵を見る」ことが生み出すもの

タスクボードを全員が持つことの価値は、情報の効率化だけではない。

パートナー会社のデザイナーが、自分の制作物の先に何があるかを知っている状態と知らない状態では、仕事の質が変わる。佐々木さんが、自分の書くコピーがどのタイミングでクライアントに見られるかを知っていれば、そのコピーに込める意識が変わる。吉田さんが、プロジェクトの全体像を会議の場だけでなく日常的に見えていれば、判断が速くなる。

「同じ絵を見る」とは、単に情報共有のツールの話ではない。プロジェクトに関わる全員が、自分の仕事の文脈を持てる状態を作るということだ。

所属が違っても、優先度がずれていても、ツールの習慣が違っても——全員が同じボードを見ていれば、「今何が起きているか」という共通認識を持てる。その共通認識が、会議の回数を減らし、確認メールの往復を減らし、何より担当者それぞれが自律的に判断できる余地を生む。

複数社横断プロジェクトを「重い」ものにしているのは、人ではなく構造だ。その構造を変えることで、田中さんも佐々木さんも吉田さんも、今より少ない摩擦で、自分の仕事に集中できるようになる。