このシリーズについて

CMSの選択肢は年々増え、ブロックを積み上げてページを作れる仕組みも、いまや多くの製品で標準的な機能になりました。新しくサイトを作るとき、あるいはリニューアルを考えるとき、「どのCMSを選ぶか」「どう作るか」で考えることは多いと思います。

このシリーズでは、長く使い続けられるCMSをどう設計するか、その考え方を整理してお伝えします。対象は、ある程度の規模のCMS構築・運用に実務として関わる方です。具体的には、CMS導入プロジェクトのユーザー側責任者、Web担当者、運用部門のマネージャー、制作・開発会社のディレクターや設計担当の方を想定しています。

特定の製品や手法を推す内容ではありません。長年いくつものCMS構築プロジェクトに関わってきて見えてきた、設計時に押さえておきたい考え方を共有します。設計の段階で何を決めておくか。それが、運用の数年先までを左右します。

CMS設計を4つの構成要素で考える

CMSを設計するとき、私は次の4つの構成要素を意識しています。どんなCMSにも当てはまる構造で、製品によって呼び方は違っても、本質的にはこの4つの単位を持っています。

1. ページ(テンプレート)
サイトの中にどんな種類のページがあるかを決める単位です。ホーム、お知らせ詳細、製品情報、コラム本文、お問い合わせ。こうしたページの種類ごとにテンプレートを用意します。設計の出発点であり、サイト全体の見通しを決める要素です。

2. パーツ
ページの中で組み立てる部品の単位です。見出し、画像付きテキスト、引用、CTAボタン、FAQ。ページの中にどんなパーツを、何種類用意して、どう配置するかを考えます。

3. 共通パーツ
複数のページから参照される情報の単位です。製品情報、人物プロフィール、お知らせ、セミナー情報。一箇所で更新すれば、参照しているすべてのページに反映される仕組みです。「実体」「マスタ」「コンテンツタイプ」など、CMSによって呼び方は様々ですが、機能としては同じものを指します。

4. 項目(フィールド)
パーツや共通パーツの中の最小単位です。タイトル、本文、画像、公開日、カテゴリ。入力フォーム上で運用者が触る単位とも言えます。

4つの構成要素の関係

4つの構成要素は次のような関係にあります。

ページ(テンプレート)
   │
   ├── パーツ(ページ内で組み立てる部品)
   │      └── 項目(フィールド)
   │
   └── 共通パーツ(複数ページから参照される情報)
          └── 項目(フィールド)

ページの中にパーツが並び、パーツは項目の集合体です。共通パーツも同じく項目の集合体ですが、ページに直接配置されるのではなく、複数のページから参照されます。

なぜ構成要素ごとに分けて考えるのか

構成要素を意識せずに設計すると、いくつかのことが起きやすくなります。

ひとつは、論点が混ざって決まらないことです。たとえば「製品情報のページをどう作るか」という議論で、ページ全体の構成・パーツの種類・項目の名前が同時に飛び交うと、何を決めたのか曖昧になります。

もうひとつは、後から変更しにくい設計になることです。本来は「項目を追加すれば済む」話を、ページ全体を作り直す方向で議論してしまうことがあります。

そして、レビューで見落としが出やすくなります。構成要素ごとに分けて確認すれば気づける問題が、混ざった状態だと見えにくくなります。

構成要素ごとに整理すると、それぞれの判断を順番に丁寧に進められます。設計レビューも構成要素単位で行うほうが、網羅性が上がります。

たとえば製品情報を例にとると、こう整理できます。「製品情報ページ(テンプレート)の中に、製品概要パーツ・添付文書パーツ・関連製品パーツが並ぶ」「製品情報そのものは共通パーツとして、複数のページから参照する」「製品情報の項目は、製品名・規格・薬価・添付文書PDF…」。こうやって構成要素を分けて話すと、議論が前に進みやすくなります。

このシリーズで扱うテーマ

本シリーズは全8回で構成します。各回は独立して読めるように書きますので、関心のある回から読んでいただいてかまいません。

第1回:CMSのページ構成方式の選び方
ページごとに、構成を固定するか、運用者が自由に組み立てられるようにするか。実は選択肢は何通りもあります。固定フォーム型、エディタ単体型、ブロック積み上げ型、それらの混合型。コンテンツの性質に応じて選ぶ視点を整理します。

第2回:CMSのテンプレート一覧と命名規則
設計の最初に作るべきは、サイト全体のテンプレート一覧です。識別コードと表示名の付け方、プレフィックスや連番に意味を持たせる方法など、後の運用を支える設計の基盤づくりを扱います。

第3回:CMSの共通パーツ設計
複数ページで使う情報をどう一元管理するか。ここで一番大事なのは「どこに表示されるかを全部洗い出してから設計する」ことです。並び順や絞り込みのキー、表示場所ごとのビュー定義など、設計時に決めておきたいポイントを整理します。

第4回:CMSのパーツ設計
パーツの種類はどこまで増やすか、ネストを許すか、出力デザインを運用者に委ねるか。判断軸を提示します。

第5回:CMSの項目(フィールド)設計
項目名を運用者目線でつける、説明文を充実させる。一見地味ですが、運用フェーズの問い合わせ件数を大きく左右する設計判断です。

第6回:自動化しない領域を決める
ヘッダー・フッター・サイトマップなど、CMS化するか直書きにするか迷う領域があります。自動化することのメリットと、そうしないことの合理性を整理します。

第7回:CMS設計を実コンテンツで検証する
設計書の机上レビューだけでは見つからない問題が、実データを入れた瞬間に見えることがあります。モックではなく実コンテンツで検証する方法論を扱います。

各回に共通する「テスト観点」

各回の本文の最後には、その回の論点に関するテスト観点を入れます。たとえば第3回(共通パーツ)の最後には「想定される全表示場所に実データを表示してみる」というテスト観点を提示します。

設計書の机上レビューで分かることには限界があります。実コンテンツで動かして初めて、設計の不足が見える場合が多いものです。テストの方法論そのものは第7回で詳しく扱いますが、各回でも具体的なテスト項目を提示します。

設計時に「これをどうテストするか」まで考えておくと、後工程の手戻りを大きく減らせます。

おわりに

CMS設計に唯一の正解はありません。サイトの性質、運用体制、予算、運用期間によって、最適な判断は変わります。ただ、判断の軸を持っていると、迷う場面が減ります。このシリーズが、その軸を作る材料になればと考えています。

次回(第1回)は、ページ構成方式の選び方から始めます。

著者

STSD株式会社代表 鴻田孝雄。製薬企業のWebサイトを中心に、BtoB向けCMSの開発・設計に20年以上関わっている。長期運用を前提とした設計と、運用負担を最小化する仕組み作りに関心がある。