03 / BUILD
つくるフェーズ
WordPress・CMS
更新・運用を支える基盤設計
Flying High Works（FHW）では、WordPressをはじめとするCMSをWeb制作における一つの手段として扱っています。
CMSは便利な反面、要件や運用を整理しないまま導入すると、
- 更新が複雑になる
- 拡張が難しくなる
- 技術的負債が蓄積する
といった問題を引き起こします。
FHWでは、「CMSを使うこと」ではなく、「何を実現したいか」を起点に、CMSの選定・設計・実装を行います。
WordPressは「万能」ではない
WordPressは、非常に多くの実績があり、柔軟性の高いCMSです。
一方で、
- すべてをWordPressで完結させようとする
- プラグインに依存しすぎる
- 実装意図が見えないカスタマイズを重ねる
といった使い方をすると、保守や拡張が難しくなります。
また、SEOに強いといううわさ話がありますが、あくまでもうわさです。
FHWでは、WordPressを「向いている用途で使うCMS」として位置づけています。
CMS導入時に整理する観点
CMSを導入する際、FHWでは以下の点を整理します。
- 誰が、どの頻度で更新するのか
- 更新対象は何か（記事／固定情報／データ）
- 将来的に増える可能性のある機能は何か
- 外部システムやAPI連携の有無
- CMSに持たせる責任範囲
これらを整理したうえで、WordPressを使うのか、別のCMSを使うのかを判断します。
WordPressで対応する領域
WordPressは、以下のような用途で力を発揮します。
- 記事・お知らせ・実績などのコンテンツ管理
- 比較的シンプルな更新フロー
- 運用担当者が多い案件
- 既存資産を活かしたリニューアル
FHWでは、必要以上にWordPressに役割を持たせないことを重視しています。
カスタマイズと拡張の考え方
WordPressのカスタマイズでは、
- テーマ構造の整理
- 管理画面の使いやすさ
- 更新ミスを防ぐUI設計
を意識します。
また、機能要件が増えてきた場合には、
- Laravel等での機能分離
- API連携による役割分担
といった選択肢も含めて検討します。
ヘッドレスCMSという選択肢
案件によっては、WordPressをヘッドレスCMSとして利用する、あるいは別のヘッドレスCMSを採用するケースもあります。
この場合、
- CMS：コンテンツ管理
- フロントエンド：表示・UX制御
と役割を明確に分けることで、パフォーマンスや拡張性を高めます。
CMSを「長く使う」ために
CMSは、導入した瞬間が完成ではありません。
- コンテンツが増えたとき
- 運用体制が変わったとき
- 機能追加が必要になったとき
こうした変化に耐えられる構成かどうかが重要です。
FHWでは、最初から完璧なCMSを作ることよりも、将来の変更に対応できる構造を作ることを重視しています。
このページで伝えたいこと
WordPressやCMSは、使えば自動的にうまくいく仕組みではありません。
- 何をCMSに任せるのか
- どこまでをシステム側で担うのか
- 将来どう変わる可能性があるのか
これらを整理したうえで使うことで、CMSは更新と運用を支える強力な基盤になります。
FHWでは、CMSを「目的に応じて選び、設計する技術」として扱っています。CMSを基盤に、検索・会員・予約・管理機能などへ拡張した事例は、Webシステム開発実績でご覧いただけます。
PRACTICAL INSIGHT CMSの自由度は、更新できることより再現できることで決める
CMSは自由に入力できるほど運用しやすいとは限りません。想定する記事を担当者が同じ品質で再現できるように、固定する範囲と選択できる部品を設計します。
公開を急ぐ場合は、必要な固定ページを先に整え、完成画面と運用対象を確認したうえでCMSへ移す方法もあります。最初からすべてをCMS化せず、実際の更新に必要な見出し、本文、画像、ボタン、囲み、余白などを再利用部品にします。
操作項目の説明だけでなく、テンプレート記事を作り、部品の順序、プレビュー、公開後の表示まで検証します。値がない部品は安全に省略し、独自機能やプラグインは競合、保守、操作権限を確認してから採用します。
構造・内容・見た目を、同じ入力欄へ押し込まない
更新担当者が変えるのは、原稿や画像などの「内容」が中心です。見出しの階層、余白、文字サイズ、ボタンの形といった「構造」と「見た目」まで毎回自由にすると、同じサイトの中でページごとの品質が揃わなくなります。
私たちは、まず実際の更新作業を確認し、固定する構造、入力する内容、選択できる部品へ分けます。例外的なページまで自由入力で吸収せず、通常更新で再現できる範囲と、個別に制作・確認する範囲を分けることで、CMSを複雑にしすぎないようにします。
通常の記事だけでなく、崩れやすい条件を先に通す
管理画面の入力欄が保存できても、公開画面で安全に使えるとは限りません。短い見出しだけでなく長い見出し、画像あり・なし、空欄、最大件数、異なる画像比率を登録し、一覧、詳細、スマートフォン表示まで確認します。
複数人が更新する場合は、プレビュー、確認、公開、差し戻し、履歴からの復元も運用の一部です。誰がどの状態まで進められるかを決め、表示が崩れたときに入力を直すのか、部品を改修するのか、制作会社へ戻すのかまで整理します。
新しい運用担当を加えるときは、作業から権限を決める
CMSの権限は、部署名や役職名だけでは決められません。同じ部署でも、記事を作る人、内容を確認する人、公開する人、ファイルだけを差し替える人では、必要な操作が異なります。
最初に、担当者が日常的に行う作業を書き出します。そのうえで、閲覧する情報、編集する項目、公開操作の有無、削除の可否、ファイルの更新先を作業単位で決めます。必要のないメニューや担当外のデータは見せず、誤操作が起きにくい範囲へ限定します。
既存CMSへ担当者を追加する場合も、現在の管理者権限をそのまま複製しません。既存担当者と新担当者の作業、両者で共有する確認、管理者だけが行う設定を分け、担当変更時に停止・変更するアカウントも決めます。
確認しておきたいこと
- 運用開始後に担当者が作成する記事・ページの種類
- 固定する見た目と、担当者が選択・並べ替えできる部品
- 管理画面の項目名と公開画面の対応関係
- テンプレート記事で再現性を確認する通常・例外パターン
- 最短・最長・空欄・最大件数・画像比率の違いによる表示
- 閲覧、下書き、編集、公開、削除のうち担当者に必要な操作
- 更新できる投稿種別、カテゴリ、ページ、ファイル
- 公開前の確認者、差し戻し・履歴復元の方法、担当変更時のアカウント対応
この考え方が有効な条件
決まった種類の記事を複数担当者が更新する場合に有効です。毎回異なるレイアウトが必要な場合や、記事更新ではなく業務データの状態変更・承認・操作ログまで扱う場合は、管理画面として別に設計します。
関連するケーススタディ
RELATED CONTENT 次に読む
同じ「つくるフェーズ」から、あわせて読みたい内容をご案内します。