CMS導入の全体像――要るかどうかの判断から、選定・構築・定着まで

CMSの導入は、製品を一つ選べば終わる話ではありません。そもそも要るのか、どの種類にするのか、誰がどう使うのか、いくらかけるのか、どう移し替えて公開するのか、そして導入したあと現場に根づくのか。判断することは、製品を比べる前から公開の後まで続きます。

CMSの導入と移行を扱うこのコーナーの記事を横断すると、共通した考え方が見えてきます。費用は相場の数字より、同じ条件で取った見積もりで比べる。仕組みは、使う人と運用体制から逆算して決める。セキュリティや保守は、提供事業者と自社のどちらがどこまでを持つかという責任の分界で考える。このページでは、この考え方を軸に、読み手が判断していく順に全体をまとめました。個別の論点を詳しく知りたいときは、文中のリンクから各記事へ進めます。

CMSは要るのか――ページ数より、更新の頻度と体制で考える

CMS（Content Management System）は、HTMLやCSSの知識がなくても、ブラウザ上の管理画面から文章や画像を登録してWebページを作成・更新できるシステムです。ページの内容と、デザインや共通部分の管理を分けることで、更新作業を担当者の手に取り戻すことを目的としています。

仕組みとしては、担当者が操作する管理画面、コンテンツや画像を保管するデータベース、データにデザインを流し込んでページの形に整えるテンプレート、プレビューや公開予約・公開と非公開の切り替えを制御する公開処理、の4つの要素に整理できます。製品によって呼び方や構成は異なりますが、土台にあるのは「入力と表示を分ける」という考え方です（CMS（コンテンツ管理システム）とは？）。

手作業のHTML管理でサイトを続けていると、次のような問題が起こり得ます。

• 軽微な修正でも外部の制作会社を通すことになり、時間と費用がかかる
• 「あの人しかHTMLを触れない」という属人化が起き、退職や異動のたびにリスクになる
• 共通部分（ヘッダーやお知らせ枠など）の変更を全ページに手作業で反映することになり、ページごとに新旧が混在する
• 誰がいつ何を変えたかの記録が残らない

CMSはこれらに対して、更新の内製化、権限と履歴の管理、共通部分の一元管理といった手段を提供します。どの問題を解消したいかが、選び方の出発点になります。

CMS導入・移行のよくある質問は、検討の目安を少し違う形で挙げています。更新を特定の人に依存していてその人がいないと止まる、誰がいつ何を変えたかの記録が必要になっている、共通部分の変更を全ページへ確実に反映したい、URL変更時のリダイレクト対応など手作業のミスを仕組みで防ぎたい。このうち複数が当てはまるなら、検討する価値がある、としています。

一方で、CMSを持たない選択もあります。ページ数よりも、更新頻度と体制で判断する考え方です。更新がほとんど発生しないサイトなら、CMSを持たない選択も合理的です。定期的に内容を書き換えるなら、規模が小さくても導入の検討に値します。

なお、ヘッダーのような共通部分をどこまでCMSで管理するかについては、CMSの設計を扱う別コーナーに、これとは違う前提の考え方があります。構築の節で両方を並べます。

種類の違いは「誰がどこを管理するか」の違い

CMSには、クラウド型（SaaS）、オンプレミス型、自社開発型、ヘッドレス型、ハイブリッド型といった区分があります。CMSの種類と違いは、この違いを費用の差としてよりも、システムのどの部分を誰が管理するかの違いとして捉えています。サーバーとソフトウェアの保守を提供事業者に任せるのか自社で持つのか、表示部分を製品に任せるのか自分たちで作るのか。この分担の違いが、費用の構造、カスタマイズの自由度、必要な体制に表れます。

区分を横断して比べるときの観点は、4つです。

• 立ち上げまでの速さ： 既製の範囲で使う構成ほど速く、開発を伴う構成ほど時間を要します。
• カスタマイズの自由度： 開発を伴う構成ほど高く、クラウド型は製品の範囲内に収まります。
• 保守の責任： クラウド型は事業者側の比重が大きく、オンプレミス型・自社開発型では自社側の比重が増えます。
• 必要な体制： ヘッドレス型と自社開発型は、開発体制を持つことが前提です。

絞り込むときは、次の順に確かめていきます。

1. Web以外への配信予定はあるか。アプリ等への展開があるなら、ヘッドレス型・ハイブリッド型が候補になります。
2. 保守体制を自社で持つか。持たない・任せたいなら、クラウド型が第一候補です。
3. 基幹システム連携など、独自要件はどの程度か。深い連携や作り込みが要るなら、オンプレミス型のパッケージや開発を伴う構成を検討します。

セキュリティも、分界の問題として考える

セキュリティについても、同じ「誰がどこを持つか」の見方が使われています。CMS自体が新たな管理対象になるのは事実ですが、古いファイルの放置や、更新されないシステムの使い続けにもリスクはあります。どちらが安全かは一概には言えず、どこまでを提供事業者が守り、どこからを自社が守るかの分界を明確にできる構成を選ぶ、という考え方が判断の軸になります。たとえばクラウド型なら、インフラは事業者側、アカウントと権限設定は自社側です。こうした責任の境界が、契約と運用の両方で明確になっている構成を選びます。

製品を見る前に、体制と要件を固める

CMS導入でつまずくパターンとして、CMSの選び方と導入準備は次の3つを挙げています。

• 導入後に、必要な承認フローが組めないと分かる
• 操作が現場に合わず、更新が止まる
• 初期費用だけで稟議を通し、翌年の運用費が確保できない

いずれも製品そのものではなく、選ぶ前の準備の段階で確かめられたはずのことです。また、CMS（コンテンツ管理システム）とは？は、製品の比較に入る前に次の3点を確認しておくと判断の軸になる、としています。

• 誰が使うのか。 更新を担うのが専任のWeb担当者か、各部署の兼任者かで、求める操作性は変わります。
• コンテンツの構造は決まっているか。 製品情報のように項目構成が決まっているコンテンツが中心か、コラムのように毎回構成が変わるコンテンツが中心かで、向く入力方式が変わります。
• 運用体制はどうなっているか。 承認を挟むのか、公開まで一人で完結するのか。組織の実態に合わない仕組みは、導入しても使われなくなるおそれがあります。

業種・規模・目的の3つの軸で洗い出す

要件は、業種・規模・目的の3つの軸で洗い出します。

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

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

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

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

「向く入力方式」は、業種の軸（項目を固定できる方式）にも目的の軸（書き手が迷わない方式）にも出てきます。どの方式をどのページに使うかの考え方は、CMSの設計を扱うCMS設計の実務指針で「ページ構成方式」として扱われています。

機能・非機能・運用の3つに分け、優先度を付ける

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

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

必須機能を絞り込めないときは、「これが無いと現在の業務のどれが止まるか」を一つずつ確かめる方法があります。判断に迷ったときの助言として、CMS導入・移行のよくある質問は、この問いで要件を3つに絞り込んでみることをすすめています。そうすると、必須と希望が分かれます。

費用は「構造」と「年数」で見る

種類ごとの費用の違いは、初期に重いか、継続に重いかという構造の違いとして表れます。クラウド型は初期が軽く、継続的な利用料が中心です。オンプレミス型や開発を伴う構成は、初期が重くなります。

予算は、初期費用だけでなく、利用料・保守・追加開発の予備まで含めた複数年の総額で組みます。使う期間が長くなるほど、総額に占めるランニング側の比重は上がります。軽微な修正のたびに外注費が発生する構成かどうかで、数年単位の総額は変わります。そのため、内製でどこまでできるかを確かめておきます。準備の節で挙げた「初期費用だけで稟議を通し、翌年の運用費が確保できない」というつまずきも、この点に関わります。

金額そのものは、同じ区分の中でも要件と構成によって変わります。費用を扱う3本の記事（種類と違い、選び方と導入準備、よくある質問）はいずれも、一般的な相場を先に見るより、自社の要件を固めたうえで、各社に同じ条件で見積もりを依頼することをすすめています。そうすると、同じ土俵で比べられます。

RFPとデモ――実際の担当者が、通しで試す

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

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

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

担当者本人が触ることには、もう一つの意味があります。日常の更新を技術者なしで行えるようにすることは、CMSという製品分類の主要な目的の一つです。ただし、実際にそれが成り立つかは製品と自社の体制によるため、更新を担当する本人がデモを操作して確かめます。カタログの記載だけでは分からない判断材料が、そこで得られます。

あわせて、技術者なしで回るとしても、そのまま何も要らないわけではありません。画像の扱いや著作権、公開前の確認といった基本的なWebリテラシーの教育は必要です。また、テンプレートの改修や外部連携など、構築側の作業には、自社か委託先に技術者が要ります。

実データで確かめる考え方は、CMSの設計の側で詳しく扱われています。こちらは製品を選ぶためのデモではなく、自社で作った設計を実コンテンツで検証する話です（CMS設計の実務指針・第7回）。

選んだ後が本番――構築の4つの工程

製品の選定が終わっても、プロジェクトは半分も終わっていません。CMS構築フェーズの実務は、構築を次の4つの工程に分けています。ここで決めた仕様は、公開後も長く使い続けることになります。

1. 情報設計・テンプレート設計：サイト全体の構造とページの雛形を定義する
2. 権限・承認フローの構築：誰が何をどこまでできるかを実装する
3. コンテンツ移行：既存サイトのデータを新しいCMSへ移す
4. 公開前後の確認・運用の立ち上げ：本番公開の最終チェックと初動体制

情報設計とテンプレート設計

ここで決め切れていない部分は、後の工程で手戻りの種になり得ます。コンテンツの種類ごとに必要な項目（タイトル、本文、公開日、メタ情報、絞り込み用の分類など）を定義し、テンプレートは、再利用性・入力のしやすさ・共通部分の一元管理を原則に設計します。

この工程の各論――入力方式の選び方、テンプレートの命名、共通パーツや項目の設計――は、CMSの設計を扱うコーナーでまとめて扱われています。全体像はCMS設計の総集編で読めます。構築に入る前に目を通しておくと、設計の議論の土台になります。

設計側の記事では、言葉の使い方が少し違います。CMSの仕組みを説明する際の「テンプレート」は、データにデザインを流し込む仕組みを指します。一方、CMS設計の前に押さえておくべき4つの構成要素では、設計の対象を「ページ（テンプレート）・パーツ・共通パーツ・項目」の4つに分け、テンプレートはページの種類ごとの単位を指しています。同じ「共通パーツ」も、設計側では製品情報や人物プロフィールのように、複数のページから参照される情報を指します。

ヘッダーなどの共通部分をどこまでCMSで管理するか

共通部分の扱いについては、このコーナーと設計側のコーナーで前提が違います。

• このコーナーの記事： 共通部分（ヘッダーやお知らせ枠など）の変更を全ページに手作業で反映することを、CMSがないと起きやすい問題の一つに挙げています。その一元管理はCMSが提供する手段の一つとされ、導入を検討する理由にも、テンプレート設計の原則にも入っています。また、「あの人しかHTMLを触れない」という属人化を、CMSで解消したい問題として挙げています。
• 設計側のヘッダー・フッターはCMS管理すべきか： ヘッダー・グローバルナビ、フッター、HTMLサイトマップは、CMSで自動管理するより直書きにすることを推奨しています。ヘッダーについては、一部のページだけナビの構成を変える、外部サイトへのリンクを混ぜる、キャンペーンを一時的に追加するといった変則対応が、実務では頻繁に出てくることを理由に挙げています。フッターの編集は頻度が低く、編集できるのは限られた担当者なので、HTMLを直接編集できる体制を整えておくほうが実務に合う、としています。自動化するか直書きにするかは、変則対応の頻度、編集者の人数とスキル、自動化で生じる制約、例外が出るかの4つの観点で、領域ごとに判断します。

どちらの記事も、もう一方の考え方には触れていません。このページでは、どちらかに寄せず、2つの考え方を並べるにとどめます。

権限と承認フロー

権限は、「管理者・編集者・作成者・閲覧者」のような階層で整理する方法があります。承認フローで注意したいのは、多忙な承認者のところで更新が止まることです。代理承認の仕組みや、コンテンツの重要度に応じたフローの分岐を、実装の前に設計へ含めておきます。

現場の実態に基づかないフローは、公開の速度を落とし、形骸化しかねません。「今の業務で実際に誰が確認しているか」から逆算する考え方が安全です。

コンテンツ移行

移行は、対象の量が多いうえに、機械的に済ませられない判断が混ざるため、工数を見積もりにくい工程です。全ページを完全に自動で移行できるとは限りません。

• 範囲に優先度を付ける。 全ページを同じ品質で移そうとすると、計画に無理が出やすくなります。主要ページは丁寧に移し、残りは機械的な移行やアーカイブにするなど、範囲と品質の割り切りを先に決めると、計画を立てやすくなります。
• URLの対応表を早い段階で作る。 URL構造が変わる場合、旧URLから新URLへの301リダイレクトが正確でないと、これまでの検索評価を引き継げなくなります。旧サイトの全URLを抽出し、1対1の対応表を、構築の終盤ではなく早い段階で確定させます。検索への影響に対しては、これが対策の中心です。
• アセットを整える。 画像やPDFは、移行を機にファイル名の規則を整えると、公開後のファイル管理がしやすくなります。

公開の前と後

公開直前には、リダイレクトの全パターンの動作、メタ情報の全ページへの反映、検証環境と本番の表示の差を確かめます。

公開後は、サーチコンソール等でリンク切れ（404）の発生を監視し、検索インデックスの状況とサーバーの負荷を確かめながら、運用の初動を固めます。公開してからしばらくは、この監視を運用の一部として続けます。

定着させる――役割ごとに教え、手間を測る

導入しても定着するかどうかは、記事の中では、教育と測定の2つの面から扱われています。

教育は、役割ごとに分ける考え方が実務的です。日常の更新を行う人、承認する人、権限やテンプレートを管理する人では、覚える範囲が違います。全員に全機能を教えるより、役割別の短い教育を用意する方法があります。

定着の指標は、自社で決めておく方法があります。たとえば「更新から公開までの操作数」や「承認にかかる時間」を導入前に測っておき、導入後に比べます。現場にとって以前より手間が増えていないかを、監視の対象にします。

全体を通して見えること

記事を横断すると、CMSの導入で考えることは、次の順に整理できます。

1. 更新の頻度と体制から、そもそも要るかを決める
2. 種類を、どこを誰が管理するかの違いとして比べる
3. 使う人と運用体制を起点に、要件を洗い出して優先度を付ける
4. 費用を、構造と複数年の総額で見て、同じ条件で見積もる
5. 実際の担当者が、実データに近いもので通しで試す
6. 構築の4つの工程で、長く使い続ける仕様を決める
7. 導入前後で手間を比べ、定着を確かめる

いくつもの段階に、同じ3つの考え方が出てきます。比べるときは相場ではなく同じ条件で比べること。仕組みは、使う人と運用体制から逆算すること。セキュリティや保守は、提供事業者と自社のどちらがどこまでを持つかで考えること。また、よく挙げられる導入のつまずき（承認フローが組めない、操作が現場に合わない、翌年の運用費が確保できない）は、製品そのものではなく、選ぶ前の準備の段階で確かめられたはずのことだ、という見方も示されています。

一方で、どこまでをCMSに任せ、どこを人の手に残すかについては、このコーナーと設計側のコーナーで前提の違うところがあります。構築の具体に進むときは、CMS設計の総集編もあわせて読むと、その違いを踏まえて判断できます。