段階公開と担当交代を、一つの進行へまとめた企業サイト

制作対象は一度にすべて公開されるのではなく、複数のページや関連領域を段階的に公開する前提でした。段階ごとに対象が変わると、今回直す範囲と次回へ送る範囲、共通部へ反映する変更、個別ページだけの変更を区別しなければなりません。

代理店を含む体制では、要望の確認経路と最終判断者も複数になります。さらに担当者が交代すると、過去の打ち合わせで決まった理由が失われ、同じ論点を再検討する可能性があります。契約条件そのものを公開内容へ持ち込まず、制作上必要な範囲、修正条件、承認状態を継続して共有することが課題でした。

各公開段階について、対象URL、必要素材、共通部への影響、確認者、公開条件を一覧にしました。すべての要望をその段階へ入れる案は採らず、公開に必要な変更と、次の段階でまとめて行う変更を分けています。

ヘッダーなど複数ページへ影響する仕様は、個別課題の中だけに残さず、現在の共通仕様としてまとめました。担当交代時には、過去のやり取りを渡すだけでなく、決定済み、未決定、確認待ち、公開後対応を整理して再キックオフしています。

この進め方は、複数社が関わり、段階公開する案件に有効です。ただし、最終承認者や公開権限が段階ごとに異なる場合は、承認経路を個別に設定する必要があります。

段階公開では、今回公開するページだけが整って見えることに加え、後から追加されるページと共通部が矛盾しないことを重視しました。ヘッダー、導線、見出し、余白のルールを共通仕様として持ち、個別ページの要望で全体ルールを無意識に変えないようにしています。

修正依頼は、見た目の好み、情報の誤り、共通仕様の変更、公開段階の変更に分けました。すべてを同じ優先度で扱わず、公開条件へ影響するものから判断しています。

担当交代時には、完成画面だけでなく、なぜその表現を採用したか、他案を採用しなかった理由、次段階で見直す箇所も共有しました。これにより、交代後の担当者が過去判断を再現できる状態を目指しました。

実装では、共通ヘッダーやフッターを段階ごとの個別ページへ複製せず、一つの変更を対象ページへ反映できる構成にしました。ただし、まだ公開しない導線まで先に露出しないよう、公開段階に応じた表示条件を確認しています。

各段階のリリースでは、対象ファイル、共通部の変更、既存ページへの影響、反映後の確認項目を分けました。担当者が交代しても作業を再開できるよう、実装済み、未反映、確認待ちの状態を記録しています。

段階公開では、同じコードを持つことと、同時に表示することは別問題です。将来のページを見越して共通化しつつ、現在公開してよい範囲だけを安全に見せる設計が必要だと整理しています。