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

WordPressを、専門じゃない人間が本番運用していけるか！？

ちょっとした情報サービスを作ろうと思い立って、ここ数日間¹、個人でホスティングしているさくらのインターネットにWordPressをインストール²して、がっつり取り組んだ。
WordPressについては以前にも仕事で何度か使い、使うたびに苦労した覚えがある。

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

WordPressとは

WordPressはPHP+MySQLベースのブログソフトウェア。CMSとしても活用され、広く世界中で用いられている人気のOSSだ。
豊富なテーマとプラグインが魅力で、これらを適宜選択・インストールすることで、プロフェッショナルなデザインと機能を兼ねそろえたサイト制作が比較的簡単に行える。
テーマやプラグインは無償も有償もあり、周辺のマーケットも大変盛況だ。日本でも100ドル前後のテーマを購入してサイトを展開している企業やブログサイトも多い。手軽な値段で超クールで最新デザインのサイトが作れてしまう！そりゃあ楽ですばらしい話である！

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

商用サービスを展開する場合にWordPressを活用するのはありか、を考えたい。
WordPressを使う商用サービスの業務パターンは、だいたい次のようなケースではなかろうか。
（SaaS/ASPなどでのWordPress自体の提供サービスを除く）

対象	業務タイプ	商用展開シーン	利用目的
	①ウェブコンテンツ制作会社	企業ページ / ECサイト	ブログ / CMS / ECサービス
	②ブロガー業務	ブログ展開	ブログ
	③ウェブサービス会社	ウェブサービスサイト	（サービス用コンテンツの）CMS
	④アプリ制作会社	アプリのコンテンツページ	（サービス用コンテンツの）CMS

本記事の考察では、 のついた ③、④ のケースについて考えたい。

①の場合はWordPressでの構築・運用を何度も専門的に行ってきているので、一定の形式知化が進んでいるだろうから除外。②も同様で、経験や成功体験から、自分なりに体系化した知識と応用力で解決をできるのではないか。

問題となるのは、③と④の場合。
③は、何かウェブサービスを展開しているプロジェクトがあって、ディレクタ、デザイナ、PGが数名から多くて10名ぐらいの小規模でサービスを回している場合。サービスのコアじゃないコンテンツ部分（ニュースやお知らせ記事など）を、うまくCMSなどを使って展開しようと模索していたりする。
④も③と似たような形で、アプリ内でWebView表示される静的なHTMLコンテンツをCMS管理したいとかいう場合。開発規模も③と同程度の少人数プロジェクト。

③と④のケースのように、小規模な開発チームの現場でWordPresssがCMSの候補にあがることはあるだろう。そのような場合の参考になれれば良いと思う。

WordPressのアドバンテージ

最初に、WordPressの良いところを確認しよう。
公式ページの冒頭で次の３つがまずアピールされている。これらはそのままWordPressのアドバンテージと言ってよいだろう。³

「美しいデザイン性」

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

「パワフルな機能」

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

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

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

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

• 歴史があり、だいぶ"こなれた"ソフトウェアである。インターネット上でたくさんの記事やフォーラム、トラブルシュート情報も見つけられる。
• 導入が楽な場合が多い。SaaS(ASP)として提供されていたり、クラウドでもインストール済みOSイメージが用意されていたりとかする。Docker Hubにも公式レポジトリがある。
• SEやPGじゃない、デザイナやディレクター職の人でも導入、設定、カスタマイズが可能。サーバ設定やプログラムを知らなくても、環境を整えてさえしまえばWordPressでサイトを管理し、ページを作成し、公開が可能。

 § § §

さて、これら利点はそのままWordPressを利用することのメリットに繋げられる。費用対効果も高そうで、上流工程での意思決定にも影響を与える要素だ。
実際、WordPressは完成されたシステムであるし、使いこなせばかなり強い。
そう”使いこなせるかどうか”が問題なのである。

WordPressの課題

ここからはWordPressの課題を整理していく。

結論をいうと、この課題を一言で言えばずばり「管理にとにかくコストがかかる」ことである。

なぜコストがかかるのかを整理していきたい。
（ここでいうコストは、銭金の話というよりは、理解と要領を得るのに必要な時間と労力、という意味です）。

管理の課題

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

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

WordPressのユーザー権限にはいくつか種類があるが、（ちょっと紛らわしいが）「管理者」という権限１種類にフル権限が与えられている。
「管理者」権限を与えられた管理者は、次の設定を管理画面から行うことができる。（記事の投稿・編集に関する管理は他の権限で行えるので、以下割愛する）

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

管理者が管理・設定すること = \left(デザイン\right) + \left(デザイン以外のサービス設定\right)

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

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

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

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

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

ところが困ったことに、どこで何が設定できるかは、導入したテーマやプラグインによって変化するのだ。メニューが増え、設定項目が増え、既存の設定内容が適宜カスタマイズされる。それら設定情報を、管理者はうまくコントロールしなければならない。
テーマによっては「あらかじめXXXというプラグインを導入せよ」と指定しているものもあり、すでに入れているプラグインとの競合も発生し得る。プラグインが互いにメニューを追加して、同じ機能が別なメニューとして存在しまう、といったとほほな状況もあるあるだ。

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

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

上で、「異なる２軸の設定管理を『管理者』１つの権限に委ねられてしまう」と書いた。
たいていの管理者は、デザイナ寄りかSE寄りかどちらかの人間なので、この２軸を管理しなければならないことは、管理者にストレスを生じさせやすい。

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

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

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

投稿記事ならばWordPress側でリビジョン管理をしてくれるので、何が誰によってどう変更されたかなど追っていける。
しかし、テーマやプラグインの導入、設定、カスタマイズ内容など、設定の変更内容の記録と履歴は、WordPressは管理してくれない。必要に応じて自分たちで管理しなければならない。
特にテンプレートのCSSやPHPコードをカスタマイズした場合などは、どこをどう変更したかを記録しておかないと、後できっと痛い目にあう⁴。むしろ痛い目に合わないために、カスタマイズは禁止してもいいのではないかと思う。

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

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

とあるテーマの導入やプラグインの設定などを考える。
デモを見ると、イマジネーションを掻き立てながらぬるぬる動いている、素敵なテーマだ。
インターネットでも情報も多そうだし、紹介文を見る限りではそれほど導入も難しくなさそうだ。当然そのテーマも関連プラグインも、管理画面から検索してインストールもできる。
管理画面での設定内容も、おおよそ把握できていて、大抵のことは設定できるようになっている。
なので、きっとこう考えるだろう。

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

…残念ながら、この見積もりは失敗するケースが多い。
次のような問題が発生し得る。

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

テーマに過度な期待を持たないようが良い。ドキュメントが無かったり足りなかったり、内容が古かったりするテーマもよくある。導入を試みて初めて期待していた機能がないとわかる場合もある。見栄えのするデモの再現に困難をきたし、できない内容をどう解決するかを調べて試し、とやっている間に、想定工数があっという間に過ぎたということ、みなさん経験はないだろうか？ 私はある！
特定のプラグイン導入を前提にしているテーマもあり、そのプラグインの導入・設定に関しては「よしなによろしく〜」と説明を省いている場合もよくある。さらに、そのプラグインがすでに公開終了している場合だってある。とほほ。
デモどおりの動きをさせるのになんでこんなに挫け心が折れるのか！？と、みなさん泣いた経験はないかだろうか？ 私はある！ 何度もだ！

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

プラグインもテーマと同じ問題をはらんでいる。加えて、似たり寄ったりのプラグインが多く、選定にコストもそれなりにかかる。目的の機能があるか、信頼できる製作者か、メンテされているものか、他と比較してどうか、などなどだ。
陳腐化もよくある。テーマのドキュメントで導入しろと案内されているプラグインや、インターネットの情報頼りに探したプラグインがすでに公開終わっていたり、とか、バージョンの互換性が保証されていなかったりとか。途方にくれてしまう。
無料と思って導入したら有償アップグレードしなければ必要な機能が提供されない（ズコー）なことも、プラグインあるあるだ ⁵。

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

”WordPressはなんでもできる”という変に知識をかじっているディレクターは、やれ「このテーマのこの部分をスライダーにして」とか、やれ「この条件のときだけパララックスになるようにして」とか、指示してこないだろうか？ どうやらいつのまにか客先とそういうデザイン仕様で合意をしてきている、といったりとか。カム着火インフェルノォォォォ！。
テーマは、テーマが提供しているデザイン以外のことをやろうとすると、とても手間がかかる。うまくプラグインだったりがハマればいいが、そうでなければCSSをカスタマイズして、レスポンシブの場合も考慮してカスタマイズして、画面サイズも考慮してカスタマイズして、必要ならばPHPコードの方も修正して…など、やることが沢山だ。工数だって読みにくい。
テーマのカスタマイズをすることの無いよう、開発の最初の段階で合意しておいたり、もしする必要になった場合でもそれなりの工数をもらえるようにしておく、といったネゴができれば幸いだ。

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

属人化の問題

管理者が管理することの多さと煩雑さを上に書いてきた。
管理者がリリース前に苦労して培った設定ノウハウは、その後の運用にも当然必要になってくる。

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

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

管理の課題のまとめ

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

管理の課題の解決案

管理者の管理しなければならない範囲は、広く、多い。
もし解決策を図るのであれば、管理者は1人にアサインするのではなく、役割ごとに管理する人間数名で、管理担当を分割しながらするのが良いではないだろうか。
属人化しないよう、シングルポイントにならないよう、管理範囲をある程度重複させることも必要だろう。

その他の課題

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

可用性の課題

WordPressを使ったサービスの冗長構成化にベストプラクティスはない。
WordPressのレイヤー外の設計の話だが、やり易いかどうかという点ではやりにくい。自分たちで冗長化手段を考え動作を担保する必要がある。

• WordPressの基本設計方針は1サーバ＋1DBを想定している。複数サーバを使った運用は想定されていないので、次の考慮が必要。
  • 同期方法（特に設定ファイルや画像など、ファイル単位のデータの同期）。
  • DBの冗長化と同期、フェイルオーバー時の切り替え方法。
  • バックアップ、リストアの方法。
• Dockerイメージ化が楽かもね。
• 基本的に動的コンテンツを提供するので、ある程度のサーバスペックは必要。
  • 静的コンテンツ化するプラグインなどの検討の余地もあり。
  • CDNの利用サポートをするプラグインもあるが、CDN上のコンテンツ管理はまた別な話。
  • 設定変更やらプラグイン導入、アップデートなどは、各サーバごとに行う必要がある。

セキュリティ要件の課題

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

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

コアな部分の脆弱性対応以外は、あくまでコンテンツ提供側（管理者）に任せるスタンス。必要なアップデートやプラグイン導入などでうまく安全管理してってね、というようだ。
この方針も、管理者の負担が増えてしまっている要因の１つだ。

• セキュリティ対策としてのプラグインへの依存度が高い。
  • たとえば、未だに、HTTPベースのログイン画面がデフォルトで、恐ろしいことにHTTPSでないことにWordPressからは警告などは一切表示されない。
  • サーバ設定やセキュリティ管理に明るくない人間が、ログイン画面・管理画面について、HTTPポートを閉じてなかったり、サーバ認証やIP制限を入れずに誰でもアクセスできる状態で商用運用している、といったケースも実にあるあるだ。
  • 常時HTTPS化や管理画面のアクセス制限とかはプラグインでも提供されていたりする⁶。
  • そういうセキュリティ周りについて、適切に、効率的に管理できるかどうかは、管理者次第。

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

脆弱性問題で記憶に新しいのが、次のREST APIの問題。デフォルトにするのおかしいだろうってツッコミたくなる。
『WordPress REST APIの深刻な脆弱性について』 - GMOクラウドの脅威・対策ページから

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

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

WordPressコア、テーマ、プラグインのアップデートは管理画面で簡単に行えるが、テーマやプラグイン自体の問題やバージョン互換性の問題が解決されるかどうかは、その作者次第だ。OSSのしょうがないところでもある。
WordPressがプラグインに依存することが多いシステムである以上、どうしてもこういうケースはある。管理者の適切な判断が必要になってくる。

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

以上、WordPressの問題を挙げてきた。

冒頭の方で区分した③ウェブサービス会社や④アプリ制作会社の小規模なプロジェクトで、リソースをあまり割けない規模のプロジェクトが、商用サービスのCMS管理にWordPressをほいほい手軽に利用できるか、と考えると ノー だ。
私は、お勧めしない。

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

• 管理コストが相当かかり、管理者の負担が大きい。
• 知見とノウハウを蓄積していないと、管理・運用が難しい。
• 設計・制作でも、思わぬところで想定通りにことが進まず、コストがかかりがち。
• しかも、工数が見積もりしにくい。
• テーマとプラグインに依存した製品コンセプトなので、それらの陳腐化に対応した置き換え手段がコンスタントに求められる。
• セキュリティもプラグインの導入と設定状況に依存している。適切な管理は管理者次第。
• 注意しないと管理状況が属人化・シングルオペレーションになりがち。
• スケーラビリティに弱い。

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

（以上）