編集カレンダーの作り方——公開日より先にテーマの重なりを管理する

編集カレンダーへ最初に入れるのは、公開日ではない。読者が何を判断する記事なのか、既存記事で答えていないか、今回どこまで新しく答えるのか。この三つが先に要る。

日付だけを並べると、同じテーマの記事が別の担当者から上がり、公開直前に重なりへ気づく。調査は終わっても専門家の確認が取れず、空いた日に別の記事を差し込む。新規記事で枠が埋まり、古い記事の更新は「余裕ができたら」のままになる。カレンダーがあるのに予定が崩れるのは、表が制作能力と企画差分を持っていないからだ。

編集カレンダーは、企画のポートフォリオと制作上の約束を一つにしたものだ。企画・制作・日付の三層を一行で管理し、公開日は最も遅い依存関係から決める。週次で順番を見直せば、重複企画を増やさず、公開と更新の両方へ時間を残せる。

編集カレンダーは、公開日の表ではない

一般的なカレンダーには、タイトル、担当者、締切、公開日が並ぶ。今日何を公開するかは分かる。一方で、なぜその企画が必要か、既存記事と何が違うか、どの確認が終われば公開できるかは見えにくい。空欄の日へ企画を置くことが目的になると、本数は埋まっても媒体全体の答えは増えない。

英国国家統計局のコンテンツ指針は、コンテンツをつくる前に、利用者が達成しようとしていることを根拠から利用者需要として定義する。似た需要をまとめ、既存コンテンツですでに満たしているもの、重複するもの、根拠が弱いものを除き、優先順位をつける。[1] この順番を編集カレンダーへ移すなら、タイトルより先に「誰の、どの判断を助けるか」を書くことになる。

GOV.UKの移行手順も、新規制作前に既存コンテンツの利用状況、古さ、重複を監査する。コンテンツ計画には、何を公開するかだけでなく、何を公開しないか、どこに情報の不足があるか、誰が管理するかを入れる。[2] カレンダーは「つくるもの一覧」では足りない。見送る理由と、既存記事へ戻す判断も残す必要がある。

企業メディアなら、最低でも各行へ「読者の問い」「既存の中核記事」「今回の新しい答え」を置く。この三列が空いた企画は、まだ日付を持てる状態ではない。イベント日や社内都合から逆算する場合も、読者へ何を足すかが定まらなければ、長編記事ではなく告知やBriefとして扱うほうがよい。

オウンドメディアの編集方針では、読者価値から企画の公開・修正・見送りを決める基準を扱った。編集カレンダーは、採択した企画同士の重なりと制作順を管理する道具である。

日付を入れる前に、読者の問いと既存記事を重ねる

テーマが同じだけでは、重複とは限らない。「オウンドメディア」という大テーマでも、編集方針を決めたい読者と、運営体制を組みたい読者では、次の判断が違う。反対に、タイトルの言い回しが違っても、同じ読者へ同じ答えを返すなら競合する。

新規企画は、既存記事との関係を四つへ分ける。

たとえば「編集カレンダー」と「コンテンツ監査」は、どちらも記事一覧を見る。前者は制作前の企画へ日付を与える前に、問いと差分と依存関係を確かめる。後者は公開済み記事を残す、統合する、削除するために評価する。対象と判断が違うため別記事にできるが、相互に案内すれば読者は制作前と公開後を往復できる。

GDSはロードマップを、高水準の計画を視覚化し、複数の案件をポートフォリオとして横断して見るために使った。共通の見方は必要だが、すべての案件を同じ型へ押し込まず、状況に応じて調整できることも重視している。[7] 編集カレンダーでも、行ごとの締切だけでなく、同じ読者課題やクラスターが固まりすぎていないかを見る。

この照合を新規制作前に行えば、似た検索語ごとに記事を増やす必要はない。既存記事で答え切れていない部分なら、追記または明確な別記事へする。答えが同じなら、タイトル違いの記事を足す代わりに、既存記事の導入、構成、内部リンクを改善する。

企画を三層の行へ変える

企画の差分が決まったら、一行を企画、制作、日付の三層へ分ける。列が増えること自体が目的ではない。「なぜつくるか」「何待ちか」「いつ出せるか」を別々に読めることが重要だ。

企画層の「差分」は一文で書く。「初心者向け」のような読者属性だけでは弱い。「既存記事がKPIの選び方を扱うのに対し、今回は公開前にテーマの重なりを判定する」のように、答えの違いまで記す。

制作層では、状態を「執筆中」だけにしない。一次資料確認済み、構成確定、本文初稿、専門確認待ち、権利確認待ち、最終原稿、公開準備完了など、次の動作が分かる語へ分ける。担当者名だけでは、誰の返答を待っているかが見えないからだ。

日付層には公開予定だけでなく、最短公開日と見直し日を置く。最短公開日は、必要な確認を短縮せず出せる最初の日である。見直し日は、企画が古くなっていないか、固定イベントとの関係が変わっていないかを再判断する日だ。公開予定を動かすときも、品質不足と優先順位変更を区別できる。

GOV.UKのソーシャルメディア手引きは、編集カレンダーへ公開物だけでなく、政策の節目、ロードマップ上の成果物、イベントを置く。日々の管理にはTrello、週・年の見通しには表計算を使う例も示す。[3] ソーシャル運用の事例をそのまま記事制作へ移す必要はない。近い仕事を細かく、遠い仕事を粗く持つという粒度の分け方が使える。

制作能力は、最も遅い依存関係で見積もる

一週間に三本書ける人がいても、一週間に三本公開できるとは限らない。専門家の確認が一週間かかる。写真の利用条件を確かめられない。CMSへ入れた後の表示確認が一人へ集中する。公開後の訂正が残っている。公開できる本数は、一連の工程で最も詰まりやすい箇所に制約される。

オウンドメディアの運営体制では、決める、進める、つくる、確かめるという四つの機能と、判断ごとのownerを整理した。編集カレンダーには、その役割分担を各企画の依存関係として記す。単に「担当：A」ではなく、「専門事実：Bが11月10日まで」「画像権利：Cが確認中」のように、対象と期限を分ける。

GitLabのBlog Handbookは、企画を予定日の少なくとも2週間前に出す運用例を示し、blog reviewを制作工程へ置く。緊急性の高い投稿が入れば、calendarの予定は変わり得るとも明記する。[5] 必要なlead timeを先に共有することと、変更可能性を隠さないことは両立する。

GOV.UK Service Manualは、時間、資材、技能が有限である以上、分析、利用者調査、関係者の入力をもとに優先順位を見直すよう勧める。計画には新機能だけでなく、supportとmaintenanceも含める。[4] メディアなら、公開済み記事の更新、リンク修正、訂正、画像差し替えがこれにあたる。

したがって、週の公開枠には更新や突発対応の余地を残す。五枠すべてを新作へ予約せず、その一部を保守へ割り当てる。比率は媒体ごとに決めればよい。保守も予定された仕事として扱う。

週次で順番を変え、更新枠を残す

編集カレンダーは、守るために固定するのではない。新しい根拠、読者の反応、社内の確認状況を受けて、媒体の約束を守るために順番を変える。

GDSのquarterly missionsの実践では、期間内でも優先順位を見直し、範囲が大きすぎる場合は絞った。roadmapは将来を正確に予言するものではなく、その時点の最善の見通しとして扱われる。[6] カレンダーも同じで、日付変更そのものを失敗とみなさない。根拠もなく後ろへ送り続けることと、品質や読者価値のために組み替えることを区別する。

少人数の編集部なら、週次の20〜30分で次の五つを確認できる。これは公的資料の規定ではなく、ここまでの原則を日常運用へ落としたCONTEXT編集部の型である。

• 次の二〜三本は、出典、画像、確認者まで揃っているか。
• 同じ読者の問い、同じ答えの記事が並んでいないか。
• どの企画が誰の何待ちで、期限と代替案があるか。
• backlogから次に一つだけ進めるなら、何が最も読者価値を増やすか。
• 更新、リンク修正、訂正へ使う枠が残っているか。

この会議で「全部急ぐ」とは決めない。企画差分が弱ければ統合する。根拠や権利確認が間に合わなければ延期する。既存記事で答えられると分かれば、新規企画を更新へ変える。日付を守るために品質条件を外さない。

完成したカレンダーは、華やかな年間表でなくてよい。読者の問い、既存記事、今回の差分があり、必要な確認とownerが見え、最短公開日と見直し日が分かれば機能する。日付はその結果として置かれる。

最初の改善は、いまの表へ列を一つ足すことではない。次の十企画を並べ、「同じ読者へ同じ答えを返していないか」を確認する。重なりがあれば更新か統合へ移し、残った企画だけに制作条件と日付を与える。編集カレンダーは、公開本数を埋める表から、媒体の答えを増やす判断表へ変わる。