多層の制作体制を、実装可能な受け渡し条件へ変えた会員サイト

ご要望は、支給された要件とデザインをもとに、決められた範囲を正確に制作することでした。一方で、誰がどのファイルを用意し、共通部分をどの方法で組み込み、どの状態を納品完了とするかは、画面だけでは判断できませんでした。

代理店、制作会社、実装担当が分かれる体制では、個別ページが完成しても、共通パーツの差し替えや確認環境への反映方法が揃っていなければ手戻りになります。そこで、デザイン上の要望と、実装・納品上の制約を分け、担当範囲、共通化する単位、確認経路を着手前の確認事項として整理する必要がありました。

最初に、ページ一覧と担当者を対応させ、支給されるもの、FHWで制作するもの、他社側で組み込むものを分けました。そのうえで、ヘッダーやフッターなどの共通部分を各ページへ複製する案と、includeして一元管理する案を比較し、納品先の環境と更新方法に合わせて受け渡し単位を決めました。

見た目の確認だけで完了とせず、ファイル構成、相対パス、共通パーツの呼び出し、修正時の連絡経路までを確認対象にしました。多層体制では、担当者間の口頭理解に依存するほど差分が生まれます。実装ルールを先に小さく合意し、最初のページで受け渡しを検証してから横展開する進め方を採用しました。

この方法は、納品先の組み込み方式が確定している案件に有効です。環境や担当境界が未確定の場合は、先に検証用の一ページを用意し、受け渡し後の動作まで確認する必要があります。

支給デザインをそのまま画面へ起こすだけでなく、複数ページへ展開したときに同じルールで判断できるかを確認しました。見出し、余白、表組み、ボタン、入力部品などを共通単位として整理し、ページごとの例外が必要な箇所を分けています。

多層体制では、デザイン上の意図が途中の伝達で省略されやすいため、数値や見た目だけでなく、優先順位も共有しました。たとえば、狭い画面で何を先に見せるか、文章量が増えたときにどこまで高さを可変にするか、画像が未確定でも保てるレイアウトかを確認しています。

完成画面の再現性に加え、後工程の担当者が判断に迷わないことをデザイン仕様の一部として扱いました。

実装では、共通パーツを管理する方法と、納品先で組み込みやすいファイル構成を先に確認しました。ページごとに同じコードを複製すると、修正漏れや差分が起きやすくなります。一方、includeを前提にし過ぎると、納品先の環境でそのまま使えない場合があります。そこで、利用環境と担当境界を確認し、共通化する範囲と静的に渡す範囲を分けました。

最初のページで、パス、画像、共通部、レスポンシブ表示、受け渡し後の組み込みを確認し、問題がないことを確かめてから他ページへ展開しました。修正時には、共通部分の変更か個別ページの変更かを明示し、反映先を追える形にしています。

この経験から、外部の制作体制へコードを渡す案件では、実装技術より先に、納品形式、確認環境、共通部の所有者、完了条件を揃えることが重要だと整理しています。