保守契約のある客先が二十社あるとして、月末に二十通のメールを書く。「料金ページの記載に変更はございませんか」「採用情報は引き続き募集中でよろしいでしょうか」「特定商取引法通信販売などで事業者名・所在地・返品条件などの表示を義務づける法律。ネットで物やサービスを売るサイトには「特定商取引法に基づく表記」のページが要る。の表記に変わった点はありませんか」。返事が来る先もあれば、来ない先もある。来ない先には翌月また同じ文面を送り、来た先の「変更ありません」はメールボックスの中に埋もれ、担当が替わるとそのスレッドごと見えなくなる。
保守をやっている会社なら、多かれ少なかれこの作業を抱えているはずです。この記事は、それをメールの往復ではなく、客先のWordPressの中に置く話です。
保守プランの中に「内容の確認」は入っていない
公開されている保守サービスの内容を見比べると、標準に入っているのは本体・プラグインの更新、死活監視、バックアップ、セキュリティ対策あたりで、ページの更新やコンテンツの修正は個別見積や別料金にしている会社が多い。範囲が読めない作業を月額に含めない、という設計で、これ自体は合理的だと思います。
ただ、その線引きだと「まだ合っていますか」と聞いて回る作業は、どちらの側にも入りません。更新ではないし、監視でもない。契約に無い作業なので、やる会社は善意でやり、やらない会社は言われるまで動かない。やらないほうを責めにくいのは、客側もその作業に対価を払っていないからです。
結果として、客先サイトの古い情報は宙に浮きます。制作会社は「変更のご連絡をいただいていない」、客側は「見てくれていると思っていた」。どちらも嘘ではなく、間に「誰がいつ聞くか」が無いだけ。ここを埋めているのが月末のメールで、その弱さは冒頭のとおり。
確認依頼を、メールではなくページの中に持たせる
やることは単純で、客先サイトの中で確認が要るページ（またはページの一部分）ごとに、次にいつ確認するか、誰が確認するか、誰がその返事を受けるかを決めて、そこに置く。期限が近づいたら本人に通知が届き、返事はそのページの管理対象に確認結果として残る。コンテンツ更新管理はこの形をWordPressプラグインとして実装したもので、以下はその前提で書きます。
管理の単位はページ全体でなくてもよく、料金表や営業時間のような一部分だけを「コンテンツ更新管理セクション」ブロックで囲んで、そこにだけ期限を持たせられます。客先サイトで古くなるのはたいてい一部分なので、この使い方のほうが多くなりそうです。記事の一部分にだけ期限をつける話は別に書きました。
誰が確認して、誰が返事を受けるか
管理対象には担当者（必須）と承認者（任意）を置けます。制作会社の運用で考えると、配置は二通りです。
客側が確認し、制作会社が受け取る。 客側の担当者を「担当者」に、制作会社の担当を「承認者」にする。期限前の通知は客側に届き、客側がページを見て「内容を更新した」「変更不要」「対応対象外」のいずれかを登録する。それが制作会社側への依頼として届き、制作会社が受け取って閉じる。客側が自分でページを直せる（ブロックエディタで料金表を書き換えられる）ケースはこちらが自然です。
制作会社が確認し、客側が合意する。 逆に制作会社を「担当者」、客側を「承認者」にする。期限が来たら制作会社が客先に問い合わせて直し、確認結果を登録すると客側に返事の依頼が届く。客側が「合っている」と押して完了。客側が合っていると言った事実がページの中に残るのはこちらで、実務ではこの配置のほうが多いだろうと見ています。
どちらの配置でも、担当者と承認者に指名できるのは、そのページを編集できるユーザーだけです。作っている側の判断として、確認作業の画面には本文やフィールドの値をそのまま出すので、編集権限の無い人を指名できてしまうと「担当なのに開けない」ができる。それを避けるために割り当ての側で条件を課しました。だから客側ユーザーには、対象のページを編集できるロールを与えておく必要があります。投稿者ロールでは他人の投稿や固定ページを担当できないので、客先の固定ページを任せるなら編集者以上か、権限を個別に付けることになる。同じ人が担当者と承認者を兼ねることはできません。自分の返事を自分で受けることになるので。
三つ目の役割としてエスカレーション先があります。返事が無いまま期限超過が続いたときの通知先で、こちらは権限を問いません。客側の上長でも自社の営業担当でも、WordPressのユーザーであれば置ける（購読者ロールだけは候補から外れます）。確認しない人こそ宛先になる、という運用を想定しています。
返事が来ないときに、止まらないようにする
メール運用でいちばん困るのは、返事が来ないことです。ここは通知の段階で補います。期限前は「7日前・1日前」のように複数の日数で送り、期限を過ぎたあとも「1日・3日・7日」のように段階で送れる。それでも動かなければエスカレーション先へ。1通のメールを見落とされて終わり、にはなりにくい。
もう一つ、指名は通知の宛先であって、操作の鍵ではありません。確認を実行できる権限を持ち、そのページを開けるユーザーであれば、担当者でなくても対応を進められる。客側が音信不通のまま期限だけ過ぎていくとき、制作会社側が代わりに確認結果を登録して先へ進めることはできます。その場合も履歴には実行したユーザーが残るので、「客側が答えた」ことにはなりません。区別が付く形にしてあります。
Chatworkの客先ルームに流す
制作会社の連絡がChatworkに寄っているなら、通知もそこへ流せます。Chatworkの接続はAPIトークンとルームIDの組で、複数登録できるので、客先ごとのルームを一つずつ登録し、管理対象ごとにどのルームへ送るかを選ぶ形。ルームには期限前・超過・依頼・完了といった通知が流れ、プロフィールにChatworkのアカウントIDを登録している人にはメンションが付きます。メールだけでも動くので、Chatworkは客先の都合で選べばよい。
客先ルームに流すうえで一つ大事なのは、チャンネル宛の通知には投稿本文の抜粋・フィールドの値・確認メモを載せない仕様になっていることです。載るのは通知の種別、管理対象名、ページのタイトル、期限、担当者、確認画面へのリンクといった管理情報だけ。社内向けに書いた確認メモは個人宛のメールにしか入りません。共有ルームに社内の注意書きが流れる事故は、仕様の側で起きないようにしてあります。
履歴が「聞いた・答えた」の記録になる
管理対象ごとの履歴には、通知を送ったこと（どのチャンネルで、担当者宛か承認者宛か、どのアドレスやルームへ）、確認結果が登録されたこと、受け取って閉じたこと、差し戻したこと（理由つき）が、実行日時と実行ユーザーとともに並びます。「先月の何日に客側担当者宛に期限前通知が届き、何日に『変更不要』が登録され、何日にこちらが閉じた」がページごとに読める。
通知の宛先の役割を、表示のたびに現在の担当者から推定するのではなく送信時点で記録しているのは、担当者を後で替えたときに過去の履歴の意味が変わらないようにするためです。客先の担当者が異動して指名を替えても、去年の通知が「当時の担当者宛」だったことは変わらない。履歴は通常の操作では編集も削除もできず、消えるのは保持期間の経過とアンインストールのときだけ。
これを契約上の証拠と呼ぶつもりはありません。ただ、「聞いた・聞いていない」「答えた・答えていない」がメールボックスの外、そのページの中に残っている状態は、保守の範囲を話し合うときの土台になります。確認のやりとりが何回あり、何回が修正につながったかが見えれば、コンテンツ更新を別料金にするにしても根拠のある見積になる——というのは想定の使い方で、実績があるわけではありません。
客側の人には、自分の分だけが見える
客側ユーザーがログインしたときに、制作会社の内部管理まで全部見えるのは避けたいところです。管理対象の一覧に全件が出るのは、管理対象全体を管理する権限を持つ人か、他人の投稿を編集できる人（既定では管理者・編集者）。それ以外の人には、自分が担当者・承認者・エスカレーション先に指名されている行と、自分が作成した投稿の行だけが出ます。加えて「自分の担当」という画面があり、本日期限・期限接近・期限超過・承認待ち・差し戻し・対応完了の区分で自分の分だけが並ぶ。客側の人にはこの画面を案内しておけば十分でしょう。
一つ注意があって、担当者にはそのページを編集できる権限が要るので、客側ユーザーを編集者にした場合は一覧に全件が見えます。客先サイトには客先のページしか無いので、困る場面は少ないはずです。
制作会社側から見ると、客先ごとに月末のメールを書く仕事が、通知と履歴に置き換わります。全体像は公開後の確認を回す仕組みの全体像にまとめてあり、製品ページは コンテンツ更新管理 にあります。
