複数ブランドのサイトで、ヘッダーの予約ボタンを大きくしたい。架空の運営本部を例に、代表サイトでは見やすくなったものの、別ブランドでは長い名称と重なり、店舗別の予約先も変わってしまった場面を考えます。依頼は小さな見た目の修正でも、共通部品の使われ方によって影響は広がります。
変更前にそろえたいのは、部品の利用先、ブランドや店舗の例外、確かめる画面、問題が起きたときの戻し方です。これらを一枚の表で対応づけると、本部と制作会社が同じ範囲を見て相談できます。サイトをすべて統合する話から始める必要はありません。今回は、現在使っている共通部品を変更するときの確認材料を整理します。
同じ見た目と、同じ変更元は別のこと
見た目が同じヘッダーでも、一つの部品を参照している場合と、似た内容を各サイトへ複製している場合があります。前者なら元の変更が複数の掲載先へ及ぶ可能性があり、後者なら一か所を直しても残りは変わりません。画面の写真だけから、どちらかを判断するのは難しいところです。
WordPressの公式資料でも、変更が利用箇所へ同期されるパターンと、挿入後に個別に編集するパターンを区別しています。これは一つのサイト内の機能の説明であり、別サイトまで自動的に同期するという意味ではありません。複数サイトで何が共有されているかは、実際の構成を確認します。
本部が準備するのは、対象サイトのURLと、変更したい部分の画面です。制作会社には、どの管理画面・ファイル・設定から表示されるのか、ほかにどこで使われるのかを調べてもらいます。「共通ヘッダー」という呼び名が同じでも、ブランドごとに別の部品なら、その違いを記録します。
文字、色、リンク先も同じ単位で管理されているとは限りません。枠のデザインは共通でも、予約先だけ店舗別に登録している構成があります。今回変えるのは余白なのか、表示名なのか、行き先なのかを分けると、必要のない情報まで一括で書き換える依頼を避けられます。
部品から利用先へ、確認表を作る
サイト一覧だけでは、共通部品を変えたときにどの画面を開くかが決まりません。部品ごとに利用するサイトと例外を結び付けます。全ページの一覧を最初から手入力するのではなく、実装上の利用範囲を調べ、その中の確認対象を選ぶ順序にします。
次の表は、複数ブランドを運営する架空の企業の整理例です。戻し方の欄は実施手順の代わりではなく、制作会社へ確認する復旧単位を示しています。
| 共通部品 | 参照するサイト | 例外条件 | 検証する画面・操作 | 戻し方で確認すること |
|---|---|---|---|---|
| ヘッダー | ブランドA・B | Bは名称が長い | 狭い画面でメニューを開く | 旧部品と店舗別設定の両方 |
| 予約ボタン | 全店舗ページ | 一部は外部予約 | 店舗詳細から正しい予約先へ | 行き先の設定を別に戻すか |
| フッター | 企業・採用サイト | 採用は連絡窓口が別 | 下部リンクと連絡先を確認 | 既存の窓口情報を保持できるか |
| お知らせ帯 | ブランドA | 期間終了時は非表示 | 表示中・終了後を確認 | 表示条件と本文を戻す単位 |
| メニューの動作 | ブランドA・B | Bだけ項目数が多い | 開閉・スクロール・リンク移動 | 関係する動作の部品も必要か |
実際の表には、部品の管理上の名前、確認用URL、担当者も加えます。「全店」と書く場合は、どの一覧を基にした全店なのかを残します。新しく追加した店舗や、旧構成で残るページを含むか分からなければ、確認済みの対象と未確認の対象を分けます。
利用していないと確認したサイトも、理由を記録しておくと役立ちます。たとえば独立した採用サイトは別ヘッダーであり、今回は共通部品を読まないと分かった場合です。一方、表示されていないだけで共通の動作を読み込む構成もあります。画面に部品が見えないという理由だけで、影響範囲から外さないよう制作会社に確認します。
部品の中に別の共通部品が含まれる場合は、その関係も一段たどります。ヘッダー自体はブランド別でも、内部の予約ボタンやメニュー開閉だけを共有していれば、その修正は両方に関わります。管理上の名前と画面の呼び名を並べて残すと、本部が「右上の予約」と呼ぶ箇所を、実装担当者が迷わず特定できます。
例外は、店舗名ではなく条件で集める
代表店舗一つで問題がなかったからといって、全店舗で同じになるとは限りません。名称の長さ、メニューの項目数、ロゴの縦横比、予約方法など、画面を変える条件を先に集めます。その条件に当てはまる実際の店舗を確認対象にすると、選定理由が説明できます。
たとえば長い店名と多いメニュー項目が同時にある店舗は、通常の店舗とは別に確認します。電話予約だけの店、外部予約へ移る店、受付を一時停止している店も、ボタンの見え方と行き先が異なります。まだ存在しない条件を大量に作るより、現在運用している違いを本部と現場で確かめることが先です。
例外を残すことと、古い不具合を残すことは区別します。「このブランドだけ以前から違う」という説明があれば、その違いが意図した仕様なのか、直したい問題なのかを担当者へ確認します。判断が決まらないものは、変更対象外と勝手に扱わず、確認待ちとして依頼表に残します。
共通の変更に合わせられない例外がある場合は、個別設定を残す、別部品へ分ける、例外側も修正する方法を比較します。どの方法がよいかは、今後の更新頻度と確認負担も判断材料です。見た目をそろえるためだけに、店舗ごとの受付方法まで共通化しないようにします。
画面幅だけでなく、開いた状態まで確かめる
ヘッダーは最初に表示された状態だけでは確認できません。メニューを開いたとき、ページを下へ動かしたとき、リンクへキーボードで移動したときに、別の問題が現れることがあります。確認表には画面のURLに加え、何を操作し、どの状態を見るかを書きます。
MDNのメディアクエリーの説明では、画面の表示領域や端末の特徴に応じてスタイルを切り替える仕組みが解説されています。このため、パソコンとスマートフォンという名前だけで確認条件を済ませず、実際の切り替わりを制作会社と確認します。メニューが折りたたまれる幅の前後も、検査候補になります。
文字が読めるか、ボタンが重ならないか、メニューを開いたまま必要な項目へ進めるかを見ます。タップだけでなく、キーボードで移動したときの選択位置が分かるかも確かめます。見た目の比較画像は役立ちますが、画像だけではリンク先や開閉の動作までは証明できません。
予約ボタンでは、押せることと、正しい店舗へ進むことを別々に確認します。移動先の店名や用件を確認できるところまで進めば、別ブランドの受付へ誤って送る問題を見つけやすくなります。実際の予約や注文の送信が必要な検査は、試験環境やテストデータの扱いを担当者と決めて行います。
変更前後で、同じ条件を比べる
変更前の状態を記録していないと、公開後に見つかった違いが今回の修正によるものか分かりにくくなります。対象URL、日時、画面幅、操作の手順、表示結果をそろえて残します。変更後も同じ条件で確認し、意図した違いと想定外の違いを分けます。
「表示問題なし」だけでなく、「ブランドBの長い名称が予約ボタンに重ならず、メニューからBの店舗一覧へ進める」のように、確かめた結果を書きます。失敗した場合も、画面写真と発生手順があれば、制作会社が再現しやすくなります。担当者によって合否が変わらない表現にすることが狙いです。
検証表には、成功と失敗に加えて未実施も残します。外部予約先の確認権限がない、店舗担当者の返答を待っている、といった状態を空欄のままにすると、見落としなのか保留なのか分かりません。未実施の理由と確認する人を記録し、公開前に必要な確認が残っていないかを判断します。代表画面での合格を、未確認の例外へそのまま広げないことが大切です。
表示速度まで変更する場合は、別に測定条件をそろえます。PageSpeed Insightsの改善優先順位は、速度の指標と利用者への影響を整理する記事です。今回の共通部品確認では、点数の改善だけで合格にせず、各ブランドの入口と例外の操作が維持されているかを確認します。
新しい確認用画面と、利用者が見ている公開画面が同じ版かも確かめます。保存済みの表示が残る仕組みがある場合、更新直後に古い内容が見えることもあります。担当者ごとに見えるものが違ったら、すぐに再修正する前に、どのURL・版・条件を見ているかを制作会社と照合します。
戻す単位と、止める条件を先に決める
「バックアップがある」だけでは、何を戻せるかは分かりません。部品の見た目、リンク先の設定、店舗情報、メニューの動作が別々に管理されているなら、変更前の状態に戻すために何が必要かを確認します。担当者、保存場所、対象の版、作業に必要な時間を制作会社と整理します。
特に、サイト全体の情報を過去へ戻す方法では、変更後に入った問い合わせや通常更新まで影響しないかを確認する必要があります。共通部品だけを戻せるのか、設定も合わせて戻すのかを検討し、範囲が不明なまま復元を実行する手順にはしません。復旧は、現在の運用情報を保つことも含めて設計します。
止める条件は、変更の目的に合わせて決めます。別店舗の予約先へ進む、メニューから必要なページを開けない、重要なボタンが押せないなどは、公開を進めず修正する判断材料になります。小さな余白の差まで同じ扱いにせず、担当者が公開可否を判断できるよう問題を分けます。
一部のサイトだけ先に反映する方法を選ぶなら、仕組み上その単位で切り替えられるかも調べます。一つの共通部品を全サイトが同時に参照する構成で、「まず一店舗だけ」と予定しても、そのままでは実現しないことがあります。段階的に反映できない場合は、確認環境と全体へ反映する時間帯、直後の確認体制を具体化します。
依頼する成果物を、修正済み画面だけにしない
制作会社へ渡す時点で部品の利用先が分からなければ、まず調査と整理を依頼できます。修正費用に含まれると思い込まず、利用関係の調査、例外の確認、実装、表示・操作の検査、公開後確認を分けて範囲を決めます。店舗担当者には、受付方法や名称など、その店の事実を確かめてもらいます。
納品時には、変更した部品、影響を確認したサイト、検証した画面と操作、残る未確認事項、戻す手順の所在を受け取ります。次に新しい店舗を加えるときも、今回の確認表へ追加できる形にします。別の管理表を増やすより、現在の構成に合わせて更新できる一覧を保つことが大切です。
公開直後に確認するURLと担当も、この表から引き継ぎます。画面確認が済んだ版と実際に反映した版を対応づけ、別の更新が同時に入った場合は変更内容を記録します。問題を発見した連絡先と、修正か差し戻しかを決める担当が分かれば、店舗ごとに独自の応急修正を重ねて構成が分からなくなる事態を避けやすくなります。
相談前にそろえるものは、対象URL、変更したい画面、困っている操作、残したいブランド・店舗の違いです。技術的な構成が不明でも、その事実を明記すれば調査範囲を相談できます。共通部品の修正は、一画面の完成で終わらせず、利用先と例外の画面で意図した案内が保たれるところまでを依頼範囲に含めましょう。
参考資料
確認日：2026年9月16日。資料の機能説明と、この記事の確認表・設計例を区別しています。実際の共有範囲や復旧方法は、各サイトの構成調査で確認します。
