結論：デジタルエージェンシーの案件を1つのハブで回すには、ツール選びより先に「誰が何をどこに書くか」のルール設計が決め手になる。

月に15本の案件を抱えるデジタルエージェンシーで、ディレクターの中村さんはある朝、クライアントのABC商事からメールを受け取った。「先週のミーティングで話した修正、どこに反映されましたか?」。社内のSlackを検索し、外注先との共有フォルダをひらき、メールスレッドを遡る。20分後、修正指示はChatWorkのグループに流れていたことがわかった。中村さんが費やした20分は、その日だけの話ではない。

デジタルエージェンシーや制作会社の案件には、複数の「壁」がある。社内PMと外部クリエイターの間にある壁、クライアント担当者と制作チームの間にある壁、そして外注のデザイン会社と外注のエンジニアリング会社の間にある壁。それぞれが慣れたツールを使い続けるため、情報は必然的に分散する。Slackには社内のやりとり、メールにはクライアントへの報告、ChatWorkには外注先への依頼。1つの案件なのに、情報の置き場所が3か所に割れている。

この構造を整理するのが「案件管理ハブ」という考え方だ。全員が同じ場所を見て、同じ状態を把握できる。報告のために別途まとめ直す必要がなく、確認の電話を入れる前に画面を見れば答えが出ている。そこに辿り着くための設計を、実際の現場の姿から考えていく。

デジタルエージェンシーの案件構造を分解する

典型的な案件には4つの立場の人間が関わる。

クライアントの担当者は、要件定義とフィードバックを担う。週に1〜2回の確認タイミングで、制作物の進捗と品質を判断する立場だ。社内PMやディレクターは、案件全体のスケジュールと予算を見ながら、外注先との調整を担う。フリーランスのデザイナーやコピーライターは、特定の制作物を担当し、案件によって顔ぶれが変わる。そして外注の制作パートナー会社は、エンジニアリングや映像制作など専門領域を担い、それ自体が複数人のチームで動いている。

この4者が絡む構造は、情報の流れを複雑にする。クライアントからの修正要望は社内PMに届き、PMがフリーランスデザイナーの藤岡さんに伝え、藤岡さんが制作パートナーのエンジニアチームに共有する。このリレーの中で、ニュアンスが削られ、期日の認識がずれ、誰かの返信待ちが発生する。

関与者主な役割使いがちなツール
クライアント担当者要件確認・フィードバックメール・Zoom
社内PM/ディレクター全体調整・スケジュール管理Slack・社内ツール
フリーランスクリエイター制作物の担当ChatWork・メール
外注制作パートナー専門領域の制作独自ツール・ChatWork

この表を見ると、案件に関わる全員がバラバラのツールで動いていることがわかる。これはツールの選び方の問題というより、「それぞれが慣れた方法を使い続けてきた結果」だ。

情報分散が生む本当のコスト

ツールが3つに割れているとき、問題になるのは「どこに何があるか」の把握コストだ。

新しいフリーランスの山田さんが案件に加わった初日、彼女は必要な情報を集めるために3つのツールにアクセスし、担当者に「最新の要件定義はどこにありますか?」とメッセージを送る。その質問に答えるために、ディレクターはまた検索に時間を使う。

週次の進捗報告も、ツールが分散していると手間が倍になる。各ツールから情報を集めて、クライアント向けにまとめ直す。この「まとめ直し」は情報の二次生産であり、制作の本質とは無関係な仕事だ。社内に10人のチームがあり、それぞれが週2時間この作業に使っているなら、月に換算すると80時間以上が報告のための報告に消えている計算になる。

月15案件を10名の社内チームと20名の外注先で回しているエージェンシーを例に取ると、関係者は合計30名以上になる。この規模になると、ツールの分散は単なる不便ではなく、案件品質に直結するリスクになる。誰かの修正指示が届いていなければ、成果物はクライアントの期待と違う方向に進み続ける。

案件管理ハブの設計思想

ハブとは「全員が同じ場所を見ている状態」をつくることだ。1つのプラットフォームに、クライアントも外注先も社内チームも入れる。

この設計の核心は3つある。

1案件=1グループの原則

案件管理ハブで最初に決めるべきことは、情報の単位だ。Paqutでは「グループ」が案件の単位になる。ABC商事のサイトリニューアル案件なら、そのグループの中にタスク、ファイル、やりとりが集約される。グループが案件と1対1で対応しているため、関係者は「どのグループを見ればいいか」で迷わない。

案件が終わればグループのゲストメンバーを外し、次の案件では新しいメンバーを招待する。この繰り返しで、過去の案件が現在の情報を汚染しない。外部ゲストの追加に追加費用がかからない構造であれば、関与者が多い案件でもコストを気にせずハブに集めることができる。

見せる情報と見せない情報の設計

クライアントをツール内に招待するとき、避けて通れないのが「見せていい情報」と「社内だけで持つべき情報」の区別だ。

クライアントのABC商事の担当者には、制作物の進捗とフィードバックの場を見せればいい。一方、外注先との単価交渉や社内のコスト管理はクライアントには見せない。この区別をグループ内の権限設定で実現できるかどうかが、ツール選びの分水嶺になる。

権限設計の一例として、次のような構成が考えられる。

役割見られる範囲操作できること
社内PMグループ全体タスク作成・メンバー招待・全コメント
クライアント担当者制作物タスクのみコメント・ファイル添付
フリーランス(藤岡さん)担当タスクのみステータス更新・コメント
外注パートナー関連タスクのみステータス更新・成果物アップ

この設計があることで、クライアントは進捗をリアルタイムで把握でき、社内は「進捗報告メールを書く」という仕事から解放される。

既存ツールとの共存

「全員を1つのツールに移す」という理想は、現実には段階的にしか実現しない。社内チームはSlackを使い続けるかもしれないし、長年の付き合いがある外注パートナーはChatWorkを手放したくないかもしれない。

PaqutはSlack、Discord、ChatWorkと連携できる。案件管理ハブをPaqutに置きながら、通知はそれぞれが慣れたコミュニケーションツールに届ける構成が取れる。これは「ツールを統一する」ではなく、「情報の置き場所を統一する」という発想の転換だ。

移行の現実：ルール整備が先、ツール導入は後

案件管理ハブの導入で失敗するパターンは決まっている。ツールを先に入れて、使い方を後から決めようとする場合だ。

ツールを入れた初週、全員が試行錯誤でタスクをつくる。2週目には「ここに書いていいですか?」という質問が飛び交う。3週目には「やっぱりSlackのほうが早い」と言い出す人が出てくる。ツールの問題ではなく、「どこに何を書くか」のルールが決まっていないことが原因だ。

ハブ移行の前に決めておくべきことは3つある。

タスクの粒度だ。「サイトリニューアル」というタスクは粒度が大きすぎる。「トップページのワイヤーフレーム作成」「クライアントへのワイヤーフレーム確認依頼」「修正反映と再提出」という単位に分解して初めて、誰が何を持っていてどこで止まっているかが見えてくる。

コメントの書き先だ。タスクに関する質問はタスクのコメント欄に書く、案件全体に関する連絡はグループの共有スレッドに書く、という最低限のルールを明文化する。これがないと、重要な決定がSlackに流れ、ハブが形骸化する。

ステータスの定義だ。「進行中」「確認待ち」「完了」という3段階でもいいし、より細かく設定してもいい。重要なのは、全員がステータスの意味を同じに理解していることだ。フリーランスの山田さんが「確認待ち」にしたとき、それがクライアント待ちなのか社内PM待ちなのかが区別できるように定義しておく。

ハブが機能し始めたとき

適切に設計されたハブが動き始めると、チームの景色が変わる。

ディレクターの中村さんは、朝に画面を開くだけで全15案件のステータスが把握できる。クライアントから進捗確認のメールが来たとき、「確認して折り返します」ではなく「グループを見てください」と一言送るだけで済む。ABC商事の担当者は、いつでも最新の進捗を自分で確認できる。

フリーランスのデザイナー藤岡さんは、自分の担当タスクと締め切りを一覧で見ながら仕事を進める。修正指示がどこかのメールに埋もれることなく、タスクのコメントとして残るため、「あの指示はどこだっけ」という検索時間がなくなる。

外注パートナーは、自分たちに関係するタスクだけが見えている状態で動く。社内の議論や単価交渉は視界に入らず、制作に集中できる。

越境したチームが同じ絵を見て動いている状態。それがデジタルエージェンシーの案件管理ハブが目指すところだ。ツールがその状態をつくるのではなく、ルールとツールの組み合わせが実現する。月15案件を回すチームも、月3案件からはじめるチームも、まず「どこに何を書くか」を決めるところから始めてほしい。Paqutがエージェンシー現場でどう使われているかは、広告代理店・デジタルエージェンシー向けの活用ページでまとめている。