HTMLとCSSで作ったサイトを納品し、その後はお客さま自身がページを増やしていく。そう聞くと、更新しやすいテンプレートを用意すれば終わるように見えます。けれど実際には、納品後に誰がどこまで触るのかを決めないままでは、少しの変更がサイト全体へ広がります。
私たちの反省会でも、制作途中でテンプレートやCSSの構造が変わったこと、更新担当者の経験を十分に確認できていなかったこと、引き渡す範囲の説明が足りなかったことが残りました。表示が完成していても、更新の境界が曖昧なら、運用できるサイトを渡したとは言い切れません。
そこで、直接編集を前提にする案件では「自由に触れること」だけを目標にしません。お客さまが安全に変えられる場所、共通ルールとして守る場所、制作会社へ戻す変更を先に分けます。
まず、直接編集が本当に向いているかを決める
HTMLやCSSを編集できる担当者がいることと、その運用が何年も続けられることは同じではありません。最初に、更新する人、内容、頻度、担当交代の可能性を確認します。
- 誰が更新し、どの程度HTMLとCSSを扱えるか
- 新しいページを作るのか、既存情報だけを差し替えるのか
- 更新頻度と、一度に追加するページ数
- 担当者が替わったときに引き継げるか
- 承認や公開前確認を誰が行うか
- CMSの方が安全な更新内容ではないか
商品や事例のように同じ形を繰り返すなら、CMSへ入力する方が向く場合があります。一方、更新回数が少なく、担当者がコードを管理できるなら、静的なテンプレートが扱いやすい場合もあります。方式を先に決めず、運用する人から選びます。
編集範囲を四つに分ける
「自由に編集してください」では、変更してよい場所が分かりません。私たちは、納品物を次の四つに分けて考えます。
- 文言、画像、リンクなど、お客さまが日常的に変更する場所
- 複製して使うページや部品のテンプレート
- ヘッダー、ナビゲーション、共通CSSなど、全体へ影響する場所
- 構造変更や新機能など、制作会社へ相談して進める変更
この区分は、編集を制限するためではありません。担当者が迷わず触れて、変更後の影響を予測できるようにするための境界です。
空のテンプレートではなく、実際の変化で試す
きれいなサンプルが一件表示できても、運用に耐えられるとは限りません。納品前には、更新時に起こりそうな変化を入れて確認します。
- タイトルや本文が想定より長い
- 画像がない、または縦横比が異なる
- 項目数が一件から十件へ増える
- 一部の項目だけを非表示にする
- 新しい見出しや表を追加する
- 日本語以外の原稿を入れる
- スマートフォンで改行や並び順が変わる
実際に複製し、文字や画像を入れ替えたときに初めて、説明が必要な場所や壊れやすい構造が見えてきます。
CSSは、変更の届く範囲が分かる形にする
直接編集で怖いのは、あるページを直したつもりが、別のページまで変わることです。共通CSSとページ固有CSSを分け、クラス名とファイルの置き場所から影響範囲を読み取れるようにします。
広い要素へ一括で指定するより、部品やページの役割が分かる単位で指定します。既存ルールを上書きするだけの追記を重ねず、どのファイルが最新版か、どこへ追加するかも決めます。制作側だけが理解できる命名では、担当交代のたびに説明が必要になるためです。
最新版を二つ作らない
お客さま側と制作会社側がそれぞれファイルを持ち、別々に変更すると、どちらが最新版か分からなくなります。公開中のデータ、編集元、確認用データの役割を決め、変更を戻す場所を一つにします。
- 日常更新の正本はどこか
- 制作会社が改修するとき、最新データをどこから受け取るか
- 変更履歴と公開日をどこへ残すか
- 同時編集を避ける連絡方法
- 公開前に戻せるバックアップをどう取るか
ルールは大がかりな管理システムでなくても構いません。ただし、「たぶんこちらが新しい」という状態では、安全に改修を再開できません。
納品物に、更新判断まで含める
ソース一式と操作説明だけでなく、更新時に判断できる材料を渡します。
- 編集元と公開用ファイルの構成
- 複製して使えるテンプレートと入力例
- 画像サイズ、ファイル名、保存先のルール
- 共通部品とページ固有部品の区分
- 変更後に確認するページと画面幅
- 制作会社へ相談する変更の目安
- 公開と復旧の手順
分厚い手順書を作ることが目的ではありません。更新担当者が「これは自分で直せる」「ここから先は確認しよう」と判断できることが重要です。
更新後は、変更したページだけを見ない
共通CSSや部品を触った場合は、変更したページに加えて、同じ部品を使う代表ページも確認します。パソコンとスマートフォン、リンク、フォーム、画像の読み込み、公開先のソースまで見ます。
お客さま自身が更新できることは、大きな利点です。ただし、自由度だけを渡すと、事故が起きたときの責任範囲まで曖昧になります。更新できる範囲と確認方法を一緒に設計することで、直接編集は初めて継続できる運用になります。
直接編集が向く条件、別の方法を考える条件
直接編集が向く条件
- 更新担当者と技術水準が明確
- 更新回数とページの型が限られている
- ファイル管理と公開確認を継続できる
- 共通部へ触れずに日常更新を完結できる
CMSや保守運用を考える条件
- 複数人が頻繁に更新する
- 担当者が替わりやすい
- 承認、予約公開、履歴管理が必要
- ページの種類や件数が増え続ける
- コードを触らずに品質を揃えたい
引き渡し前のチェックリスト
- 更新担当者と更新内容を確認したか
- 直接編集を選ぶ理由が運用に合っているか
- 触ってよい場所と共通部を分けたか
- 実際の原稿量、画像差、件数差で試したか
- CSSの影響範囲をファイルと命名から判断できるか
- 編集元と公開版の正本を決めたか
- 制作会社が再改修するときの受け渡し方法があるか
- 変更後の確認ページと端末を決めたか
- バックアップと復旧手順を確認したか
- 担当交代後も読める説明を残したか
