共通パーツとは何か

CMSにおける共通パーツとは、複数のページから参照される情報のかたまりのことです。たとえばBtoBサービスサイトを例にとると、次のような情報が共通パーツの候補になります。

  • サービス情報（サービス名、概要、特徴、料金、関連資料）
  • 導入事例（顧客名、業種、課題、解決策、成果）
  • セミナー情報（タイトル、開催日時、会場、登壇者、申込みリンク）
  • 人物プロフィール（氏名、肩書、所属、写真、略歴）
  • お知らせ（タイトル、本文、公開日、カテゴリ）

これらの情報は、それぞれの「詳細ページ」に表示されるだけでなく、サイトのあちこちに登場します。サービス情報なら、サービス一覧ページにも、ホームの「人気サービス」セクションにも、関連サービスの推奨欄にも表示されます。導入事例なら、事例一覧ページにも、サービス詳細ページの下部にも、業種別の関連表示にも出てきます。

共通パーツとして一元管理しておけば、サービス情報を1箇所で更新するだけで、参照しているすべてのページが自動的に更新されます。逆に、各ページに同じ情報をコピーして持たせていると、改訂時にすべてのページを手作業で直すことになり、直し漏れが発生します。

ここまでは共通パーツの基本的な利点で、多くのCMS解説記事で書かれていることです。本記事の主題はその先、つまり「共通パーツをどう設計すればよいか」です。

共通パーツ設計の最大のポイント

共通パーツを設計するとき、私が最も注意するのは次の点です。

設計の最初に、その共通パーツが表示されるすべての場所を洗い出す。

シンプルなことですが、これを徹底するかどうかで、共通パーツの完成度が大きく変わります。

詳細ページに必要な項目だけを見て設計すると、後で必ず破綻します。よくあるのは、詳細ページで「これだけ項目があれば十分」と思って共通パーツを設計し、いざ運用が始まって一覧ページを作ろうとしたら「並び順のキーがない」「サムネイル画像のサイズが違う」「カテゴリで絞り込みたいのにカテゴリ項目がない」と気づくケースです。

設計時に「この共通パーツはどこに表示されるか」を全部書き出していれば、こうした見落としは防げます。

「出し側」を洗い出すとはどういうことか

具体的に何を洗い出すか、サービス情報を例に考えてみます。

サービス情報という共通パーツは、最低でも次のような場所に表示される可能性があります。

  1. サービス詳細ページ：すべての項目を表示
  2. サービス一覧ページ：タイトル、サムネイル、概要の冒頭、カテゴリ、並び順
  3. ホームの「主要サービス」セクション：タイトル、サムネイル、ごく短い説明、リンク
  4. 関連サービスの推奨欄（サービス詳細の下部など）：タイトル、サムネイル、ごく短い説明
  5. 検索結果ページ：タイトル、概要の冒頭、URLパス
  6. サイトマップ：タイトル、URLパス
  7. お問い合わせフォームの「興味があるサービス」プルダウン：タイトルだけ
  8. メールマガジン本文の関連サービス紹介：タイトル、ごく短い説明、URL
  9. 管理画面の一覧表示：タイトル、公開日、ステータス

これだけの場所で使われる可能性があります。それぞれの場所で必要な情報は微妙に違います。一覧ページではサムネイル画像が必要ですが、詳細ページのメインビジュアルとはサイズや縦横比が違うかもしれません。ホームの主要サービスセクションでは、20〜30文字程度の短い説明文が欲しいですが、詳細ページの概要は500文字あるかもしれません。

すべての出し側を洗い出してから設計すれば、共通パーツに必要な項目が見えてきます。たとえばサービス情報には、次のような項目が必要だと分かります。

  • サービス名（フル）
  • サービス名（短縮版、一覧やナビゲーション用）
  • メインビジュアル（詳細ページ用、横長サイズ）
  • サムネイル画像（一覧用、正方形サイズ）
  • 概要文（詳細ページ用、500文字程度）
  • 短い説明文（一覧用、80文字程度）
  • 極短の説明文（ホーム・関連表示用、30文字程度）
  • カテゴリ（絞り込み用）
  • 並び順を決める数値項目
  • 公開日（並び替え用）
  • ステータス（公開・非公開）

詳細ページだけを見ていては絶対に出てこない項目が、出し側を洗い出すことで見えてきます。

表示パターンを共通パーツとセットで設計する

出し側が複数あるなら、それぞれの出し側でどの項目をどう表示するか、つまり表示パターンもセットで設計します。

表示パターンというのは、「この共通パーツを、ある場所に出すときにはこの項目をこのように表示する」というルールのことです。たとえばサービス情報の表示パターンは次のようになります。

  • 詳細パターン：すべての項目をフル表示。メインビジュアル、サービス名（フル）、概要文（500文字）、料金、関連資料リンクなど
  • カードパターン（一覧用）：サムネイル、サービス名（フル）、短い説明文（80文字）、カテゴリ、詳細ページへのリンク
  • コンパクトパターン（ホーム・関連表示用）：サムネイル、サービス名（短縮版）、極短の説明文（30文字）、詳細ページへのリンク
  • テキストパターン（サイトマップ用）：サービス名（フル）、URLパス
  • プルダウン用パターン：サービス名（短縮版）と内部識別子だけ

表示パターンをセットで設計しないとどうなるか。実装担当者が表示場所ごとに自分の判断で「この項目を使う」「この文字数で切る」と決めることになり、表示ルールがコードのあちこちに散らばります。後から「ホームの主要サービス欄の文字数を変えたい」となったときに、どこを直せばよいか追跡できなくなります。

表示パターンを共通パーツの設計書に明記しておけば、表示ルールが一箇所に集約され、変更にも対応しやすくなります。

並び順・絞り込みのキーを最初から持たせる

共通パーツが一覧表示される場面では、並び順や絞り込みが必要になります。これらのキーになる項目を、設計時に最初から共通パーツに含めておくのが重要です。

並び順のキーとして、よく使うのは次のようなものです。

  • 公開日・更新日（時系列で並べる）
  • カテゴリ・タグ（同じ種類でまとめる）
  • 並び順専用の数値項目（運用者が任意の順序を決める）
  • 人気度・閲覧数（自動集計で並び替える）

絞り込みのキーとして使うものも、ほぼ同じカテゴリ・タグ系の項目になります。

ここで設計の原則として一つお伝えしたいのが、並び順専用の数値項目を最初から1つ持たせておくことです。これは「念のため」の項目ですが、運用が始まってから「やっぱりこの順序で並べたい」というニーズが出てくることが非常に多いためです。

公開日順や更新日順だけでは対応できないニーズ、たとえば「主要サービスを上に固定したい」「キャンペーン中のサービスを目立たせたい」「特定のサービスを別の理由で優先表示したい」といった要望に、並び順専用項目があれば即座に対応できます。後から追加すると、既存データすべてに値を埋める作業が発生します。

共通パーツ間の関係を設計する

共通パーツは単独で存在するだけでなく、互いに関係を持つことがよくあります。たとえば次のような関係です。

  • サービス と 導入事例（このサービスにはこれらの事例がある）
  • サービス と 関連資料（このサービスにはこれらの資料がある）
  • セミナー と 登壇者（このセミナーには誰が登壇する）
  • 導入事例 と 業種（この事例はこの業種に属する）

これらの関係を設計時にどう持たせるか、いくつか判断ポイントがあります。

親子関係か、参照関係か
親子関係（サービスを削除したら関連する事例も削除されるべきか、孤立する事例として残すか）と、参照関係（事例側がサービスを参照しているだけで、削除時の影響はない）では設計が変わります。

1対多か、多対多か
1つのサービスに複数の事例が紐づくのは1対多です。1つの事例が複数のサービスに紐づく可能性があるなら多対多です。多対多の場合は、関係を保持する別の仕組み（中間テーブル、タグ機能など）が必要になります。

双方向の参照が必要か
「このサービスからこの事例を見る」だけでなく「この事例からこのサービスを見る」という双方向の参照が必要か。双方向なら、両側から参照できる仕組みが必要です。

これらは技術寄りの判断に見えますが、実は運用フローに直結する設計判断です。たとえば「サービスを廃止するときに、関連事例をどうするか」は、最終的には運用ルールの話になります。設計時にこれらの関係を明確にしておかないと、運用開始後に「廃止サービスの事例だけが孤児として残ってしまった」という事態が起きます。

この回のテスト観点

共通パーツの設計が適切かは、次の観点で確認できます。

  • 想定される全表示場所に実データを入れて表示してみる：詳細ページだけでなく、一覧ページ、ホームの関連表示、検索結果、メールテンプレートなど、設計時に洗い出した全ての場所で実データを表示する。表示が不自然になったり、項目が不足していると感じる場所があれば、共通パーツの項目設計に戻る
  • 既存コンテンツの中で「異常値」を含むデータを試す：タイトルが極端に長いもの、短いもの、画像なし、特殊文字を含むもの、極端に古いもの、極端に新しいもの。これらが各表示場所で破綻しないか確認する
  • ニーズが出たときの並び替えを試す：仮に「特定の項目で並び替えたい」というニーズが出たとき、既存の項目で対応できるか。対応できないなら、並び順キーが不足している
  • 削除・非公開時の影響を確認する：共通パーツを1件削除（または非公開）したとき、参照しているすべてのページがどう変わるか。「リンク切れ」「孤児データ」「表示崩れ」が発生しないか確認する

検証の方法論については第7回で詳しく扱います。

まとめ

共通パーツを設計するときの最大のポイントは、設計の最初に「どこに表示されるかを全部洗い出す」ことです。詳細ページだけを見ていては必要な項目が出てこないため、後から追加する羽目になります。

出し側を洗い出したら、それぞれの表示パターンをセットで設計し、並び順・絞り込みのキーを最初から持たせ、共通パーツ間の関係を明確にします。これらが揃うと、運用が始まってからのトラブルが大きく減ります。

共通パーツの設計は、CMS設計の中でも特に「設計時の判断が運用の数年先まで影響する」領域です。手戻りのコストが大きいので、最初の設計に時間をかける価値が十分にあります。

次回（第4回）は、ページの中で組み立てるパーツの設計について扱います。

著者

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