作成日:  (更新日: )

企業サイト制作時の WordPress の利点と欠点

このページは、企業や団体のサイト制作時の WordPress の利点と欠点を考えるページです。

目次

注意

  • 現状このページを作ったひとの頭の整理のために記載しているため、WordPress 経験者でないとわからない用語などがそのまま記載してあります。

利点

無料・高品質

  • 無料で高品質なコンテンツ更新の仕組みを用意できる
    • ◎ 制作チームにプログラマーが不在でも制作可能 (デザイナーのみ、デザイナー＋インフラエンジニアのみなど)
    • 顧客要件に上手くはまれば1からの作りこみが必要なくなり、作業 (要件定義～設計～実装～テスト) の手間を減らせるため顧客に安価に提供できる
  • 管理画面のデザインや操作性がある程度確保されているので顧客に提供しやすい
    (デザインや操作性が悪いとカスタマイズせざるを得なくなる箇所が増えるので工数が増える)

機能性が高い

機能 実現方法
ブログや新着情報・ページの更新の仕組み 標準装備 (投稿、固定ページ)
お問い合わせフォーム Contact Form 7 プラグイン等
ページの一部のみを更新できる仕組み 標準装備 (カスタムフィールド)、Advanced Custom Fields プラグイン
下書き保存、プレビュー 標準装備
予約投稿機能 標準装備
履歴管理と復元 標準装備
ユーザー権限機能 標準装備 (管理者、編集者、投稿者、寄稿者、購読者)
ページの複製機能 Duplicate Post プラグインなど
種類の異なる一覧・詳細ページの用意
(ブログ、新着情報、採用情報など)		 標準装備 (カスタム投稿タイプ)、Custom Post Type UI プラグインなど
SEO 対策 All in One SEO Pack プラグイン等 (なくてもいい)
セキュリティ対策 SiteGuard WP Plugin など
  • その他足りない機能も既存のプラグインで補えやすい。最悪独自にプラグインを開発することもできる (後述の欠点もある)

カスタマイズ性が高い

  • 本体の動作や表示を変更できる仕組み (フィルターフックとアクションフック) が用意されているため本体ソースコードを変更せずに動作を変更できるポイントが多い (設定画面でできる設定も多い)
  • テーマ (公開側の外観) を自作できる。一から起こしたデザインをテーマ化しやすい

過去バージョンとの互換性が比較的保たれている

  • 他のオープンソース製品を踏まえるとバージョンアップでの破壊的変更が比較的少ない
    (昔のコードでも比較的動く。逆に本体ソースコードの書き方が古いなどで読みづらい欠点もある)

ドキュメントの情報量が多い

  • 公式のドキュメントが整理されている (WordPress Codex。日本語版もあるが英語版を見たほうが正確)
  • オープンソースで世界中で使用されているため公式以外の資料も豊富
    (書籍やブログ等。逆に古いバージョンの内容がネット上に残り続けている欠点もある)

欠点

継続的なバージョンアップのコストが高い (手間がかかる)

※ この部分については逆に保守業務を提案しやすい利点があります。
  • セキュリティ上バージョンアップし続ける必要がある (基本的に保守が必要)
    • バージョンアップする際に動作テスト工数が必要 (テスト環境用意など)
    • バージョンアップで逆に脆弱性が混入することがある
    • バージョンアップでデザインや機能が変わって作業者が困ることがある (再度マニュアル更新などが必要になる)
      • 例: 管理画面デザイン変更 (ver 4.0)
      • 例: 入力エディタ変更 (ver 5.0。ブロックエディター (Gutenberg))
      • 例: サーバー動作環境の変更 (ver. 5.2)
      • デザインや機能はそのままにしてセキュリティ部分だけを選択して対応することはできない
        (マイナーアップデートだけをし続けてもいつかはメジャーアップデートしないといけない)
    • 本体が問題なくても導入したプラグインに脆弱性が混入しているケースや、プラグインの開発が止まるケースがある (プラグイン選定が重要。プラグイン作者が企業なのか個人なのか、長く使われている有名なものか、プラグインがある程度マネタイズできていて継続開発されそうかなどを確認する必要がある)

標準機能や既存プラグインで対応できない要件は極端に実現難度が上がる

  • 標準機能や既存プラグインで顧客要件を満たせない場合、プラグインを自作するかテーマのスクリプト (functions.php) で対応する必要がある
  • WordPressの本体ソースコードや仕組みを熟知している人員が必要になる
    (古いコードベース、アクションフックなどの仕組みによる本体の内部動作が把握がしづらい欠点が顕在化する)
  • 「制作チームにプログラマーが不在でも制作可能」のメリットが潰れる
    (プログラマーがいても WordPress のノウハウが無いと頓挫する)

運用時の安全性担保の難度が 静的 HTML (CMS 無し) や CMS 独自開発より高い

※ この部分は WordPress の安全性が低いという意味ではなく制作側がどう安全性を担保するのかという課題の意味合いです。
  • WordPress のマーケットシェアが高いため、攻撃対象になりやすい
  • WordPress の仕組みについて知識があるメンバーがいないと WordPress のどこに気を付けるべきか判断できない
    • REST API, XML-RPC, 管理画面のアクセス制限など
  • 動的生成方式 (動的 CMS) のため、サーバー全体にアクセス制限などをかけづらい
    • 静的生成方式 (静的 CMS) の場合は管理サーバーと公開サーバーを分けられるが、動的だと分けづらい
    • WordPress にも静的生成用のプラグインはあるが、導入に検証やノウハウが必要

既製 CMS 全般の課題

  • バージョンアップを怠ると安全性が下がる
    • CMS 独自開発の場合、バージョンアップや改修は制作チームや顧客のスケジュールに合わせてコントロール (ハンドリング) できる
    • 既製 CMS だといつバージョンが上がるかコントロールしづらい
  • CMS と導入したプラグインの全機能を把握・テストして納品すること (問題ないと言い切ること) が現実的に不可能

参考: 静的生成方式の CMS やジェネレーター

コンテンツチェックの支援機能が手厚くない

※ この部分は IR 情報などの正確性が重要なページの公開前チェックを想定しています。
  • 標準や公式プラグインで承認ワークフローの機能が無い (プラグイン選定か開発が必要)
    • ユーザー権限機能は標準装備されているため、寄稿者が記事作成→編集者が公開、という流れは可能
    • 承認依頼メール等は標準機能には無い
    • 要件によって複数のプラグインを組み合わせることになりやすく、プラグイン同士で動作の連携が取れない場合やプラグインを多く入れることによるバージョンアップコスト・安全性などの課題が増える
      (例えばインターネット上でよく言及がある Peter’s Collaboration E-mails 等は 2020/03 時点では最終更新が4年前のため導入リスクが高い)
  • 一度公開したページを編集する際、前の状態を公開にし続けながら下書きを作ることができない
    • 新規ページを作って URL (slug) を差し替えるなどの方法を採る必要がある
    • テスト環境 (ステージング環境) を用意する場合、本番環境とテスト環境のデータの同期の仕組みや効率性が課題になる

参考: 承認ワークフロー機能のある CMS

その他

豊富なテーマ

  • 企業サイトを作るときはデザインを一から作成するのでテーマの利点は無い