引き継ぎ資料に書けるのは、手順のあるものだけです。ログイン先、更新の操作手順、依頼が来たときの連絡経路。ここまでは一日で書き上がります。抜け落ちるのは、どのページを・いつまでに・誰が見るはずだったか——前任者の頭とカレンダーにしか無かった予定のほう。
更新の引き継ぎで本当に渡すものは手順ではなく、次回確認日と、その宛先に入っている名前です。これがWordPressの中にあれば、引き継ぎの実作業は「絞り込んで、まとめて付け替える」の二手で終わる。
以下はコンテンツ更新管理というプラグインを前提にした話で、退職の局面で効いてくる仕様と、手続きの順番を間違えたときに何が抜けるかを扱います。まだ出していない製品なので、どこかの会社でこう回りましたという報告ではありません。期限と担当者をサイトの中に持つ枠組みそのものは柱の記事に書きました。
抜けるのは「担当者」ではなく、宛先に入っていた1人のユーザー
このプラグインで管理対象に指定する担当者は、WordPressのユーザーから1人を選ぶ形です。必須項目で、部署や課、店舗といった単位では持てません。承認者を置く場合も同じくユーザー単位で、担当者との兼任は保存できない仕様。エスカレーション先だけは権限を問わず置けます。
部署で持てないことは弱点として書けなくもないのですが、引き継ぎの局面ではむしろ前提として効きます。人が抜けたときに、何が空いたのかが1対1で分かる。「営業部が確認することになっていたが、本当に見ていたのが誰かは分からない」という状態にはならない。代わりに、人が替わるたびに必ず付け替えが要る、というだけの話です。
だから退職が決まった時点で、前任者の名前が入っている管理対象が何件あるかを先に数えます。ダッシュボードには担当者別の件数が出ているので、そこで規模が分かる。20件なのか200件なのかで、引き継ぎの段取りは変わります。
アカウントを先に消すと、期限は残って宛先だけが消える
順番の事故が起きるのはここです。退職手続きの流れでWordPressのユーザーを削除すると、その人を担当者・承認者に指名していた管理対象は一覧に「ユーザー未設定」と出て、管理者へ警告が届きます。
消えるのは宛先だけで、期限も履歴も残ります。ただし通知は宛先を解決できないので、「送信先なし」として通知ログに1行残る。この行には再送ボタンが出ません。代わりに案内が出るだけ——同じ設定のまま押しても結果が変わらないからです。ダッシュボードにも設定不整合の警告として件数が上がります。
WordPress側の削除画面では、その人が書いた投稿を別のユーザーへ引き継ぐかどうかを選べます。ただし移るのは投稿の作成者で、管理対象の担当者はプラグイン側の別データなので付いてきません。「投稿は移したから大丈夫」と思ったところが、いちばん静かに落ちる場所。
通知が送れなくなっても投稿の保存や表示は止まらない設計です。壊れないぶん、気づくのは次の期限が来て誰にも届かなかったとき。付け替えを先、アカウント削除を後。順番はこれだけです。
付け替えは、絞り込んでから一括操作で
管理対象の一覧には9軸の絞り込みがあり、そのうちの1つが担当者です。前任者で絞ると、その人が持っていた行だけが並ぶ。既定の並びは期限超過が先、次に期限の早い順で、1ページ50件。
そこから一括操作で担当者を差し替えます。一括操作は8種あって、担当者・承認者・エスカレーション先・次回確認日・更新頻度・重要度・通知設定・無効化。引き継ぎで使うのは最初の3つと、後で触れる次回確認日です。
ここで詰まる場所が2つあります。
押せる人が限られる。 担当者・承認者・エスカレーション先の割り当て変更ができるのは「管理対象全体を管理」する権限を持つ人だけで、既定では管理者です。退職する本人が自分で付け替えて去る、という形は取れません。管理者を巻き込む段取りが要る。
後任が指名の条件を満たしていないことがある。 担当者に指名できるのは、確認を実行する権限を持ち、かつその投稿を編集できるユーザーだけです。作っている側の事情を書くと、後半の条件は途中から足しました。総合テストで、担当に指名されているのに管理対象を開けない行が実際に出たからです。確認作業の画面には投稿本文やフィールドの値がそのまま並ぶので、開けるかどうかは投稿の編集権限で判定している。割り当ての側に同じ条件が入っていないと、指名はできるのに開けない行が作れてしまう。帰結として、投稿者ロールの人は他人の投稿や固定ページを担当できません。後任のロールを先に整えてから付け替える順になります。
前任者が承認者だった行にも注意が要ります。担当者と承認者を同じ人に寄せる付け替えは保存できないので、二人体制が一人になる局面では、承認者を別の人に置くか外すかを決めることになる。
なお、付け替えが間に合わなくても確認そのものは止まりません。指名は通知の宛先と「自分の担当」の絞り込みを決めるもので、操作の鍵ではないからです。確認を実行できて対象を開ける人なら、担当者でなくても対応を進められます。
後任は、前任者のリズムを引き継いで始まる
付け替えが終わると、後任がログインしたときに「自分の担当」へ行が並びます。この画面の区分は6つ。本日期限・期限接近・期限超過・承認待ち・差し戻し・対応完了。引き継いだ初日に期限超過が何件出るかで、前任者の最後の数か月がだいたい見えます。
そして期限の日付そのものが厄介です。次回確認日は前任者が確認を終えた日を起点に計算されているので、後任にとっては意味の無い日付が並んでいる。しかも引き継ぎ直後は、業務そのものの立ち上げと重なります。
ここは一括操作で次回確認日を動かして散らします。全件を同じ日へ寄せるのではなく、重要度の高いものから順に確認できる位置へずらす。あとは1件ずつ確認を完了させれば、次回確認日はその完了日から計算し直されるので、2周目の期限は後任が実際に手を動かした日の並びになります。前任者の日付は残りません。
履歴の中の役割は、当時のままで動かない
抜けたあと、しばらくしてから「このページ、去年は誰が見ていたのか」を聞かれる場面が来ます。
管理対象ごとの履歴には、担当者を替えた操作も変更前と変更後の名前つきで残ります。前任者から後任へ、と1行。過去の通知に書かれた役割も送信時点で固定されているので、付け替えたあとで「当時は誰宛だったのか」が書き換わることはありません。そうしてある理由と、履歴がいつ消えるかは確認の記録を残す記事のほうに。
引き継ぎの局面でこれが効くのは、後任が責任の範囲を切れることです。前任者の在任中に確認が止まっていた期間があるなら、それは記録として残っている。後任が引き継いだ日から先の話と、それ以前の話を分けて説明できる。
次に誰かが抜けるまでにやっておくこと
退職や異動は一度きりの事故ではありません。次があります。備えて置いておけるものが2つ。
ひとつはエスカレーション先。担当者宛の通知とは別枠で、期限超過が続いたときに届く宛先です。権限を問わないので、上長でも他部署の責任者でも置ける。担当が空いている期間でも、上へは届きます。
もうひとつは、運用ルールへの誤解を先に解いておくこと。投稿タイプやカテゴリの条件で担当者や更新頻度を配る仕組みはありますが、これが配るのは初期値だけです。ルールの初期担当者を後任に書き換えても、すでに作られている管理対象は変わりません。引き継ぎは一括操作の側でやり、ルールは次に作られる投稿のために直す。両方やることになります。ルールが何を配って何を配らないかは運用ルールで担当者と更新頻度を配る記事にまとめました。
こうしておくと、引き継ぎ資料に書くことは1行に減ります。「更新の予定は管理画面にあり、担当者の付け替えは管理者が一括操作で行う」。どのページをいつ見るかを文書へ書き写す作業は、要らなくなる。渡すのは名前だけです。
製品ページは コンテンツ更新管理 にあります。
