記事の編集カレンダーの作り方｜企画・執筆・確認・公開を無理なく管理する

記事の公開予定日だけをカレンダーに入れても、原稿は予定どおりに完成しません。資料待ち、構成確認、修正、入稿など、その前に必要な作業があるからです。編集カレンダーは、本数を並べる表ではなく、各記事が次の工程へ進める状態かを共有するために作ります。

この記事では、少人数のメディアや外注を使う担当者が、最初の一か月分の予定を組む手順を説明します。カテゴリーの分類や運営マニュアル全体ではなく、進行管理に必要な日付、状態、担当、待ち時間を整理します。高機能な管理ツールがなくても、共有できる表から始められます。

公開本数より先に、確認できる量を把握する

最初に、企画、執筆、確認、入稿を誰が担当するかを書きます。一人が複数を担当していても、工程は分けてください。執筆者が五人いても、確認できる担当者が一人なら、その人の処理量が公開本数の上限になる場合があります。

一週間で使える時間と、既存記事の更新や問い合わせ対応に必要な時間を確認します。すべてを新規記事へ割り当てると、突発対応が起きた時に予定が崩れます。最初は過去の作業記録や少数記事の試行から、無理なく処理できる範囲を見積もります。理想の速度を実績として使わないことが重要です。

一記事の工程を同じ言葉で表す

状態は、企画候補、資料準備、構成確認、執筆中、原稿確認、入稿、公開確認、公開済みなどに分けます。細かくしすぎると更新が負担になるため、担当者が変わるところや判断が必要なところを中心にします。媒体の規模に合わせて省略して構いません。

各状態の完了条件も決めます。「執筆完了」は本文があるだけか、出典と画像情報まで揃っている状態かで意味が違います。「確認中」のまま一週間止まっている場合も、誰の何を待っているかが分かるようにします。状態名だけでは理由が見えないため、待ち事項の列を用意してください。

原稿確認の完了条件を決める際は、外注記事の検収方法｜納品原稿の確認項目と差し戻しの伝え方で納品後の確認範囲を整理できます。

日付は公開日から逆算する

公開日が決まっている記事は、入稿確認、修正、原稿確認、執筆、構成確認の順に期限を戻していきます。取材や商品の入手が必要なら、その前に日程を置きます。土日や担当者の休みを無視して日付を埋めると、表の上だけで成立する予定になります。

締切は余裕のない連続日程にせず、必要な確認時間を確保します。例えば金曜公開なら、金曜朝に初稿が届く計画では修正できる余地が少なくなります。実際の確認にかかる時間を記録し、次回の予定へ反映してください。納期を早める前に、待ち時間を減らせないかを見ることも有効です。

記事ごとの依存関係を入れる

新しい料金記事から比較記事へ案内する場合、リンク先が先に公開されているか、同時公開できるかを確認します。先に公開した記事のリンクが未公開ページへ向かないよう、順番をカレンダーへ反映します。共通図版や監修が必要な記事も、関連する工程を見えるようにします。

依存関係は複雑な図にしなくても、「先に必要な記事ID」「待っている資料」で管理できます。一つの資料が遅れた時、どの記事が影響を受けるかが分かれば十分です。影響しない記事まで止めず、独立して進められる作業へ担当を切り替える判断ができます。

新規制作と更新を同じ予定で扱う

新規記事だけを管理すると、料金変更や広告終了への対応が予定外の仕事になりがちです。更新も一つの作業として登録し、対象URL、変更理由、期限を残します。公開予定の本数とは分けて集計しても、担当者の時間は同じ表で把握します。

更新の優先度は、読者への影響と期限で判断します。表示を少し整える作業と、終了した広告への誘導を止める作業は同じではありません。急ぎの更新を入れた場合は、代わりに何を後ろへ動かしたかを明示します。何も減らさず仕事だけ追加すると、計画は機能しなくなります。

企画候補をすべて締切付きにしない

まだ資料がない企画、案件の提携結果を待つ企画は、候補として残します。調査が終わっていない段階で公開日を約束すると、内容を薄くして間に合わせる圧力が生まれます。着手可能な企画と、判断が必要な企画を分けておくと、空いた時間に次の仕事を選びやすくなります。

候補欄には、読者の疑問、必要な調査、着手条件を書きます。「ASPから掲載条件の回答が届いたら構成作成」のように次の条件が分かれば、保留が放置になりにくくなります。案が多いことと、すぐ制作できる記事が多いことは別として管理してください。

一か月の仮予定を組んで負担を見る

説明用に、毎週二本の新規記事と一本の更新を行う計画を考えます。初週は構成確認を二本、翌週はその原稿確認と次の構成確認が重なります。執筆だけを見ると余裕があっても、確認担当の仕事は週を追って増える可能性があります。

予定を担当者別に見直し、同じ日に確認が集中していないかを見ます。公開日を毎週同じにすることより、確認が間に合う配置を優先します。この本数は運営規模の推奨値ではなく、工程の重なりを考えるための仮例です。自社の処理量に合わせて減らしたり増やしたりしてください。

遅れた時は原因を状態として残す

遅延理由は、資料待ち、担当者の作業超過、方向性の変更、確認漏れなどに分けます。単に赤い日付を付けるだけでは、次の予定を改善できません。執筆の遅れに見えても、実際は構成が承認されるまで着手できなかった場合があります。

公開日を変更したら、旧予定と変更理由を残します。毎回上書きして履歴を消すと、どの工程で遅れやすいか分からなくなります。担当者を責めるための記録ではなく、次回の前提を直すための記録にしてください。繰り返す遅れには、締切の短縮ではなく工程の変更が必要な場合があります。

週次の確認では次の障害だけを決める

週次確認では、すべての記事を詳しく読み直す必要はありません。今週公開する記事、止まっている記事、来週着手する記事を中心に、誰が何をいつまでに解消するかを決めます。「進めます」で終わらず、回答を得る、資料を受け取る、構成を承認するなど具体的な次の行動にします。

会議の後に表が更新されなければ、話した内容が担当者の記憶にしか残りません。決定事項をその場で記録できる簡単な形式にします。参加人数を増やすより、判断できる人が必要な情報を見て、次の担当へ渡せることを重視してください。

最小限の管理表を作る記入例

一行に記事ID、仮タイトル、状態、現在の担当、次の期限、待っているもの、公開予定URLを入れます。説明用に「記事十二、費用比較、資料準備、担当甲、火曜、公式回答待ち」と書けば、今は執筆者を急がせても進まないことが分かります。担当甲は仮の名前で、実際の体制を示すものではありません。

公式回答が届いたら、状態を構成確認へ変え、次の担当と期限を更新します。以前の待ち事項は履歴へ残し、現在の欄には残さないようにします。古い状態と新しい状態が混ざると、誰も表を信用しなくなります。更新する人を一人に固定するか、工程を受け取った人が変更するかを決めてください。

記事IDは、タイトルが変わっても同じものを使います。原稿、資料、画像、確認記録を同じIDで関連付けると、名称変更のたびに探し直さずに済みます。URLが未確定の場合も、その状態を明示します。カレンダーへURL候補を書いたことをもって、公開URLが決定したと解釈しないようにします。

運用を始めて使われない列が見つかったら、目的を確認して減らします。入力する情報が多いほどよいわけではありません。次の担当と障害が分かることを優先し、必要になった列だけを追加していく方が、日々の更新を続けやすくなります。

公開後の点検日も予定へ入れる

公開直後の表示確認と、一定期間後の反応確認を分けて登録します。前者はリンクやレイアウトの不具合、後者は検索語句や読者の動きなどを見るためです。すべての記事を同じ頻度で改稿する必要はなく、役割と変更頻度に合わせて設定します。

最初の一か月が終わったら、予定本数だけでなく、確認待ちの日数、差し戻しの原因、更新に使った時間を振り返ります。カレンダーの完成は空欄がなくなることではありません。予定外の変更があっても、何を優先し、何を後ろへ動かすかを判断できる状態を作ることです。

記事数が増え、企画・制作・確認を一人で管理しきれない場合は、制作体制を含めて任せられる範囲をご確認ください。