多くの経営者はプロジェクト立ち上げ時にこう言います。「コーポレートサイトと管理画面を一緒に作れば楽だ」と。
聞こえは合理的ですが、実際に進めると次の3つの状況が最も起こりやすくなります。コーポレートサイトが先に公開され、管理画面はまだ修正中。管理画面のフィールドが変わると、コーポレートサイトのページがすべて作り直しになる。両側を別々の担当者に依頼し、APIが噛み合わず、最後にお互い待ちになってしまう。
問題は「一緒に作ること」ではなく、計画の順序がないことにあります。以下では実際のプロジェクト経験に基づいて、このテーマを分解して説明します。
先に管理画面のデータを決め、その後でコーポレートサイトのページを決める
コーポレートサイトは表示層であり、管理画面はデータ層です。順序が逆になると、作り直しはほぼ避けられません。
具体的な場面を挙げます。産業機器を扱う企業がコーポレートサイトをリニューアルし、同時に営業担当者が製品パラメータ・事例・ニュースを自分で更新できる管理画面を作るとします。先にコーポレートサイトのトップページを描き、その後で管理画面の入力方法を考えると、よくある結果は管理画面のフィールド設計が場当たり的になることです。たとえば「製品の特徴」がリッチテキストボックス1つしかないのに、コーポレートサイトでは3項目を横並びで表示したい。最終的には編集者が手動でレイアウトするしかなく、半年後にはコンテンツが乱れます。
より安定した方法は、先にコンテンツモデルを列挙することです。製品にはどのようなフィールドがあるか、事例はどの製品に関連付くか、ニュースにカテゴリは必要か、画像は複数サイズが必要か。フィールドが決まれば、コーポレートサイトのページ構造は自然に導き出されます。
注意点：管理画面のフィールドをそのままデータベースのフィールドにしてはいけません。編集者に見せるフィールド名は分かりやすい言葉にし、技術的なフィールドは別に保存します。そうしないと、運用担当者は2回入力しただけでメンテナンスを諦めてしまいます。
APIを先行させ、両側の完成後に結合テストをしない
コーポレートサイトと管理画面を同時に開発する場合、最大の時間浪費は結合テストにあります。
開発の第1週にAPIドキュメントを確定することをおすすめします。たとえ紙面上の取り決めでも構いません。一覧APIが何を返すか、ページネーションパラメータの名前は何か、画像URLは相対パスか完全URLか。フロントエンドは仮データでページを動かし、管理画面は同じ取り決めに従って出力します。
ここで見落とされやすい細部があります。コーポレートサイトとミニアプリ開発はしばしば同じAPIを共有します。企業が今後予約ミニアプリも作る場合、管理画面のAPI設計ではモバイル向けのフィールド削減をあらかじめ考慮し、PC向けの大きなフィールドを全量返さないようにする必要があります。App開発も同様で、APIバージョン番号を最初から付けておけば、後の変更がずっと楽になります。
注意点：APIフィールドの命名に中国語と英語を混在させず、1つのAPIに3つの用途を詰め込まないこと。APIが2つ増えるほうが、万能APIを1つ作るよりよいです。
権限と公開フローは最初のバージョンで明確にする
管理画面のロールは管理者だけではありません。
実際のプロジェクトでよくあるロールは少なくとも、スーパー管理者、コンテンツ編集者、営業または地域責任者です。最初のバージョンで1アカウントだけにすると、後から権限を追加する際にデータテーブルを変更する必要があり、最初から設計するよりコストが大幅に高くなります。
公開フローも同じです。コーポレートサイトのコンテンツは審査後に公開する必要があるか。ニュース公開に下書きを残す必要があるか。これらは「後で考える」機能ではなく、テーブル構造に影響する要素です。
実行可能な方法の1つは、コンテンツテーブルにステータスフィールド（下書き、審査待ち、公開済み）を追加し、ロールテーブルに操作範囲を追加することです。最初のバージョンでは2つのロールだけを開放しても、構造は用意しておきます。
注意点：権限をページ内にハードコードしないこと。フロントエンドでボタンを隠すだけでは権限管理になりません。API層で必ず検証する必要があります。企業サイトが問い合わせや顧客情報を扱う場合、この点は特に重要です。
リリースのタイミングを2段階に分け、1回のリリースに縛らない
コーポレートサイトと管理画面を一緒に作ることは、一緒に公開することと同じではありません。
より安定した進め方は、管理画面を先に公開してコンテンツ入力を通し、その後でコーポレートサイトを公開し、実データで埋めることです。これにより、コーポレートサイトの初回公開時にコンテンツが完全な状態になり、公開後に補う必要がありません。
時間が迫っている場合は、コーポレートサイトの静的版を先に公開し、管理画面を並行開発して、2週目にデータソースを切り替える方法もあります。前提として、ページ構造が前述のコンテンツモデルに基づいて決まっており、切り替え時にレイアウトを変更する必要がないことです。
注意点：公開前にセキュリティテストの時間を確保すること。企業サイトはフォーム送信や管理画面ログインを伴うため、一般的なインジェクション、権限昇格、弱いパスワードの問題を一通り確認する必要があります。この作業量はWebサイト開発自体とは別なので、計画時に漏らさないでください。
どのような場合にMIC Studioに依頼するのが適切か
チームに安定したフロントエンドとバックエンドがいる場合、上記の順序で自分たちでスケジュールを組めばよく、外部介入は不要です。
ただし、以下のような場合は外部チームに依頼したほうが時間を節約できます。1つ目は、コーポレートサイトのリニューアルと管理画面を同時に開始し、社内の窓口が1人しかいないため、要件とスケジュールをまとめる人が必要な場合。2つ目は、既存システムにミニアプリ開発やApp開発を追加し、APIを再利用する必要があり、先にデータ構造を整理する人が必要な場合。3つ目は、公開前にWebサイトのセキュリティテストやリバーステストが必要で、社内に対応経験がない場合。
MIC Studioがこの種のプロジェクトを担当する場合、通常はまず要件整理とフィールド一覧を作成し、その後でWebサイト開発のスケジュールに入り、作りながら変更することを避けます。順位を約束せず、誇大な宣伝も行いません。境界と工期を明確に説明することを重視しています。
実行可能な3つの提案
1. プロジェクト立ち上げの第1週に、コンテンツモデルとロール一覧を出力してからページを描く。フィールドが決まっていないうちにデザイン案を急がない。
2. APIドキュメントとフロントエンドの仮データを同時に着手すれば、結合テストの時間を半分以上短縮できる。
3. リリースは管理画面先行、コーポレートサイト後続に分け、その間にセキュリティテストとコンテンツ充填の時間を確保する。
この3つを完了すれば、コーポレートサイトと管理画面を一緒に作ることはリスクではなく、コストを節約する選択になります。