お客さまもHTML・CSSを更新するサイトで、編集範囲をどう設計するか

HTMLやCSSを編集できる担当者がいることと、その運用が何年も続けられることは同じではありません。最初に、更新する人、内容、頻度、担当交代の可能性を確認します。

• 誰が更新し、どの程度HTMLとCSSを扱えるか
• 新しいページを作るのか、既存情報だけを差し替えるのか
• 更新頻度と、一度に追加するページ数
• 担当者が替わったときに引き継げるか
• 承認や公開前確認を誰が行うか
• CMSの方が安全な更新内容ではないか

商品や事例のように同じ形を繰り返すなら、CMSへ入力する方が向く場合があります。一方、更新回数が少なく、担当者がコードを管理できるなら、静的なテンプレートが扱いやすい場合もあります。方式を先に決めず、運用する人から選びます。

「自由に編集してください」では、変更してよい場所が分かりません。私たちは、納品物を次の四つに分けて考えます。

1. 文言、画像、リンクなど、お客さまが日常的に変更する場所
2. 複製して使うページや部品のテンプレート
3. ヘッダー、ナビゲーション、共通CSSなど、全体へ影響する場所
4. 構造変更や新機能など、制作会社へ相談して進める変更

この区分は、編集を制限するためではありません。担当者が迷わず触れて、変更後の影響を予測できるようにするための境界です。

きれいなサンプルが一件表示できても、運用に耐えられるとは限りません。納品前には、更新時に起こりそうな変化を入れて確認します。

• タイトルや本文が想定より長い
• 画像がない、または縦横比が異なる
• 項目数が一件から十件へ増える
• 一部の項目だけを非表示にする
• 新しい見出しや表を追加する
• 日本語以外の原稿を入れる
• スマートフォンで改行や並び順が変わる

実際に複製し、文字や画像を入れ替えたときに初めて、説明が必要な場所や壊れやすい構造が見えてきます。

直接編集で怖いのは、あるページを直したつもりが、別のページまで変わることです。共通CSSとページ固有CSSを分け、クラス名とファイルの置き場所から影響範囲を読み取れるようにします。

広い要素へ一括で指定するより、部品やページの役割が分かる単位で指定します。既存ルールを上書きするだけの追記を重ねず、どのファイルが最新版か、どこへ追加するかも決めます。制作側だけが理解できる命名では、担当交代のたびに説明が必要になるためです。

お客さま側と制作会社側がそれぞれファイルを持ち、別々に変更すると、どちらが最新版か分からなくなります。公開中のデータ、編集元、確認用データの役割を決め、変更を戻す場所を一つにします。

• 日常更新の正本はどこか
• 制作会社が改修するとき、最新データをどこから受け取るか
• 変更履歴と公開日をどこへ残すか
• 同時編集を避ける連絡方法
• 公開前に戻せるバックアップをどう取るか

ルールは大がかりな管理システムでなくても構いません。ただし、「たぶんこちらが新しい」という状態では、安全に改修を再開できません。

ソース一式と操作説明だけでなく、更新時に判断できる材料を渡します。

• 編集元と公開用ファイルの構成
• 複製して使えるテンプレートと入力例
• 画像サイズ、ファイル名、保存先のルール
• 共通部品とページ固有部品の区分
• 変更後に確認するページと画面幅
• 制作会社へ相談する変更の目安
• 公開と復旧の手順

分厚い手順書を作ることが目的ではありません。更新担当者が「これは自分で直せる」「ここから先は確認しよう」と判断できることが重要です。

共通CSSや部品を触った場合は、変更したページに加えて、同じ部品を使う代表ページも確認します。パソコンとスマートフォン、リンク、フォーム、画像の読み込み、公開先のソースまで見ます。

お客さま自身が更新できることは、大きな利点です。ただし、自由度だけを渡すと、事故が起きたときの責任範囲まで曖昧になります。更新できる範囲と確認方法を一緒に設計することで、直接編集は初めて継続できる運用になります。