多くの経営者はプロジェクト立ち上げ時にこう言います。コーポレートサイトと管理画面を一緒に作れば楽だ、と。
一見合理的に聞こえますが、実はこれが最も失敗しやすい組み合わせです。コーポレートサイトは顧客向けで、重視するのは表示速度、ビジュアル表現、コンバージョン導線です。管理画面は社内スタッフ向けで、重視するのはデータの正確性、操作効率、権限の明確さです。この二つは目的が異なるため、無理に一つのプロジェクトに押し込むと、最終的にはコーポレートサイトが遅延し、管理画面が未完成品になることがよくあります。
以下では、実際のプロジェクトの進め方に沿って、この問題を分解して説明します。
まず二つのラインを分ける：表示ラインと業務ライン
計画の第一歩はページを描くことではなく、境界を分けることです。
コーポレートサイトは表示ラインに属し、核心はコンテンツの提示とリード獲得です。管理画面は業務ラインに属し、核心はデータ入力、審査、集計です。この二つのラインは同じドメイン、同じアカウント体系を共有できますが、コード構造、イテレーションのリズム、検収基準は分けるべきです。
よくある誤ったやり方は、管理画面をコーポレートサイトの付属機能として扱い、まずコーポレートサイトを作り、管理画面は「ついでに数ページ追加する」というものです。その結果、管理画面には独立したデータモデル設計がなく、フィールドはすべて場当たり的に追加され、三ヶ月後には誰も変更できなくなります。
より堅実なやり方は、まず管理画面のデータ構造を定め、そのデータをコーポレートサイトが消費する形にすることです。例えば、コーポレートサイトの製品ページ、ニュースページ、事例ページのコンテンツはすべて管理画面から入力し、フロントエンドは表示のみを担当します。こうすれば、コーポレートサイトのリニューアル時に管理画面を触る必要がなく、管理画面にフィールドを追加した際もコーポレートサイトが自動的に追従できます。
データモデルを先に定め、ページは後から描く
これはWebサイト開発全体の中で最も飛ばされやすく、最もコストがかかるステップです。
具体的なシナリオを挙げます。設備販売を行う企業が、コーポレートサイトと管理画面システムを作るとします。管理画面では製品カテゴリ、製品パラメータ、販売店情報、問い合わせ記録を管理する必要があります。最初からページベースでプロトタイプを描くと、「製品一覧ページ」「製品詳細ページ」といったページ単位の設計になりがちで、最終的にパラメータがカテゴリごとに変わる必要があることに気づき、変更は作り直しになります。
正しい順序は、まずエンティティを列挙することです。製品、カテゴリ、パラメータ項目、販売店、問い合わせ票。各エンティティにどのフィールドがあり、互いにどのような関係があるか。これらをテーブル構造図に描いてから、ページについて議論します。
データモデルを間違えると、後続のすべてのページが手戻りになります。 このステップで二、三日多く費やすことで、後の二週間の押し問答を省けます。
権限とアカウント体系は、最初から余地を残す
管理画面で後から要件が追加されやすい箇所は権限です。
最初は管理者と一般社員の二種類のロールしかないかもしれませんが、リリースから半年後には「エリアマネージャーは自エリアのデータのみ閲覧可能」「経理は注文金額のみ閲覧可能でステータスは変更不可」といった要件が出てきます。アカウント体系が最初から固定された二段階ロールであれば、ロールを追加するたびにコードを変更する必要があります。
Webサイト開発の段階でロール＋権限ポイントの構造にすることを推奨します。権限ポイントはモジュール単位で区分し、例えば製品管理、注文閲覧、データエクスポートなどです。ロールは権限ポイントを自由に組み合わせられます。こうすれば、後からロールを追加するのは設定だけで済み、リリースは不要です。
コーポレートサイト側も事前に明確にしておく必要があります。会員ログインが必要か、管理画面のアカウントと連携する必要があるか。コーポレートサイトに予約や申し込みといった機能がある場合、ユーザーデータと管理画面の顧客データは同一のものか別々か。この決定は、ミニプログラム開発やApp開発の段階で再利用できるかに影響します。
スケジュールは最後まで並行にせず、ピークをずらして納品する
多くのプロジェクトの失敗は、作れないからではなく、検収のリズムが乱れるからです。
コーポレートサイトと管理画面を同時に開発し、同時に納品するということは、同じ時期に二つの全く異なるものを検収する必要があるということです。テストリソースが足りず、問題が山積みになり、どの工程の責任か誰も説明できなくなります。
より現実的な進め方は、管理画面を先に利用可能なバージョンとして出し、コーポレートサイトを後から接続するというものです。管理画面でコンテンツ管理と主要な業務フローを先に通し、コーポレートサイトは実際のデータに直接接続してページを作ります。こうすれば、コーポレートサイトの検収時に見えるのは実データであり、ダミーデータではないため、問題がより早く露見します。
時間が迫っている場合は逆にすることもできます。コーポレートサイトを先に静的バージョンで公開して対外的な表示を確保し、管理画面を二期に分けて納品します。ただし、静的バージョンを公開した後、いつ管理画面に接続するかを明確にしておく必要があります。そうでなければ、長期的に二つのコンテンツを保守することになりがちです。
セキュリティとテストは最後に回さない
管理画面は社内データを扱うため、セキュリティテストをリリース一週間前まで待つことはできません。
基本項目には、ログイン失敗回数の制限、権限外アクセスのテスト、ファイルアップロードの種類検証、APIパラメータの検証が含まれます。これらは開発段階では低コストで実施できますが、リリース後に補うにはアーキテクチャの変更が必要になります。管理画面に対外APIがある場合、APIがバイパスできないか、パラメータが改ざんできないかを確認するリバーステストも必要です。
コーポレートサイト側では、フォーム送信とファイルアップロードに注目してください。多くの企業サイトがスパム問い合わせを大量に受け取るのは、フォームに基本的な検証がないためです。
MIC Studio に依頼するのが適しているケース
チームに専任のバックエンドやフロントエンドがいない場合、またはいてもスケジュールが埋まっている場合は、コーポレートサイトと管理画面をまとめて外部チームに任せるのは合理的です。
適しているケースは概ね次のとおりです。要件がすでに比較的明確で、どのデータを管理し、コーポレートサイトで何を表示するかを把握している。管理画面とコーポレートサイトで同じデータを使い、二つのコンテンツを保守したくない。今後ミニプログラム開発やApp開発も予定しており、基盤となるAPIを再利用したい。
あまり適さないケースは、要件がまだ頻繁に変わっており、管理するフィールドすら明確になっていない場合です。この段階では、直接開発するよりも要件の整理を先に行う方が割に合います。
MIC Studio はこの種のプロジェクトでは、まずデータ構造と権限設計を提示し、確認後にページとAPIの開発に進み、企業サイトと管理画面を同期して進めつつも別々に検収するという進め方をしています。
実行可能な三つの提案
第一に、プロジェクト立ち上げ時にまず一ページのデータ一覧を書くこと。 管理画面で管理するすべてのエンティティとフィールドを列挙します。図は不要で、文章で明確に列挙します。この一枚の紙が、後の要件変更の半分を防ぎます。
第二に、コーポレートサイトと管理画面を別々に検収すること。 管理画面で先に業務フローを通し、コーポレートサイトは実際のデータに接続します。両方が完成してからまとめてテストするのを待たないでください。
第三に、権限とセキュリティは開発段階で実施すること。 ロール権限ポイント構造、API検証、ログイン制限。これらはリリース前の仕上げ作業ではなく、アーキテクチャの一部です。
コーポレートサイトと管理画面を一緒に作ることは問題ありません。問題は、それらを二つのものとして計画しているかどうかです。