CMS刷新で比較表だけでは判断できない理由 拡張性を整理して見積の前提を揃える
CMSを比較するときは、機能や価格に目が向きがちです。しかし、大企業のプロジェクトでは、運用開始に要件が増え、設計や調整が必要になることが少なくありません。 そのため、製品名ではなく、「どこまで拡張性があるか」という視点で比較することが重要です。
本記事では、拡張性を五つの観点に分け、比較するときの考え方を解説します。
目次
CMS選定で拡張性を先に定義すべき理由
大企業のCMSは、部門だけで使うのではなく、グループ会社やブランドへ展開するケースが多くあります。
その際に増えるのはページ数だけではありません。権限、承認フロー、テンプレートの管理ルール、連携先、監視項目が増え、運用の仕組みも複雑になります。
結果、見積が当初より増えたり、リリースの順番やスケジュールを見直したりすることがあります。
そのため、拡張性は後から考えるものではなく、最初に決めておく判断基準として扱うことが大切です。
社内の議論でも、拡張性は機能・性能・データ・連携・ユーザーインターフェース（UI）・開発運用に分けて整理する考え方が示されています。
拡張性を五つの観点に分解する
ここでは、意思決定に使いやすいよう、拡張性を次の五つに分けて整理します。必要な専門語には短い補足を付けます。
連携拡張性（APIカバレッジ）
連携拡張性は、APIの有無だけで判断するものではありません。どのデータを取得できるか、どのデータを更新できるかまで確認することが重要です。
社内共有でも、パッケージ製品はAPIの対応範囲が広い一方、SaaSでは利用できる範囲が限られる場合があることが議論されています。
この観点で増えるのは、確認する項目と代替手段案です。
参照だけでよいのか、更新まで必要なのかによって、設計項目が変わります。
更新が必要な場合は、認証方式、排他制御、再送方法、データの整合性を確認する手順まで要件に含めます。
運用拡張性（権限・承認・統制）
運用拡張性は、権限設計、承認フロー、監査ログ、テンプレートの管理ルールによって決まります。
部門をまたぐほど関係者が増え、公開までの調整回数も増えるため、役割分担と担当範囲を要件として明文化します。
具体的には、最上位管理者の権限範囲、承認段数、代理承認、緊急公開の方法、監査ログの保管期間を決めます。
これらを決めないまま開発を始めると、ルールを追加するたびに画面や権限の改修が必要になります。
性能拡張性（ピーク、検索、出し分け）
性能は応答速度だけではありません。
同時アクセス、検索、会員ごとの出し分けが重なると、キャッシュの仕組みや計測方法も設計項目になります。
社内共有でも、キャッシュやレンダリングの設計、計測ツールについて議論されており、性能要件を後回しにしないことの重要性が示されています。
性能要件を定義するときは、ピーク時の同時アクセス数、検索条件、出し分け条件、許容する応答時間を具体化します。
数値が決まるほど、監視項目やテスト範囲を決めやすくなり、関係者の合意も取りやすくなります。
UI・表現拡張性（ブランド表現と編集体験）
大企業サイトでは、ブランド表現の自由度と編集のしやすさを分けて評価すると整理しやすくなります。
SaaSでは管理画面を自由に変更できない場合が多いため、どこまで標準機能を使い、どこから独自開発するかを決める必要があります。
この観点で増えるのは、コンポーネント数とガイドラインです。
自由度が高いほど設計の選択肢は増えますが、設計ルールを決めないと、部品が増え続け、編集しにくくなります。
入力ルール、プレビュー、変更点の確認、公開前チェックの流れも合わせて設計します。
開発拡張性（標準化、CI/CD、移行）
開発拡張性は、開発メンバーが増えても品質を保てるかという観点です。
CI/CD、テスト、設定管理、移行手順まで標準化すると、追加機能を開発するときの作業時間や手戻りを減らせます。
社内共有でも、CI/CDやデータ移行について議論されています。
CMS刷新後の連携設計や、拡張を見据えたシステム構成について詳しく知りたい方は、バッチ・API開発の詳細ページもあわせてご覧ください。
LYZONのバッチ・API開発サービス
データ連携で複雑な業務フローを自動化
定期処理・外部API連携・データ同期まで対応。安定稼働を前提にしたバッチ・API設計の詳細はこちら。
誤解が生まれやすいポイントを先に整理する
Webhookでの拡張と製品内拡張は同じではない
SaaSではWebhookを利用して外部アプリで機能を追加する構成がよく使われます。
しかし、「外部に作れば何でもできる」と考えると、担当範囲や運用の負担を見落としやすくなります。
社内共有でも、「Webhookでつなげばできる」という説明だけでは、それがSaaSの機能ではなく外部アプリの機能である点が議論されています。
外部アプリが増えるほど、監視対象、障害時の切り分け、データ整合性を確認する手順も増えます。
そのため、拡張する場合は、保守の担当範囲と復旧手順まで決めておく必要があります。
データ拡張と同時に必要になる管理画面の拡張
データ項目を追加すること自体は、多くの方式で対応できます。
ただし、入力画面や編集画面も追加・変更する場合は、その分の開発作業が必要です。
どのデータを誰がどの頻度で編集するかを明確化し、編集者の負担が増えない設計にすることが、運用拡張性と合わせて重要です。
進め方の基本は「棚卸し」→「先回り検証」→「設計」
拡張性について話し合っても、進め方が決まっていないと判断が進みません。 次の順番で進めると、見積が増える原因を把握しやすくなります。
ステップ1 現状と要件を棚卸しする
サイト数、ブランド数、言語数、会員機能、申込・決済機能、連携先（CRM、会員DB、MA、EC、検索、分析）を一覧にします。そのうえで、どの観点の重要度が高いかを固定します。たとえば、マルチサイト統制が優先なら、権限とテンプレート統制を先に要件化します。
ステップ2 先回り検証で不確実性を減らす
先回り検証では、連携拡張性と性能拡張性を中心に確認します。APIは、実際に試して初めて分かる制約が見つかることもあるため、参照と更新の両方について利用できる範囲を確認し、代替手段（中間基盤、バッチ、イベント連携）も準備します。
この段階で確認しておくことで、後工程での追加調査や仕様変更を減らせます。一方で、初期段階では確認項目や関係者との合意作業が増えます。
ステップ3 設計で運用体制と責任分界を固定する
最後に、権限、承認、監査、ログ、障害時の切り分けを設計します。ログは量を増やすだけでは解決しません。障害発生時に、どの処理で何が起きたかを追える構造として定義すると、切り分け時間が短くなります。
チェックリスト（意思決定用）
以下は、比較表に落とすための確認項目です。項目を埋めるほど、関係者との調整が進めやすくなり、見積の前提も揃います。
- 連携拡張性：参照対象、更新対象、認証方式、レート制限、イベント連携、障害時の再送手順
- 運用拡張性：最上位管理者の権限範囲、承認段数、代理承認、監査ログ、テンプレート管理のルール
- 性能拡張性：ピーク時の同時アクセス数、検索負荷、出し分け条件、キャッシュ設計、計測指標、監視項目
- UI・表現拡張性：デザインの自由度、編集者の役割分担、入力ルール、プレビュー要件
- 開発拡張性：標準化の範囲、CI/CD、テスト方針、移行ステップ、リリース手順
変更耐性も拡張性とセットで評価する
変更耐性とは、変更したときに、どこへ影響するかを把握しやすい状態を指します。 拡張できる範囲が広い方式では、設計項目が増えるため、影響範囲を追いやすい構造を作る必要があります。一方、SaaSは変更できない部分が多い分、アップデートの影響範囲が限られやすいという考え方もあります。
大企業のプロジェクトでは、自由度と変更耐性のどちらを優先するかを最初に決めると、方式選定の議論を進めやすくなります。
参考：拡張が進むと何が増えるか
最後に、拡張が進むと増えやすい項目をまとめます。増える内容をあらかじめ把握しておくと、計画段階で関係者の合意を取りやすくなります。
- 設計項目：権限、承認、データ整合性、例外処理、復旧手順
- 関係者：編集部門、情報システム、セキュリティ、外部ベンダー、運用担当
- 運用手順：公開手順、緊急対応、監査、問い合わせ対応
- 監視項目：性能指標、連携エラーの検知、再送キュー、ログの保管と検索
- テスト範囲：回帰テスト、負荷試験、権限テスト、連携テスト
複数サイト統合では、CMSの方式以上に「情報設計」と「管理構造」が運用工数を左右します。LYZONでは、統合検討の初期段階から以下をご支援します。
- 統合対象の棚卸し（コンテンツ種別、更新頻度、運用体制、標準化対象の整理）
- ツリー型／リスト型の使い分け設計（主要領域と末端データ領域の整理）
- テンプレ標準化と例外設計（将来の移動・統合を前提にした設計）
- ガバナンス設計（権限・承認・命名・棚卸しの仕組み化）
LYZONでは、CMSを中心とした情報設計や、アプリ・外部システムとの連携開発をご支援しています。
検討初期でも、まずは現状把握と判断軸づくりから進められます。下記よりぜひご相談ください。
CMSの拡張性についてのよくある質問
Q1. 拡張性は何から確認すると判断が進みますか
まずは連携拡張性と運用拡張性を確認すると、関係者の前提を揃えやすくなります。連携は参照と更新に分けて確認し、運用は最上位管理者の権限範囲と承認フローを要件として明文化します。
Q2. SaaS型CMSでWebhook連携を想定していますが、何を要件に含めるべきですか
外部アプリ側の保守担当、障害時の切り分け手順、再送方法、監視項目、監査ログの保管先まで決めておきます。
Q3. データ項目の追加はどのように工数へ影響しますか
データ項目を追加すると、入力画面や編集画面、権限、監査ログ、データ移行についても対応が必要になります。編集する人と編集頻度を先に整理すると、必要な設計項目が決めやすくなります。
LYZONの拡張性重視のWeb設計
改修コストを大幅に抑える、柔軟な設計
コンテンツとシステムを分離した設計で機能追加・CMS変更に強い持続可能なWeb基盤を構築します。
株式会社LYZONの社内ニュースを始め、デザインの知識やお役立ち情報など様々な情報を発信しています。
