CMS刷新の比較表が機能しない理由 拡張性を定義して見積の前提を揃える

CMSの導入や切り替えを検討するとき、比較表に並ぶのは機能一覧や価格になりがちです。しかし大企業の案件では、稼働後に要件が増える確率が高く、当初の前提から外れた瞬間に、追加の設計項目や関係者調整が一気に増えます。たとえば、公開運用から始まり、出し分け、会員登録、申込、変更、決済へと段階的に広がると、権限設計や監視項目、テスト範囲が増えます。こうした増え方を前提に意思決定するためには、製品名ではなく拡張性を判断軸として整理する必要があります。

本記事では、拡張性を五つの観点に分解し、要件整理から先回り検証までを一連の手順としてまとめます。ベンダー比較に使えるチェックリストも用意しました。

大企業のCMSは、部門単位の導入で終わらず、グループ会社やブランドに展開する流れが発生しやすいです。その過程で増えるのはページ数だけではありません。権限、承認フロー、テンプレートの統制、連携先、監視項目が増え、運用体制の要件が上がります。結果として、当初の見積が上振れし、リリース順やスケジュールも見直しが必要になります。

拡張性は後から足すための便利な言葉ではなく、最初に前提として置くべき判断軸です。社内の議論でも、拡張性を機能・性能・データ・連携・UI・開発運用に分けて捉える整理が示されています。

ここでは、意思決定に使えるように、拡張性を次の五つへ分けます。必要な専門語には短い補足を付けます。

連携拡張性（APIカバレッジ）

連携拡張性は、APIがあるかどうかではなく、どのデータを参照でき、どのデータを更新できるかを範囲として捉えます。社内共有でも、パッケージ側はAPIのカバレッジが高い一方で、SaaS側は範囲が限定されることがある点が議論されています。

ここで増えるのは、確認項目と代替案です。参照だけでよいのか、更新まで必要なのかで、設計項目が変わります。更新が必要なら、認証方式、排他制御、再送、整合性の確認手順まで要件に含めます。

運用拡張性は、権限設計、承認フロー、監査ログ、テンプレートの統制によって決まります。部門をまたぐほど関係者が増え、公開までの調整回数が増えるため、役割分担と責任分界を要件として明文化する必要があります。

具体的には、最上位管理者の権限範囲、承認段数、代理承認、緊急公開の扱い、監査ログの保管期間を決めます。ここが未定のまま開発に入ると、後からルールを追加するたびに画面や権限の改修が増えます。

性能拡張性（ピーク、検索、出し分け）

性能は応答速度だけではありません。同時アクセス、検索、会員の出し分けが重なると、キャッシュ戦略や計測が設計項目として増えます。社内共有では、キャッシュやレンダリングの設計、計測ツールの話が出ており、性能要件を後回しにしない重要性が示されています。

性能要件を定義するときは、ピーク同時数、検索クエリの種類、出し分け条件の数、許容応答時間を具体化します。数値が決まるほど、監視項目とテスト範囲が固定され、関係者の合意が取りやすくなります。

UI・表現拡張性（ブランド表現と編集体験）

大企業サイトでは、ブランド表現の自由度と編集体験を分けて評価すると整理しやすくなります。SaaSは管理画面のカスタマイズができない場合が多く、自由度を求める場合は、どこまでを標準で賄い、どこからを個別実装にするかの判断が必要になります。

この観点で増えるのは、コンポーネント数とガイドラインです。自由度が高いほど設計余地は増えますが、設計を定義しないと、部品が増殖して編集体験が低下します。入力制約、プレビュー、差分確認、公開前チェックの手順も合わせて設計します。

開発拡張性（標準化、CI/CD、移行）

開発拡張性は、開発者が増えたときに品質がぶれないかという観点です。CI/CD、テスト、設定管理、移行手順の整備を含めて標準化できると、追加機能の実装コストと手戻りが減ります。社内共有では、CI/CDやデータ移行に関する論点が話題に挙がっています。

SaaSではWebhookを使い外部アプリで機能を追加する構成が語られます。一方で、外部に作れば何でもできるという説明だけでは、責任分界と運用工数が見落とされやすくなります。社内共有でも、Webhookでつなげばできるという説明は、それはSaaS側の機能ではなく外部アプリの機能であるという論点が示されています。

外部アプリを増やすほど、監視対象、障害時の切り分け手順、データ整合の確認手順が増えます。拡張を採用する場合は、保守の担当範囲と復旧手順まで要件として定義します。

データ拡張と同時に必要になる管理画面の拡張

データ項目を増やすこと自体は多くの方式で可能です。ただし、入力・編集といった管理画面の開発も必要な場合はその分工数がかかります。

どのデータを誰がどの頻度で編集するかを明確化し、編集者の作業量が増えない設計にすることが、運用拡張性とセットで重要になります。

拡張性を議論しても、進め方が曖昧だと判断が先送りになります。次の順序で進めると、上振れ要因が見えやすくなります。

ステップ1 現状と要件を棚卸しする

まず対象を特定します。サイト数、ブランド数、言語数、会員の有無、申込や決済の有無、連携先（CRM、会員DB、MA、EC、検索、分析）を一覧化します。そのうえで、どの観点が重要度が高いかを固定します。たとえば、マルチサイト統制が優先なら、権限とテンプレート統制を先に要件化します。

ステップ2 先回り検証で不確実性を減らす

先回り検証では、連携拡張性と性能拡張性を中心に検証します。APIの範囲は、実装して初めて分かる制約が出ることがあるため、参照と更新の両方について取れる項目を確認し、代替案（中間基盤、バッチ、イベント連携）を準備します。

ここで減らせるのは、後工程での追加検証と仕様変更の回数です。増えるのは、初期の確認項目と関係者合意の作業量です。

ステップ3 設計で運用体制と責任分界を固定する

最後に、権限、承認、監査、ログ、障害時の切り分けを設計します。ログは量を増やすだけでは解決しません。障害発生時に、どの処理で何が起きたかを追える構造として定義すると、切り分け時間が短くなります。

以下は、比較表に落とすための確認項目です。項目を埋めるほど、関係者調整の論点が減り、見積の前提が揃います。

• 連携拡張性：参照対象、更新対象、認証方式、レート制限、イベント連携、障害時の再送手順
• 運用拡張性：最上位管理者の権限範囲、承認段数、代理承認、監査ログ、テンプレート統制のルール
• 性能拡張性：ピーク同時数、検索負荷、出し分け条件、キャッシュ設計、計測指標、監視項目
• UI・表現拡張性：デザイン自由度の許容値、編集者の役割分担、入力制約、プレビュー要件
• 開発拡張性：標準化の範囲、CI/CD、テスト方針、移行ステップ、リリース手順

変更耐性とは、変更したときにどこへ影響が出るかを把握しやすい状態を指します。拡張できる範囲が広い方式は、設計項目が増える分、影響範囲を追える構造を作る必要があります。一方で、SaaSは触れない領域が多い分、アップデートによる影響が限定されやすいという見方もあります。

大企業のプロジェクトでは、自由度と変更耐性のどちらを優先するかを先に決めると、方式選定の議論が収束しやすくなります。

最後に、拡張が進むと増えやすい論点を列挙します。増える対象が見えるほど、計画段階の合意が取りやすくなります。

• 設計項目：権限、承認、データ整合、例外処理、復旧手順
• 関係者：編集部門、情報システム、セキュリティ、外部ベンダー、運用担当
• 運用手順：公開手順、緊急対応、監査、問い合わせ対応
• 監視項目：性能指標、連携の失敗検知、再送キュー、ログの保管と検索
• テスト範囲：回帰テスト、負荷試験、権限テスト、連携テスト

複数サイト統合では、CMSの方式以上に「情報設計」と「管理構造」が運用工数を左右します。LYZONでは、統合検討の初期段階から以下をご支援します。

• 統合対象の棚卸し（コンテンツ種別、更新頻度、運用体制、標準化対象の整理）
• ツリー型／リスト型の使い分け設計（主要領域と末端データ領域の整理）
• テンプレ標準化と例外設計（将来の移動・統合を前提にした設計）
• ガバナンス設計（権限・承認・命名・棚卸しの仕組み化）

検討初期でも、まずは現状把握と判断軸づくりから進められます。統合方針が固まっていない段階でもご相談ください。