既存Web基盤へ新サイトを追加。CMS権限・公開・継続運用をどう設計したか

新サイトは既存サイトと同じドメイン、サーバー、CMSを利用する一方、施設担当者と既存サイト担当者が互いの管理領域を閲覧・変更できない状態にする必要がありました。施設担当者の日常作業は、指定されたカレンダーファイルの差し替えに限定されていました。

公開作業にはSFTPの接続情報だけでなく、VPN、接続元、対象ディレクトリ、操作権限が関わり、制作側だけでは準備を完結できない環境でした。また、PDF単体の表示上の問題も、既存ドメイン配下を維持するかというURL設計へ戻って判断する必要がありました。公開に必須の条件と、公開後も継続する更新権限を分けて設計することが課題でした。

CMS権限を「管理者」「担当者」という肩書だけで決めず、誰が、どのファイルを、どの場所へ、どの操作で更新するかに分解しました。管理者、既存サイト担当、施設担当の役割ごとに、閲覧範囲、利用機能、アップロード可能なファイルを定義しています。

公開工程は、既存サイト側による領域準備、制作側による確認環境への反映、既存サイト側の確認、調整または本番反映に分けました。VPN、SFTP、対象領域、バックアップ、操作確認をチェック項目とし、誰の作業が完了したら次へ進むかを共有しました。

同じCMSを利用者全員へ広く開放する案は採用せず、必要な操作だけを許可する方針としました。この方法は、既存基盤へ別部門を追加する場合に有効ですが、CMS更新後も独自機能が動くか継続確認が必要です。

ページ数と役割を構成段階で見直し、利用料金と設備備品は資料ダウンロードへ集約し、問い合わせは別途用意されるフォームへの導線として設計しました。施設写真と利用実例を中心に、利用後のイメージを持てる情報順を組み立てています。

スマートフォン向けの構成を先に検討し、ファーストビューからコンテンツ途中まで、どこで施設を理解し、どこで資料や問い合わせへ進むかを確認しました。レスポンシブとリキッドレイアウトの違いが確認者によって曖昧にならないよう、画面幅で何が変化するかを説明対象にしています。

FigmaやPDFでは、提示範囲がそのまま確認範囲に見えることがあるため、確定箇所、検討中、参考表示を分け、後戻りの影響を抑える共有方法も見直しました。

既存のMovable Typeへ、施設担当者が許可されたHTMLファイルだけを所定のカレンダーデータ領域へアップロードできる機能を組み込みました。利用者のロール、ファイル名、保存先を確認し、許可外のファイルは受け付けない処理として実装されています。

公開時にはVPN、接続元、SFTP、対象ディレクトリの権限を確認し、確認環境と本番反映を段階化しました。接続情報があっても対象領域へ書き込めない場合があるため、最小の操作確認を本番反映前に行っています。

公開後もCMSの脆弱性対応とバージョンアップがあり、限定アップロード機能の保存先判定を継続して確認しています。独自機能は公開時に動けば完了ではなく、CMS更新、元ファイルの状態、日常運用まで保守対象として追う必要があります。