多くの企業がコーポレートサイトを制作する際、ついでに「管理画面も一緒に作りましょう」と言います。聞こえは気軽ですが、実際に進めると二つの要件がぶつかり合うことがよくあります。
コーポレートサイトは見栄えがよく、高速で、検索エンジンにインデックスされる必要があります。管理画面はコンテンツを編集でき、データを閲覧でき、権限を分けられる必要があります。両者は同じデータを共有しながら、まったく異なる利用者にサービスを提供します。計画が不十分だと、最もよくある結果はこうです。サイトが先に公開され、管理画面でフィールドを一つ変更しただけでフロントエンドが全崩壊する。あるいは管理画面が完成したものの、サイト側のコンテンツ構造とまったく噛み合わない。
本記事では実際のプロジェクトの流れに沿って、Webサイト開発におけるコーポレートサイト＋管理画面の計画を明確にします。
まず二つのラインを分ける：表示ロジックと編集ロジック
コーポレートサイトは表示ロジック、管理画面は編集ロジックです。この二つのラインは別々に設計しますが、一つのデータモデルを共有します。
具体的には、まずコンテンツモデルを決め、次にページを決めます。たとえば企業サイトでよくあるカテゴリ：ニュース、製品、事例、採用。各カテゴリにどんなフィールドがあるか、どれが必須か、画像サイズはどれくらいか、多言語対応するか。これらはページを描く前に決めておく必要があります。
注意点：管理画面をページモジュールに直接対応させないこと。多くのプロジェクトで管理画面を「トップページ第一画面のコピー」「トップページ第二画面の画像」のように作り、その結果サイトをリニューアルすると管理画面がすべて無効になります。正しい方法は、管理画面はコンテンツを管理し、ページは表示を管理し、その間をフィールドマッピングでつなぐことです。
もう一つの落とし穴は権限です。管理画面には少なくとも管理者、編集者、閲覧のみの三つのロールが必要です。これは企業サイトのプロジェクトでよく見落とされ、公開後にインターンがデータを削除できてしまうことに気づきます。
スケジュール上、管理画面はサイトより先にデータ層を完成させるべき
比較的安定した順序は：データモデル → 管理画面API → 管理画面UI → サイトページです。
サイトページは実データに依存します。管理画面がまだ動いていない場合、フロントエンドは仮データで作るしかなく、結合テスト段階で問題が集中します。まず管理画面で入力・編集・正しい構造の返却ができるようにし、その後サイトを接続すれば、手戻りはかなり少なくなります。
具体例を挙げます。設備レンタル会社で、サイトに設備一覧とオンライン予約を表示し、管理画面で設備情報、予約記録、ステータス遷移を管理する場合。先にサイトを作ると、予約フォームのフィールドと管理画面の記録構造が噛み合わなくなりがちです。たとえばサイトが「希望レンタル期間」を受け取っても、管理画面には「開始日」しか保存されていない、といった具合です。こうした問題は結合テストで初めて発覚し、修正にはデータベースの変更が必要になります。
したがってスケジュール上、管理画面には少なくとも三分の一の先行期間を確保し、サイトの付属品として扱わないようにしましょう。
インターフェースを先に取り決め、ページを描き終えてから話し合わない
サイトと管理画面の間はインターフェースの関係です。フィールド名、型、ページネーション方式、エラーコードは、開発前に簡単なドキュメントにまとめておくのが望ましいです。
それほど正式である必要はなく、一ページの表で十分です：APIパス、入力パラメータ、返却例、異常ケース。これがあるだけで口頭コミュニケーションを大幅に削減できます。
注意点：画像アップロード。サイトと管理画面の両方で画像を扱いますが、要件は異なります。サイトは圧縮、CDN、遅延読み込みが必要。管理画面はオリジナル画像、トリミング、並び替えが必要。アップロードロジックは一つのサービスに統一し、両方で別々に書かないようにしましょう。
検索とフィルタリングも同様です。管理画面のフィルタ条件はサイトより複雑なことが多く、API設計時にサイトだけを考慮すると、管理画面用に別のクエリを追加する必要が出てきます。事前にフィルタパラメータを組み合わせ可能な設計にしておけば、後が楽になります。
セキュリティと管理者入口は別途考慮する
管理画面は攻撃面が最も大きい場所です。Webサイト開発でよく飛ばされるステップが、管理画面のセキュリティテストです。
少なくとも行うべきことは：管理画面ログインにキャプチャとログイン失敗制限を追加；管理者パスワードの複雑さを強制；APIで権限チェックを行い、フロントエンドのメニュー非表示だけに頼らない；操作ログを記録する。
ミニアプリ開発やApp開発のプロジェクトでは、管理画面が複数のクライアントと連携することが多く、権限モデルがより複雑になります。この場合は管理画面を「コンテンツ管理」と「業務管理」の二つに分割し、前者を運用担当、後者を業務担当に割り当てて誤操作を減らすことをお勧めします。
注意点：サイトと同じアカウント体系で管理画面を管理しないこと。フロントエンドユーザーと管理者は必ず別テーブル、別ログインロジックにします。
受け入れ基準は事前に書き、公開直前に考えない
サイトの受け入れは読み込み速度、モバイル対応、SEO基本項目（タイトル、ディスクリプション、構造化データ）を確認します。管理画面の受け入れは三つ：完全に入力できるか、正しくサイトに表示されるか、権限が正しいか。
受け入れチェックリストを作り、各項目に実行可能な確認アクションを対応させることをお勧めします。たとえば「ニュースを一件追加し、サイトの一覧ページに1分以内に表示される」「編集ロールはデータを削除できない」「画像アップロード後、サイト表示が300KBを超えない」。
チェックリストはプロジェクト開始時に開発とすり合わせておく方が、公開直前に急に要求するよりはるかに効果的です。
MIC Studio に依頼するのが適しているケース
チームに専任のバックエンドがいない場合、またはサイトと管理画面を同時に一つの期日に間に合わせる必要がある場合、一部を外部委託するのは合理的です。MIC Studio が企業サイトと管理画面の一体開発を行う際は、通常まず顧客とコンテンツモデルとインターフェースの取り決めを整理してから開発に入ります。
私たちに適しているケース：サイトのリニューアルと同時に管理画面の再構築が必要；予約や申し込みなど業務フローを伴うサイト；管理画面がミニアプリやAppのマルチデバイスプロジェクトと連携する場合。数行のコピーを変更するだけなら、完全なプロジェクトプロセスを踏む必要はありません。
実行可能な三つの提案
第一に、着手前に一ページのコンテンツモデルを書き、カテゴリ、フィールド、必須項目を決め、サイトも管理画面もそれに従うこと。
第二に、スケジュール上、管理画面のデータ層を先に動くようにし、サイトはその後実APIに接続して結合テストの手戻りを減らすこと。
第三に、公開前に管理画面のセキュリティチェックと権限テストを一度行い、問題が起きてから補わないこと。