CMS選定の進め方
要件整理・評価表・デモ比較の実務手順

CMS選定でよくある失敗は、候補製品を先に決めてから、自社の要件を当てはめることです。製品デモを見ると、どのCMSにも魅力的な機能があり、必要な機能と「あれば便利な機能」の区別が難しくなります。

CMS選定は、製品比較の前に、サイトの目的、現在の課題、運用体制、必要な統制、移行範囲を整理する作業です。本記事では、企業サイトのリニューアルで使えるCMS選定の手順を、評価表やデモ比較の方法まで含めて解説します。

この記事のポイント

• 製品名を挙げる前に、目的・課題・運用体制を整理する
• 要件はMust・Should・Couldに分け、重み付けする
• デモは各社へ同じシナリオを依頼し、実務担当者が操作する
• 費用は見積もり範囲をそろえ、5年間の総費用で比較する

CMS選定は、次の7ステップで進めると、製品の印象や知名度に左右されにくくなります。

1. 目的と現状課題を整理する
2. 利用者・承認者・保守担当を可視化する
3. 要件をMust・Should・Couldに分ける
4. CMSタイプと候補製品を絞る
5. 評価表と配点を作る
6. 同じシナリオでデモを実施する
7. 見積もり・契約・移行リスクを比較する

「サイトを新しくしたい」「古いCMSを入れ替えたい」だけでは、評価軸を作れません。現在の業務やリスクを、改善したい状態へ置き換えます。

CMSを使用する人だけでなく、サイト運営に関係する人を整理します。広報、IR、人事、事業部、法務、情報システム、制作会社、サーバー会社などが対象です。

次に、代表的な更新作業について、「原稿作成」「CMS入力」「確認」「承認」「公開」「公開後確認」を誰が担うかを書き出します。現状と理想の両方を作ると、CMSで解決すべき業務が明確になります。

要件は、次の3段階に分けます。

Must：必須

満たさなければ候補から除外する条件。例：部門別権限、二段階承認、SSO、特定のセキュリティ基準。

Should：重要

選定評価へ大きく影響する条件。例：見たまま編集、複数サイト管理、操作サポート。

Could：あると望ましい

将来利用する可能性がある条件。例：多言語追加、MA連携、パーソナライズ。

「すべて必須」にすると、候補が極端に少なくなり、個別開発が増えます。逆に優先順位がないと、営業資料で目立つ機能に評価が引っ張られます。

候補製品を調べる前に、SaaS型、パッケージ型、オープンソース型、ヘッドレス型など、どのタイプが自社の運用方針に合うかを決めます。

例えば、基盤保守を任せて標準化したいならSaaS型、独自開発を重視するならパッケージ・オープンソース・ヘッドレス型が候補になります。この段階で3〜5製品程度に絞ると、詳細評価を行いやすくなります。

評価表には、評価項目、重要度、配点、判定基準、根拠、確認状況を含めます。「○・△・×」だけでは評価者によって基準が変わるため、点数の定義も決めます。

各社の標準デモを見るだけでは、操作性を比較できません。自社で頻度の高い作業をシナリオとして渡し、同じ条件で実演してもらいます。

• 既存ニュースを複製して公開日を予約する
• ページ内の画像とPDFを差し替える
• 担当者が申請し、上長が差し戻し・承認する
• 緊急時に公開中ページを修正する
• 新しいカテゴリやサイトを追加する
• 誤操作時に過去の状態へ戻す

デモには、管理職だけでなく実際の更新担当者も参加します。可能であれば、説明を受けた後に担当者自身が操作し、迷った箇所を記録します。

見積もりは、各社の対象範囲をそろえて比較します。CMSライセンスだけの見積もりと、デザイン・移行・サーバー・保守・サポートを含む見積もりを、そのまま比較してはいけません。

• 初期設計・デザイン・構築
• CMSライセンス・利用料
• サーバー・CDN・監視・バックアップ
• データ移行・リダイレクト・SEO移行
• 操作研修・マニュアル
• 保守・セキュリティ・バージョンアップ
• 追加改修・サイト追加・容量超過
• 解約・再移行時の費用

同時に、製品の提供終了、担当会社への依存、特定技術者の不足、データ移行の難しさなどのリスクも評価します。