結論：記事1本をタスク1つに対応させ、関わる外注先全員を同じ画面で見られる状態にするだけで、「あの原稿どこまで?」という確認の往復はほぼなくなる。

出版・メディアの仕事は、毎回メンバーが変わるプロジェクトの連続だ。今月の特集に入るライターは3人、来月は別の2人。カメラマンは案件の内容によって呼び分ける。イラストレーターとデザイナーは記事のジャンルで使い分ける。一人ひとりは優れた作り手なのに、進行を束ねる編集者のコミュニケーション量だけが膨らんでいく。

こうした現場で実際に起きていることは、「管理の問題」ではなく「全員が同じ絵を見ていない問題」だ。ライターはSlackで入稿したと思っている。編集者はメールに届いたものが最新版か自信がない。デザイナーはどの原稿が確定したのかを編集者に確認するメッセージを送っている。それぞれが誠実に動いているにもかかわらず、確認の往復が積み重なって締め切りが近づく。

月20本の記事を動かすWebメディアでも、年4回の特集号を組む出版社でも、構造は同じだ。コンテンツ制作は「誰が何をどこまでやったか」を全員が把握できる状態をいかに作るかにかかっている。

出版・メディアの外注構造を整理する

コンテンツ制作に関わる外注先は、大きく次の役割に分かれる。

役割主な関与フェーズ関与の頻度
原稿ライター構成確認〜原稿提出記事ごとに変わる
取材カメラマン取材・撮影案件ごとに変わる
イラストレーター原稿確定後〜デザイン前記事のジャンルで変わる
グラフィックデザイナー編集後〜入稿媒体・案件で変わる
校正者最終確認定期起用が多い

これだけ見ると整理されているように見えるが、実際には1本の記事にこれらの役割が重なりながら関わる。取材写真が揃わないとデザインが進まない。原稿が確定しないとイラストの発注指示が出せない。各フェーズが前のフェーズの完了を待っているため、どこか1箇所が詰まると全体が遅れる。

そしてこの構造の中で、編集者は各工程の状況を「個別に確認するか、記憶しておくか」の二択を迫られ続ける。

進行管理の典型的な問題

フリーランスが多い現場の進行管理で最もよく起きることは、確認の往復が止まらないことだ。

「あの原稿、今どのくらい進んでいますか?」 「写真データはDropboxに入れましたか?」 「修正した版を昨日送りましたが届いていますか?」

一つひとつは小さなメッセージだが、10本の記事を並行して動かしていると、編集者は毎日このやりとりを繰り返すことになる。確認するためにSlackを開き、返信を待ち、状況を把握してから次の判断をする。この「確認のためのコスト」が、編集者が本来使うべき「コンテンツの質を上げるための時間」を削っている。

問題は外注先の対応が遅いのではない。連絡手段がバラバラで、進捗が一元化されていないことが原因だ。

記事制作フローをタスクに落とし込む

記事1本の制作フローを分解すると、次の工程になる。

企画 → 構成確認 → 取材・撮影 → 原稿提出 → 編集 → デザイン → 最終確認 → 入稿

これをPaqutで管理するときの設計は、記事1本につきタスク1つを作ることから始まる。タスク名は「【6月特集】在宅勤務の生産性 / 担当:田中さん」のように記事タイトルと担当者を入れておく。

タスクには次の情報を紐づける。

  • 担当ライター(ゲストとして招待)
  • 入稿期限
  • 構成メモや参考URLを添付
  • 各工程のステータス(「構成確認中」「執筆中」「初稿提出済」「編集中」「デザイン入り」「確認待ち」「入稿完了」)

ライターはタスクのステータスを自分で更新する。「執筆中」から「初稿提出済」に変えると編集者に通知が届く。編集者が確認してコメントを残すと、ライターに通知が届く。このやりとりが全てタスクの中に記録される。

ゲスト招待でコストゼロの外注先連携

Paqutはゲストユーザーを人数に関わらず無料で招待できる。ライターが5人いても、カメラマンが月によって変わっても、追加コストは発生しない。

ゲストとして招待されたライターは、自分が担当するタスクだけを見られる。他の記事の進行状況や、他のライターの情報は見えない。編集者側は全タスクを一覧で見られる。この非対称な見え方が、適切な情報共有と情報の保護を両立させる。

月20本×8名のフリーランスを動かす設計

月20本の記事を8名のフリーランスと作っているWebメディアのケースで考えてみる。

編集長の中村さんは毎月、ライター別・テーマ別に原稿の進捗を追いかけていた。Googleスプレッドシートに一覧表を作り、毎朝ライターにメッセージを送って状況を確認し、スプレッドシートを更新する。それだけで午前の2時間が使われる日があった。

Paqutを導入した後、中村さんが変えたのは「進捗の確認」を自分の仕事から外したことだ。各記事のタスクをライターに担当者として割り当て、ステータス変更を通知する設定にした。ライターは自分の作業が進んだらステータスを更新する。中村さんは通知が来たときだけ確認する。

「今どこまでですか?」という確認メッセージを送ることはなくなった。Paqutのボードを見れば、20本のうち何本が「執筆中」で、何本が「編集待ち」で、何本が「デザイン入り」かが一目でわかる。

複数テーマを並行して動かすプロジェクト設計

月間のコンテンツ計画が特集ごとに分かれている場合、Paqutのグループ機能を使う。「6月特集:働き方改革」「6月特集:食と健康」「6月特集:旅行」のように特集テーマをグループにして、その中に各記事のタスクを置く。

これにより「この特集の進行が遅れている」「こちらの特集はデザインが詰まっている」という単位で状況を把握できる。編集者が全タスクを同じ場所で見ながら、優先順位の判断ができる。

デザイナーとの連携をどう設計するか

原稿が確定してからデザイナーが動き始めるケースでは、タスクのステータス変更を引き継ぎのトリガーとして使う。

編集者が「編集完了」にステータスを変更した時点で、デザイナーが担当者として追加され、通知が届く設計にする。デザイナーはそのタスクを開くと、確定した原稿・使用する写真・レイアウト指示が全て揃っている。「どのバージョンの原稿が最新ですか?」という確認が不要になる。

デザインが上がったら、デザイナーがステータスを「確認待ち」に変更する。編集者に通知が届き、最終確認に入る。修正があればタスクのコメントで指示する。「昨日送ったメールに修正点を書きましたが」という行き違いが起きなくなる。

外注先が「追いかけられる側」にならない設計

ここで大切にしたいのは、ライターやデザイナーが「管理される」という感覚を持たない設計にすることだ。

ステータスの更新は報告ではなく、次の工程への引き渡しだ。ライターが「初稿提出済」に変えるのは、編集者へのバトンを渡す行為だ。デザイナーが「確認待ち」に変えるのは、自分のパートが完了したことを記録する行為だ。タスクはチームで一つの作品を仕上げるための共有スコアボードとして機能する。

フリーランスで働く人たちは、複数の案件を並行して動かしている。どのクライアントの仕事が今どの状態にあるかを自分で把握できていると、スケジュール調整が楽になる。Paqutのタスクは外注先にとっても「自分の仕事の状態を把握する場所」になる。

出版社・コンテンツ制作会社が得られるもの

記事制作をタスクで管理する体制が整ったとき、変わるのは編集者の働き方だけではない。

外注先との関係性が変わる。毎回「今どこですか?」と確認していた関係から、互いに状況が見えている関係になる。信頼を積み重ねやすくなる。

品質の追いかけ方が変わる。入稿の遅れに気づいたとき、それが誰のどの工程で止まっているかがすぐわかる。「なんとなく遅れてきた」ではなく「この記事の編集フェーズが3日止まっている」と具体的に把握できる。

編集者が使える時間が変わる。確認の往復に使っていた時間が、企画の検討や原稿へのフィードバックに使えるようになる。コンテンツの質を上げる仕事に、もっと集中できるようになる。

月20本の記事を動かしているWebメディアが、外注先8名と「同じ絵を見ながら」仕事を進められる体制は、特別な仕組みなしでも作れる。記事1本をタスク1つにして、全員が状況を更新できる場所を用意する。それだけで、確認のための往復はほぼなくなる。