多くの経営者はプロジェクト開始時にこう言います。「公式サイトと管理画面を一緒に作ろう、どうせどちらもウェブサイトだから」と。
聞こえはコストも手間も省けるように思えますが、実際に進めてみると、二つの要件が互いに衝突し、工期はどんどん延び、予算は次々と追加されることがよくあります。
問題は「一緒に作れるかどうか」ではなく、二つの事柄の境界を先に明確にできているかどうかにあります。公式サイトは顧客に見せるもの、管理画面は自分たちが使うものです。両者の目標、進め方、検収基準はまったく異なります。以下、実際のプロジェクト経験に基づいて、計画の考え方を分解して説明します。
一、まず「一緒に作る」を二つのラインに分解し、一つの要件定義書に混ぜない
最もよくある失敗現場：要件定義書に100項目を書き、公式サイトと管理画面が混ざり合い、開発が半分進んだところで公式サイトの表示ロジックが管理画面のフィールド設計に依存していることに気づき、管理画面もまだ確定していない。
より堅実な方法は、二つの要件に分け、一つのデータモデルを共有することです。
- 公式サイトライン：カラム構造、ページ数、コンテンツ表示形式、SEO要件、モバイル対応
- 管理画面ライン：誰がログインするか、何を操作できるか、データはどこから来るか、審査フローはどう進むか
- 共有部分：コンテンツフィールド、画像仕様、カテゴリ体系、ステータス遷移
具体的なシナリオを挙げます。産業機器を扱う企業サイトのリニューアルで、同時にニュース配信、製品登録、問い合わせ閲覧ができる管理画面が必要だとします。最初から「製品」というフィールドを明確に定義しておけば——名称、型番、パラメータ表、メイン画像、詳細画像、所属カテゴリ、公開/非公開ステータス——公式サイトの製品一覧ページと管理画面の製品管理ページを同時に開発でき、管理画面が完成するのを待ってから公式サイトを作る必要はありません。
落とし穴回避の注意：「管理画面は適当でいい」といった言葉でプロジェクトを開始しないでください。管理画面が権限、審査、ログを扱うようになると、作業量は公式サイトに劣りません。
二、技術選定は両端を考慮し、片方だけの都合で選ばない
公式サイトと管理画面を同時に作る場合、技術スタックの選択は後の保守コストに直接影響します。
よくある組み合わせは三つあります：
1. 同一フレームワークで全部をカバー：フロントエンドとバックエンドを分離せず、公式サイトも管理画面も一つのプロジェクト内に置く。利点は速くて低コスト。欠点は公式サイトのアクセス量と管理画面の操作が互いに影響し、後の拡張が面倒になること。
2. フロントエンドとバックエンドを分離し、公式サイトと管理画面がインターフェースを共有：公式サイトはサーバーサイドレンダリングまたは静的化でSEOを確保し、管理画面はフロントエンドフレームワークでインタラクションを実装。現在の企業サイトでは比較的主流の選択です。
3. 公式サイトを静的化 + 管理画面を独立デプロイ：公式サイトはCDN経由、管理画面は別途イントラネットに置くかアクセス制限をかける。セキュリティが向上し、データに敏感な業務に適しています。
プロジェクト後期にミニプログラム開発やApp開発への拡張可能性がある場合、インターフェース設計は事前に余地を残す必要があります。例えばコンテンツインターフェースの返却構造を統一すれば、ミニプログラム側とApp側でそのまま再利用でき、書き直す必要がありません。
落とし穴回避の注意：管理画面のアドレスにadminのようなデフォルトパスを使わないこと、ログインインターフェースに頻度制限をかけること。これらはウェブセキュリティテストで最も基本的なチェック項目ですが、多くのプロジェクトではリリース前にまったく実施されていません。
三、インターフェースと権限モデルが、後の要件変更コストを決める
管理画面の出来不出来は、画面の見た目の美しさではなく、二つの事柄で判断します：インターフェースが明確か、権限を柔軟に設定できるか。
インターフェースについては、開発前にまずインターフェース一覧を作成し、少なくとも以下を明確に記載することを推奨します：
- パスとリクエスト方式
- 入力パラメータのフィールドと型
- 返却構造
- エラーコードの意味
- ログインが必要か、どのロールが必要か
権限については、最初から複雑なRBACを実装しないでください。中小企業のウェブ開発プロジェクトでは、通常三つのロールで十分です：スーパー管理者、コンテンツ編集者、読み取り専用閲覧者。業務が本当に複雑になってから拡張すればよいです。
ここで実際の教訓を一つ。ある教育機関の公式サイトでコースを表示し、管理画面でコースの公開と非公開をサポートする必要がありました。最初に権限を分けていなかったため、マーケティング部門の人がコースを直接削除でき、誤操作で販売中のコースを削除してしまい、公式サイトが同期エラーを起こしました。後に「削除には二次確認 + 操作ログ」を追加して、ようやく問題が解決しました。
落とし穴回避の注意：削除、一括変更、エクスポートといった操作には、必ずログと二次確認が必要です。これは追加要件ではなく、基本中の基本です。
四、リリースの進め方：公式サイトを先に公開し、管理画面は段階的に納品
多くの人は全部完成してからでないと公開できないと思っていますが、実はその必要はありません。
より合理的な進め方は：
- 第一段階：公式サイトの静的ページ + 基本管理画面（コンテンツ公開、画像アップロード）
- 第二段階：問い合わせ、フォーム、データ統計
- 第三段階：権限の細分化、操作ログ、データエクスポート
公式サイトを先に公開すれば、早くから検索エンジンにインデックスされ、業務部門も先に使い始めて意見を出せます。管理画面を段階的に納品すれば、開発負荷が小さく、手戻りコストも低くなります。
予約系の業務、例えば店舗予約やコース体験の場合、管理画面では時間の衝突、定員制限、通知リマインダーも考慮する必要があります。こうした要件はミニプログラム開発で受ける方が適しており、公式サイトは表示と集客を担当し、ミニプログラムはコンバージョンとリテンションを担当し、管理画面でデータを一元管理します。
落とし穴回避の注意：公開前に必ず一回完全なテストを行い、フォーム送信、画像アップロード、権限切り替え、モバイル表示を含めてください。多くの問題は開発がやっていないのではなく、テストが行き届いていないのです。
五、どのような場合に MIC Studio に依頼するのが適切か
以下のような状況に遭遇した場合、自社でチームを組むか個人開発者に依頼するのは割に合わないかもしれません：
- 公式サイトと管理画面を一緒に作りたいが、社内に要件を明確に書ける人がいない
- 既存の企業サイトがあり、リニューアルと同時に管理画面を追加したいが、データ移行の問題が心配
- ウェブ開発 + ミニプログラム開発 + App開発 のマルチプラットフォーム連携が必要
- 公開前にウェブセキュリティテストやリバーステストを行い、インターフェースと権限の脆弱性を洗い出したい
MIC Studio のアプローチは、まず要件を公式サイトラインと管理画面ラインに分解し、理解できる計画書を作成してから、見積もりと工期について話します。機能を詰め込まず、大きな絵を描かず、まず境界を明確にします。
最後に三つの実行可能な提案
1. 先にフィールドを書き、次にページを書く。コンテンツモデルを確定すれば、公式サイトと管理画面を並行して開発できます。
2. インターフェース一覧と権限表を開発前に確認する。この二つのドキュメントが後期の大量の揉め事を省きます。
3. 公式サイトを先に公開し、管理画面は段階的に納品する。全部完成するのを待たず、早く公開して早くインデックスされ早く使い始めましょう。
管理画面と公式サイトを一緒に作ることは、できないことではありません。計画を明確にしてから作ることが重要です。境界をはっきり考えることは、100項目の要件を書くよりも役立ちます。