皆さんこんにちは、taneCREATIVEの「ちほうタイガー」です。
2020年8月末に本記事を書いています。
新型コロナの影響で日本中がまだまだ大変な状況ですが、こういう時だからこそ皆様のお役に立てる記事を書ければと思います。長文になるかと思いますが、どうぞよろしくお願い致します。
本記事では、企業にてWordPressサイトの運用・管理を担当されている担当者様を対象にして、そもそもWordPressとはどのようなCMSなのか、WordPressのメリット、WordPressのデメリットと対応策、そして他社様が制作・開発されたWordPressサイトの保守をお引き受けし難いケースなどについて、一通り基本事項を解説することで、WordPressサイトの保守の必要性と注意点についてお伝えしたいと思います。
なぜ、今更“WordPressサイトの保守”なのかといいますと、2020年5月からですが、他社様が制作されたWordPressサイトの保守を引き継いでほしいといったご相談が増えてきているからになります。
大抵の理由は、「今までお願いしていた制作会社さんが解散になった」とか「突然担当者に連絡がとりにくくなった」「エンジニアの人員が足りず対応できないと言われた」といった企業サイドからのご相談が多いのですが、一方で「解散することになった」あるいは「事業縮小で赤字の保守事業をサービス停止することになったので引き受けてほしい」というようにWeb制作会社さんサイドからのご相談も増えてきていると感じます。
これまでも月に1~3件ほどご相談がありましたが、コロナ禍の特に2020年5月以降は、週に3~10件ほどのご相談があるといった状態で、特に一定の規模を有する企業様からWordPress+AWSという組み合わせでのご相談が急増している印象があります。
また、WordPress+AWSという組み合わせでのご相談が増えている点については、そもそもWordPress+AWSという組み合わせが多いことに、(もちろんダメではありませんが)当社としては若干の戸惑いを感じている状態です。
詳細は後述いたしますが、例えば、当社にてAWSをクライアントにお勧めするケースは、【アクセス負荷の急激な増大に対応する可能性がある】とか【将来的にWebサービスの柔軟な拡張性が求められる】場合なのですが、こういった案件ではCMSとしてWordPressをお薦めするのは避ける傾向にあるからです。
そこで、本記事においては、WordPressサイトを当社にて引継がせていただく際に、当社より説明をさせていただく事項と、引き継ぎをする側から見た確認事項等をできるだけ基本的な事項からお伝えできるように努めたいと思います。
目次
WordPress(ワードプレス)は2020年8月末現在、世界で圧倒的な支持を得ているオープンソースのブログソフトウエアであり、CMS(コンテンツ管理システム)です。
元々はブログソフトウエアとして開発されたCMSとしては、Movable Type(ムーバブル・タイプ)が先行してシェアを有していました。日本でも2008年ごろまでは、「CMSと言えばMovable Typeでしょう」という制作会社さんが多かったという印象です(あくまで筆者の記憶上の主観的な印象です)。
しかしながら、世界ではそれより早くWordPressが主流となってきており、W3Techsによれば、本記事を記載している2020年8月31日時点で、世界中のWebサイトの約38.2%がWordPressで構築されているとのことです(グラフ1参照)。当社の記録によれば、2年前である2018年の春に確認した際には30.7%でしたので、この2年間でも凄まじい勢いでシェアが増えていることがわかります。
なお、同じくW3Techsによれば、CMSというマーケットにおいて、WordPressは63.5%のシェアを有しているとのことですので(グラフ2参照)、もはや圧倒的な支持を得ているCMSであると言ってよいでしょう。
当社は2012年の創業以来、WordPressを多く利用してWebサイトを制作しておりますが、その理由としては、当社代表を含む創業メンバーが、2008年頃から「WordPressが日本でもシェアトップを奪う」と確信してノウハウの蓄積を行ってきたからになります。
現在はケースによってお薦めするCMSを使い分けておりますし、静的サイトジェネレーター(SSG)を含めた各種最新技術も実践に耐えられるレベルに日々洗練されてきておりますが、まだしばらくはCMSの世界トップシェアはWordPressのままであると考えております。
ここで誤解を少なくすべく付言すると、当社代表は、Movable Typeの静的なコードを生成するという根本思想が大好きですし(それが高じて、2018年よりいわゆる静的サイトジェネレーターのノウハウの蓄積を進めています)、優秀なCMSであることは間違いないと思います。
ただ、当社代表の好みはどうでもよいとして、WordPressが圧倒的なシェアを有するようになった根本的な原因について、私見を述べれば、WordPressは、オープンソースのCMSであるがゆえに、CMS自体が完全無料であるだけでなく、様々なテーマやプラグインなどが豊富に開発されており、その結果、「初期費用を抑えながら、一定レベル以上の高品質なWebサイトの制作、管理システムの開発、運用を実現できる」ということになるかと思います。
WordPressのメリットを丁寧に説明しようとすれば、かなりのテキスト量となってしまう為、ここでは「WordPressを利用するとどうして初期費用を抑えることが出来るのか」について、一般的なWeb制作会社の観点からポイントだけ解説していきたいと思います。
CMS自体の権利取得・更新に関するライセンス費用の削減(WordPress本体の利用) |
Webサイトを管理するCMSにも色々ありますが、例えば、前述のMovable Typeを企業サイトで利用しようとした場合、Movable Type 7の初年度は90,000円、2年目以降は年間30,000円の年間メンテナンスライセンスが必要となります(Movable Typeの料金表はこちら)。 このMovable Typeは実は安い方で、数百万円の初期ライセンス費用がかかるCMSはいくつもありますし、いわゆるエンタープライズ向けCMSの場合には、更に桁が違うケースもあります。これに対し、WordPressは完全無料のオープンソースのソフトウエアであるためCMS自体のライセンス取得・更新に費用が掛かりません。 WordPressは、世界中の多数の専門家が、日夜、無償で改善・開発・その他の運営業務を継続してくださっており、そのお陰で私たちは無料で高品質なCMSを利用することが出来ます。 |
デザイン・コーディング工数の削減(テーマの利用) |
WordPressには、テーマと呼ばれるWebサイトのデザイン・機能がセットになったパッケージが多数存在し、これを簡単に利用することができます。 このテーマには、無料のWordPress公式ディレクトリーのテーマと企業や個人のエンジニアが販売している有料のテーマが存在しますが、これらのテーマをそのまま利用するか、テーマにカスタマイズをすることで、一からデザインすることなく(ケースによってはほとんどHTML,CSSをコーディングすることなく)、Webサイトのデザイン並びに基本的なHTML,CSSが生成できてしまいます。 これにより、デザイン工数とコーディング工数を削減することができます。 |
各種追加機能開発・実装工数の削減(プラグインの利用) |
WordPressには、プラグインと呼ばれる様々な追加機能が多数存在し、これを簡単に利用することができます。 このプラグインも、無料で利用できるものが数多く揃っていますが、企業や個人のエンジニアが販売している有料のプラグインも存在します。 これらのプラグインを利用することで、様々な追加機能を実装することができるため、各種追加機能の開発・実装工数を削減することができます。 |
セキュリティー対策に関する初期工数の削減 |
Webコンサルティングの一環として、あるいは他社様が開発されたWebシステムをお引き受けする際に、かなりの確率で脆弱性が発見されますが、規模の小さなWebシステムにおいては、スクラッチ開発(全ての要素を独自に開発する手法)のケースで最も高確率で致命的な脆弱性が見つかっています。 あくまで当社の推測ではありますが、小規模な案件ではエンジニアによるクロスチェックや脆弱性審査などがなされずに納品されるため、エンジニアのケアレスミスによる脆弱性が取り除かれていない状態で納品されているケースが多いのではないかと感じます。これに対し、WordPressの場合、WordPress本体(コアファイル)、テーマ、プラグインを適切にバージョンアップさえすればほとんどの脆弱性に対応することができます。むしろCMS側がセキュリティー対策を実施してくれるため、エンジニアがケアレスミスで脆弱性を組み込む確率は低いと言ってよいでしょう。 これは、貢献者と呼ばれる世界中の専門家の皆さんと、テーマ、プラグインの開発関係者の皆さんが、日夜迅速な対応をしてくれているからに他なりません。 これにより、セキュリティー対策にかかる初期費用を大幅に削減することができます。 |
このように、WordPressは、(これをサポートされているコミュニティーも含めて)非常に優秀なCMSであり、そうであるがゆえに世界で圧倒的なシェアを占めているわけですが、一方で動的なCMSであることから、Webサイトの表示速度が遅くなり易いという構造上の弱点があります。
ここでいう「動的なCMS」とは、ユーザーがアクセスをした時の情報に基づいて、リアルタイムでWebページを生成するCMSのことを指します。
すなわち、Webサーバー内に最初から完全なHTMLファイルが存在するわけではなく、①ユーザーがWebサーバーにアクセス(リクエスト)をすると、②CMSの方でDBサーバーにコンテンツデータを渡すよう指示を出し(クエリ送信)、③DBサーバーからコンテンツデータを送ってもらった上で、④ユーザーがブラウザで入力したデータや、Webサーバー内に元からある更新頻度の低いファイルと組み合わせて、⑤HTMLファイルを作成して、ブラウザへ送信します。
これに対し「静的なCMS」とは、Webサーバー内に最初から完全なHTMLファイルが存在させる手法で、①ユーザーがWebサーバーにアクセス(リクエスト)をすると、②Webサーバーが要求されたデータをそのままブラウザに送信し、表示します。
※この静的なCMSと静的サイトジェネレーター(SSG)の違いもあるため、それぞれの流れを(かなり)単純化してまとめた図を作成してみました。
【対策】WordPressサイトの表示速度を高速化するための対策例 |
Webサイトの表示速度はSEOの面でも、UX改善の面でも非常に重要であるという点に異論は少ないと思います。その為、WordPressを使いながらどのように表示速度を高速化するかについては、色々な対策が生み出されています。 一般的な対策例を列挙していきますので、検討していただければ幸いです。 ・WordPress高速化パッケージサービス・サーバーを利用する。 ・PageSpeed Insightsでチェックしながら高速にするため一つ一つ改善する。 ・次世代通信プロトコルHTTP/2を利用する。 ・Webサーバー内部にPHPの中間コードのキャッシュを実装する。 ・Webサーバー内部にページのキャッシュを設置する。 ・Webサーバー外部にページのキャッシュを設置する(CDN)。 |
前述のように、WordPressでは、テーマと呼ばれるWebサイトのデザイン・機能がセットになったパッケージを利用することで、デザイン・コーディングの工数を削減することができます。
このテーマも公式のものを利用・カスタマイズされている分には、お引き受け時に問題が生じることはあまりないのですが、いわゆるサードパーティ製の有料テーマを利用されている場合、後ほど運用段階での拡張性で課題が生じるケースがあります。
有料テーマは機能が豊富ですし、高度にパッケージ化されていることから、有料テーマで想定されている挙動・機能を実装するには非常に適していると言えます。
しかしながら、有料テーマで想定されていない挙動や機能を実装しようとすると、逆に「できるけど、一から作るより時間がかかる」といった問題がしばしば起こります。パッケージとして完成されているがゆえに、想定外の改修が難しくなるということですね。
引継ぎ後に、担当者の方から「前の制作会社さんに修正を依頼したら、『WordPressなのでできません』と回答された。『WordPressのメリットは拡張性』だと最初に説明を受けていたのに…」といったお話をたまに聞きますが、大抵は有料テーマとの関係かプラグインの関係であるケースが多いと感じます。
『WordPressなのでできません』というのは、おそらくは「できるだけど、工数がかかりすぎるので予算内ではできない」という意味で回答されたのかなといつも推測しています。
また、『WordPressのメリットは拡張性』というのはおそらくは初期構築段階で簡単に機能を追加できるという意味で使用されていたのではないかなと思います。それが運用段階で当初の想定外の機能を追加しようとすると逆に工数がかかる場合があるということで…言葉の使い方って難しいですね。
また、何かトラブルが生じたときに、それが有料テーマに原因があるのか、それともWeb制作会社のカスタマイズに原因があるのかといった原因の切り分けと責任範囲の線引きが難しくなるというデメリットもあります。
【対策】Webサイトの運用計画・ご予算に合わせて有料テーマを使うかどうかを決める |
有料テーマにはメリットとデメリットがありますので、下記有料テーマの利用に適しているケースと適していないケースを参考にしていただきながら、自社のケースに合った選択をしていただければ幸いです。
①有料テーマの利用に適しているケース ②有料テーマの利用に適さないケース ③「有料テーマの利用に適さないケース」であったが、有料テーマを使ってしまっている場合 |
テーマやプラグインは、開発関係者の皆さんによる日々の尽力によって、通常はWordPress本体(コアファイル)のバージョンアップに対応させる形で随時更新がなされています。
しかしながら、テーマやプラグインの更新が止まってしまうことがある点をリスクとして認識しておく必要があります。
このテーマやプラグインの更新が止まってしまうことにより、WordPress本体のバージョンアップを行うと、テーマやプラグインが正常に挙動しないということがわりとよく起こります。
【対策】テーマ・プラグインを慎重に選び、管理する |
テーマ・プラグインの更新停止に対する対策としては、有料テーマやプラグインを出来るだけ使用しないことが基本となります。 しかしながら、テーマやプラグインを利用しなければ、WordPressの最大のメリットである初期制作・開発費用の削減効果が薄まってしまうことも事実です。そこで、一般的には、Webサイトの目的や使用方法に合わせて、下記の点を考慮に入れながら、テーマ・プラグインを選定・管理していくことになります。 ①「有料テーマの利用に適さないケース」では有料テーマを出来るだけ使わない。 ②有料テーマを利用される場合、有料テーマの配布元企業の信用情報を可能な限り調べてから採用を判断する。 ③プラグインの使用は最小限度にする。 ④プラグインを使用する場合は、「必要性」「許容性」で判断する。 |
WordPressは世界で最も有名かつ利用されているCMSであることから、攻撃を受けやすいのも事実です。
その為、まずはWordPress特有の仕様に対する対策をしておく必要があります。
特に、WordPress本体(コアファイル)とテーマ、プラグインのバージョンアップを適切に実施することが非常に重要になります。
なお、大抵の対策はWebサイト制作後でも実装が可能なのですが、テーマとプラグインについては、Webサイト制作時にメンテナンス(バージョンアップ)を念頭に置かずに構築されていると対応が難しくなる場合があります。
例えば、テーマやプラグインの更新が止まってしまったことで、WordPress本体のバージョンアップを行うとそのテーマやプラグインの挙動がおかしくなってしまい、その結果WordPress本体のバージョンアップを実施できなくなり、脆弱性が発生する…等のトラブルが起こりえます。
【対策】WordPress特有の仕様に対する対応が必要 |
|
管理画面へのログインURLをガードする | WordPressのデフォルトの仕様では、管理画面へのログイン画面のURLが“wp-login.php”となっています。 WordPressへの攻撃を試みるロボットは“wp-admin”または”wp-login.php”を探して来ますので、この「ログイン画面のURLを変更」したり、「IP制限」や「Basic認証」を掛けることでURLへのアクセス自体をガードしましょう。 なお、攻撃を試みるロボットが管理画面へのログイン画面にたどり着いてしまうと、ブルートフォースアタックという総当たり攻撃を受けてしまう可能性があります。そうしますと、仮に侵入されなかったとしても、閾値の低い共有サーバーなどではそれだけでサーバーをシャットダウンしてしまうことがあります。 その為、攻撃者をログイン画面にたどり着かせないという対策(bot対策)が重要になります。 なお、WAFを設定しているので大丈夫なのではないかという質問を時々受けますし、実際に最近のWAFはある程度botアクセスを防御することが可能なので、WAFを設定してくれればかなり安心できるのは事実ですが、通常はWAFもbotによるアクセスであると検知するまで一定量のリクエストを受け付けますので、狙われやすいWordPressの場合には、特段の理由が無い限りは「そもそもbotを管理画面にたどり着かせない対策」を実施しておくことをお薦めしています。 |
WordPressを使用していることを察知されないようにする | 上記のように、WordPressへの攻撃を試みるロボットはソースコード上のWordPressの痕跡を探して、攻撃対象サイトを探してきますので、ソースコード上からWordPressの痕跡を消し去ることで、一定程度狙われにくくすることは可能です。 しかしながら、これを実施してしまうと、WordPress本体、テーマ、プラグインの脆弱性を定期的にチェックするツール(Wpsec等)が誤作動を起こすなどのデメリットもある点に注意が必要です。 その結果、当社のように、保守にて脆弱性を潰すことを優先し、この対策は敢えて実施しない制作会社も多いと思います。 |
WordPress本体(コアファイル)・テーマ・プラグインのアップデートを適切に実施する | WordPressはとにかく狙われる確率が高いCMSですので、WordPress本体・テーマ・プラグインに脆弱性が見つかった場合には、速やかにバージョンアップを実施して行く必要があります。
そこで、WordPress本体・テーマ・各プラグインに更新がある毎に、 しかしながら、これを更新がある毎に実行するとなると、それだけで保守コストが多額になってしまうという経済合理性の問題が発生します。すなわち、そもそもCMSを実装するのはコンテンツ制作にリソースを集中するためという理由がありますが、WordPressを使用することで、保守の段階で余分なリソースが掛かり続けるとなると、CMSとしての本質的な価値に疑念が生じてしまいます。 そこで、通常は、WPSEC(WPScans)のようなスキャンサービスを利用して、一定以上のアラートが出た際に更新を実施するエスカレーション体制と役割分担を整備した上で、企業とWeb制作会社が協力して対応していくことになります。 |
停止中のプラグインは削除しておく | 上記のプラグインの脆弱性は、プラグインを「停止中」であっても存在していることに留意する必要があります。 対策として、停止中のプラグインはWordPressの管理画面からできるだけ「削除」しておくようにしましょう。 |
プレフィックスをデフォルトから変更する | WordPressはMySQLというデータベースを採用していますが、デフォルトでは、データのテーブルに「wp_」というプレフィックス(接頭辞)が設定されるようになっています。 これが「テーブル名」の特定に利用され、データベースに対する攻撃に利用される恐れがあります(SQLインジェクション等)。 この為、プレフィックスを変更しておくことが推奨されます。 |
ディスカッション設定を適切に管理する | WordPressは元々がブログソフトウエアであったことから、コメント投稿機能・ピンバック機能(リクエストを受け付ける機能)・トラックバック機能(参照元のサイト管理者にリンクを貼ったことを通知する機能)が実装されており、これらの機能はデフォルトではONになっています(これらは「ディスカッション設定」で管理できます)。 これらの機能を使っていないのであれば、Dos攻撃・DDos攻撃(大量のデータを送りつける攻撃)に利用される可能性がありますので適切に管理しておく必要があります。 具体的には、不要なコメントフォームを非表示にした上で、サーバー側でwp-comments-post.phpへアクセス拒否等の設定を実施する他、使用していないのであればピンバック機能・トラックバック機能についてはOFFにしておくとよいでしょう。 |
【対策】WordPressに限らず実施した方が良いセキュリティー対策を実施する |
|
OS・ミドルウエアのバージョンを適切に保つ | 共用レンタルサーバーであれば、OS・ミドルウエア(PHPとそのフレームワーク、Apache、nginx、mysql、mariadb等はホスティングサービスの内容としてサーバー会社が保守をしてくれますが、サーバー会社によってその範囲が異なりますので確認が必要です。 例えば、Xserverの場合、公式にサポートしているPHPのバージョンはPHP7.2.x以上となりますので(2020年9月1日現在)、それ以下のバージョンはPHP 7.4.x への移行を推奨されています。 こういったケースでは、共用レンタルサーバーをお使いの場合にもミドルウエアのバージョンアップが必要となります。 また、AWS等のクラウドサーバーの場合には、ゲストOSの保守やミドルウエアの保守はユーザー側の責任となります。 この為、通常は企業側の情報システム部門と役割分担を決めた上で、パッチ適用ルールとパッチ適用フローを定めて、保守作業としてパッチを適用していくことになります。 |
管理画面へのログインの難易度を高める | 上記のように、管理画面へのログイン画面へたどり着かれると、ブルートフォースアタックを受けてしまう可能性がありますが、その際に、「パスワードを複雑で長くする」「ログインの試行回数を制限する」「ログインに(ひらがな等の)画像認を追加する」等のログインの難易度を高めることで、万が一攻撃者にログイン画面までたどり着かれても、アタック段階のセキュリティーをある程度高めることができます。 WordPressの場合、「ログインの試行回数を制限する」並びに「ログインに(ひらがな等の)画像認を追加する」ことは「SiteGurad WP Plugin」という有名プラグインで簡単に実現できますし、xserverのようにサーバー側でログイン試行回数を制限できるサーバーもありますので、実施しておきましょう。 |
IP制限(アクセス制限)を実施する | IP制限とは、接続元のグローバルIPアドレスによってアクセスを制限することで、事前に許可したグローバルIPアドレス以外からの接続を拒絶する対策です。 このIP制限を管理画面全体や、Webサイトの重要な部分に掛けておくことで、セキュリティーを大幅に高めることができます(ただし、旅先などから接続できなくなりますので、運用ケースに合わせて実施してみてください)。 なお、上記のような厳格なIP制限の他に、国外IPアドレスからのアクセスを制限するという限定的な制限もよく利用されます。 |
ブラウザからDBへアクセスできる部分には脆弱性診断を実施しておく | WordPressに限らず動的CMSを採用したケースや、スクラッチ開発したケースなどでWebサーバー内にデータベース(DB)が存在する場合、検索ボックスやお問合せフォームなどDBにアクセスする入り口があると狙われやすくなります。 サイト内検索などは、こだわりがないのであればGoogleのサイト内検索を利用するなどしてブラウザからDBへアクセスできる部分を出来るだけ減らしておくことも有効ですが、動的なページではなかなかそうもいかないのが現状です。 このような場合は、1年に1回程度でも脆弱性診断を実施しておくことをお薦めしています。 当社では、株式会社ビットフォレストさんが提供するクラウド型Web脆弱性診断ツールVAddyを採用しており、納品時にProfessional版でチェックをかけておりますが、一定水準以上のセキュリティーが求められるサイトでは、クライアントにEnterprise版をご契約いただいて、適宜チェックされることをお薦めしております。 |
WAFを設定する | WAF(Web Application Firewall)は、その名の通りファイアウォールの一種で、外部とWebアプリケーションのやり取りを検知・制御することで不正侵入を防御するセキュリティー製品です。 前述のWordPressを例にすると、WordPress本体やプラグインのバージョンアップを実施することは脆弱性自体を潰していく対策ですが、WAFはWebアプリケーションへの攻撃そのものを検知・制御するものですので、例えば使用しているプラグインに致命的な脆弱性が見つかり、更新が追い付いていない間に攻撃を受けた場合(ゼロディ攻撃)でも、WAFであれば一定程度防御できることがあります。 また、防御範囲も、XSS対策やSQLインジェクション対策、ファイル不正アクセス対策、PHPの関数の脆弱性対策などの検知しやすい攻撃への対策だけに留まらず、パスワードリスト攻撃、DDos等年々広くなっています(WAF製品・設定によって異なります)。 近年では、WAFを設定することは、Web制作業界でも「やっておいた方がいい」程度には一般的になっていると思いますし、実際に多くのレンタルサーバーではWAFが標準装備となっていますので、是非WAFを設定してセキュリティーを高めましょう。 なお、最近当社にご相談が増えているAWSの場合、事前設定済みのルールセットであるAWS WAF のマネージドルールを利用するケースがほとんどですが、より高度な設定を行う場合には高度な知識とノウハウが必要なため、設定にコストがかかるという問題があります。 |
ファイアーウォール、IDS・IPSの設定を確認する | ファイアーウォール(Firewall)は、サーバーやネットワークの入り口で主にIPアドレスとポート番号を監視して、「通過させてはいけない通信」を阻止するシステムです。 IDS(Intrusion Detection System)・IPS(Intrusion Prevention System)とは、その名の通り侵入検知・侵入防御システムのことですが、「通過させてはいけない通信」を阻止するシステムである点はファイアーウォールと同一です。すなわち外部からの不正アクセス・攻撃を防ぐだけではなく、例えば内部からの秘密情報の不正公開も「通過させてはいけない通信」として阻止してくれます。 この3つのシステムはセキュリティー対策の基本であり、各サーバーには、大なり小なり設置されていることが通常です。 しかしながら、サーバーの種類やプランによって対応範囲が異なりますので、ご利用になられているサーバーではどこまでを標準で阻止してくれるのかを確認しておくとよいでしょう。その上でもし不足を感じれば追加でセキュリティー製品を導入するなどを検討することになります。 |
問題がおこった際に対応できる体制を構築する | 以上のように、Webサイトのセキュリティーには色々な対策がありますが、残念ながら万全のセキュリティーというのは非常に困難であると考えております。少なくとも当社単独では実現できません。 その為、何かトラブルが起こりそうな際、起こった際に迅速に対応できる体制を整えておくことが重要になります。 通常は企業側の情報システム部門と当社のような保守業者が役割分担表を作成し、ケースにより適用するエスカレーションフローを作成して、対応できる体制を整備することになります。 |
このように、WordPressには多くのメリットがあると同時に、WordPressサイトを保守・運用していく際には、いくつか気をつけておくとよいポイントがありますので、既に運用段階に入っているWordPressサイトの保守についてご相談をいただきましても、なかなかスムーズにお引き受けできないケースがあります。
そこで、(あくまでも当社の経験上ではありますが)お引き受け時に慎重にならざるを得ないケースについて、以下記載させていただきます。
①WordPress高速化の限界に近付いているケース
ユーザー参加型のWebサイト(投稿系コンテンツがあるサイト)などがWordPressで制作・開発されており、サービスの成長(ユーザー数の増加によるアクセス負荷増加)に従って速度が追い付かないようになり、既にKUSANAGIやKinstaといったWordPress高速化パッケージサービスを使うことで、なんとかサービスとして成り立たせている状態で、お引き受けの相談をうけるケースがあります。
ほとんどが、サービスの成長による影響についてそれほど慎重に検討することなく、あるいは速度の問題は認識しておられても初期費用を抑えるためにWordPressで開発してしまったケースなのですが、前述のようにWordPressである以上速度問題を解決することは容易ではありません。
特に、既に表示速度を劇的に改善できるKUSANAGIのようなサービスを使っていてギリギリの状態となっていると、それ以外の表示速度の改善を実施したとしても延命処置にしかならないという状態ですので、なんとか打てる手を打ってサービスを持たせている間に、将来のユーザー数の増加によるアクセス負荷増加に対応できるWebアプリケーションを開発するという地獄モードに突入することになります(新しいアプリケーションを当社が開発するケースも地獄ですが、そこは別の会社に依頼済みで、そこまでの間WordPressサイトを持たせてほしいという、当社的に報われないご相談も稀にあったりします。流石によほどのことが無い限りお引き受けできないのですが…)。
このような、そもそも開発技術の選択がミスマッチを起こしているケースは、非常にお引き受けしにくいといえます。
②WordPressの拡張面での課題に直面しているケース
前述のように、有料テーマや使用されていたり、Webサイトの重要部分がプラグインで実装されている場合には、当該有料テーマ・プラグインが想定している運用については非常に強みを有しますが、想定外の機能追加、表現の実装をしようとすると一気に難易度があがるケースがあります。
そして、制作を担当された会社様ではなく、当社のような会社にWebサイトの引き受けをご相談されるケースでは、えてして想定外の機能追加、表現の実装をしようとしたら、「現在のWeb制作会社から『WordPressなのでできない』と言われた」とか、「初期費用と比較したら多額すぎるのではないか」と感じるお見積りが出てきた、というケースだったりします。
こちらも、結局は運用時のことを想定していないか、していても優先順位を間違えて技術選択をしてしまったケースであると言えるかもしれません。
しかしながら、WordPressと有料テーマ・プラグインの組み合わせにより初期費用を抑えるというメリットを優先された以上、有料テーマ・プラグインが想定していない機能拡張に関しては、諦めるかコストが高くなることをご理解いただかないといけないため、結局は当社でもそのようにご説明させていただいております。
一方で、上記のデメリットについてはご理解をいただいた上で、ご相談を頂く場合には、「ご利用になっている有料テーマ・プラグイン」と「実現したいこと」によって解決策が変わって参りますので、ご相談をお受けしながら検討させていただくという形になります。
③セキュリティー上の問題があるケース
WordPress特有の仕様に対する対応がなされていない場合も、場合によってはお引き受けし難いケースに該当します。
これまでも、お引き受け前調査をさせていただいている間に、そもそも既に侵入されていることが判明する(それまでオーナーサイドでは気が付いていない)というケースも複数ありました。その経験上、侵入済みのWebサイトのほぼ全てで2年以上WordPress本体やプラグインの更新が止まっていましたので、こういうケースは引き受け側としては要注意となります(逆は必ずしも真ならずで、WordPress本体やプラグインの更新が2年以上止まっていれば侵入されているということではありませんのでご注意ください。ただし、侵入される確率は格段に上昇するというのが当社の認識です)。
既に侵入されてしまっている場合、あるいはお引き受け後対策を実施する前に侵入されてしまった場合、新しいサーバーを用意するかサーバーを初期化して、確実に侵入されていなかったと思われるときのソースコードで復旧させる手法が基本となります(ソースコードのバックアップ体制が重要になります)。
実際のところ、WordPress特有の仕様に対する対応がしっかりとなされているケースでは、クライアントサイドでもセキュリティーに対する意識が高い傾向にありますので、こういったケースではそれほど問題なくお引き受け作業に入れます。
しかしながら、WordPress特有の仕様に対する対応があまりなされていないケースでは、当社の場合、お引き受け時に2人日程度を限度として、セキュリティー上の問題点を簡易的にチェックさせて頂いた上で、お引き受けをさせていただいても問題がなさそうかを判断させていただいております。
④AWSなどのクラウドサーバーを利用しているケース
WordPressサイトなのにAWSなどのクラウドサーバーを利用しているケースも、軽々にお引き受けし難いケースにあたります。
本記事の最初に記載させていただきましたように、当社としてはWordPress+AWSという組み合わせでのご相談が増加していることに、技術的なミスマッチを感じています。
例えば、当社がサーバーにAWSをお薦めする典型例その1は、Webサイトへのアクセス負荷が急激に増大する可能性がある場合なのですが、前述のように、WordPressは元々速度が遅いCMSであり高速化の限界は他技術より早く訪れる傾向にあることから、アクセス負荷増大の原因が(シーズン限定のものではなく)Webサービスの成長にあって、負荷の継続的な増加が予想される場合には、そもそもWordPress以外の技術体系で実装すべきであったということになる傾向にあります。この場合は、経験上お引き受け後苦戦するケースが多い為、お引き受け時に慎重になります。
また、当社がサーバーにAWSをお薦めする典型例その2は、柔軟な機能追加が予想されるような本格的なWebアプリケーションの場合なのですが、前述のように、WordPressに有料テーマが使われていたり、あるいは重要な機能がプラグインで実装されていたりすると、柔軟な拡張が困難であるケースが多いことから、同様にWordPress以外の技術体系で実装すべきであったということになる傾向があります。この場合も、お引き受け後やはり苦戦するケースがありうるため、お引き受け時には慎重になります。
なお、こういった技術的なミスマッチ以外に、純粋に共用レンタルサーバーとAWSのようなクラウドサーバーとの役割分担の違いに関する問題もあります。
具体的には、サーバー会社がどこまで責任をもって面倒を見てくれるのかという部分が大分異なります。
共用レンタルサーバーでは通常、サーバー・OS・ミドルウエアがパッケージで提供されるので、サーバーチューニングやOS、ミドルウエアへの干渉もほとんどできませんが、逆に言えばサーバー・OS・ミドルウエアの保守についてサーバー会社が面倒をみてくれます。つまり、情報システム部門やWeb制作会社が保守をすべき対象は基本的にはWebアプリケーション(Webサイト・WordPress等)のみとなります。
一方で、AWSのようなクラウドサーバーの場合、提供されるのは仮想サーバーのみで、提供されるプラットフォーム内でどのようなサーバー構成にするかもユーザー次第ですし、OS、ミドルウエアの選択や干渉も基本的には可能です。逆に言えば、OS・ミドルウエアについてはユーザー側でメンテナンスとセキュリティー対策をしないといけません。特にPHPを使われているケースでは、かなり短めのスパンでセキュリティーサポートが切れますので(PHP7.2でさえ2020年11月20日で切れます)、単なるバージョンアップによるメンテナンスだけでは足りず、WAFなどで可能な限りガードしておくことが重要になります。
つまり、AWSの場合、AWS自体に関するナレッジを有しているだけでなく、OS・ミドルウエアに対するメンテナンス(バージョンアップ)やセキュリティー対策についても実施していく必要がありますので、これらに対応できる体制・リソースがないとお引き受けし難いという問題があります。
当社の場合ですと、上記のような点についてヒアリングをさせて頂いて、当社でも技術的にお引き受けさせていただけそうなケースで、かつ当社に対応できるリソースがある場合には、クライアントの情報システム部門やインフラを管理されているベンダーの方々との役割分担表を作成し、慎重に対応させていただく形になります。
⑤他のシステムやアプリと連動しているケース
最後に、例えばWordPressサイトが基幹システムとAPIを通じて連動しているとか、androidやiosアプリと連動している(ハイブリッドアプリ)場合には、基幹システム側の保守担当者とやり取りが発生する上に、モバイルアプリのメンテナンスも必要となるケースが多く、要求されるスキル、ナレッジが更に広く、高度になってきます。
こうなると、基幹システムやアプリが、どのような言語、フレームワークで開発されているかなども関係してきますので、当社においても応相談となってしまいます。
以上のように、WordPressは圧倒的に優れたCMSであって、世界№1シェアを誇るからこそ外部からの攻撃が増加し、その結果対策も必要になっているという状況には、WordPressを10年以上追いかけ続けてきた当社からしますと、思うところはありますが、いずれにしましても「もはやWordPressサイトは専門の保守チームと共に運営していくべき技術体系になった」と考えております(今後は、ローコストでWebサイトを制作・運用する層は、いわゆるローコード・ノーコード系の技術で実装される世の中になると予測しています)。
そうなると、当社の役割は、WordPressサイトの保守を最適なコストでサポートさせていただくことになると考えておりますが、本記事でも一部ご説明させていただいたように、勉強せねばならないことが時間経過と共に増えて行く状況でして…日々の業務でも大変なのに新しいことを適宜マスターしていけるわけはないのです(心の叫び!)。
皆さんの利用されているWeb制作会社さんも、日々時間に追われている中で可能な範囲で努力されておられると思いますので、やさしい目をもってWeb制作会社さんに接して頂けますと幸いです。
taneCREATIVEに所属する謎のトラ。