制作会社が完成データをそのまま本番公開できる案件ばかりではありません。媒体側のCMSへ入稿する、既存の管理環境へ機能を組み込む、代理店や別会社へデータを納品するなど、制作環境と公開環境が分かれる案件があります。
この場合、制作環境できれいに表示できたことは、公開完了を意味しません。納品先で利用できる技術、CMS側のスタイル、画像やCSSのパス、入稿権限、確認方法が異なるためです。
私たちが担当した制作にも、外部CMSへLPを入稿するもの、既存CMSへ検索・入力機能を追加するもの、支給デザインを別環境へ納品するものがありました。制作中はきれいに見えていたのに、受け渡した先で条件が合わない。そんな手戻りを避けるには、コードや画面の完成だけでなく、反映、差し戻し、最終確認までを一つの工程として決める必要があります。
最初に確認するのは、制作方法ではなく最終的な置き場所
制作側が普段使っている構成を先に選ぶと、納品時に変換や作り直しが発生することがあります。着手前に、最低限次を確認します。
- 公開先は通常のWebサーバーか、CMSか、媒体固有の環境か
- HTML、CSS、JavaScript、サーバー処理のうち何を利用できるか
- ファイルと画像をどの単位で入稿するか
- CSSやJavaScriptをページ側から読み込めるか
- 共通ヘッダーなど、公開先が自動的に付与する要素があるか
- 制作会社が確認環境へアクセスできるか
- 本番反映を行うのは誰か
- 納品後の修正をどのデータへ戻すか
「HTML一式を納品」という言葉だけでは、受入条件は分かりません。静的HTMLが必要なのか、ビルド前のソースが必要なのか、CMSへ貼り付ける断片が必要なのかによって、ファイル構成も確認方法も変わります。
制作環境・入稿データ・公開画面を分けて確認する
外部環境へ入稿する制作では、確認段階を少なくとも三つに分けます。
制作環境で確認できること
- デザインと基本レイアウト
- レスポンシブ表示
- 基本的なリンクと動作
- 画像、文字、部品の対応
- 制作側で管理するコードの整合性
入稿・納品データで確認すること
- 指定されたファイル構成になっているか
- 画像やCSSのパスが成立するか
- 利用できない技術へ依存していないか
- 文字コード、ファイル名、容量などの条件を満たすか
- 納品対象と対象外が区別されているか
公開環境で確認すること
- CMSや媒体側のスタイルによって崩れていないか
- フォント差で改行や高さが変わっていないか
- ヘッダーや既存要素と干渉していないか
- 本番URL、フォーム、検索、リンクが機能するか
- 権限や公開状態が正しいか
制作環境のプレビューだけで公開画面を保証できない場合は、CMS反映後のスクリーンショット、確認用URL、テスト結果など、確認結果を受け渡す方法も決めます。
修正の戻し先を一本化する
入稿後の画面を直接修正し、制作元のデータにも別の修正を加えると、二つの最新版が生まれます。次の入稿で修正が消えたり、どちらを納品すべきか分からなくなったりします。
原則として、修正は制作元へ戻し、そこから入稿・納品データを作り直します。ただし、公開環境でしか変更できない設定がある場合は、コードの修正と環境設定を別の記録として管理します。
差し戻し時には、次を明確にします。
- 問題が制作元、入稿データ、公開環境のどこで発生したか
- 修正する担当者
- 修正を戻す元データ
- 再入稿が必要な範囲
- 公開環境だけで行った設定
- 最終確認者
既存CMSへ追加する場合は、入力・表示・検索を対応させる
既存CMSへ機能を追加する案件では、画面が表示できることだけでは不十分です。管理画面で入力した値が、どのページへ表示され、どの検索条件へ使われるかを対応させます。
特に、既存の複数サイトや複雑なカテゴリ構造へ追加する場合は、次を資料とテストで揃えます。
- データを登録する場所
- 必須・任意・条件付きの入力項目
- 公開画面での項目名
- 検索条件と入力値の関係
- 結果なし、未入力、例外データの表示
- 旧データから新項目への移行方法
- 運用者が確認するマニュアル
仕様書、設計書、テスト結果、運用マニュアルの名称を揃えると、制作側と運用側が同じ項目を確認しやすくなります。
公開環境を確認できない場合の進め方
制作会社が本番環境へ入れない場合もあります。その場合、推測で完成とせず、受入条件と確認経路を決めます。
- 最小構成のテストデータを先に渡す
- 納品先で読み込めるか確認する
- 公開環境固有の差を記録する
- 修正を制作元へ戻す
- 本番用データを作成する
- 反映後の確認結果を返してもらう
確認用URLを共有できない場合は、画面だけでなく、端末、URL、確認日時、操作内容が分かる証跡を受け取ります。制作会社が確認できない範囲を曖昧にせず、どこからが納品先の確認責任かを明示します。
完了条件は「データを渡した」では決めない
案件によって完了条件は異なります。
- 指定形式のデータを納品した時点
- CMSへ入稿して確認用画面を作った時点
- 公開環境で表示確認が終わった時点
- 運用者へマニュアルとテスト結果を渡した時点
- 本番反映後の修正が完了した時点
これらを契約上の納品条件と混同せず、制作進行上の確認状態として整理します。制作会社が最終公開を担当しない場合は、「制作完了」「入稿完了」「公開確認完了」を分ける必要があります。
この進め方が有効な場合
- 媒体や外部CMSへ入稿する
- 代理店や別の制作会社へデータを納品する
- 既存CMSやマルチサイトへ機能を追加する
- 公開環境へ制作会社が直接アクセスできない
- 納品先の技術制約が強い
- 実装後に別組織の確認・公開作業がある
別の進め方が適する場合
制作会社が開発環境から本番公開まで一貫して管理し、同じ構成をそのまま配置できる場合は、確認段階を細かく分ける必要はありません。また、CMSへの単純な文章入稿だけで、独自のHTMLや動作を持ち込まない場合は、コード納品よりCMSの入力ルールと承認フローを中心に整理します。
重要なのは、書類や確認工程を増やすことではありません。制作環境と公開環境の間で何が変わるかを把握し、誰がどの状態を確認できるかを明確にすることです。
着手前チェックリスト
- 公開先と納品形式が決まっているか
- 利用できる言語・処理・ファイル構成を確認したか
- CMSや媒体側が自動付与する要素を確認したか
- 制作環境、入稿データ、公開画面を分けて確認するか
- 本番反映を行う担当者が明確か
- 修正を戻す元データが一つに決まっているか
- 公開環境を確認できない場合の証跡を決めたか
- 入力項目、表示、検索条件が対応しているか
- 移行手順、テスト結果、運用資料が必要か
- 制作完了、入稿完了、公開確認完了を区別したか