専門の開発者でなくても、
Web サイトを運用できるか

当社の更新が通る経路です。担当者が意識しているのは、左端の編集と、右から二番目のプレビュー確認だけで済むようにしています。

図は横にスクロールできます。

当社が仕組み側に寄せた項目です。覚えることを減らすほど、更新の心理的な負担が下がりました。

1. 01

   リンク切れと必須項目の抜けは、公開前に自動で落とす

   掲載内容に必要な項目が埋まっているか、リンク先が実在するか、題名や説明文が重複していないかを機械が検査します。担当者が一覧を目で追う必要はありません。

2. 02

   本番に出る前に、必ず実物が見られる

   変更を上げると、本番とは別の場所に同じものが公開されます。担当者は、そこで実際の画面を見てから公開の判断をします。想像で確認する工程をなくしました。

3. 03

   自動生成されるファイルのずれを、公開の直前で止める

   サイトの一覧や参照用のファイルは、掲載内容から自動生成されます。生成し直した結果と記録が食い違っていれば、その時点で公開を止めます。「生成し忘れ」を人が覚えておく必要がなくなりました。

4. 04

   知らない URL は、そのまま「見つかりません」として返す

   存在しない URL にアクセスされたとき、無理に何かを表示せず、見つからないことをそのまま返す構成にしています。担当者がページを移動・削除したときに、中途半端な状態が残りにくくなります。

仕組みを作る前に決めた項目です。順番を逆にすると、あとから作り直すことになります。

1. Step 01

   触ってよい範囲を決める

   どこまでを担当者が変更してよいのかを先に決めました。文章と画像の差し替えは担当者、構造や公開の仕組みに関わる部分は別、という切り分けです。範囲が決まると、必要な確認の内容も決まります。

2. Step 02

   公開の判断を誰が行うか決める

   検証が通ったからといって自動で公開されるのではなく、公開してよいかを人が判断する場所を残しました。内容の妥当性は機械には判断できないためです。

3. Step 03

   書き方の基準を文書にする

   何を書いてよく、何を書かないのかを文書にしました。表現の統一より、公開してよい情報かどうかの基準を優先しています。判断に迷ったときに戻れる場所を作るためです。

4. Step 04

   戻し方を先に確認する

   公開したあとに問題が見つかったとき、どう戻すのかを先に確認しました。戻し方が分かっていると、更新の判断が速くなります。

当社が分けている基準です。判定が一つに決まるものは、なるべく仕組みへ寄せています。

当社が実際に用意した項目です。仕組みだけでは足りず、決めごとが必要でした。

仕組みが整っていても、更新に使える時間が業務の中に確保されていなければ更新は止まります。ここは仕組みでは解決できませんでした。