自動化＝善ではない

CMS設計では、「すべてを仕組みに乗せたい」という発想になりがちです。ヘッダーのナビゲーション項目を増やすたびに直接HTMLを編集するのは面倒に思え、CMSで一元管理して自動生成したくなります。サイトマップも、ページが追加されるたびに自動で更新される仕組みがあれば便利そうです。

ただ、この発想で設計を進めると、後で困ることが出てきます。サイトには必ず「定型から外れるケース」があります。複数ドメインの跨ぎ、特設サイトとの連携、外部サービスへのリンク、季節限定のキャンペーンページ、グループ会社のサイトとの連携。これらの変則ケースで、自動生成の仕組みは破綻しがちです。

CMSの設計者がやるべきことの一つは、「自動化する範囲」と「自動化しない範囲」を意識的に線引きすることです。「全部自動化したい」という気持ちを抑えて、自動化しない領域を残しておく。これが長期運用の柔軟性を支えます。

本記事ではまず、自動化しないことを推奨する代表的な領域として、ヘッダー・フッター・サイトマップを取り上げます。そのあとで、「型に収まらないページ」の逃げ場として、エディタ単体型の使い方を扱います。

ヘッダー・グローバルナビは直書きを推奨

サイトのヘッダーに並ぶグローバルナビゲーションは、直書きで運用することをおすすめします。

ヘッダーは、サイト全体で使われる共通領域なので、「CMSの設定画面でナビ項目を編集できれば便利」と考えがちです。実際、多くのCMSにそうした機能があります。しかし実務では、次のような変則対応が必要になる場面が頻繁に出てきます。

  • 一部のページだけ、グローバルナビの構成を変えたい（特設ページなど）
  • ナビ項目の中に、外部サイトへのリンクを混ぜたい
  • 一時的なキャンペーンを目立つ位置に追加したい
  • 複数のサブドメイン（あるいは別サイト）と統合したヘッダーにしたい
  • ハンバーガーメニューの中だけ、構成を変えたい
  • 特定の項目を、ログイン状態や属性によって出し分けたい

これらの要望が出るたびに、CMSの自動生成機能を拡張していくと、設定画面が複雑化します。最終的には「設定画面で何ができて何ができないのか、設計者しか分からない」状態になります。

最初からHTMLで直書きにしておくと、変則対応はHTMLを直接編集すれば済みます。「グループ企業のヘッダーリンクを追加する」「キャンペーン期間中だけリンクを追加する」のような対応が、CMSの仕様に縛られずにできます。

ヘッダーは確かに「サイト全体で共通」ですが、その共通は「常に1つの定型に収まる」という意味ではありません。むしろ「サイト全体で見せたい情報を、状況に応じて柔軟に組める領域」と捉えたほうが、長期運用の実態に合います。

フッターも同じ理由で直書きを推奨

フッターも、ヘッダーと同じ理由で直書きを推奨します。

フッターには、会社情報・関連リンク・SNSリンク・コピーライト・プライバシーポリシーへのリンクなど、サイトによって様々な情報が入ります。これらをCMSで自動管理しようとすると、ヘッダーと同様の問題が起きます。

フッターの変則対応の例としては、次のようなものがあります。

  • 認定マーク・認証バッジ（J-CRM、PマークなどのISO関連、業界団体のロゴ）の追加
  • 関連法令への注釈（業界によっては必須の表示が増えていく）
  • 多言語サイトのフッターを切り替える
  • グループ会社のリンクを構造化して並べる
  • 季節の挨拶・お知らせ・営業時間変更の告知を一時的に表示

フッターは「滅多に変わらない」と思われがちですが、実際の運用では追加・修正が想像以上に発生します。直書きにしておくと、こうした変則対応に柔軟に対応できます。

CMSで管理したくなる気持ちの背景には、「運用者がフッターを編集できるようにしたい」という意図があるかもしれません。しかし実態として、フッターの編集は頻度が低く、編集できるのは限られた担当者です。であれば、HTMLを直接編集できる体制を整えておくほうが、実務に合った仕組みになります。

HTMLサイトマップも直書きを推奨

サイトの全ページへの導線を提供するHTMLサイトマップ（/sitemap/ のようなページ）も、自動生成より直書きをおすすめします。

サイトマップの自動生成は、機械的な処理としては実装可能です。CMSのページ一覧を取得して、階層構造に従って並べる。技術的にはこれで動きます。問題は、機械的に生成されたサイトマップが、人間にとって見やすいとは限らないことです。

人間向けのサイトマップに求められるのは、次のような特性です。

  • カテゴリの並び順が、サイトの導線として自然である
  • 階層が深すぎず、一覧で把握できる
  • 重要なページが目立つ位置にある
  • 廃止されたページや古いページは表示されない
  • 外部サイト・関連サイトへのリンクも適切に含まれる

これらは「自動生成のロジックに任せる」より、「人間が判断して組む」ほうが品質が高くなります。サイトマップは、サイト全体の構造を俯瞰できる重要なページです。ここを機械任せにすると、サイトの見せたい順序や強調が崩れます。

ページが追加されたり廃止されたりするたびにサイトマップを編集する手間は確かにありますが、その手間は「数ヶ月に一度の作業」程度です。逆に、自動生成された見にくいサイトマップを放置するほうが、長期的なサイト品質を下げます。

「型に収まらないページ」の逃げ場を用意する

ヘッダー・フッター・サイトマップ以外にも、CMSの定型テンプレートに収まらないページが、運用中に出てきます。

代表的な例は次のようなものです。

  • 特設ページ・キャンペーンページ（1回限りのデザインで作りたい）
  • 法務系ページ（プライバシーポリシー、利用規約、特定商取引法表記）
  • 採用情報の特設ページ
  • お詫び・告知ページ（緊急対応で作る一回限りのページ）
  • 周年記念ページ・ブランドメッセージページ
  • 外部サービス連携用のページ

これらに共通するのは、他のページと構造が違う、あるいは1回限りの特殊なデザインが必要ということです。これらを既存のテンプレートで無理やり作ろうとすると、テンプレートが歪みます。

そこで、設計時にエディタ単体型のテンプレートを「逃げ場」として用意しておくことをおすすめします。第1回で扱ったエディタ単体型のテンプレート（HTMLを丸ごと流し込めるテンプレート）を、こうした例外的なページのために残しておく考え方です。

エディタ単体型のテンプレートは、運用が大変だから常用するものではありません。しかし「型に収まらないページが出たとき」のために、最初から1つ用意しておくと、設計の柔軟性が大きく上がります。「想定外のページを作りたい」というニーズが出たとき、既存テンプレートを無理に拡張せず、エディタ単体型のテンプレートを使えばよいからです。

逃げ場を用意しておくのは、設計が雑であることの裏返しではなく、現実の運用に対応する設計判断です。すべてを定型に収めようとする設計よりも、例外を例外として扱える設計のほうが、長期運用に耐えます。

線引きの判断軸

「自動化するか、直書きにするか」を判断するときに使える観点を紹介します。

観点1：変則対応の頻度
その領域に対して、定型から外れる対応がどの程度発生するか。年に数回でも発生するなら、直書きを基本にしたほうが楽です。逆に、本当に定型のみで運用される領域は、自動化が向きます。

観点2：編集者の人数とスキル
その領域を編集できる人が、HTMLを書けるか。書けるなら直書きで問題ありません。書けない場合は、自動化したくなりますが、変則対応の頻度が低いなら、HTMLを書ける担当者に依頼する体制で運用するほうが、結果として柔軟になります。

観点3：自動化することで生じる制約
自動化すると、CMSの仕様に縛られた範囲でしか変更できなくなります。その制約を受け入れられるか、それとも長期的に問題になりそうか。長期運用で困りそうなら、直書きを選びます。

観点4：例外ケースが想定されるか
そのコンテンツが、定型的な構造で表現できないケースが将来発生し得るか。発生しそうなら、定型化せず、エディタ単体型での運用を視野に入れます。

これらの観点で見て、自動化の利得と直書きの利得を比較し、領域ごとに判断します。

この回のテスト観点

自動化の線引きが適切かは、次の観点で確認できます。

  • 変則対応のシナリオを5つ書き出してみる：「グループ会社のリンクを追加したい」「キャンペーンページのヘッダーを変えたい」「臨時のお知らせをフッターに出したい」など、想定される変則ケースを書き出す。それぞれが、設計した仕組みで対応可能か確認する
  • 対応できないケースは、どう逃げるか考えておく：すべてのケースを設計時に解決する必要はありません。ただし「対応できないケースが発生したとき、どうやって逃げるか」は事前に考えておきます。エディタ単体型の存在が、その逃げ道になります
  • 自動化されている領域の編集権限を確認する：自動化された領域を編集できるのは誰か、どんな範囲を変更できるかを確認します。「設計者しか触れない」状態になっていないか、「想定外の変更ができてしまう」状態になっていないか、両方をチェックします
  • エディタ単体型のテンプレートが使える状態か確認する：実際に1ページ作ってみて、運用上の制約がないかを確認します。「エディタはあるが、実際には使えない」状態になっていないか、確認しておきます

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

まとめ

CMS設計では「すべてを自動化したい」という気持ちが働きがちですが、実務の運用には変則対応がつきものです。ヘッダー・フッター・サイトマップのような共通領域は、自動化しすぎると変則対応が効かなくなります。これらは直書きを基本にして、HTMLを直接編集できる体制を整えておくほうが、長期運用の柔軟性を保てます。

加えて、「型に収まらないページ」が出たときの逃げ場として、エディタ単体型のテンプレートを設計時に1つ用意しておきます。すべてを定型に収めようとせず、例外を例外として扱える設計を残しておくことが、現実の運用に耐える仕組みになります。

「自動化＝善」という発想を一旦置いて、領域ごとに「自動化するか、直書きにするか」を判断する。この線引きが、長く使い続けられるCMSを支えます。

次回（第7回）は、本シリーズの締めくくりとして、設計を実コンテンツで検証する方法を扱います。机上のレビューだけでは見つからない問題が、実データを入れた瞬間に見えることがある、という話です。

著者

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