CMSテンプレート編集で全ページ崩壊を防ぐ3層構築の役割分担

container.choregate.com には、いま公開中のページと投稿が合わせて407件ある（固定ページ31件・投稿376件）。
先日、フッターの共通ナビゲーションに新しいバナーを1本追加する作業をした。
触ったファイルは1つ、編集した管理画面の項目も1箇所だけ。
それなのに、公開中の407件すべてに同じバナーが反映された。

この動きを見るたびに、少し身構える。
1箇所の修正が全体に波及するのは便利だが、間違えれば同じ規模で事故が起きるということでもある。
Container がこの怖さを構造で抑えている仕組みが、3層構築だと思う。

この記事はもともと5月に公開したものを、今日書き直している。
当時の本文は3段落しかなく、3層構築が「何をしてくれるのか」を紹介するだけで終わっていた。
実際に4か月ほどこの仕組みの中で作業を続けてみて、便利さだけでなく、気をつけるべき境界線も見えてきたので、その体験を足して書き直すことにした。

フッターを1箇所直したら、407ページ全部に反映された

フッターは「footer(MENU)」という名前のサイトモジュールで1つに部品化されている。
バナーのリンクを1本足す作業は、このサイトモジュールを編集して保存するだけで終わった。
公開ページ側で407件を1つずつ開いて直す、という作業は発生していない。

これは裏を返すと、この1箇所を間違えると407件が同時に崩れるということでもある。
実際の作業では、公開前にプレビューで見た目を確認してから保存する、という手順を必ず踏む。
影響範囲が広い箇所ほど、確認の手間を惜しまないようにしている。

どこを直すとどこまで変わるかが分からないのが一番怖い

CMS の運用で怖いのは、機能が壊れることよりも「どこまで影響するか読めないまま触ること」だと思う。
テンプレートの1行を直したつもりが、実は全ページ共通の部品だった、という事故は珍しくない。
Container を触る前に別の CMS で作業していたときも、共通パーツと個別ページの区別が画面上ではっきりしておらず、修正後にトップページ以外が崩れて気づいた、ということがあった。
そのときは、崩れたページを1件ずつ見つけて直すだけで半日かかった。
影響範囲が事前にわかっていれば、確認だけで済んだはずの作業だった。

Container では、この「どこまで影響するか」を画面の構造そのもので示している。
サイトテンプレート・サイトモジュール・ページモジュールという3つの管理画面が分かれていて、いま触っているのがどの層かを迷いにくい。
触る場所と影響する範囲が最初から一致しているので、「思わぬところが壊れる」が起きにくい設計になっている。

Container が分ける3つの層は、枠・共通部品・中身

1層目はサイト全体の枠と世界観を決める「サイトテンプレート」。
2層目はヘッダーやフッターなど、複数ページで共有する部品を切り出した「サイトモジュール」。
3層目は、文章や画像といったページごとの中身を組み立てる「ページモジュール」。

サイトテンプレート（1層目）を切り替えれば、サイト全体の見た目を一括で刷新できる。
サイトモジュール（2層目）を1箇所直せば、それを使っている全ページに反映される。
ページモジュール（3層目）は、そのページだけの中身なので、直しても他のページには影響しない。

今回のフッターの作業は2層目、サイトモジュールの編集だった。
だから407件全部に反映された。
逆に言えば、1ページだけ直したいときにサイトモジュールを触ってしまうと、意図せず他のページまで巻き込むことになる。

23個のサイトモジュールと58個のページモジュールという数の意味

いま container.choregate.com には、サイトテンプレートが16種類、サイトモジュールが23個、ページモジュールが58個ある。
サイトテンプレートの16種類は、トップページ・下層ページ・お知らせ詳細ページなど、ページの種類ごとの「枠」の数だと考えるとわかりやすい。
サイトモジュールの23個には、ヘッダー・フッターのほか、パンくずや共通CTA、404ページ専用の部品などが含まれる。

ページモジュールの58個は、見出し・本文・画像・お問い合わせフォームといった、ページの中身を組み立てるための部品だ。
1つのページは、この58個の中から必要なものを選んで組み合わせてできている。
数だけ見ると58は23より多いが、1個あたりの影響範囲はページモジュールのほうがずっと狭い。
影響範囲の広さと部品の数は、必ずしも比例しない。

この記事の書き直しは、中身の層だけで完結する

この記事自体、今日は公開日を変えずに本文だけを書き直している。
これはページモジュール、つまり3層目の中身の編集にあたる。
どれだけ書き直しても、他の406件のページや投稿には一切影響しない。

同じ「編集」という作業でも、触る層によって影響範囲がまったく違う。
コラムを1本書き直すのと、フッターのバナーを1本足すのとでは、リスクの大きさが2桁くらい違う感覚がある。
作業を始める前に「これは何層目の作業か」を自分に問うようにすると、確認の手間をかけるべき場面かどうかの判断がしやすい。

層を勘違いすると、思わぬところで詳細度が衝突する

あるページだけ、見出しの周りの余白を変えたいことがあった。
ページモジュール側、つまり3層目にクラスを追加して調整したつもりだったが、見た目は変わらなかった。
原因を辿ると、下層ページ共通のスタイル、つまり2層目のサイトモジュール側で同じ要素に既に2重のクラスが掛かっていて、CSS の詳細度でそちらが勝っていた。

中身の層を直したつもりが、実際には共通部品の層の指定と衝突していた、ということになる。
3層に分かれていても、見た目のスタイルまで完全に独立しているわけではない。
共通部品の層に強い指定が残っていないか、before/after で表示を比べて確認するようにしている。

3層構造は移行やリニューアルのときにこそ効いてくる

3層構造がいちばん効いてくるのは、日々の小さな修正よりも、サイトリニューアルや他 CMS からの移行だと思う。
枠（サイトテンプレート）だけを新しくして、中身（ページモジュール）はそのまま引き継ぐ、という進め方ができる。
全ページを1から作り直す必要がないので、移行にかかる工数の見積もりも立てやすくなる。

逆に、共通部品（サイトモジュール）と中身（ページモジュール）の区別があいまいな作り方をしていると、移行のたびに「どこまでが使い回せる部品か」を1ページずつ確認する作業が発生する。
CMS を選ぶ・乗り換える段階で、この3層の分かれ方がどれくらい徹底されているかを見ておくと、次のリニューアルが楽になるはずだ。

比較表に載っている機能の丸の数だけを見ていると、この違いには気づきにくい。
デモ環境で実際にサイトモジュールを1つ編集してみて、変更がどこまで波及するかを目で確認するのがいちばん早いと思う。
16種類あるサイトテンプレートのどれか1つを切り替えてみるだけでも、枠と中身がどれくらい独立しているかは体感できるはずだ。

仕組みの詳細は3層構築のご紹介ページにまとめている。
他の CMS からの乗り換えを検討している場合は、移行支援のページもあわせて確認してほしい。