選定は「準備」から始まる

CMS導入でつまずくパターンとしてよく挙げられるものには、共通点があります。導入後に必要な承認フローが組めないと判明する。操作が現場に合わず更新が止まる。初期費用だけで稟議を通して翌年の運用費が確保できない。いずれも製品そのものではなく、選定前の準備の段階で確認できたはずのことです。

この記事では、要件を整理する3つの軸と、要件定義からRFP・デモ評価までの進め方をまとめます。

3つの軸で要件を洗い出す

業種の軸

業種には、法律や商習慣に由来する「外せない要件」があります。

  • 製造業・型番の多い事業:製品情報の構造化管理と検索性。項目を固定できる入力方式が要点になります
  • 製薬・医療:公開前の承認フロー、誰がいつ何を変えたかの記録、閲覧範囲の制御。規制対応をシステム上で担保できるかを確認します
  • 小売・EC:キャンペーンの更新頻度と、アクセス集中への耐性
  • サービス業:コンテンツ発信のしやすさと、実績・事例の管理

自社の業種で「これがないと業務が成立しない」機能を先に特定しておくと、候補を絞りやすくなります。

規模の軸

規模の違いは、機能よりもまず体制の要件に表れます。更新者が数人か数十人か、部署をまたぐか、承認が何段階か。運用に関わる人数と役割が増えるほど、権限管理と承認まわりの要件が重くなります。

目的の軸

  • コーポレートサイト:正確さと統制。権限管理の細かさを重視します
  • オウンドメディア:更新のしやすさ。書き手が迷わない入力方式を重視します
  • 多言語・グローバル:言語ごとのURL構造と、翻訳の運用フローが要件になります

要件定義の3分類

洗い出した要件は、次の3分類で整理し、「必須・重要・あれば良い」の優先順位をつけます。

  • 機能要件:入力方式、メディア管理、版の管理、承認フロー、公開予約、メタ情報管理、リダイレクト設定、外部連携など
  • 非機能要件:想定アクセス数、表示速度、稼働率、バックアップ、障害時の復旧など
  • 運用要件:誰が更新するか、承認は何段階か、教育をどう行うか

必須機能を絞り込めないときは、「これが無いと現在の業務のどれが止まるか」を一つずつ確認する方法があります。

費用は総額で見る

初期費用だけでなく、利用料・保守・追加開発の予備まで含めた複数年の総額で予算を組みます。金額は要件と構成によって変わるため、要件を固めた上で各社に同じ条件で見積もりを依頼すると、同じ土俵で比較できます。

RFP(提案依頼書)とデモ評価

要件が固まったら、RFPに落とし込んでベンダーに渡します。最低限、解決したい課題・必須機能・制約条件(既存システムや公開時期)を明記します。

デモでは、画面のきれいさではなく、実際の運用シーンを試します。

  • 実際に更新を担当する人がデモを操作する
  • 自社の実コンテンツに近いデータで、登録から承認・公開までを通しで確認する
  • 一括更新など、量のある作業を確認する

設計を実データで検証する考え方は、CMS設計の実務指針・第7回で詳しく扱っています。また、実際の導入検討で交わされた質問と回答は検討リファレンスにまとまっています。準備段階の答え合わせに使えます。