「配信先が確定したら告知文を直す」。依頼がチャットに残っていても、確認する人や投稿予約までの期限が決まっていなければ、作業は止まりやすい。小規模なアニメ・映画メディアなら、まず共有表を一枚用意し、次に動く人と完了条件を見えるようにしたい。企画を記録するだけでは、告知作業の抜けは防げない。
管理するのは「企画」ではなく、次に動ける作業
「新作映画を盛り上げる」は目標であり、担当者が完了にできる作業ではない。「公開済み紹介記事からSNS用の短文を作る」「配信情報の確定状況を確認する」なら、終わりを判断できる。一つの企画に工程が複数ある場合は、確認、制作、承認、公開を必要な範囲で分けよう。ただし、短い投稿の句読点を直すだけなら、独立した行にするほどではない。
記事原稿の進行表や企画カレンダーがすでにあるなら、情報を丸ごと複製しない。カレンダーには「いつ何を扱うか」、マーケティングのタスク表には「告知や導線整備のために、次に誰が何をするか」を記す。作品紹介記事の公開予定日はカレンダーで管理し、タスク表には「記事公開後に告知文のリンク先を確認する」と入れる。予定が動いたときも、作業の所在を追いやすい。
最初の一枚に入れる項目
表計算シートでも、既存のタスク管理ツールでもよい。編集部の全員が開けて、担当者自身が更新できる場所を選ぶ。列は増やしすぎず、まずは次の項目に絞る。
- 作業名：「SNS対応」ではなく「作品紹介記事の告知文を作成」のように、何をするかが分かる名前にする
- 対象と掲載先：作品名・企画名と、記事、ニュースレター、SNSなどの掲載先を記す
- 担当者：作業を進める人を一人決め、協力者は必要に応じて補足する
- 期限：公開日時ではなく、担当者が作業を終えるべき日時を記す
- 状態：未着手、進行中、確認待ち、保留、完了から選ぶ
- 次の一手・待っているもの：再開に必要な確認先や条件を短く書く
- 参照先：原稿、公式発表の記録、承認済み素材など、判断に必要な資料の保存場所を示す
「担当：告知担当／期限：木曜15時／状態：確認待ち／次の一手：編集担当が配信地域の記述を確認」とあれば、表を開いた人にも止まっている理由が分かる。参照先には共有フォルダーや内部資料の場所を記し、未公開の発表資料や連絡先を、閲覧権限の広い表に直接貼り付けない。
期限は「公開日」から逆算して分ける
作品記事の公開と告知投稿を同時刻に予定していても、告知文の確認をその時刻まで待つわけにはいかない。タスクには作業上の期限を設定し、必要なら公開予定日時を別欄に置く。承認に時間がかかるなら、その分だけ作業期限を前倒しする。
たとえば金曜の夕方に記事を公開するなら、水曜に告知文の初稿を作り、木曜に作品名と視聴方法を確認し、金曜にリンク先と公開状態を最終確認する。この日程はあくまで一例。素材提供の条件や担当者の勤務時間に合わせて調整する。直前にしかできない確認と、前日までに済ませられる制作を分けておくことが肝心だ。
アニメの配信情報は、サービス名だけでなく、対象地域、開始日時、見放題か都度課金かといった条件も告知文に関わる。未確定の項目は推測で埋めず、「配信条件を公式情報で再確認」をタスクにする。期限までに確定しなければ、該当箇所を告知文から外すか、公開予定を見直すか。担当者が判断できるようにしておこう。
状態は少なく、意味を揃える
状態を細かく分けても、「作業中」と「確認中」の境界が人によって違えば一覧は読みにくい。最初は未着手、進行中、確認待ち、保留、完了の五つ程度で十分だ。特に次の三つは、チーム内で意味を揃えておきたい。
- 確認待ち：原稿や素材を提出済みで、次に判断する相手が決まっている
- 保留：公式情報の発表や権利確認など、作業を進める条件がまだ満たされていない
- 完了：書いただけ、予約しただけではなく、決めた完了条件を満たしている
「確認待ち」には確認者と依頼日を、「保留」には再確認する日を添える。理由だけを書いて見直す日がなければ、表の中で埋もれてしまう。投稿タスクの完了を「予約設定済み」とするのか、「公開後に表示とリンクを確認済み」とするのかも、運用開始時に決めておく。予約と公開後確認を別の人が担うなら、タスクも分けた方が明確だ。
優先順位は締切だけで決めない
同じ締切でも、後から差し替えられる文言調整と、告知を公開できるかどうかに関わる権利確認では重みが違う。「公開を止める作業」「日時が固定された作業」「後から調整できる作業」の順に見ると、急ぎの判断がしやすい。細かな重要度の点数を付けるより、先に済ませないと他の担当者が動けない作業を示す方が、小さなチームには役立つ。
同じ作品をSNS、ニュースレター、記事内で案内するなら、共通の事実確認を先に一件立てる。その結果を各作業から参照すれば、担当者ごとに異なる配信日時を書いてしまうリスクを減らせる。
タスクの入口を一つにし、更新の習慣を決める
依頼がチャット、口頭、メールに分散するのは避けにくい。問題は、受けた人の記憶だけが管理場所になることだ。作業が発生したら、依頼者か受けた人が共有表に登録する。「表に入るまでは正式なタスクとして扱わない」と決めておくと、登録漏れにも気付きやすい。
詳細が未定なら、推測で埋めずに「担当未定」「期限要確認」と書く。そのうえで、担当を決める人と確認日を入れておく。急な映画関連ニュースを受けて告知内容を変える場合も、元の行を黙って書き換えず、変更理由を一文残したい。止めた根拠が分かれば、後から再開しやすい。
確認のために長い会議を設ける必要はない。平日は各担当者が状態を更新し、週に一度、期限が近い行と「確認待ち」「保留」の行をチームで見る。聞くべきなのは進捗報告そのものより、「誰の判断があれば動けるか」「期限を直す必要があるか」。完了行を一覧から非表示にしても、一定期間残しておけば、似た企画で必要だった工程を確かめられる。
公開後の作業も、必要なものだけ登録する
告知は投稿ボタンを押して終わりとは限らない。公開後にリンク切れや画像の表示、案内した視聴条件を確認する必要があれば、あらかじめタスクに入れる。ただ、全投稿に同じ点検項目を増やすと、大事な確認が埋もれる。リンク先が公開時に初めて有効になる投稿や、配信条件が更新される可能性のある案内を優先したい。
記事本文の情報更新と告知の作業は、担当を分けて記録すると混乱しにくい。配信情報が変わったなら、本文の確認・修正を一件、既存の告知文に修正が必要かの判断を一件にする。本文更新の判断材料には、古いアニメ・映画記事を更新するときの確認ポイントで扱うような項目も参照できるが、タスク表に書くのは今回必要な作業だけでよい。
効果測定も、毎回すべての数字を記録する必要はない。特定の告知方法を試したときは、「公開から一定期間後に結果を確認し、次回に使う気付きを一行残す」とタスクにしておく。見る目的と確認日が決まっていれば、閲覧数を書き写すだけで終わらない。
小さく試して、行が増えすぎたら整理する
導入直後は、進行中の企画を一つか二つ選んで試そう。過去の作業をすべて入力し直す必要はない。数日使ったら、担当者が不明な行、状態が変わらない行、別の表と二重管理になっている行を確認する。使われない列があれば、その情報が毎回必要か見直す。
一行に複数の担当者が並び、誰も完了にできないなら作業を分ける。反対に、数分で終わる確認が大量の行を占めるなら、関連するタスクの完了条件にまとめる。基準は表の細かさではなく、担当者が開いたときに次の行動を決められるかどうかだ。
まずは次に予定している作品紹介の告知を一件だけ登録してみる。「告知文を作成」と書き、担当者、初稿の期限、参照する確認済み記事、完了条件の「編集担当へ提出」を入れる。提出したら状態を「確認待ち」に変え、確認者の名前を添える。その一行を見れば、次に誰が動くか分かる。
