【WordPress】もう恐くない!運用や開発でのリスクマネジメントを知っておく

launcher-kit-wordpress-risk-management-in-the-production-environment-wordpress

解決できる悩み
  • 開発者ではないがWordPress運用についてのリスクを知っておきたい
  • WordPressを運用するにあたってのリスクヘッジをしたい
  • プラグインの更新やテーマの切り替えのときにドキドキする

ウェブサイトを運用して行くときにはリスクマネジメントが必要です。

今回はWordPress運用にあたってのリスクにどのようなものがあるのか?その解決法は何か?というところをピックアップしていきたいと思います。

WordPressに潜むリスク

リスクマネジメントで最も重要なことは問題が起きないようにすること(原因療法)です。
リスクに対しての対策というのはあくまで対症療法であり、原因療法にはなりません。

なのでWordPressでサイトを運用したり開発するなかで起こり得る潜在的なリスクを理解しておきましょう。

バージョン管理が難しい

補足

バージョン管理とはソフトウェア(ウェブサイト、アプリなど)の状態にラベルをつけタイムライン形式で保管しておくことを指します。

サイトを運用する中で「想定していた動きをしない」や「何故だが上手く動作しない」という時、まずは「ある状態に戻そう」ということを考えると思います。

WordPressでもコアシステム(WordPress本体)や、プラグイン、テーマなどの多くはバージョン管理されていますが、サイトの設定やコンテンツ全体をバージョン管理する機能は組み込まれていません。
なので、WordPressの設定を変更して上手く行かない時「ある時点に戻す」というのは結構ハードルが高いです。

依存関係が複雑

補足

依存関係とはソフトウェアに組み込まれているパーツや部品などが、それぞれ相互に作用しあっている状態を指します。

WordPressは依存関係が非常に複雑です。

WordPressサイトはエンドユーザーに表示されるまでに以下のような依存関係を経ています。

  • サーバー
  • PHP
  • MySQL
  • コアシステム
  • プラグイン
  • テーマ

この依存関係ゆえに「ネットの情報を参考に自分のWordPressサイトでも同じ方法を試してみたけど解決しない」という問題が’発生します。

操作ログが残らない

補足

操作ログとはソフトウェアの管理者やユーザーがどういう操作を経て今の状態に至っているかの記録のことを指します。

WordPressではほとんどの操作や変更にログが残りません。
なので、何か不具合が発生して自分で解決することを諦め、専門家に相談しても原因の特定が難しいです。

運営者本人の記憶をたどって原因を予測することになり手間がかかるため改修費も高額になりがちです。

本番環境でのリスク

次に本番環境(ウェブ上に公開していてユーザーが利用する事ができる)で運用しているWordPressサイトに潜むリスクを知りましょう。

変更が即時に公開される

本番環境での最大のリスクは変更が即時に公開されることです。
本来、試験的な機能の導入やテーマのカスタマイズなどを本番環境で行うべきではありません

実践的なホームページ制作やソフトウェア開発では変更を加えた際に、ユーザーが見えない環境で確認を経て公開へ至ります。

補足

上記のように公開前に一旦テストする環境のことをローカル環境やステージング環境と言います。

変更が即時に反映されるというのは最新の情報をいち早くお届けできるというメリットもあります。
しかしユーザーにとってマイナスな変更もすぐに反映されてしまいます。

不具合が発生して画面が真っ白になったり、秘匿したい個人情報を掲載してしまった場合でも本番環境である限りはユーザーが訪問する可能性があります。

リスクを回避(リスクヘッジ)する方法

WordPress環境への理解を深める

言うまでもなくあらゆる場面で役に立つリスクヘッジです。
これは私自身が身を持って体験しています。

ウェブ開発に関する知識や技術もなく初めは手探りでWordPressサイトを運用していました。
その当時は色んなことに不安になっていましたが、現在ではWordPressで起こりうる問題のほぼ全てを解決できます。

ただしウェブエンジニアを目指す人でもない限りWordPressサイトを運用する目的は別のところにあるので、費用対効果が良いとは言えないでしょう。

バックアップを確保する

誰でも比較的簡単に導入でき、一定のリスクヘッジ効果が見込めるのがバックアップによる対策です。

補足

バックアップとバージョン管理は似て非なるものです。
バージョン管理が「ソフトウェアの状態にラベル付け」、バックアップは「ある時点でのソフトウェアのセーブデータ」という感覚です。

バージョン管理と比べると細かな取り回しや差分検知がしづらいのですが、専門的な知識が無くともすぐに導入できる、自動化しやすいというメリットがあります。

バックアッププラグインを導入する

WordPressのバックアップは手動で行うことも可能ですがプラグインを導入することで更に簡単になります。

WordPressのバックアッププラグインの多くはリスクヘッジに必要な以下の機能を備えているものが多いです。

  • 手動バックアップ機能
  • スケジュールによる自動バックアップ機能
  • バックアップデータの圧縮
  • バックアップデータを自動でダウンロード&アップロード
  • バックアップデータから復元

契約しているサーバーのバックアップ機能を活用する

WordPressサイトを運用しているサーバー会社のサービスによって、サイトのバックアップを保管してくれる機能があることもあります。

私がWordPressサイトの運用に利用しているサービスのひとつであるXserverには自動バックアップ機能があります。

割と「WordPressが使えます!」というのを売りにしているサーバーサービスではバックアップ機能を搭載していることが多いように感じます。
自身が契約しているプランにバックアップ機能が付帯しているか調べてみても良いでしょう。

開発環境を用意する

WordPressに潜むリスクや発生するトラブルの大半は本番環境であることに原因があります。
こういった場合は本番環境の前にテストが出来る環境があれば良いでしょう。

ただし、これらの環境を十分に活用する場合には開発者として、それなりに専門的な知識を求められるケースが多いです。

開発環境を用意することはリスクヘッジの方法としてかなり効果的ですが、同時に導入ハードルもそれなりのものになるでしょう。

ここでは開発環境の代表的なものであるローカル環境とステージング環境について説明します。

ローカル環境

WordPressにおけるローカル環境とは自身のパソコンの中に仮想的なサーバーを設置して運用するWordPress環境のことを言います。

WordPressのハウツー記事を見ると「WordPressサイトを作るにはサーバー契約が必要」という情報を目にすると思いますが厳密には「外部に向けて公開するWordPressサイトを作るにはサーバー契約が必要」というのが正確です。

ローカル環境は外部に公開する必要が無いのでサーバー契約が無くとも構築可能で、作って壊すために存在します。

ステージング環境

WordPressにおけるステージング環境とはローカル環境と本番環境の間に存在するより本番に近い正確な検証ができる開発環境です。

ローカル環境と違い実際に存在するサーバーで検証するため、ネットワーク速度、表示の早さ、マルチデバイスなどをかなり正確に検証ができます。

英語のリーディング力を高める

WordPressは他のソフトウェアに比べるとかなり日本語の情報が充実しています。
しかし、英語圏の情報量や鮮度とは比較になりません。

問題に直面したときにネットで解決法を調べると日本語では解決できなくても英語で検索すると良い情報がヒットすることはよくあります。

これもWordPress環境への理解を深めると同様に学習コストが高いため気軽に導入できるものではありません。
しかし、先々開発者を目指す人や英語に高い関心がある人にとって「英語が読める」というのは大きな財産になるのでオススメです。