Edited at

WordPressはいろいろコストが高すぎてお薦めできない

ちょっとした情報サービスを作ろうと思い立って、ここ数日間、個人でホスティングしているさくらのインターネットにWordPressをインストール1して、かなりがっつり取り組んだ。

以前仕事でも何度か使い、使うたびに苦労した覚えがある。

デザイン性や手軽さから人気のWordPressだが、商用サービスのコンテンツ提供CMSとして使うにはけっこうハードルが高い(重い)のでは、と以前から感じていた。今回の経験も含めていろいろ考察できたので、改めて問題を整理してみた。


WordPressとは

https://ja.wordpress.org/

WordPressはPHP+MySQLベースのブログソフトウェア。CMSとしても活用され、広く世界中で用いられている人気のOSSだ。

豊富なテーマとプラグインが魅力で、これらを適宜選択・インストールすることで、プロフェッショナルなデザインと機能を兼ねそろえたサイト制作が比較的簡単に行える。

テーマやプラグインは無償も有償もあり、周辺のマーケットも大変盛況だ。日本でも、100ドル前後のテーマを購入して、サイトを展開している企業やブログサイトも多いだろう。そのぐらいの値段で超クールで最新デザインのサイトが作れてしまうのだから、そりゃあ楽で素敵だ!


このドキュメントのゴール

商用サービスにおけるWordPressの展開シーンを考えると、だいたい次のようパターンではなかろうか。(SaaS/ASPなどでのWordPress自体の提供サービスを除く)

業務タイプ
商用展開シーン
利用目的

①ウェブコンテンツ制作会社
企業ページ / ECサイト
ブログ / CMS / ECサービス

②ブロガー
ブログ展開
ブログ

③ウェブサービス会社
ウェブサービスサイト
(サービス用コンテンツの)CMS

④アプリ制作会社
アプリのコンテンツページ
(サービス用コンテンツの)CMS

①の場合、WordPressでの構築を何度も専門的に行ってきて、時間をかけて形式知化を進めてきた会社を想定している。この場合、今回の記事にあるような問題については一定の解決力がすでに備わっていると思う。

②も同様で、経験や成功体験から、自分なりに体系化した知識と応用力で解決をできるのではないか。

問題となるのは、③と④の場合。

③は、何かウェブサービスを展開しているプロジェクトがあって、ディレクタ、デザイナ、PGが数名から多くて10名ぐらいの小規模でサービスを回している場合。サービスのコアじゃないコンテンツ部分(ニュースやお知らせ記事など)を、うまくCMSなどを使って展開しようと模索していたりする。

④も③と似たような形で、アプリ内でWebView表示される静的なHTMLコンテンツをCMS管理したいとかいう場合。開発規模も③と同程度の少人数プロジェクト。

③と④についてはこういうモデルケースを想定しているが、この小規模な開発チームの現場で果たしてWordPresssがお薦めできるか考察する、というのがこのドキュメントの目的である。


WordPressのアドバンテージ

最初に、WordPressの良いところを確認しよう。

公式ページの冒頭で次の3つがまずアピールされている。これらはそのままWordPressのアドバンテージと言ってよいだろう。2


「美しいデザイン性」

WordPressはテーマに基づいたデザイン駆動型のモデルだ。クールで最先端のデザイン手法を取り入れた豊富なテーマが公開(無償・有償)されている。ユーザーは1からサイトのデザイン設計やコーディングをしなくて済む
これは工数の削減にも繋がっている。テーマのデモでクライアントと具体的なイメージをすり合わせられる、カッコいいウィジットをソースコード修正やサーバへのアップロードなしに導入できる、軽いテーマでサクッとLPを作る、などなど。
 

「パワフルな機能」


管理画面が強力で、よくできている機能を拡張するプラグインも豊富で、たいていのものが用意されている。こういったプラグインやテーマも管理画面からサクッと検索・導入・アップデートができ、コードを書いたり修正する必要もない。鼻をほじりながら簡単にできる。実にパワフルで楽だ。
 

「望むものは何でも作れる自由」

テーマをカスタマイズしてCSSやHTMLを改変するも自由、PHPのコードを修正するも自由。もちろん修練を積んでテーマやプラグインの自作も可能。自前サービスを拡張するも良し、公開してお金を儲けることもよし。確かになんでもできるすごい柔軟性がある。強い!(白目)
 

この他、次のような利点もある。



  • 歴史があり、だいぶ"こなれた"ソフトウェアである。インターネット上でたくさんの記事やフォーラム、トラブルシュート情報も見つけられる。


  • 導入が楽な場合が多い。SaaS(ASP)として提供されていたり、クラウドでもインストール済みOSイメージが用意されていたりとかする。Docker Hubにも公式レポジトリがある。

  • SEやPGじゃない、デザイナやディレクター職の人でも導入、設定、カスタマイズが可能。サーバ設定やプログラムを知らなくても、環境を整えてさえしまえばWordPressでサイトを管理し、ページを作成し、公開が可能。

 § § §

さて、これら利点はそのままWordPressを利用することのメリットに繋げられる。費用対効果も高そうで、上流工程での意思決定にも影響を与える要素だ。

実際、WordPressは完成されたシステムでもある。使いこなせばかなり強い、なんでもできる。

そう”使いこなせるかどうか”が問題なのである。


WordPressの課題

次に、WordPressの利用を通して得た課題を整理する。

課題を一言で言えば「管理にとにかくコストがかかる」

購入費などの銭の話ではなく、何をするにしても、理解と要領を得るのに相応の時間と労力を要する、という意味だ。


管理の課題

管理者の負担がすごく大きくなるのがWordPressの管理の特徴と言える。


WordPressの「管理者」の範囲の問題

WordPressのユーザー権限にはいくつか種類があるが、(ちょっと紛らわしいが)「管理者」という権限1種類にフル権限が与えられている。

「管理者」権限を与えられた管理者は、次の設定を管理画面から行うことができる。(記事の投稿・編集に関する管理は他の権限で行えるので、以下割愛する)

管理対象
内容

基本設定
・サイト基本情報
・サーバ設定
・セキュリティ設定

テーマ
・デザインやレイアウト、サイト基本情報、ウィジットの設定

プラグイン
・機能拡張
・ウィジット
・サイト設定系

カスタマイズ
・テーマやテンプレートのカスタマイズ(コーディング)

ユーザー
・ユーザの追加・変更

管理者が管理することは、大きく「デザイン」に関する設定と「デザイン以外」に関する設定の2軸だ

管理者が管理・設定すること = \left(デザイン\right) × \left(デザイン以外\right)

デザインに関する設定は、テーマの選択はもちろん、そのテーマの基本デザインやレイアウト的な設定、ウィジットの管理、関連するプラグインの設定といった、完全にデザインマターな内容。

一方デザイン以外の設定は、サイトのセキュリティだったり、ユーザー管理だったり、機能拡張のプラグインの設定だったりと、デザインに全く関係ないことが多い。

この異なる2軸の設定管理を「管理者」1つの権限に委ねてしまうことは、業務分掌の点からもやりづらい。せめてデザイン管理に関しては、もう1つ権限レベルがあっても良いと思う。


管理内容がダイナミックに変化する

使い始めると分かるが、まず、管理画面のどこで何が設定できるかをまず把握する学習は必要。これはまあ仕方がないだろう。何をするにしてもそうだ。ただ、WordPressはできることも多いだけに、管理項目も多い。

ところが困ったことに、どこで何が設定できるかは、導入したテーマやプラグインによって変化するのだ。メニューが増え、設定項目が増え、既存の設定内容が適宜カスタマイズされる。それら設定情報を、管理者はうまくコントロールしなければならない。

テーマによっては「あらかじめXXXというプラグインを導入せよ」と指定しているものもあり、すでに入れているプラグインとの競合も発生し得る。プラグインが互いにメニューを追加して、同じ機能が別なメニューとして存在しまう、といったとほほな状況もあるあるだ。

管理者は、導入したテーマとやプラグインの設定の、何が設定できてどう設定すべきか、などの情報を含めて管理しなければならない。つらたん。


管理者のアサインが難しい

上で、「異なる2軸の設定管理を『管理者』1つの権限に委ねられてしまう」と書いた。

たいていの管理者は、デザイナ寄りかSE寄りかどちらかの人間なので、この2軸を管理しなければならないことは、管理者にストレスを生じさせやすい

デザイナ寄りな管理者ならば、テーマやウィジットのプラグイン管理は設定しやすいが、それ以外の設定に関しては誰かを頼ったりとかあるだろう。SE寄りな人ならば反対に、デザインについてはデザインの責任者にいちいち確認しながらでないと設定が進まない。

人員や開発リソースに限りがある環境では、管理者を誰にするか、複数人に分散させるか、とか、管理者と管理内容をどう管理するかという再起的な問題も発生しうる。つらたん。


変更管理・変更履歴・バックアップは自分たちで管理する必要がある

投稿記事ならばWordPress側でリビジョン管理をしてくれるので、何が誰によってどう変更されたかなど追っていける。

しかし、テーマやプラグインの導入、設定、カスタマイズ内容など、設定の変更内容の記録と履歴は、WordPressは管理してくれない。必要に応じて自分たちで管理しなければならない。

特にテンプレートのCSSやPHPコードをカスタマイズした場合などは、どこをどう変更したかを記録しておかないと、後できっと痛い目にあう3。むしろ痛い目に合わないために、カスタマイズは禁止してもいいのではないかと思う。

WordPressのイケてないことの1つに、設定内容がファイル(wp-config.php)とDBに分かれているというのがある。バックアップを取るならばそれぞれで取らなければならないし、リストアもそれぞれで行う必要がある。ソースファイルならばgit管理が良さげだろうし、DBのバックアップならばバッチを書いたりツールを使えば良さそうである。が、そういう管理って誰がどうやるの?という問題も整理しておく必要があるだろう。


管理画面での設定工数を見積もりしにくい

とあるテーマの導入やプラグインの設定などを考える。

デモを見ると、イマジネーションを掻き立てながらぬるぬる動いている、素敵なテーマだ。

インターネットでも情報も多そうだし、紹介文を見る限りではそれほど導入も難しくなさそうだ。当然そのテーマも関連プラグインも、管理画面から検索してインストールもできる。

管理画面での設定内容も、おおよそ把握できていて、大抵のことは設定できるようになっている。

なので、きっとこう考えるだろう。

「ま、長くても1人日程度で、設定も含めてうまくテーマが導入できるのではないかな」

…残念ながら、この見積もりは失敗するケースが多い。

次のような問題が発生し得る。


テーマの品質が一定ではなく、想定通りに設定が進まない

テーマに過度な期待を持たないようが良い。ドキュメントが無かったり足りなかったり、内容が古かったりするテーマもよくある。導入を試みて初めて期待していた機能がないとわかる場合もある。デモの再現に困難をきたし、できない内容をどう解決するかを調べて試し、とやっている間に、想定工数があっという間に過ぎたということ、みなさん経験はないだろうか? 私はある!

特定のプラグイン導入を前提にしているテーマもあり、そのプラグインの導入・設定に関しては「よしなによろしく〜」と説明を省いている場合もよくあるだ。さらに、そのプラグインがすでに公開終了している場合だってある。とほほ。
デモどおりの動きをさせるのになんでこんなに挫け心が折れるのか!?と、みなさん泣いた経験はないかだろうか? 私はある! 何度もだ!
 

海千山千のプラグインの中から、ベターなものを選定する必要がある

プラグインもテーマと同じ問題をはらんでいる。加えて、似たり寄ったりのプラグインが多く、選定にコストもそれなりにかかる。目的の機能があるか、信頼できる製作者か、メンテされているものか、他と比較してどうか、などなどだ。

陳腐化もよくある。テーマのドキュメントで導入しろと案内されているプラグインや、インターネットの情報頼りに探したプラグインがすでに公開終わっていたり、とか、バージョンの互換性が保証されていなかったりとか。途方にくれてしまう。

無料と思って導入したら有償アップグレードしなければ必要な機能が提供されない(ズコー)なことも、プラグインあるあるだ[^4]。

他のプラグインが干渉してて、目的の設定が反映されないことだってある。この場合プラグインを停止して1つ1つ有効にして確かめたりなどして問題の調査を行う必要がある。まるでWindows 95の立ち上がりのトラブルシューティングだ!
 

テーマをカスタマイズすることはぶっちゃけ難しい

”WordPressはなんでもできる”という変に知識をかじっているディレクターは、やれ「このテーマのこの部分をスライダーにして」とか、やれ「この条件のときだけパララックスになるようにして」とか、指示してこないだろうか? どうやらいつのまにか客先とそういうデザイン仕様で合意をしてきている、といったりとか。カム着火インフェルノォォォォ!だ。

テーマは、テーマが提供しているデザイン以外のことをやろうとすると、とても手間がかかる。うまくプラグインだったりがハマればいいが、そうでなければCSSをカスタマイズして、レスポンシブの場合も考慮してカスタマイズして、画面サイズも考慮してカスタマイズして、必要ならばPHPコードの方も修正して…など、やることが沢山だ。工数だって読みにくい。

テーマのカスタマイズをすることの無いよう、開発の最初の段階で合意しておいたり、もしする必要になった場合でもそれなりの工数をもらえるようにしておく、といったネゴは必要だろう。
 

WordPressでの制作経験が高い①ウェブコンテンツ制作会社などならば見積もり精度も高いかもしれないが、そうでない場合は、多めに工数を見積もったほうが良い。


属人化の問題

管理者が管理することの多さと煩雑さを上に書いてきた。

管理者がリリース前に苦労して培った設定ノウハウは、その後の運用にも当然必要になってくる。

しかしながらこの状況は、注意しないと属人化運用シングルオペレーションになってしまう。

そうならないように人を割り当てたり、知識を共有化・形式知化するといった施策も取れるだろうが、リソースに限りのある開発現場ではすぐに実践できない場合もあるだろう。「そのうちやらなければ」のTODOやTOBEなステータスまま、他の優先タスクを進めてしまう、っていうケースが”あるある”ではないだろうか。


管理の課題のまとめ

管理の課題をまとめると、こんな感じだ。

課題
課題内容
主な問題点

管理内容がダイナミック
テーマとプラグインに応じて管理項目が変化する。
・管理項目の増加
・設定内容に依存性が生じる

管理者のアサインの困難性
1人に一元管理か複数人での役割分散か、デザイナーが管理すべきかSEが管理すべきかか、など。
・デザインとデザイン以外の2軸を管理する必要がある

変更管理・変更履歴・バックアップ
変更管理・変更履歴の記録方法、バックアップ方法は、自前で用意する必要あり。
・どうやって管理・記録するか
・どうやってバックアップするか(PHPファイルとDB)
・リストア方法の確立

設定工数が見積もりしにくい
テーマやプラグインの品質などに影響されて、工程や工数が想定からずれる。
・テーマやプラグインが期待通り導入・機能しない
・テーマやプラグインの陳腐化
・プラグインの追加検討の発生

属人化
属人化が発生しやすい
・シングルポイントのまま放置
・ノウハウを形式知化できてない


管理の課題の解決案

管理者の管理しなければならない範囲は、広く、多い。

もし解決策を図るのであれば、管理者は1人にアサインするのではなく、役割ごとに管理する人間数名で、管理担当を分割しながらするのが良いではないだろうか。

属人化しないよう、シングルポイントにならないよう、管理範囲をある程度重複させることも必要だろう。


その他の課題

管理の課題の他に、商用サービスとして展開する場合に想定される課題を挙げる。


可用性の課題

WordPressを使ったサービスの冗長構成化にベストプラクティスはない

WordPressのレイヤー外の設計の話だが、やり易いかどうかという点ではやりにくい。自分たちで冗長化手段を考え動作を担保する必要がある


  • WordPressの基本設計方針は1サーバ+1DBを想定している。複数サーバを使った運用は想定されていないので、次の考慮が必要。


    • 同期方法(特に設定ファイルや画像など、ファイル単位のデータの同期)。

    • DBの冗長化と同期、フェイルオーバー時の切り替え方法。

    • バックアップ、リストアの方法。




  • Dockerイメージ化が楽かもね

  • 基本的に動的コンテンツを提供するので、ある程度のサーバスペックは必要



    • 静的コンテンツ化するプラグインなどの検討の余地もあり。

    • CDNの利用サポートをするプラグインもあるが、CDN上のコンテンツ管理はまた別な話。


    • 設定変更やらプラグイン導入、アップデートなどは、各サーバごとに行う必要がある




セキュリティ要件の課題

WordPressの大きな問題の1つとしてセキュリティの問題がある。なんせ問題の発生頻度がわりと高い


セキュリティに関する基本方針が甘い

コアな部分の脆弱性対応以外は、あくまでコンテンツ提供側(管理者)に任せるスタンス。必要なアップデートやプラグイン導入などでうまく安全管理してってね、というようだ。

この方針も、管理者の負担が増えてしまっている要因の1つだ。


  • セキュリティ対策としてのプラグインへの依存度が高い


    • たとえば、未だに、HTTPベースのログイン画面がデフォルトで、恐ろしいことにHTTPSでないことにWordPressからは警告などは一切表示されない

    • サーバ設定やセキュリティ管理に明るくない人間が、ログイン画面・管理画面について、HTTPポートを閉じてなかったり、サーバ認証やIP制限を入れずに誰でもアクセスできる状態で商用運用している、といったケースも実にあるあるだ。

    • 常時HTTPS化や管理画面のアクセス制限とかはプラグインでも提供されていたりする4

    • そういうセキュリティ周りについて、適切に、効率的に管理できるかどうかは、管理者次第




明らかにデフォルト値がおかしいだろうってこともWordPressあるある

脆弱性問題で記憶に新しいのが、次のREST APIの問題。デフォルトにするのおかしいだろうってツッコミたくなる。

『WordPress REST APIの深刻な脆弱性について』 - GMOクラウドの脅威・対策ページから

その他、ログインIDやメールアドレスが普通に記事中に晒される設定になっていたり(テンプレによってはハードコードされていたり)、コメントやトラックバックPing設定がデフォルトでONになっていたりと、昨今のセキュリティ意識をあまり反映していない印象が多い。


セキュリティアップデートできない場合もありうる

WordPressコア、テーマ、プラグインのアップデートは管理画面で簡単に行えるが、テーマやプラグイン自体の問題やバージョン互換性の問題が解決されるかどうかは、その作者次第だ。OSSのしょうがないところでもある。

WordPressがプラグインに依存することが多いシステムである以上、どうしてもこういうケースはある。管理者の適切な判断が必要になってくる。


(まとめ)WordPressは気軽に商用サービスでの利用を薦められるか

以上、WordPressの定性的な問題を挙げてきた。

冒頭の方で区分した③ウェブサービス会社や④アプリ制作会社の小規模なプロジェクトで、リソースをあまり割けない規模のプロジェクトが、商用サービスのCMS管理にWordPressをほいほい積極的に利用できるか。

私の答えは、ノーだ。お勧めしない。

WordPressは完成されたシステムと言える。言えるのだが、コストがかかりすぎる。


  • 管理コストが相当かかり、管理者の負担が大きい。

  • 知見とノウハウを蓄積していないと、管理・運用が難しい。

  • 設計・制作でも、思わぬところで想定通りにことが進まず、コストがかかりがち。

  • しかも、工数が見積もりしにくい。

  • テーマとプラグインに依存した製品コンセプトなので、それらの陳腐化に対応した置き換え手段がコンスタントに求められる。

  • セキュリティもプラグインの導入と設定状況に依存している。適切な管理は管理者次第。

  • 注意しないと管理状況が属人化・シングルオペレーションになりがち。

  • スケーラビリティに弱い。

導入に際してはよくよく検討を。

(以上)





  1. ちなみにさくらのインターネットでは、コントロールパネルを通して、実に簡単にWordPressをインストールが可能である。 



  2. 公式ドキュメントでは、テンプレート駆動型と言っている。しかしながら、実際はテンプレートよりもそれを包含しているテーマのほうが、サイト構築にあたっては重要だ。 



  3. プログラムのソースコードで、勝手な修正、秘密の修正、履歴の残らない修正がすごく問題になりやすいのと同じ。 



  4. さくらのインターネットでは、専用のプラグインを用意している。