Dyno

WordPress に不満がある。とりうる選択肢は?

今回は WordPress でサイトを運営している方が WordPress に不満があるときにどんな選択肢をとりうるのか というお話をします。

対象読者は次の方です。

  • WordPress でサイトを運用しているウェブ担当者または事業主
  • WordPress に不満がある

WordPress への不満を解消するための選択肢

WordPress サイトに不満があるときにとりうる選択は大きく分けて 2 つあります。

  • WordPress を使い続ける
  • WordPress をやめる

前者は WordPress の利用を継続した形で不満ポイントの解消を試みるパターンです。 後者は WordPress をやめて別のプラットフォームに載せ替えるパターンです。 状況によってはその他の選択肢もあるでしょうが、多くのケースでとりうる代表的な選択肢はこの 2 つでしょう。

具体的にどんなポイントに不満があるのかによってとりうる選択肢・とるべき選択肢は変わってくるので、以下代表的なポイントをあげて説明していきます:

  • デザイン
  • 表示速度
  • 機能
  • セキュリティ
  • コスト

デザイン

WordPress のデザイン面・見栄えに不満がある場合です。

実はデザイン面に関しては、 WordPress を使うことによる制約というのはほとんどありません。 よほど特殊なデザインや SPA 1 等であれば別ですが、世の中にあるたいていのサイトデザインは WordPress 上でムリなく実現できます。 どちらかというと、制作を担当するデザイナーや技術者のスキルの限界がボトルネックになることの方が多いです。 そのため、不満のポイントがサイトのデザイン面だけにあるのであれば、ほとんどの場合は WordPress をやめる必要はありません。 むしろ WordPress を使い続けるべきです。

できること:

  • WordPress のままテーマを差し替える
  • オリジナルテーマを作ってカスタマイズする

表示速度

WordPress の表示速度――いわゆる「パフォーマンス」の面に不満がある場合です。

「 WordPress は遅い」という声がウェブ上でわりとたくさん見られるので WordPress は無条件に遅いものだとお考えの方もいらっしゃるかもしれませんが、 WordPress はパフォーマンスが特別に悪い CMS ではありません。 少なくとも「適切な使い方をしているのに遅くて全然使い物にならない」なんてことはありません。

WordPress サイトのパフォーマンスが悪くなる原因はさまざまで、よくある原因には次のようなものがあります。

  • サイトのコンテンツ量やトラフィックが多い
  • サーバーマシンやネットワークのスペックが低い
  • WordPress の使い方が悪い

これらのいずれのケースでも原因は WordPress にはありません。

ですので、サイトのコンテンツ量やトラフィックがよほど多いということでなければ、 WordPress のまま改善するというのが第一の選択肢となります。 それでもどうしてもダメな場合にのみ、パフォーマンスに有利な JAMstack やウェブアプリケーションフレームワーク(以下「フレームワーク」)に移行するという選択肢を検討します。

他の CMS に乗り換えるという選択肢もありますが、 WordPress と同等の機能を持った CMS であればパフォーマンス面は似たり寄ったりで、劇的な改善は望めません。 ですので、パフォーマンスを主な理由に WordPress から別の CMS に乗り換えるのはよい戦略ではありません。

できること:

  • サーバーマシンやネットワークのスペックを上げる
  • WordPress 本体やプラグインの使い方を見直す
  • 適切なパフォーマンスチューニングが行えるプロに依頼する

機能

WordPress の機能面に不満がある場合です。

実は、一般にウェブサイトに求められる機能のほとんどは WordPress 本体と定番プラグインでカバーできます。 ですので、あくまでも「ウェブサイト」の範疇のサイトを運用していて機能が不足しているなら、使えるプラグインを探すのが第一の選択肢です。 それでもダメならカスタムプラグイン開発による対応を検討します。

カスタムプラグイン開発でも対応が難しかったりコストが高くつく場合は、より自由度の高いフレームワーク等への乗り換えを検討します。 この場合、対象のサイトは「ウェブサイト」の範疇を越えて「ウェブアプリケーション」と呼ぶべきものになっていると思います。

できること:

  • 定番プラグインを探し、合うものがあればそれを使う
  • カスタムプラグインを作る(できるプロに依頼する)
  • WordPress をやめてフレームワークに載せ替える

セキュリティ

WordPress のセキュリティ面に不満がある場合です。

WordPress 等の CMS を使ってサイトを運用する場合、セキュリティは絶対に手を抜いてはいけないポイントです。 特に WordPress のような動的 CMS はさまざまな切り口からの攻撃が可能なので、気をつけるべきポイントもそれだけ多くなります。

「動的 CMS 」に起因する部分でセキュリティを改善したいなら、動的でないサイト管理手法への移行を検討します。 具体的には、静的サイト・静的 CMS ・ JAMstack 等を検討します。 フレームワークへの移行という選択肢もありますが、フレームワークは動的であるという点では WordPress と同じなので、この場合はフレームワークへの移行はあまり有効な解決策ではありません。

また、一般にサイトが動的であることにはセキュリティやパフォーマンスの面でのデメリットを上回るメリットがあります。 ひとつの側面だけにとらわれず、必ず総合的な評価をして「静的サイトや JAMstack の方が総合的に見てよい」と確信できる場合のみ移行を実施するべきです。

尚、「動的 CMS 」というカテゴリの中でいうと WordPress のセキュリティは決して弱くないので( 参考 )、あくまで「動的 CMS 」の範囲の中でセキュリティ向上を検討するなら、別の CMS に乗り換えるのはよい選択肢ではありません。

できること:

  • WordPress のセキュリティ強化が適切に行えるプロに依頼する
  • WordPress をやめて静的 CMS や JAMstack に載せ替える

コスト

WordPress のコストに不満がある場合です。

ここでは手間の面でのコストは考えず金銭的コストだけをコストとして考えます。 もし制作コスト等の初期コストをすべて払い終えているのだえれば、運用時にかかってくるコストの大部分は「 WordPress の保守」と「サーバーのホスティング」の 2 つが占めるはずです。

このうち「 WordPress の保守」の方は、一般に年間数万円〜数十万円の範囲に収まることが多いかと思います。 「サーバーのホスティング」の方は、契約プランやトラフィック次第なところもありますが、多くの中小零細では年間数万円ぐらいの範囲に収まるでしょう。

これらをあわせても高々年間数十万円なので、人件費や宣伝広告費の額と比べると桁違いに安いはずですが、それでも負担になる場合は静的サイトやクラウドサービスへの載せ替えを検討します。 ただし載せ替えにも相応のコストがかかるので、「コストを下げるつもりがかえってコストが上がってしまった」といったことにならないように注意が必要です。

トラフィックが多くてサーバーのホスティングのコストがかさむという場合は、よっぽどトラフィックが多ければ JAMstack や動作の軽いフレームワークに載せ替えます。 ただし、サーバーにかかるコストは人件費に比べると安いので、サーバーにかかる多少のコスト増は受容するという選択肢がよい場合もよくあります。

できること:

  • WordPress をやめて静的サイトやクラウドサービスへの載せ替える

まとめ

ということで、 WordPress サイトに対する不満を解消したいときにどのような選択肢があるのか・どのように考えればよいのかというお話でした。

WordPress に不満があると人はすぐ「 WordPress はダメだ!他のものに乗り換えよう!」となりがちですが、勢いだけで他のプラットフォームに乗り換えることだけは避けるようにしてください。 問題の根本原因を理解せずに他のプラットフォームに乗り換えてしまうと、後々「やっぱり WordPress の方がよかったなぁ」と気づいて後の祭にもなりかねません。

不満の原因は WordPress にあるのか、別のところにあるのか。 直面している課題は WordPress を使うかぎり避けられないものか、何らかの回避策や緩和策があるものなのか。 そのあたりを正しく把握し、不満を解消するための最適な一手を打つようにしていただければと思います。

ご参考になれば幸いです。 尚、今回は WordPress を取り上げましたが、他の CMS でも考え方は同じです。

Dyno でも WordPress サイトに関するご相談をお受けしていますので、お悩みの方はぜひお気軽にご相談ください。


  1. シングルページアプリケーション

  2. 静的サイトと動的サイトを併用したようなアーキテクチャ。 JAM は JavaScript + APIs + Markup の頭文字です。参考: JAMstack とは?なぜ今 JAMstack なのか? / CMS と比べた JAMstack のメリット・デメリット