COLUMN
サイト更新の確認作業の減らし方｜全ページを同じ重さで見るのをやめて、3段に分けた
サイトの更新を確認する手間は、確認する段を3つに分けると、毎回同じ重さで確認し続けるより、ずっと少ない手間で守れると私は考えている。
うちでは、毎回やる確認を5項目に絞り、第三者の承認を通すのは影響の大きい更新だけにしている。
残りの更新は公開後に履歴から戻せる状態にしておく。
この記事では、その3段の分け方と、コンテナの機能をどこに当てているかを書く。
全ページを同じ重さで確認すると、確認が形だけになる
更新ミスを減らしたくて、最初は「公開前に必ず全員で見る」というルールにしていた。
誤字を1文字直すだけの更新も、トップページのレイアウトを変える更新も、同じ承認待ちの列に並ぶ。
承認する側は、毎回同じ重さの確認を求められるので、だんだん流し読みになっていく。
本当に見てほしい大きな更新と、見なくても困らない小さな更新が、同じ「確認済み」の印で並んでしまうのが問題だった。
確認を厚くするほどミスが減るとは限らない。
確認の回数が増えると、人は「誰かが見ているはず」と考えて、自分の目を休ませる。
重い確認を全部に掛けるのをやめて、重さを更新の種類で変えたほうが、見るべき場所に目が残る。
1段目：更新した本人が、毎回5項目だけ確認する
1段目は、更新した本人が公開前に必ず通す短い確認だ。
項目は5つに絞っている。
タイトルと本文が意図どおり表示されること、リンク先が開くこと、画像が出ること、スマホ幅で崩れていないこと、公開日時が意図どおりであること。
これだけなら1ページあたり数分で終わる。
この5項目は、日々のお知らせ投稿で毎回やっている機械的な確認とほぼ同じ形だ。
私たちは記事を投入するたびに、件数が合っているか、本文が二重にエスケープされていないか、ページが正常に開くかを順に見ている。
手順が決まっているので、迷わないし、人によって見る場所がぶれない。
確認項目を増やしたくなったら、まず既存の5項目のどれかに足りない理由があるかを考える。
理由がなければ増やさない、と決めている。
公開日時を確認項目に入れているのには理由がある。
コンテナでは、公開開始日時が未来になっている記事は、公開ページで表示されない。
入力ミスで来月の日付を入れてしまうと、保存したのに画面に出ない、という状態になる。
この種のミスは本文を何度読み返しても見つからないので、日時の確認は項目として独立させた。
確認の順番も決めている。
最初に公開ページを開き、次にスマホ幅に切り替えて見て、最後にリンクを上から順にたどる。
編集画面のプレビューだけで済ませないのが大事で、実際に公開されたURLを開くと、キャッシュや公開日時の設定ミスがここで見つかる。
順番を固定すると、確認のたびに「何を見たか」を思い出さなくて済むので、疲れている日でも抜けが出にくい。
2段目：影響が大きい更新だけ、別の人に公開申請を出す
2段目は、別の人に見てもらう段階だ。
全部の更新に掛けず、影響が大きいものだけを対象にする。
トップページ、料金や申込に近いページ、共通パーツ（ヘッダーやフッター）を触る更新がこれに当たる。
共通パーツは1か所の変更が全ページに波及するので、1段目の5項目だけでは見落としが出やすい。
コンテナには、この段のために編集ロックと公開申請フローがある。
担当者が「公開申請」を出すと、承認者に通知が届き、承認か差し戻しを選べる。
申請・差し戻し・承認のステータスは一覧で見られるので、「あの申請は誰の手元で止まっているのか」を探し回らなくて済む。
編集ロックは、同じページを2人が同時に開いて、後から保存した側が先の変更を消してしまう事故を防ぐ。
上書き事故は、運営していて実際に起きたことがある。
別系統のサイトの話だが、保守作業で35ページが別のページの内容で上書きされたことがあった。
原因は人の注意不足というより、「誰がどのページを触っているか」が見えない作りだった。
編集ロックの機能は、注意力に頼らずに事故の入口を塞ぐために入れたものだ。
3段目：公開後は、履歴から1件だけ戻せるようにしておく
3段目は、確認ではなく「戻せること」で守る段階だ。
どれだけ確認しても、公開してから気づく間違いはゼロにならない。
だから、間違いに気づいたときの戻し方を先に用意しておく。
コンテナのリビジョン履歴は、投稿と固定ページの保存ごとに内容を版として自動で残す。
誰がいつ変えたかも一緒に残るので、気づいた時点で前の版を開いて、その1ページだけを戻せる。
サイト全体を元に戻す必要はない。
戻せると分かっていると、小さな更新に重い承認を付けなくても、安心して公開できる。
戻す操作そのものも、事前に練習しておく価値がある。
履歴の一覧から戻したい版を選び、内容を確認してから反映する、という流れを、本番ではなく落ち着いているときに一度通しておく。
手順を知らないまま初めて戻す場面を迎えると、焦って別の版を選んでしまうことがある。
練習で1回通していれば、本番でも落ち着いて1ページだけを戻せる。
この3段目があるから、1段目の確認を5項目で止められる。
確認を増やして不安を消すのではなく、戻せる状態を作って不安を小さくする。
私はこちらのほうが、運営チームの負担が軽く、長く続けやすいと思っている。
どの更新をどの段に振り分けるか
振り分けの基準は、「間違えたときに誰が困るか」と「戻すのにどれだけ手間がかかるか」の2つにしている。
お知らせの誤字や写真の差し替えのように、困る人が少なく、履歴から数十秒で戻せる更新は、1段目だけで公開する。
トップページや共通パーツのように、困る人が多く、戻すにも影響範囲の確認が要る更新は、2段目まで通す。
うちの振り分けは次のとおり。
- 誤字の修正・画像の差し替え・お知らせの追加：1段目（本人の5項目）だけで公開
- 記事の大幅な書き直し・新しいページの追加：1段目＋2段目（公開申請）
- トップページ・共通パーツ・URLが変わる更新：1段目＋2段目＋公開前に影響ページを突き合わせる
3つ目の「突き合わせ」は、先日サーバーを移したときに15ページを実際に開き、サイズまで比べた作業のことだ。
全ページに掛けると負担が大きいが、移行や共通パーツの変更のように一度に広く影響する更新だけに限れば、現実的な量で済む。
誰が何を確認したかは、あとから説明できる形で残す
段階を分けると、「この更新はなぜ承認を通さずに公開したのか」を後から聞かれることがある。
そのときに答えられるよう、操作の記録を残している。
コンテナの操作監査ログは、作成・更新・削除・公開といった管理画面の操作を自動で記録し、誰がいつ何を変更したかを一覧で追える。
基準を先に決めておけば、「あの更新は1段目だけで良い種類だった」と説明できる。
基準がないまま省くと、省いたことが単なる手抜きに見えてしまう。
何を毎回やり、何を条件つきでやるのかを文章にして、運用マニュアルに載せておく。
運用マニュアルは管理画面の中で公開記事と切り離して置けるので、担当が代わっても同じ線引きで動ける。
始めるときは、まず5項目を書き出すところから
自社のサイトに取り入れるなら、最初にやるのは、1段目の5項目を自分たちの言葉で書き出すことだ。
過去に実際に起きた更新ミスを3件ほど思い出して、それを公開前に防げた確認は何だったかを項目にする。
その次に、「必ず別の人に見てもらう更新」を3種類以内で決める。
種類を絞らないと、また全部が承認待ちになってしまう。
最後に、履歴から戻す手順を一度だけ試しておく。
実際に1ページを前の版へ戻してみると、必要な時間が分かり、2段目に回す更新の線引きも現実的になる。
確認を増やす前に、まず確認の重さを更新ごとに変える。
それだけで、運営チームの時間は思った以上に空く。