運用で回すのか、仕組みを持つのか CMSを入れるかどうかの判断

更新基盤設計の最初の判断は、「CMSを入れるかどうか」です。
これは必ずしも“入れるのが正解”ではありません。
判断軸になるのは、以下のような点です。

• 更新頻度はどの程度か
• 誰が更新を担当するのか
• 更新内容は単純か、構造的か
• 更新コストと制作・保守コストのバランス
• 将来的に更新量が増える可能性があるか

更新頻度が低く、内容も限定的な場合、CMSを導入することでかえってコストや運用負荷が増えることもあります。
一方で、更新頻度が低くても

• 項目が多い
• データ構造が複雑
• 将来的な拡張が見込まれる

といったケースでは、CMS化に十分な価値があります。

WordPressか、MTか、スクラッチか CMSを入れるなら「何を選ぶか」

CMSを導入すると決めた場合、次に考えるのが「何を選ぶか」です。
重要なのは、CMSの知名度や流行ではなく、更新対象の性質です。

• ページを更新したいのか
• データ（実績・物件・求人・事例など）を管理したいのか
• 担当者は技術的な操作に慣れているか
• 将来的にシステム連携が必要になりそうか

FHWでは、WordPress、Movable Type、Laravelによる独自管理画面、さらにヘッドレスCMSといった選択肢を前提に、要件から逆算して設計します。
「このCMSを使う前提」ではなく、「この更新をどう成立させるか」から考えるのが基本姿勢です。

データ更新という視点 更新対象は「ページ」だけとは限らない

更新というと「ページを直す」イメージを持たれがちですが、実際の運用では、更新対象はそれだけではありません。

• 不動産サイトの物件情報
• 採用サイトの求人情報
• 製品・技術情報
• 実績・事例・お客様の声

こうしたデータ更新をどう扱うかによって、CMS設計や管理画面の考え方は大きく変わります。
ページ更新とデータ更新を混同したままCMSを選ぶと、「更新はできるが、使いづらい」という状態になりがちです。

担当者・体制・役割が変わる前提で考える 将来の変化に耐えられる更新基盤か

更新基盤は、「今の担当者」だけを想定して設計すべきではありません。

• 担当者が変わったら
• 社内体制が変わったら
• サイトの役割が変わったら
• CMSを切り替えたくなったら

こうした変化は、長期運用では必ず起こります。
FHWでは、将来すべてを決めきれない前提で設計することを重視しています。
CMSは「固定化する仕組み」ではなく、変更可能性を残すための基盤であるべきだと考えています。

運用と品質の視点 更新しやすさより、責任が破綻しない構造か

更新基盤設計では、「誰でも更新できる」ことよりも、更新後の品質と責任範囲が保たれるかが重要です。
例えば、お客様側で直接HTMLを編集する場合、その変更内容はGit管理や検証フローに乗らず、その後の保守・改修に責任を持つことが難しくなります。
更新の自由度と引き換えに、品質管理や責任構造が崩れてしまうケースは少なくありません。
更新基盤設計は、 「更新できるか」ではなく「誰が、どこまで責任を持てる構造か」を設計する作業でもあります。

このページで伝えたいこと

CMS・更新基盤設計は、ツール選定の話ではありません。
運用体制・責任範囲・将来の変化を含めた設計判断そのものです。
FHWでは、

• CMSを入れること自体を目的にしない
• 更新対象の性質から設計する
• 将来の変化に耐えられる構造をつくる
• 更新後の品質と責任を崩さない

という視点で、更新基盤を設計しています。 「何を使うか」よりも、「どう運用し続けられるか」を重視した更新基盤設計。
それが、このページで最もお伝えしたい考え方です。