CMSの基本と導入準備【第4回】 CMS導入前に確認すべきチェックリスト：社内調整・要件定義の実務ガイド【2025年版】

CMS導入の成否は、選定前の準備で8割決まります。社内調整が不十分だと要件のすれ違いや予算超過が発生し、「使われないCMS」になりかねません。本記事では、ステークホルダー合意、予算確保、体制構築から機能・非機能・運用要件まで、導入前に確認すべきチェックリストを実務レベルで解説します。そのまま使える形式で、導入プロジェクトを成功に導きましょう。

対象： CMS導入プロジェクトのリーダー、Web担当者、情報システム部門、経営企画担当者

1. はじめに：なぜCMS導入前の準備が重要なのか
2. CMS導入の全体スケジュール
3. 社内調整のチェックリスト
4. 要件定義のチェックリスト
5. 要件定義書の作り方
- 5-1. 要件定義書の構成
- 5-2. 要件定義書作成のポイント
6. よくある失敗パターンと回避策
7. チェックリスト総まとめ
8. まとめ：準備が導入成功の鍵

1. はじめに：なぜCMS導入前の準備が重要なのか

1-1. CMS導入プロジェクトでよくある失敗

CMS導入プロジェクトは、以下のような理由で失敗するケースが少なくありません：

よくある失敗パターン：

要件が曖昧なまま選定を進めた → 導入後に「必要な機能がない」と判明
関係部署への事前説明が不足 → 導入後に現場から反発が出て使われない
予算が不十分 → 追加開発費用が出せず、中途半端な状態で運用開始
運用体制が未整備 → 担当者が決まらず、誰も更新しない
経営層の理解が得られていない → プロジェクトが途中で頓挫

これらの失敗の共通点は、選定前の準備不足です。

1-2. 事前準備で防げる問題

逆に、選定前に以下の準備を徹底すれば、多くの問題を未然に防げます：

事前準備で得られる効果：

要件の明確化 → 自社に最適なCMSを選べる
社内合意の形成 → スムーズな導入とスピーディな意思決定
予算の適正化 → 想定外のコスト発生を防ぐ
体制の構築 → 導入後も継続的に運用できる
リスクの洗い出し → トラブル発生時の対応策を事前に用意

本記事では、これらの準備を漏れなく進めるためのチェックリストを提供します。

1-3. 本記事の使い方

本記事は、以下の2つのパートで構成されています：

第1部：社内調整のチェックリスト（3章）

ステークホルダーの特定と合意形成
予算確保と承認プロセス
プロジェクト体制の構築
スケジュールとマイルストーン

第2部：要件定義のチェックリスト（4章）

現状分析
目標設定（KPI）
機能要件の整理
非機能要件の整理
運用要件の整理

各セクションのチェックリストを順番に確認していくことで、CMS導入の準備を漏れなく進められます。

2. CMS導入の全体スケジュール

まず、CMS導入プロジェクトの全体像を把握しましょう。標準的なスケジュールは以下の通りです：

CMS導入プロジェクトの標準スケジュール（6ヶ月の例）

【準備フェーズ（1〜2ヶ月）】← 本記事の対象
- Week 1-2：社内調整・ステークホルダー特定
- Week 3-4：現状分析・課題の洗い出し
- Week 5-6：要件定義・目標設定
- Week 7-8：予算確保・体制構築

【選定フェーズ（1〜2ヶ月）】
- Week 9-10：RFP作成・ベンダー選定
- Week 11-12：デモ・トライアル
- Week 13-14：最終選定・契約

【構築フェーズ（2〜3ヶ月）】
- Week 15-18：設計・開発
- Week 19-20：コンテンツ移行
- Week 21-22：テスト・調整

【移行フェーズ（1ヶ月）】
- Week 23-24：トレーニング・公開準備
- Week 25-26：本番移行・運用開始

重要： このスケジュールはあくまで目安です。企業規模や要件の複雑さによって、準備フェーズだけで3〜6ヶ月かかる場合もあります。

3. 社内調整のチェックリスト

CMS導入を成功させるには、技術的な選定よりも先に、社内の合意形成と体制構築が必要です。

3-1. ステークホルダーの特定と合意形成

CMS導入に関わる関係者（ステークホルダー）を特定し、それぞれの立場や要望を理解することが第一歩です。

ステークホルダー特定のチェックリスト：

【必ず関与させるべき部署・役職】
□ 経営層（最終意思決定者）を特定する
□ Web担当部署（マーケティング、広報等）を特定する
□ IT部門／情報システム部門を特定する
□ コンテンツ作成部署（各事業部、製品部門等）を特定する
□ 法務部門（契約・コンプライアンス）を特定する
□ 財務／経理部門（予算承認）を特定する

【必要に応じて関与させる部署】
□ カスタマーサポート部門を確認する
□ 営業部門を確認する
□ 人事部門（採用サイトの場合）を確認する
□ 海外拠点（多言語サイトの場合）を確認する

ステークホルダーごとの関心事項：

ステークホルダー	主な関心事項	合意を得るポイント
経営層	投資対効果、戦略適合性	ROI試算、競合比較、リスク対策
Web担当	使いやすさ、機能充足	デモ体験、業務効率化の具体例
IT部門	セキュリティ、保守性	技術仕様、運用負荷、既存システム連携
コンテンツ作成部署	更新の手軽さ、承認フロー	操作画面のシンプルさ、権限設定
法務部門	契約内容、データ保護	SLA、個人情報保護、利用規約
財務部門	総コスト、予算管理	5年間のTCO、分割払いの可否

合意形成のステップ：

【Step 1：キックオフミーティング】
□ プロジェクトの目的と背景を全体に共有する
□ 各部署の役割と責任範囲を明確化する
□ スケジュールの大枠を共有する

【Step 2：個別ヒアリング】
□ 各部署の現状の課題を聞き取る
□ CMSに求める要件を収集する
□ 懸念事項やリスク認識を確認する

【Step 3：要件の優先順位付け】
□ 全体で「必須」「重要」「あれば便利」を整理する
□ 相反する要件がある場合は調整する
□ 最終的な要件リストを合意する

【Step 4：定期報告】
□ 月1回以上の進捗報告会を設定する
□ 意思決定が必要な事項は早めに共有する
□ 変更があった場合は速やかに全体に通知する

失敗例と回避策：

失敗： Web担当部署だけで選定を進め、IT部門に事後報告。セキュリティ要件を満たしておらず、導入直前に経営層からストップがかかった。

理由： IT部門や法務部門への事前説明を怠り、技術的・法的リスクを見落とした。

回避策：

プロジェクト開始時に全ステークホルダーを集めたキックオフを実施
IT部門と法務部門には、選定基準の段階から参加してもらう
定期的な報告会で進捗と課題を共有

3-2. 予算確保と承認プロセス

CMS導入には、初期費用だけでなく、ランニングコストや運用費用も発生します。適切な予算を確保し、承認を得ることが重要です。

予算項目の洗い出しチェックリスト：

【初期費用】
□ CMSライセンス費用（買い切り／初期費用）を見積もる
□ サーバー構築費用（オンプレミスの場合）を見積もる
□ カスタマイズ・開発費用を見積もる
□ デザイン・テンプレート作成費用を見積もる
□ データ移行費用（既存サイトからの移行）を見積もる
□ トレーニング・研修費用を見積もる
□ コンサルティング費用（必要な場合）を見積もる

【ランニングコスト（年間）】
□ CMSライセンス費用（サブスクリプション）を見積もる
□ サーバー・ホスティング費用を見積もる
□ 保守・サポート費用を見積もる
□ SSL証明書更新費用を見積もる
□ CDN費用（必要な場合）を見積もる

【運用費用（年間）】
□ 社内担当者の人件費を見積もる
□ 外部委託費用（コンテンツ制作、保守等）を見積もる
□ 追加開発・機能拡張費用（予備費）を見積もる

【その他】
□ 既存システムの廃止費用を見積もる
□ 移行期間中の二重運用コストを見積もる

予算の試算例（中規模企業・クラウド型CMSの場合）：

※金額は参考値。要件・規模・契約条件により大きく変動します。

【初期費用】
- CMS初期費用：30万円
- カスタマイズ・開発：150万円
- デザイン・テンプレート：100万円
- データ移行：50万円
- トレーニング：20万円
合計：350万円

【年間ランニングコスト】
- CMS利用料：60万円
- サーバー・ホスティング：24万円
- 保守・サポート：36万円
合計：120万円

【5年間の総コスト】
初期：350万円
ランニング：120万円 × 5年 = 600万円
総計：950万円

予算承認プロセスのチェックリスト：

【事前準備】
□ 投資対効果（ROI）を試算する
□ 現状の課題とCMS導入で得られる効果を明確化する
□ 競合他社の事例を収集する
□ ベンダーから複数の見積もりを取得する

【承認資料の作成】
□ 導入の背景と目的を1ページにまとめる
□ 予算の内訳を明確に示す
□ 5年間のTCOを提示する
□ 想定されるリスクと対策を記載する
□ 導入スケジュールを示す

【承認プロセス】
□ 財務部門に事前相談する
□ 経営会議／予算会議の日程を確認する
□ 承認に必要な稟議書を準備する
□ 質問を想定した補足資料を用意する

【承認後】
□ 予算執行のタイミングを財務部門と調整する
□ 予算管理の担当者を明確化する
□ 予算超過時のエスカレーションルールを設定する

失敗例と回避策：

失敗： 初期費用のみで予算申請し、承認を得たが、年間ランニングコストを見落としていた。翌年の予算確保ができず、サポート契約を打ち切ることに。

理由： 5年間のTCO（Total Cost of Ownership）を試算せず、初期費用のみに注目した。

回避策：

初期費用とランニングコストの両方を明示
5年間のTCOを試算し、年度ごとの予算計画を立てる
予備費（初期費用の10〜20%）も確保しておく

3-3. プロジェクト体制の構築

CMS導入プロジェクトを推進するための体制を構築します。

プロジェクト体制のチェックリスト：

【プロジェクト組織の定義】
□ プロジェクトオーナー（最終意思決定者）を任命する
□ プロジェクトマネージャーを任命する
□ プロジェクトメンバーを選定する
□ 外部ベンダー／コンサルタントの役割を明確化する

【役割と責任の明確化】
□ 各メンバーの役割を文書化する
□ 意思決定の権限範囲を明確化する
□ エスカレーションルールを定義する
□ 作業時間の確保（兼務の場合は本業との調整）を確認する

【コミュニケーション体制】
□ 定例会議の頻度と参加者を決定する
□ 報告ルート（誰に・いつ・何を報告するか）を定義する
□ 情報共有の方法（メール、チャット、プロジェクト管理ツール等）を決定する
□ ドキュメント管理の方法を決定する

標準的なプロジェクト体制（中規模企業の例）：

【プロジェクトオーナー】
- 役割：最終意思決定、予算承認、経営層への報告
- 想定：マーケティング部長、情報システム部長、経営企画部長等

【プロジェクトマネージャー】
- 役割：プロジェクト全体の管理、スケジュール管理、課題解決
- 想定：Web担当マネージャー、IT担当マネージャー等
- 稼働：50〜100%（専任が理想）

【プロジェクトメンバー】
- Web担当（2〜3名）：要件定義、デザイン、コンテンツ移行
- IT担当（1〜2名）：技術評価、システム連携、セキュリティ
- コンテンツ担当（各部署から1名ずつ）：要件ヒアリング、コンテンツ作成
- 稼働：20〜50%（兼務）

【外部パートナー】
- CMSベンダー：製品提供、技術サポート
- 制作会社（必要に応じて）：デザイン、カスタマイズ、移行支援
- コンサルタント（必要に応じて）：要件定義支援、選定支援

失敗例と回避策：

失敗： プロジェクトマネージャーが通常業務と兼務で稼働が20%程度。スケジュール管理が疎かになり、プロジェクトが3ヶ月遅延。

理由： プロジェクトマネージャーの稼働時間を十分に確保せず、通常業務を優先してしまった。

回避策：

プロジェクトマネージャーは専任、または最低でも稼働50%以上を確保
通常業務の引き継ぎや代替要員の手配
経営層にプロジェクトの優先度を理解してもらう

3-4. スケジュールとマイルストーン

プロジェクト全体のスケジュールと、重要なマイルストーン（節目）を設定します。

スケジュール策定のチェックリスト：

【全体スケジュールの策定】
□ プロジェクト開始日を決定する
□ 本番公開の目標日を設定する（経営イベント、年度切り替え等を考慮）
□ 各フェーズの期間を設定する
□ バッファ（予備期間）を確保する（全体の10〜20%）

【マイルストーンの設定】
□ 要件定義完了日を設定する
□ CMS選定完了日を設定する
□ 設計完了日を設定する
□ 開発完了日を設定する
□ テスト完了日を設定する
□ コンテンツ移行完了日を設定する
□ 本番公開日を設定する

【リスク管理】
□ スケジュール遅延のリスク要因を洗い出す
□ 遅延時の対応策（スコープ調整、リソース追加等）を検討する
□ 定期的にスケジュールの進捗を確認する仕組みを作る

スケジュールテンプレート（6ヶ月プロジェクトの例）：

【Month 1-2：準備フェーズ】
Week 1-2：
- キックオフミーティング実施
- ステークホルダー特定
- 現状分析開始

Week 3-4：
- 課題の洗い出し完了
- 要件定義ワークショップ実施

Week 5-6：
- 要件定義書作成
- 予算承認取得

Week 7-8：
- RFP作成
マイルストーン：要件定義完了

【Month 3-4：選定フェーズ】
Week 9-10：
- ベンダー選定
- 提案書受領

Week 11-12：
- デモ・トライアル実施
- 評価・比較

Week 13-14：
- 最終選定
- 契約締結
マイルストーン：CMS選定完了

【Month 5：構築フェーズ】
Week 15-16：
- 詳細設計
- 開発環境構築

Week 17-18：
- カスタマイズ開発
- テンプレート作成

Week 19-20：
- コンテンツ移行
- 内部テスト
マイルストーン：開発完了

【Month 6：移行フェーズ】
Week 21-22：
- ユーザーテスト
- 修正対応

Week 23-24：
- トレーニング実施
- 本番環境準備

Week 25-26：
- 本番移行
- 公開
マイルストーン：本番公開

失敗例と回避策：

失敗： 「4月の新年度に合わせて公開」という要望があったが、準備期間が2ヶ月しかなく、要件定義が不十分なまま選定。結局、要件を満たせず、6月に再選定することに。

理由： 公開日から逆算せず、準備期間を十分に確保しなかった。

回避策：

本番公開日から逆算し、各フェーズに必要な期間を確保
最低でも準備フェーズ（社内調整+要件定義）に2ヶ月は確保
無理なスケジュールの場合は、公開日の延期を経営層に提案

4. 要件定義のチェックリスト

社内調整が完了したら、次は要件定義です。CMSに求める機能や性能を具体的に洗い出します。

4-1. 現状分析

現在のWebサイトやコンテンツ管理の実態を分析し、課題を明確化します。

現状分析のチェックリスト：

【現在のWebサイトの状況】
□ 現在のCMS（または管理方法）を確認する
□ ページ数を確認する
□ 月間PV数／UU数を確認する
□ 更新頻度を確認する（平均して週に何ページ更新しているか）
□ コンテンツの種類を確認する（記事、製品情報、ニュース、イベント等）

【運用体制の現状】
□ コンテンツ更新担当者の人数を確認する
□ 更新作業にかかる時間を確認する（1ページあたり）
□ 承認フローを確認する（何段階？誰が承認？）
□ 外部委託の有無と費用を確認する

【現在の課題】
□ 更新作業の課題を洗い出す（時間がかかる、ミスが多い等）
□ コンテンツ管理の課題を洗い出す（ファイルが散在、バージョン管理できない等）
□ 承認フローの課題を洗い出す（遅い、ボトルネックがある等）
□ デザイン・UI／UXの課題を洗い出す
□ SEOの課題を洗い出す
□ アクセシビリティの課題を洗い出す
□ セキュリティの課題を洗い出す

【定量的な課題】
□ 更新にかかる工数を計測する（月間○○時間）
□ 外部委託費用を確認する（年間○○万円）
□ 更新遅延の頻度を確認する（月に○回）
□ 誤公開の発生頻度を確認する（年に○回）

現状分析の手法：

1. ヒアリング： 実際にコンテンツ更新を行っている担当者に聞き取り

「どの作業に一番時間がかかっていますか？」
「どの機能が使いにくいですか？」
「理想的な運用はどのようなものですか？」

2. 作業の観察： 実際の更新作業を見学し、ボトルネックを特定

1ページ公開するまでに何ステップかかるか
どこで時間がかかっているか
どこでミスが発生しやすいか

3. データ分析： アクセス解析やログから定量的に把握

Google Analytics 4でPV数、UU数、滞在時間等を確認
検索順位の推移を確認
ページ表示速度を確認（PageSpeed Insights等）

失敗例と回避策：

失敗： Web担当者だけにヒアリングし、実際にコンテンツを更新する各部署の担当者の声を聞かなかった。導入後、「使いにくい」とクレームが続出。

理由： 実際のユーザー（コンテンツ更新担当者）の声を集めなかった。

回避策：

各部署のコンテンツ更新担当者全員にアンケートを実施
代表者数名に詳細ヒアリングを実施
実際の更新作業を見学し、課題を具体的に把握

4-2. 目標設定（KPI）

CMS導入で何を達成したいのか、具体的な目標を設定します。

目標設定のチェックリスト：

【定性的な目標】
□ 導入の目的を明確化する（例：業務効率化、コスト削減、SEO強化等）
□ 解決したい課題を優先順位付けする
□ 1年後の理想的な状態を描く

【定量的な目標（KPI）】
□ 更新工数の削減目標を設定する（例：月間50時間→25時間に削減）
□ 外部委託費の削減目標を設定する（例：年間200万円→100万円に削減）
□ 更新頻度の向上目標を設定する（例：週1回→週3回に増加）
□ PV数の向上目標を設定する（例：月間10万PV→15万PVに向上）
□ コンバージョン数の向上目標を設定する（例：問い合わせ月50件→75件に向上）
□ ページ表示速度の改善目標を設定する（例：3秒→1.5秒に短縮）

【ROI（投資対効果）の試算】
□ 削減される工数を金額換算する
□ 削減される外部委託費を算出する
□ 増加する売上・問い合わせを金額換算する
□ 5年間の効果合計を算出する
□ 投資額との比較でROIを算出する

KPI設定の例（中規模企業の場合）：

【業務効率化】
現状：コンテンツ更新に月間80時間
目標：月間40時間に削減（50%削減）
効果：年間480時間 × 人件費5,000円／時間 = 年間240万円削減

【外部委託費削減】
現状：年間300万円（デザイン修正、コンテンツ更新等）
目標：年間150万円に削減（50%削減）
効果：年間150万円削減

【コンバージョン向上】
現状：月間問い合わせ50件
目標：月間75件に向上（50%向上）
効果：年間300件増加 → 受注率20%で60件受注増 → 1件あたり100万円で6,000万円増収

【5年間のROI】
効果：（240万円 + 150万円）× 5年 = 1,950万円のコスト削減
投資：初期500万円 + ランニング100万円 × 5年 = 1,000万円
ROI：（1,950万円 - 1,000万円）／ 1,000万円 = 95%

※売上向上効果は含まず、コスト削減効果のみでもROI 95%

失敗例と回避策：

失敗： 「使いやすいCMSにしたい」という漠然とした目標だけで導入。導入後、効果測定ができず、経営層から「本当に効果があったのか？」と質問され、答えられなかった。

理由： 定量的なKPIを設定せず、効果測定の基準がなかった。

回避策：

必ず定量的なKPIを設定する
導入前の現状値を記録しておく
導入後、定期的にKPIを測定し、経営層に報告

4-3. 機能要件の整理

CMSに必要な機能を具体的に洗い出します。

機能要件のチェックリスト：

【コンテンツ管理機能】
□ コンテンツ作成機能を確認する（WYSIWYG、ブロックエディタ等の種類）
□ メディア管理機能（画像、動画、PDF等）を確認する
□ カテゴリ・タグ管理機能を確認する
□ バージョン管理機能（過去の版に戻せるか）を確認する
□ 公開予約機能（指定日時に自動公開）を確認する
□ 下書き保存機能を確認する

【承認ワークフロー】
□ 承認の段階数を決定する（1段階？2段階？3段階以上？）
□ 承認者の設定方法を確認する（役職別？部門別？）
□ 差し戻し機能を確認する
□ コメント機能（承認時のフィードバック）を確認する
□ 承認状況の可視化を確認する

【権限管理】
□ 必要な権限の種類を決定する（管理者、編集者、ライター等）
□ 権限ごとにできる操作を定義する
□ 部門別・拠点別の権限設定が必要かを確認する

【SEO機能】
□ メタ情報（title、description）の設定機能を確認する
□ URL構造のカスタマイズ機能を確認する
□ サイトマップの自動生成機能を確認する
□ 構造化データの設定機能を確認する
□ リダイレクト設定機能を確認する

【多言語対応】
□ 対応言語数を決定する
□ 言語ごとのコンテンツ管理方法を確認する
□ 翻訳ワークフローの要否を確認する
□ 言語切り替えUIの要件を確認する

【外部システム連携】
□ 連携が必要なシステムを洗い出す（CRM、MA、EC、基幹システム等）
□ 連携方法（API、CSV、手動等）を確認する
□ リアルタイム連携の要否を確認する

【検索機能】
□ サイト内検索の要否を確認する
□ 検索対象（全文検索？タイトルのみ？）を決定する
□ 絞り込み検索（ファセット検索）の要否を確認する

【フォーム機能】
□ 問い合わせフォームの要否を確認する
□ 資料請求フォームの要否を確認する
□ その他のフォーム（アンケート、イベント申し込み等）の要否を確認する
□ フォームの項目カスタマイズ機能を確認する
□ 自動返信メール機能を確認する

【アクセス解析】
□ Google Analytics 4との連携を確認する
□ CMSダッシュボードでの簡易分析機能の要否を確認する

【その他の機能】
□ A／Bテスト機能の要否を確認する
□ パーソナライゼーション機能の要否を確認する
□ 会員限定エリアの要否を確認する
□ ECカート機能の要否を確認する

機能要件の優先順位付け：

機能要件を「必須」「重要」「あれば便利」の3段階に分類します。

【必須機能】
- これがないとCMSとして機能しない
- 業務上、代替手段がない
- 例：コンテンツ作成機能、公開機能、権限管理

【重要機能】
- ないと業務効率が大幅に低下する
- 代替手段はあるが、非効率
- 例：承認ワークフロー、公開予約、バージョン管理

【あれば便利な機能】
- あると業務が楽になる
- なくても運用は可能
- 例：A／Bテスト、パーソナライゼーション

失敗例と回避策：

失敗： 「あれもこれも」と全ての機能を「必須」に設定。結果、条件を満たすCMSが見つからず、選定が難航。

理由： 優先順位をつけず、すべての要望を同列に扱った。

回避策：

「必須」は本当に不可欠な機能に絞る（全体の30%程度）
「あれば便利」は選定の決め手にしない
予算やスケジュールとのバランスを考慮

4-4. 非機能要件の整理

機能以外の要件（性能、セキュリティ、可用性等）を整理します。

非機能要件のチェックリスト：

【性能要件】
□ 想定月間PV数を設定する
□ 同時アクセス数の上限を設定する
□ ページ表示速度の目標を設定する（例：TTFB 200ms以下）
□ 管理画面の応答速度の目標を設定する

【セキュリティ要件】
□ SSL証明書の要件を確認する（標準？EV？）
□ WAF（Web Application Firewall）の要否を確認する
□ 二段階認証の要否を確認する
□ IPアドレス制限の要否を確認する
□ セキュリティ監査の頻度を確認する
□ 脆弱性対応のSLAを確認する

【可用性要件】
□ 稼働率の目標を設定する（例：99.9%以上）
□ ダウンタイムの許容時間を設定する
□ バックアップの頻度を設定する（日次？週次？）
□ 復旧時間の目標を設定する（RTO：Recovery Time Objective）
□ データ損失の許容範囲を設定する（RPO：Recovery Point Objective）

【拡張性要件】
□ 将来のページ数増加を想定する（3年後、5年後）
□ 将来のPV数増加を想定する
□ 将来の機能追加の可能性を考慮する
□ マルチサイト展開の可能性を考慮する

【互換性要件】
□ 対応ブラウザを決定する（IE11対応は必要？）
□ モバイル対応の要件を確認する（レスポンシブ？別サイト？）
□ 既存システムとの連携要件を確認する

【運用要件】
□ バックアップ方法を確認する（自動？手動？）
□ 復旧手順を確認する
□ 監視方法を確認する（稼働監視、エラー監視）
□ 障害時の連絡フローを確認する

【コンプライアンス要件】
□ 個人情報保護法への対応を確認する
□ Cookie規制への対応を確認する
□ アクセシビリティ対応（JIS X 8341-3等）の要否を確認する
□ 業界固有の規制（薬機法、金融商品取引法等）への対応を確認する

非機能要件の具体例：

【性能要件の例】
- 月間PV数：100万PV
- 同時アクセス数：500人
- ページ表示速度：TTFB 200ms以下、LCP 2.5秒以下
- 管理画面応答速度：1秒以内

【セキュリティ要件の例】
- SSL証明書：標準（ドメイン認証）以上
- WAF：導入必須
- 二段階認証：管理者のみ必須
- セキュリティパッチ：脆弱性発見後7日以内に適用

【可用性要件の例】
- 稼働率：99.9%以上（年間ダウンタイム8.76時間以内）
- バックアップ：日次自動バックアップ
- RTO：4時間以内
- RPO：24時間以内（前日分のバックアップから復旧）

失敗例と回避策：

失敗： 非機能要件を明確にせず選定。導入後、アクセス集中時にサイトが落ち、機会損失が発生。ベンダーに相談したが、「契約に含まれていない」と言われ、追加費用が発生。

理由： 性能要件や可用性要件を契約前に明確化しなかった。

回避策：

RFPに非機能要件を明記
SLA（Service Level Agreement）を契約に含める
想定を上回るアクセス時の対応策を事前に確認

4-5. 運用要件の整理

導入後の運用体制や運用方法を事前に検討します。

運用要件のチェックリスト：

【運用体制】
□ 運用責任者を決定する
□ 日常的なコンテンツ更新担当者を決定する
□ システム管理者を決定する
□ 障害対応の担当者を決定する
□ 外部委託の範囲を決定する

【運用ルール】
□ コンテンツ公開のルールを策定する（承認フロー、公開基準等）
□ 更新頻度の目標を設定する
□ 定期的なコンテンツ見直しのルールを策定する
□ 画像・ファイルの命名規則を策定する

【教育・トレーニング】
□ 初回トレーニングの計画を立てる（誰に？何時間？）
□ マニュアル作成の要否を確認する
□ 定期的なスキルアップ研修の要否を確認する
□ 新任担当者向けのオンボーディング計画を立てる

【サポート体制】
□ ベンダーのサポート内容を確認する（電話？メール？チャット？）
□ サポート対応時間を確認する（平日のみ？24時間365日？）
□ レスポンスタイム（回答までの時間）を確認する
□ サポート費用を確認する

【保守・メンテナンス】
□ CMSのバージョンアップ頻度を確認する
□ バージョンアップ作業の負荷を確認する
□ セキュリティパッチの適用方法を確認する
□ 定期的なバックアップ確認の計画を立てる

【効果測定】
□ KPIの測定頻度を決定する（月次？四半期？）
□ 効果測定のレポート作成担当者を決定する
□ 経営層への報告頻度を決定する

運用体制の例（中規模企業）：

【運用責任者】
- 役割：運用全体の統括、予算管理、経営層への報告
- 人数：1名
- 想定：Webマーケティング部長

【システム管理者】
- 役割：CMS設定、権限管理、システム連携、障害対応
- 人数：1〜2名
- 想定：IT部門担当者

【コンテンツ管理者】
- 役割：コンテンツ戦略、更新計画、品質管理
- 人数：1〜2名
- 想定：Webマーケティング担当者

【コンテンツ編集者】
- 役割：日常的なコンテンツ更新、承認申請
- 人数：各部署から1名ずつ（合計5〜10名）
- 想定：各部署の広報担当、製品担当等

【外部委託】
- デザイン修正：制作会社（月額10万円）
- システム保守：ベンダー（月額5万円）

失敗例と回避策：

失敗： 運用体制を決めずに導入。導入後、「誰が更新するのか」「障害が起きたら誰が対応するのか」が不明確で、混乱が発生。

理由： 導入することだけに注力し、導入後の運用を考えていなかった。

回避策：

導入前に運用体制を明確化
役割と責任を文書化し、全員に共有
トレーニング計画を立て、導入前に実施

5. 要件定義書の作り方

洗い出した要件を文書化し、関係者で合意を形成します。

5-1. 要件定義書の構成

要件定義書の標準構成：

1. プロジェクト概要
   1-1. 背景と目的
   1-2. プロジェクト体制
   1-3. スケジュール

2. 現状分析
   2-1. 現在のWebサイトの状況
   2-2. 運用体制の現状
   2-3. 課題の整理

3. 目標設定
   3-1. 定性的な目標
   3-2. 定量的な目標（KPI）
   3-3. ROIの試算

4. 機能要件
   4-1. 必須機能
   4-2. 重要機能
   4-3. あれば便利な機能

5. 非機能要件
   5-1. 性能要件
   5-2. セキュリティ要件
   5-3. 可用性要件
   5-4. 拡張性要件

6. 運用要件
   6-1. 運用体制
   6-2. 運用ルール
   6-3. 教育・トレーニング計画

7. 制約条件
   7-1. 予算
   7-2. スケジュール
   7-3. 技術的制約

8. リスクと対策
   8-1. 想定されるリスク
   8-2. 対策案

9. 承認
   9-1. 承認者
   9-2. 承認日

5-2. 要件定義書作成のポイント

作成時のチェックリスト：

【明確性】
□ 曖昧な表現を避ける（「使いやすい」→「非エンジニアが1時間のトレーニングで記事公開できる」）
□ 定量的に表現する（「速い」→「TTFB 200ms以下」）
□ 誰が読んでも同じ理解になるように書く

【具体性】
□ 具体例を示す（「承認ワークフロー」→「広報担当が起票→部長が承認→公開」）
□ 画面イメージを添付する（参考サイトのスクリーンショット等）

【優先順位】
□ 各要件に優先度をつける（必須／重要／あれば便利）
□ 優先度の理由を記載する

【実現性】
□ 技術的に実現可能かをIT部門に確認する
□ 予算内に収まるかを確認する

【合意形成】
□ ドラフトを関係者全員に共有する
□ フィードバックを反映する
□ 最終版を全員に承認してもらう

失敗例と回避策：

失敗： 要件定義書を作成したが、技術的に難解で、非エンジニアの承認者が理解できず、承認が遅延。

理由： IT部門の視点だけで書き、非エンジニアへの配慮が不足。

回避策：

専門用語には必ず注釈をつける
図や画像を多用して視覚的に理解しやすくする
経営層向けのサマリー（1〜2ページ）を別途作成

6. よくある失敗パターンと回避策

CMS導入前の準備でよくある失敗パターンと、その回避策をまとめます。

6-1. 失敗パターン1：ステークホルダーの巻き込み不足

失敗例：
Web担当部署だけで選定を進め、IT部門やコンテンツ作成部署への説明が後回しに。導入直前に「使いにくい」「セキュリティが心配」とクレームが出て、プロジェクトが停滞。

理由：

関係部署への事前説明を怠った
各部署の要望を聞き取らなかった

回避策：

プロジェクト開始時に全ステークホルダーを特定
キックオフミーティングで全員に目的と役割を共有
定期的な報告会で進捗を共有

6-2. 失敗パターン2：要件が曖昧なまま選定

失敗例：
「使いやすいCMSがほしい」という漠然とした要件だけで選定。導入後、「この機能がない」「あの機能が使いにくい」と不満が続出。

理由：

要件定義を怠り、具体的な機能を洗い出さなかった
優先順位をつけなかった

回避策：

要件定義に十分な時間（最低1ヶ月）をかける
各部署にヒアリングし、具体的な機能要件を洗い出す
必須／重要／あれば便利の3段階で優先順位をつける

6-3. 失敗パターン3：予算の見積もりが甘い

失敗例：
初期費用のみで予算申請し、承認を得た。しかし、ランニングコストやカスタマイズ費用を見落とし、翌年の予算確保ができず、機能が中途半端なまま運用。

理由：

5年間のTCOを試算しなかった
ランニングコストや予備費を考慮しなかった

回避策：

初期費用、ランニングコスト、予備費を含めた5年間のTCOを試算
予算申請時に全体像を提示
予備費として初期費用の10〜20%を確保

6-4. 失敗パターン4：運用体制が未整備

失敗例：
CMSを導入したが、「誰が更新するのか」「障害が起きたら誰が対応するのか」が不明確。結局、誰も更新せず、サイトが放置状態に。

理由：

導入前に運用体制を決めなかった
トレーニング計画がなかった

回避策：

導入前に運用責任者、管理者、編集者を明確化
役割と責任を文書化
導入前にトレーニングを実施し、全員が使えるようにする

6-5. 失敗パターン5：スケジュールが楽観的すぎる

失敗例：
「4月の新年度に合わせて公開」という要望に合わせ、2ヶ月の超短期スケジュールで進行。要件定義が不十分で、導入後に作り直しが必要に。

理由：

公開日から逆算せず、準備期間を十分に確保しなかった
各フェーズに必要な期間を過小評価した

回避策：

本番公開日から逆算し、各フェーズに必要な期間を確保
準備フェーズ（社内調整+要件定義）に最低2ヶ月は確保
無理なスケジュールの場合は、公開日の延期を提案

7. チェックリスト総まとめ

本記事で紹介したチェックリストを1つにまとめました。印刷して使えるPDF版もダウンロードできます。

CMS導入前チェックリスト（総まとめ）

【社内調整】
□ ステークホルダーを特定する
□ キックオフミーティングを実施する
□ 各部署にヒアリングを実施する
□ 予算の内訳を明確にする
□ 5年間のTCOを試算する
□ 予算承認を取得する
□ プロジェクトオーナーを任命する
□ プロジェクトマネージャーを任命する
□ プロジェクトメンバーを選定する
□ 全体スケジュールを策定する
□ マイルストーンを設定する

【要件定義】
□ 現在のWebサイトの状況を確認する
□ 運用体制の現状を確認する
□ 現在の課題を洗い出す
□ 定性的な目標を設定する
□ 定量的な目標（KPI）を設定する
□ ROIを試算する
□ 機能要件を洗い出す
□ 機能要件の優先順位をつける
□ 非機能要件を整理する
□ 運用要件を整理する
□ 要件定義書を作成する
□ 要件定義書の承認を得る

【次のステップ】
□ RFPを作成する
□ ベンダー選定を開始する