支給デザインのLPで、実行環境と納品形式を着手前に確定する

ご要望は、支給デザインを指定日までにランディングページとして実装し、所定の環境へ納品することでした。デザインと画面数が明確でも、納品先でPHPなどのサーバー処理を使えるか、どの形式のファイルが受け入れられるかは別の要件です。

制作環境で動く構成を先に作り込んだ後で、納品先では同じ実行方法を利用できないことが分かると、共通部やフォーム、ファイル構成を変換する必要があります。短期間の案件ほど、見た目の確認だけで着手せず、公開環境と納品条件を確定することが課題でした。

着手時の確認項目を、デザイン、原稿、素材だけでなく、公開URL、サーバー種別、利用可能な言語、フォーム処理、納品形式、公開作業者まで広げました。制作側の標準環境をそのまま使えると仮定せず、納品先の条件を優先して構成を選びます。

今回は、実行環境が異なることを確認後、サーバー処理へ依存する部分を洗い出し、静的に置き換えられる範囲と、納品先で対応が必要な範囲を分けました。個人の確認不足として扱うのではなく、見積り・着手前チェックへ戻しています。

この方法は、代理店や別会社の環境へデータ納品するLPに有効です。公開環境へ直接確認できない場合は、受入条件の文書とテスト用の最小データを先に渡し、動作可否を確認する必要があります。

支給デザインの再現を進めながら、納品形式が変わっても画面の構造を大きく作り直さないよう、静的に保持できる表現と動的処理が必要な部分を分けました。デザイン上は同じ見た目でも、実装方法が異なる箇所を制作担当と共有しています。

短期間では、細かな演出を先に詰めるより、第一画面、主要コンテンツ、行動導線、法定表記の順で確認しました。納品先で使えない処理がある場合も、利用者が必要情報へ到達できる代替表示を優先しています。

デザインデータのツールや版も確認し、書き出し差やフォント差を公開直前に持ち込まないようにしました。実行環境の制約を、画面外の問題ではなくデザイン成立条件として扱いました。

実装前に、納品先で利用できるHTML、CSS、JavaScript、サーバー処理と、ディレクトリ構成を確認する手順を設けました。制作環境で便利なincludeや処理も、納品先で動かなければ採用できません。

制約判明後は、該当する依存箇所を一覧化し、静的HTMLへ展開できる部分、JavaScriptで代替する部分、納品先の対応が必要な部分に分けました。画面ごとの手作業で直すのではなく、共通部から変換して差分を減らしています。

最終確認では、ローカル表示だけでなく、納品形式にしたデータでリンク、画像パス、文字コード、端末表示を検証しました。この経験から、技術選定は制作会社の慣れではなく、最終的に置かれる環境と引き継ぎ条件から決める必要があると整理しています。