厳格なセキュリティ制約下で進めたコーポレートサイト再構築

複数部門の情報を整理しながら、指定されたサーバーとセキュリティ条件に適合させる必要がありました。部門ごとに情報量や確認者が異なる一方、サイト全体では共通のトーンと構造を保たなければなりません。日本語・英語の文字量差や、更新領域の扱いも同時に確認する必要がありました。

利用できる共有ツールや外部環境にも制約があり、制作途中で環境条件が変わる可能性がありました。特定のツールだけへ判断経緯を残すと、利用できなくなった時点で確認状況を引き継げません。ページ、部門、言語、確定状態を、利用可能な形式で継続管理することが課題でした。

制作範囲を部門とディレクトリの単位で分け、全体で共有する領域と、部門ごとに確認するページを切り分けました。ページ一覧には、原稿、デザイン、実装、確認者、未確定事項の状態を持たせ、環境が変わっても現在地を復元できる形にしています。

共有資料は利用可能な形式へ変換し、特定ツールの画面だけを正本にしませんでした。環境条件が変わった場合は、既存の工程をそのまま続けず、確認できる場所、受け渡し単位、最終配置を組み直しました。

制作側から本番環境へ直接公開する案ではなく、クライアント側が配置・公開できる納品形態へ調整しています。この方法は外部接続が制限される案件に有効ですが、受入確認と最終公開の責任者を明確にする必要があります。

部門ごとの事業内容や情報量の違いを吸収しながら、サイト全体では共通の見出し、余白、カード、導線を維持しました。すべての部門を同じ情報量へ揃えるのではなく、共通テンプレートが受け止められる範囲と、個別設計が必要なページを分けています。

英語ページは日本語版を単純に流用せず、文字幅、行数、見出しの折り返しを確認し、言語ごとに余白を調整しました。確認資料も、利用できる形式へ変換した後にページ名と状態が分かるよう整理しています。

環境制約のため確認方法が変わっても、画面上の判断が失われないよう、確定箇所、修正箇所、未確定箇所を明示しました。

実装前に、指定サーバー、利用可能な処理、公開方法、外部ツールの制約を確認しました。共通部品と部門別ページを分離し、部門固有の変更がサイト全体へ波及しにくい構成にしています。WordPress更新領域も、固定ページと役割を分けました。

本番環境を自由に使えない状況では、制作環境で確認できる単位と、納品後にクライアント環境で確認する単位を分けました。ファイルとディレクトリの対応を明確にし、配置後の確認項目を受け渡しています。

環境条件が変わった際は、旧手順を継ぎ足すのではなく、ビルド、受け渡し、配置、確認の順序を再定義しました。セキュリティ制約下では、実装の工夫だけでなく、誰がどの環境で何を確認できるかを設計することが重要です。