更新の管理表をWordPressへ移行する：スプレッドシートの列を、どこに置き換えるか

管理表はもう手元にある、という前提から書きます。シートの名前は「記事管理」か「コンテンツ一覧」か、そのあたり。列はページ名、URL、担当、次回見直し、状態、備考——サイトが違っても、だいたい似た形に落ち着きます。これをWordPressの側へ移すとき、先に決めるのは移す列ではなく、移さない列のほうです。

運ぶのは3つです。どのページか、誰が見るか、次はいつか。この3つが投稿の側に載れば、表を開かなくても期限のほうから来るようになる。残りの列は表に置いたままで構いません。表がなぜ続かないのかという話は、ここではしません。扱うのは、どの列がどこへ行くかだけです。

全部の列を移そうとすると、移行のほうが先に止まる

数か月続いた管理表は、たいてい列が増えています。公開日、対策キーワード、月間の表示回数、リライト方針、担当、次回見直し、状態、備考。この全部に移し先を探すと、移行はそこで止まる。表示回数や順位のような数字の列には、更新期限を管理する側に置き場がありません。無理に持たせるより、その列は表に残すと決めたほうが早い。

移し先があるのは、更新の期限と担当に関わる列だけです。コンテンツ更新管理というプラグインで管理対象に持たせられるのは、管理対象名・担当者・承認者・エスカレーション先・次回確認日・更新頻度・重要度・確認メモ・参照URL・通知の設定・期限切れ処理。裏を返せば、それ以外の列はここには入りません。

表が続かなくなる理由そのものは管理表が続かなくなる構造の話に書いたので、繰り返しません。あちらが「なぜ止まるか」で、この記事は「では何をどこへ移すか」。移行の目的は表を立派にすることではなく、期限と担当を「更新する人が開く場所」へ移すことなので、移すのは3列で足ります。

表の列と、WordPress側で対応するもの

具体的に何がどこへ行くのか、列ごとに並べます。

表の列	移す先	移すときの注意
ページ名・タイトル	管理対象名	未入力なら投稿タイトルが初期値で入る。写さなくても困らない列
URL	移し先なし（列が消える）	管理対象は投稿そのものに紐づくので、URLを書いておく必要がなくなる
担当	担当者（必須）	WordPressユーザーを1人。部署名・チーム名では持てない
確認者・チェック者	承認者（任意）	担当者との兼任は保存できない
次回見直し日	次回確認日（必須）	日付そのもの
更新周期	更新頻度	1〜999 × 日・週・月・年、または「なし」
優先度・重要度	重要度	低・中・高・重大の4段階に丸める
状態・ステータス	期限状態 ＋ 運用ステータス	1列が2つに割れる（次節）
最終確認日	最終確認日	確認を完了した時点で入る。人が書き込む欄ではない
備考・確認内容	確認メモ	メール通知にだけ載る。Slack・Chatworkへは送られない
参考リンク	参照URL	確認するときに開く外部URL
更新履歴シート	履歴	17種の操作が管理対象ごとに残る

URLの列が消えるところが、移行の効き目を一番わかりやすく表しています。表では「どのページの話か」を人がURLで指し示す必要がありましたが、管理対象は投稿の中にあるので、指し示す作業ごと消える。

「状態」の列だけは、2つに割れる

移行でいちばん引っかかるのが状態の列です。表の状態列には、「未着手」「確認中」「期限切れ」「完了」あたりが混ざって入っていることが多い。ところが、このうち「期限切れ」だけは種類が違います。日付が過ぎたという事実であって、人がまだ何もしていないという事実ではない。

そこで、日付から決まる側と人の操作で動く側を分けてあります。

期限を過ぎても運用ステータスは自動では進みません。期限超過になった行は、未対応なら未対応のまま、確認中なら確認中のまま。表の状態列ではこの2つが同じセルに同居していたので、期限切れの行を見ても、放置されているのか担当者が確認中で期限だけ過ぎたのか、塗った色からは分かりませんでした。移行すると、それが別々の列として並びます。

もう一つ、表では表現しづらかった区別も入ります。最終更新日と最終確認日は別物だという話です。「見たが変えなかった」記事は更新日が動かないので、表の上では放置と同じ顔になる。移行先では確認結果として「確認したが変更不要」が残り、そこから次の期限が立つ。加えて、前回の確認以降に本文やタイトルが変わったかどうかも一覧の列として出ます。

担当の列は、そのままの名前では写せないことがある

表の担当欄には何でも書けます。「営業部」でも「制作チーム」でも「田中（兼務）」でも通る。移し先の担当者はWordPressユーザーの単一選択なので、部署やチームという単位は持てません。まずここで一度、名前を人に割り直すことになります。

指名には条件もあります。担当者にできるのは「確認を実行」権限を持ち、その投稿を編集できるユーザーだけです。

なので移行の下ごしらえは、列を写す前に人の側から始まります。表の担当欄に並んでいる名前が、WordPressのユーザーとして実在するか。そのロールで対象の投稿タイプを編集できるか。「営業部」の行が3人に割れて、そのうち1人はロールを上げないと固定ページを担当できない——ここが済んでいないと、まとめて付けようとしたときに条件を満たさない行だけが落ちます。作っている側の話をすると、そういう行は成功件数に数えず、「対象の投稿を編集できないため◯件をスキップしました」と理由つきで返すようにしてあります。20行選んで3行落ちたことに気づけないのがいちばん困るので。

3列を1行ずつ写さない。条件に配らせる

ここまで読んで、300行の表を手で写す絵を思い浮かべた人もいるはずです。表のファイルを読み込ませて一括登録する経路は用意していないので、移す作業そのものは手で行います。ただし1行ずつではありません。

移し方は、投稿タイプとカテゴリの条件に担当者・更新頻度・重要度・通知を持たせて、条件に合う投稿へまとめて配る形になります。表を眺めると、担当と周期は行ごとにばらばらではなく、「導入事例は営業の誰それが半年ごと」「料金ページは管理部が3か月ごと」のようにカテゴリで説明できる塊に分かれているはず。塊の数だけルールを作れば、行ごとの入力は要りません。

既存の投稿へ当てるときは、実行前に件数が3つ出ます。条件に一致する投稿数、そのうち既に管理対象がある数、今回作成・更新される数。移行でこの画面を見る意味はほぼ1つで、1つめの数字が表の行数と合っているか。合っていなければ、ルールの条件が表の分け方と食い違っているということです。流す前に条件を直す。既存の行をどう扱うか（スキップ・補完・上書き）や、バッチがどう進むかは運用ルールで担当者と更新頻度を配る記事のほうに書いたので、実行の段になったらそちらを開いてください。

一点だけ、日付の扱いに注意が要ります。ルールで配ると次回確認日は「適用した日 + 更新頻度」で入るので、表に書いてあった個別の見直し日は引き継がれません。日付まで移したい行があるなら、配ったあとに一覧の一括操作で次回確認日を入れ直すほうが早い。全件を同じ日に配ると次の期限も同じ日に集まるので、カテゴリごとに実行日をずらすくらいの手当てはしておくといいでしょう。

向きとしては、先にルールで配って、あとから表と突き合わせて例外の行だけ直す。この向きなら、手で触るのは例外のぶんだけで済みます。

移し終わった表に残るのは、更新期限ではない列

移行が済んだあと、表を消す必要はありません。残るのは表示回数、対策キーワード、リライト方針といった、更新管理ではなく編集計画のための列です。この列は投稿の側に置く相手がいないので、表にあるのが正しい。

消えるのは、更新のたびに人が手で同期していた列のほう。担当と次回見直し日は投稿の側にあり、確認したかどうかは確認結果として残り、誰がいつ何をしたかは履歴に積まれます。表を開いて色を塗り直す作業がなくなる。

そして一覧の意味が反転します。管理対象の一覧は12列あって、9軸で絞り込め、既定では期限超過が先、次に期限の早い順、その中で重要度の高い順に並びます。自分が担当している分だけを集めた画面と、期限や承認待ちの件数をまとめたダッシュボードもある。表で条件付き書式を組んで作っていた「期限が近い行の色」は、絞り込みの結果として出てくるものになります。人が書き込む入力先ではなく、投稿側に持たせた期限と担当と確認結果の出力。出力なので、表と実物のあいだで起きていた種類のずれは起きません。

表の更新履歴シートに当たるものは管理対象ごとの履歴へ移ります。ただし改ざんできない証跡ではありません。保持期間を過ぎた分は消えます。

移行が終わったかどうかの判定は、シンプルです。表を1か月開かないでいて、期限の話が回ったかどうか。回っていれば移行は済んでいます。回らなかったのなら、まだ表に何か残っている。何を投稿の側に持たせるかの全体像は更新期限と担当者をWordPressの中で管理する記事に書きました。

製品ページは コンテンツ更新管理 にあります。