公開しているページを定期的に見直す運用を始めると、「確認しました」の一言をどこまで信用するか、という問題が出てきます。担当者が見て問題ないと言った。それで完了にしていいのか、もう1人が目を通すべきなのか。
結論から書くと、公開後の確認に承認は常に要るわけではありません。確認する人と、その内容に責任を持つ人が同じなら要らない。別なら要る。コンテンツ更新管理では、その判断を管理対象ごとに「承認者を置くか置かないか」で決めます。置かなければ担当者が確認結果を登録した時点で完了、置けば承認者が承認するまで完了にならない。この記事は、置いた場合に何が起きるかの話です。
先に線を引いておくと、ここで言う承認は公開前の承認ではありません。下書きをレビューして公開の可否を決めるフローはPublishPressのような編集フロー系プラグインの領分で、コンテンツ更新管理はそこに手を出しません。扱うのは、すでに公開されているページを定期的に見直したときの「見ました・直しました」に、もう1人の目を通す流れです。料金表を担当者が確認したあと、責任者が「これで合っている」と言うまで完了にしない。そういう用途です。期限と担当者を持たせる全体の枠組みは柱の記事にまとめてあります。
未対応から完了までは、人が押さないと動かない
運用ステータスは8つあり、遷移は次のとおりです。
| いまの状態 | 操作 | 次の状態 |
|---|---|---|
| 未対応 | 「対応開始」 | 確認中 |
| 確認中 | 「修正開始」 | 修正中 |
| 確認中／修正中 | 確認結果を登録（承認者なし） | 完了 |
| 確認中／修正中 | 確認結果を登録（承認者あり） | 承認待ち |
| 承認待ち | 承認者が承認 | 完了 |
| 承認待ち | 承認者が理由を書いて差し戻し | 差し戻し |
| 承認待ち | 取り下げ／対象の内容が変わった | 修正中 |
| 差し戻し | 担当者が「対応再開」 | 修正中 |
| 完了 | 次回確認日が期限接近の圏内に入る | 未対応（新しいサイクル） |
期限の状態（期限前・接近・当日・超過）とは別の情報で、次回確認日を過ぎて「期限超過」になっても運用ステータスは勝手に動きません。「対応開始」を押して初めて確認中になる。投稿を編集しただけでも動きません。「修正開始」を押すか、承認待ち中に中身が変わったときだけ（これは後述）。
操作はすべて管理対象の詳細画面（確認作業画面）で行います。投稿でもブロックでもACFAdvanced Custom Fields。投稿に独自の入力欄（カスタムフィールド）を追加するプラグインの定番。無料版と有料のPro版がある。フィールドでも同じ画面、同じ操作。承認者に指名されている人には承認依頼の通知が届き、そのリンクからこの画面へ来ます。
完了は3種類。「見たけど変えなかった」も完了
確認結果は3つから選びます。「内容を更新した」「確認したが変更不要」「対応対象外」。承認者がいる場合、承認者はこの選択を変えられません。担当者が「変更不要」で出したものを承認すれば「完了・変更なし」になる。承認者の仕事は結果を書き換えることではなく、担当者の結果を通すか差し戻すかです。
「対応対象外」にも同じ承認フローが適用されます。「このブロックはもう管理しなくていい」という判断も、承認者がいるなら承認を通す。完了・対象外になっても管理は続き、管理を終えるのは「無効化」という別の操作です。
確認結果と一緒に、承認者へのメッセージ（確認コメント）と参照URLを書けます。「料金は営業部の最新資料と突き合わせた」の一言があるかどうかで、承認者が管理画面で何を見ればいいかが変わる。
差し戻すには理由が要る
承認者が差し戻すとき、差し戻し理由は必須です。空では差し戻せません。理由は差し戻し通知の本文に載り、担当者は管理画面を開く前に何を直せばいいかが分かる。「理由の無い差し戻し通知は、管理画面を開かないと次の行動が決まらない」というのが、必須にした理由です。
差し戻された担当者は「対応再開」で修正中に戻り、直してからもう一度確認結果を登録します。承認は1段階だけで、承認者の上にさらに承認者を置く多段構成は組めません。担当者が確認して、責任者が承認して、その上の役員が最終承認、という3人体制が要るなら、この製品の外の話になります。
承認を待っている間に中身が変わったら、承認は無効になる
承認待ちの管理対象で、対象の内容が変わると、承認は無効になって修正中へ戻ります。これは人の操作ではなく、保存時の変更検出が起こす唯一の自動遷移で、履歴には実行ユーザー「システム」として残ります。
この仕様にしたのは、承認者が見た内容と、公開されている内容が違う状態を作らないためです。承認依頼を出したあとに担当者が「ついでに」一行直したら、承認者は直す前の内容を承認することになる。それなら承認をいったん無効にして、もう一度依頼してもらう方が安全だと考えました。何をもって「変わった」と見なすか（投稿の6項目、ブロックのシリアライズ、フィールドの値）は変更検出の記事に書いています。
承認待ちの間に次回確認日を過ぎることもあります。その場合、期限切れ処理（下書き・非公開・リダイレクトあるURLを開いたとき、別のURLへ自動で転送すること。ページを消す代わりに関連ページへ送ると、検索エンジンからの流入やブックマークを失いにくい。など）は承認待ちでも差し戻し中でも実行されます。承認が滞っている間もサイトの表示は守る、という優先順位です。
担当者と承認者は同じ人にできない
管理対象の設定で、担当者と承認者に同じユーザーを選ぶと保存できません。自分で確認したものを自分で承認する構成は、承認を置く意味が無いからです。エスカレーション先だけは担当者と同一でも警告つきで保存できますが、こちらは通知を受け取るだけの役割なので事情が違います。
承認者に指名できるのは、「承認を実行」の権限を持ち、かつその投稿を編集できるユーザーです。既定では管理者と編集者がこの権限を持ち、投稿者は持ちません。「編集できる人」に限っているのは、詳細画面が投稿本文やフィールドの値を表示するので、編集権限の無い人には見せられないためです。
ひとつ補足すると、指名は操作の前提ではありません。承認者に指名されていなくても、「承認を実行」の権限があってその投稿を開けるユーザーは代行で承認や差し戻しができます。担当者が決まっていない管理対象を誰も動かせない、を避けるための余地です。指名が決めるのは通知の宛先と「自分の担当」画面の絞り込みで、操作できるかどうかは権限側で判定する。担当者と承認者の兼任を割り当てで弾くのは、この余地とは別の話です。
承認されると何が起きるか
承認者がいる管理対象では、承認完了の時点が「確認完了」です。ここを起点に、次回確認日が承認完了日＋更新頻度で再計算され、非表示・代替メッセージ・リダイレクトの期限切れ処理が解除され、変更検出の基準値が保存されます。担当者が確認結果を登録した時点ではなく、承認が下りた時点。承認に3日かかれば、次回確認日も3日ずれます。
SlackやChatworkの中から承認することはできません。承認依頼の通知にはリンクが載り、承認は管理画面の詳細画面で押します。
製品ページは コンテンツ更新管理 にあります。
