普段はRailsを中心にバックエンドの開発を行っておりますが、社内に蓄積された小規模なWebサイトのメンテナンスも時折行うことがあります。この手の小規模サイトにはたいていwordPressが用いられていて、wordPressはそれ自体便利な技術であることは認めるものの、その裏側をきちんと把握しないことには非常に扱いにくく、ちょっとした編集にも苦労させられる場面が多くありました。そんな折、この手の小規模サイト構築の手法としてJAMstackというアーキテクチャが広がっていると知りました。どんなものかと試したところ、wordPressに代わる小規模開発手法になりうるだけでなく、今後のフロントエンド開発の大きなトレンドになるものだろうと納得いたしました。
本記事では前編と後編とに分けて
- WordPressの何が問題となるのか(本記事)
- JAMstackのアプローチとメリット・デメリット
について解説していきます。前編では自分がWordPressの運用をしていて課題に感じた点についてまとめ、後編でJAMstackがそれらの課題にどうアプローチしているか、およびそのメリットデメリットについてまとめています。
ちなみに本ブログもJAMstack構成で構築しております。wordPressとJAMstackを実際に触れてみて感じたことをまとめておりますので、特にWordPressの運用に課題を感じているWeb開発者の方は是非ご覧ください！
WordPress以前、以後
これまで小規模Web構築の手法として鉄板の手法であったのは間違いなくWordPressだと思います。WordPressは一時代を築いた技術ではありますが、これからの技術選択としてはほとんどの場合に最適なものではなくなっていくでしょう。ここではまずWordPressとそれ以前のWebサイトを比較し、Webサイト構築の変遷を軽く振り返り、WordPressのどこが問題なのかを取り上げていきます。
Webの黎明期(静的サイト)
Webの黎明期はHTMLファイルを直接記述し、Webサーバーに配置し、ファイルを静的に配信することでWebサイトを構築していました。例えばブログのようなWebサイトを構築する場合、当初は記事更新するにも直接HTMLファイルを作成、編集し、サーバーに手動でアップロードする必要がありました。ブログのように記事投稿するようなサイトの運用はWebの知識がある人にしか運用ができませんでした。そこで登場したのがCMS(Content Management System)であり、その代表格がWordPressです。同時期にMovable TypeというCMSも先行して誕生していますが、WordPressが圧倒的に優位な存在となりました。
CMSの誕生(動的サイト)
CMSとはその名の通りコンテンツ管理をするシステムで、現在でも最も普及しているのがWordPressです。記事作成の際に必要な機能一式が用意されており、Webに詳しくない人でも簡単に記事の作成、編集、保管が可能となります。ページ表示の際はアクセスがあるたびに記事情報をデータベースから取得し、HTMLファイルを生成してユーザーに返します。アクセスのたびに都度ページを生成するので動的ページと表現されます。記事を管理するインターフェース(管理画面)をすべて用意してくれるので、プログラミングの知識がない人でも簡単に入門することができます。現在はWordPressで構築されたWebサイトが世界の約４割のWebサイトがWordPressで構築されているといわれています。[参考]
以上簡単にですがWebサイト構築の歴史を振り返りました。まとめると、静的サイトはWebサーバーに配置したHTMLファイルをそのまま配信し、動的サイトはアクセスのたびにHTMLを生成し、配信します。まずはこの違いを押さえておきます。
WordPressの何が問題か
WordPressは今なお世界の３割のWebサイトを構築している(ソース？)メジャーな技術ですが、いくつか問題が挙げられています。その中でも特に自分が運用していて気になっている部分を挙げてみます。以下は自身がRailsエンジニアで、PHPやWordPressのバックエンドの知見が乏しい立場での意見であり、WordPressの運用に長けている場合はこの限りではないことは念頭に置いていただけますと幸いです。
- オーバースペックな動的サイト
- セキュリティリスク
- DXの低さ
オーバースペックな動的サイト
静的サイトで十分な構成の場合にも、その構築の手軽さゆえにWordPressが採択される場合があります。しかし、サーバーサイドの処理やデータベースが増えることで余計な管理の手間やコストが発生し、思わぬトラブルに見舞われる可能性があります。過去に経験した例では、WordPressの自動更新によりデータベースとの不整合が発生し、ページが表示できなくなるなんてこともありました。(本来データベースが不要な構成にもかかわらず…)
ブログのような小規模なシステムでも、様々なプラグインの仕様を理解しないと過剰なプログラムを積んでしまい、実現させたいこと以上にオーバースペックとなり、サイトのパフォーマンスにも影響が起こりえます。
セキュリティリスク
WordPressが世界的に普及しているがゆえに、セキュリティのリスクも伴うとされます。有名であるがゆえにその仕組みが多くの人に知られているので、ハッカーにとっても格好の餌食なのかもしれません。また、プラグインを利用するにあたっても、ブラックボックスな要素が増える分セキュリティリスクが高まります。
詳しくは書けませんが、自分自身WordPressで構築されたサイトのセキュリティを破られた事例を何度か観測しているのと、そうでない構成のWebサイトでは今のところ一度も観測していないので、少ないサンプル数にはなりますが実感値として狙われやすいサイト構成なのだろうと感じています。
DXの低さ
Developer eXperienceという言葉もありますが、個人的にはwordPressのDXはかなり低く感じています。繰り返しますが、あくまでRailsエンジニアとしての視点です。
その中でも、ローカルPCで開発し、Githubでコードを管理するといった、今や当たり前になっている開発フローを適用するにあたり、特に大きな課題を感じていました。まずローカル開発環境の組み方がわからない。やり方はあるにはあるようですが、技術力の低さから構築することが叶いませんでした。少なくとも、何かしらソフトウェア(XAMPP, Flywheel ..etc)を別途用意して独自に構築する方法がほとんどで、localhost:<port>で起動してエディタで開発するという、馴染みのある方法は見当たりませんでした。
Githubでのコード管理についても、どこまで管理するのが正しいのかがわかりません。テーマファイルのみ管理する場合もあれば、プラグインも含めてディレクトリを丸ごと管理する場合もありましたが、ディレクトリ丸ごと管理するとして、管理画面でプラグインを変更されたらどのように検知すればよいのかなど。WordPressの管理画面は確かに高機能ですが、あくまで運用視点に過ぎません。エディタもGutenbergに切替わって以降、WordPressはNocodeツールとして舵を切ったとする見方も強いです。それゆえに運用と開発をきれいに共存する方法をついには見出せませんでした。
運用者と開発者の両方に優しい構成を
WordPressは確かに使いやすいツールではありますが、保守・開発にあたってRailsエンジニアが片手間でやるには辛いものでした。とはいえ旧来の静的ページの運用ではコンテンツ作成は開発者に依頼する必要が生じますし、そもそも更新の手間もラクではありません。だからといって、ブログや企業ホームページのようなWebサイトをRailsなどのWebフレームワークを用いて構築するのもオーバースペックにあたるでしょう。
WordPressを用いてよいのは個人ブログや、せいぜい自営業のHPなど、利用用途が個人規模で、なんらかの問題が発生しても影響範囲の少ない場合に限られるかなと思います。WordPressに知見のある方が社内にいるでもない限り、会社のHPや大規模なサービスサイトの構築には向かないでしょう。
開発者にとってもメンテナンスがしやすく、運用者にとってもコンテンツ管理が容易になり、かつオーバースペック過ぎないちょうどいい規模感の技術はないものか。。そんな折、最近話題になっているJAMstackというアーキテクチャを知りました。
「これならば丸っと解決してくれる…!」と期待を抱き、取り組んでみるに至りました。
前置きが長くなりましたが、同じような悩みを抱える方にとって、JAMstackという選択肢が有効なのではないかと考えおり、今後も自分自身勉強を続けていきたいと考えています。後半では本記事を踏まえてそもそもJAMstackとは？から、JAMstackが従来のWebサイトの仕組みと異なる点について解説し、実際にJAMstack構成でブログを構築してみて感じたことをまとめております。