運用前提のデザイン

想定する更新担当と役割

FHWが主に想定している更新担当は、社内のディレクターです。
ディレクターは、

• お客様側のWeb担当者との窓口となり
• 更新内容を整理し
• 実際の反映や指示を行う

という立場にあります。
そのため、「誰が触っても崩れない」ではなく、「ディレクターが判断しやすく、守りやすい構造」 を前提に設計します。

運用で崩れやすいポイント

運用フェーズで特に崩れやすいのは、次のような箇所です。

• 見出し階層（H2/H3の飛び）
• 画像サイズや比率のばらつき
• カード数の増減
• テキスト量の増減
• 改行・装飾の多用
• 意図しないHTML編集

特に、お客様側で直接編集された場合や、Git管理外で修正された場合に構造が崩れるケースが目立ちます。

ガイドは「制限」ではなく「指針」

FHWでは、更新を厳密なルールで縛ることはしていません。
一方で、判断に迷わないための指針は重要だと考えています。
明文化された専用ガイドがあるとは限りませんが、

• Backlogに残された設計意図
• 過去のやりとりや判断理由
• 実装時に共有された前提

これらが、実質的なガイドとして機能します。

見出し階層は「構造」として扱う

見出しは、見た目を整えるための要素ではありません。

• 情報のまとまり
• ページの構造
• 更新時の判断基準

として扱います。
そのため、見出し階層は 自由に変更できる装飾ではなく、構造として固定するものとして設計します。

画像は自由度と安全域を両立させる

画像については、

• 比率や最低条件を決める
• すべてを固定せず、自由度も残す

というバランスを取ります。
これにより、

• 更新担当が迷わず差し替えられ
• 多少のブレがあっても崩れない

状態を作ります。

カード・一覧は「変わる前提」で考える

カードや一覧系のUIは、

• 件数が変わる
• テキスト量が変わる

ことを前提に設計します。
ただし、実装者の技量やスケジュールによって、この前提が十分に反映されていないケースもあります。
そのため、運用時に無理な更新を行わず、必要に応じて調整・改修できる余地を残します。

CMS操作説明に踏み込まない理由

このページでは、

• CMS（WordPress等）の操作方法
• 具体的な更新手順

には踏み込みません。
重要なのは操作ではなく、構造として何を守るべきかだからです。