CMS設計を実コンテンツで検証する｜モックではなく実データでテストする方法

テストとは何か

CMS設計の検証を始める前に、テストという作業の意味を確認しておきます。

テストとは、仕様の通りに動作することを確認する作業です。「動かしてみて、何か問題がないか探す」作業ではありません。「想定通りに動いているか、想定と違う動作はないか」を確認する作業です。

この区別は重要です。なぜなら、仕様が曖昧なまま検証を始めると、テストの基準そのものが存在しないからです。「動かしてみて、何となく違和感がないか確認する」程度の作業では、見つかった問題が「仕様の不足」なのか「実装のミス」なのか区別できません。問題を発見しても、何をどう直せばよいか判断できない状態になります。

テストを意味のある作業にするためには、「何が正しい状態か」をあらかじめ定義しておく必要があります。CMS設計の場合、その「正しい状態」を定義するのが、これまで第2回〜第6回で扱ってきた一連の設計成果物です。

シリーズで扱ってきたものは、すべて仕様だった

第2回から第6回までの内容を振り返ると、扱ってきたテーマがすべて「仕様を作る作業」だったことが見えてきます。

これらの設計成果物が揃って初めて、「正しい状態」が定義できます。テンプレート一覧があるから「すべてのページがいずれかのテンプレートで作れること」が確認できる。項目の説明文があるから「運用者が説明文だけで自己解決できること」が確認できる。仕様があって、初めて検証の基準が成立します。

逆に言えば、仕様が曖昧な状態でCMSを作り始めると、検証の段階で「何が正しいのかわからない」状況に陥ります。実装の問題と設計の不足が混ざり、修正の方針も立ちません。設計に時間をかける価値は、ここにあります。

なぜモックではなく実コンテンツで検証するのか

仕様が揃ったら、その仕様通りに動作するかを検証します。検証で大事なのは、ダミーデータではなく実コンテンツを使うことです。

ダミーデータ（「ここにタイトルが入ります」「ここに本文が入ります」のような仮のテキスト）でテストすると、設計の不足が見えにくくなります。ダミーは均等な長さで作られていることが多く、極端なケースが含まれません。タイトルは適度に短く、画像は均一なサイズで、項目は綺麗に揃っています。これでテストして問題がなくても、実コンテンツが入った瞬間に問題が露見します。

実コンテンツは、ダミーデータが想定していない状態を含んでいます。

• タイトルが極端に長い、または極端に短い
• 画像が用意されていない、または想定外の縦横比
• 任意項目が空のままで保存されている
• 特殊文字・絵文字・記号が含まれている
• 半角・全角の表記揺れがある
• 想定していない言語が混ざっている
• 過去のサイトから引き継いだ古い形式のデータ

これらは、実際の運用が始まれば必ず発生します。ダミーデータでテストしているうちは見えませんが、実コンテンツを入れた瞬間に、レイアウト崩れ・項目不足・並び順の乱れなどとして見えてきます。

設計を検証するなら、実コンテンツを使う。これを徹底することで、運用開始後のトラブルを大きく減らせます。

検証する観点

仕様に対する検証観点を、CMS設計の階層に沿って整理します。

テンプレート単位の検証

テンプレート一覧（第2回）を起点に、すべてのテンプレートに対して実コンテンツを登録してみます。

• すべてのテンプレートに対して、最低でも3〜5件の実コンテンツを登録できるか
• 登録したコンテンツが、想定通りのURLで公開されるか
• パンくずが、テンプレート一覧で定義した通りに表示されるか
• 一覧と詳細の関係が、想定通りに成立しているか

この段階で「このテンプレートが用意されていない」「定義したURLパターンと実装が合わない」といった問題が見つかれば、テンプレート一覧の見直しに戻ります。

共通パーツとデータ構造の検証

共通パーツの設計（第3回）が、想定される表示場所すべてで機能するか検証します。

• 共通パーツが、設計時に洗い出した全表示場所で正しく表示されるか
• 表示パターンごとに、必要な項目が揃っているか
• 並び順・絞り込みのキーが、想定される並び替えに対応できるか
• 共通パーツ間の関係（親子・参照）が、データの追加・削除で破綻しないか

「一覧では情報が不足する」「並び順が変えられない」といった問題が見つかれば、共通パーツの設計に戻り、項目を追加します。

パーツの検証

パーツ設計（第4回）が、想定されるすべてのコンテンツパターンで機能するか検証します。

• 用意したパーツの組み合わせで、想定される全ページが作れるか
• 似たパーツが複数ある場合、運用者がそれぞれの使い分けを理解できるか
• パーツの種類が多すぎて運用者が迷わないか
• 出力デザインが、想定したトーン＆マナーで保たれるか

「このコンテンツを表現するパーツがない」という問題が見つかれば、パーツの種類が不足しているか、既存パーツの統合が必要なサインです。

項目の検証

項目の命名と説明文（第5回）が、運用者にとって機能するか検証します。

• 項目名だけを見て、何を入れる項目か運用者が理解できるか
• 説明文を読むだけで、運用者が自己解決できるか
• 似た項目がある場合、それぞれの使い分けが説明文から判断できるか
• 文字数制限・必須/任意・初期値が、実コンテンツで適切か

ここで「説明を読んでも分からない」「設計者に聞きたくなった」項目があれば、説明文の改善が必要です。

例外領域の検証

自動化しない領域（第6回）が、変則ケースに対応できるか検証します。

• 想定される変則対応のシナリオで、設計が機能するか
• 直書き領域は、編集できる体制が整っているか
• エディタ単体型のテンプレートが、例外的なページで実際に使えるか
• 自動化されている領域と、自動化していない領域の境界が、運用者に伝わるか

検証で見つかった問題を仕様に戻す

検証で問題が見つかったとき、対応の出発点は「仕様の見直し」です。実装を急いで修正したくなりますが、まず仕様（設計成果物）を更新するところから始めます。

たとえば「サービス情報の一覧で、業種別の絞り込みができない」という問題が見つかったとします。実装を修正して絞り込み機能を追加することはできますが、その前に「サービス情報という共通パーツに業種項目を追加する」という仕様の更新を行います。仕様が更新されてから、それに沿って実装を修正します。

このループを徹底すると、仕様と実装が常に一致した状態が保たれます。仕様書には書かれていない暗黙の機能が実装に紛れ込むことがなくなり、後から仕様を見れば実装の状態が分かるようになります。

検証は、設計を完成させるための作業の一部です。「設計を終えてから検証する」のではなく、「検証を通じて設計を完成させる」と捉えると、設計の品質が上がります。

検証のタイミング

検証は、運用開始の直前に1回だけ行うものではありません。設計の各段階で、繰り返し行います。

• 仕様が一通り揃った段階で、最初の検証を行う
• 検証で見つかった問題を仕様に反映し、再度検証する
• 実装が進んだら、実装と仕様の整合性を検証する
• 運用直前に、本番に近い実コンテンツで最終検証を行う
• 運用開始後も、新しい問題が見つかれば仕様に戻して更新する

このサイクルを回すことで、仕様と実装が常に整合した状態で運用を続けられます。

シリーズ全体のまとめ

本シリーズでは、長く使い続けられるCMSをどう設計するか、7回にわたってお伝えしてきました。振り返ると、伝えたかったことは次のような構造になります。

CMS設計の対象は、ページ・パーツ・共通パーツ・項目という4つの構成要素に整理できます（第0回）。それぞれの要素について、ページ構成方式の選び方（第1回）、テンプレート一覧の作り方（第2回）、共通パーツの設計（第3回）、パーツの設計（第4回）、項目の命名と説明（第5回）、自動化しない領域の判断（第6回）と、設計時に押さえておきたい考え方を扱いました。

そして本記事（第7回）では、これらの設計成果物が「仕様」であり、実コンテンツによる検証を通じて完成していくものだとお伝えしました。

本シリーズを通じて一貫していたのは、設計の段階で何を決めておくかが、運用の数年先までを左右するという考え方です。CMSは作って終わりではなく、5年・10年と運用が続く仕組みです。その長い期間にわたって、運用者が迷わず、品質が保たれ、変更に柔軟に対応できる仕組みを作るには、最初の設計に時間をかける価値があります。

CMS設計に唯一の正解はありません。サイトの性質、運用体制、予算、運用期間によって、最適な判断は変わります。本シリーズが、その判断の軸を作る材料になれば、書いた甲斐があります。

最後までお読みいただき、ありがとうございました。

著者

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