デザインエージェンシーでWordPressでサイトを作り続けてきて思う問題点
今の会社に入って10サイト目をローンチした
10サイト目はWordPressではなく、Shopifyだったのですがこれはこれで色々な独自ルールがあるので制作は難しかったです。というのは置いておいて、ここ最近社内で今の技術スタック(WordPress)をどうしていくかという事を議論しています。デザインエージェンシー所謂Web制作会社でWordPressのサイトを作ってきて色々問題が出てきたのでそれについて思う事を残しておこうと思います。
管理するサイトが増えると辛くなってくる
こちらの会社は各クライアントのサイトを長期間管理し続けていくのが多く、案件が増える程管理のコストが高くなっていきます。古いものだと5年以上前からメンテナンスをし続けているものもあります。会社によって違うと思いますが、特に小さい会社などは当時のドキュメントなどは無く言い伝えのように口伝で次の人にパスされていきます。そして古いもの程更新頻度は非常に低く、1年に数回記事を更新するぐらいです。
ここで問題になってくるのは、
- ドキュメントが無く今までの歴史がわからない
- ビルドツールなどのメンテナンスが無くビルド不可になっていく
- プラグインが本当に使われいるのか不明
- 有料テーマの更新が途絶えている
特に最初の2つがきちんとされていないと、メンテナンス自体が難しくなって来ます。実際の現場だとドキュメントを作っている余裕は無く、制作が開始した時点でのビルドツールでローンチまでしてしまう事が多いという現状です。ちゃんとこの辺りがメンテナンスされていれば、長期間のメンテナンスに耐える事が出来ます。
枯れた技術であり新しい事に移動しにくい
良い面としては、WordPressは枯れた技術スタックの塊でありしかも後方互換性もかなり担保されているので安定性は非常に高いです。2-3サイト作り切ってしまえば、そこから抜けるのは難しいです。いくつか理由があって、大体のサイトの規模感は似ている為おおよその制作時間が割り出しやすい事と人が入れ替わってもWordPressを使っている以上大体のWeb制作ディベロッパーは開発が可能です。
制作時間の割り出しやすさは受注生産だとクライアントにおおよその費用が提示出来ます。これによりクライアントから受注を得やすくなるのでおよその制作時間が分かるのは会社に取っては非常に良い点だと思います。
次に人が入れ替わっても大体のディベロッパーは開発が可能というのは、ほとんどのエージェンシーでWordPressを採用しています。新しく入ってくる人はほぼ100%どこかのエージェンシーでWordPressの制作の経験があります。これも古いプロジェクトなどで前から居る人が対処に回ったとしても、新しいプロジェクトや途中のプロジェクトであれば入れ替わる事が容易になります。
こういった枯れた技術や安定性があると、新しい技術スタックに移る事が難しくなって来ます。WordPressに絞って書くとメインエディタがGutenbergに変わりました。中身はReactでブロックと呼ばれる単位でエディタやフィールドを追加出来ますがReactやES6の知識が必要になって来ます。ですが今までWordPressは長い間jQueryを使って来たのでこれから勉強が必要という方が多いんじゃないかなーと思っています。
会社でもjQueryは触れるが、ReactやES6(今やES2017辺りの知識が必要かなと思います)はあまり知らないという感じです。Gutenbergに対応するのですら難しい感じです。
サイトのパフォーマンス改善が難しくなってきた
ここ最近のサイトはReactやVueを使って静的サイトにしている所が増えてきました。依然WordPressのサイトも多いですが、確実に静的サイトが増えてきています。Awwardsなどは特に顕著に出ています。これらのサイトをリファレンスとして見たりするのでどうしても比較されがちで圧倒的に静的サイトの方がパフォーマンスは高く表示は速いです。さらに最近のサーバー例えばFirebase Hosting, Netlify, Vercelなど当たり前にCDNが付いています。
WordPressでキャッシュプラグインやCloudflareで頑張ってもプラグインの無駄なファイルのロードやデータベースへのアクセスなどで、結局静的サイト化にするしか並べないので難しいところです。最終的にはサーバーのスペックがボトルネックとなり、高性能なサーバーやWordPressに最適化されたパッケージ(Kusanagiなど)が必要になってきます。
新しいスタックに移動するには
これからの事を考えると新しいスタックに移動しなければ、よりコストとしては膨大になっていくのが予想出来ます。開発サーバーと本番サーバーの増強やメンテナンス時間など必要になってくるものが増えていきます。一方で最近だとJAMStackが主流になりつつあり、大体のサイトであればドメイン以外は基本無料で制作、運用が可能です。上記にあげた問題点はほぼ解決しますが、学習コストにおいては初期段階は非常に高いと思います。
今はこの学習コストで悩んでいて、私は色々と個人的に試したりしていて一刻も早く移りたいと思っていますが色々としがらみがあって移れません。一応上記の問題点と新スタックでのメリット・デメリット(学習コスト)についてまとめて出していますが進展はありません。そもそもこれについて話し合ったのもたったの2回で、あまり現実的でないなぁと感じています。全てにおいてリソース(時間・資金・人材)が足りていないので、個人的には何か大きな出来事が無い限り変わらないのかなと感じました
超現実的な移行手段を考えてみる
このリソースが足りない上で移行するとしたら、まずは周りのディベロッパーの知識のアップデートが必須項目なので、一部分のコンポーネントをGutenbergで書いてみるのが良いのかなと考えています。特定ページのみGutenbergのカスタムブロックにする事で、通常の制作時間より少し長くなってしまうもののReactの一部やES6+について作りながら学べるので最終的にはGutenbergのカスタムブロックのみで作れれば、Reactを使ったスタックに移っても最小の学習で済むのかなーと思ってます。
WP-REST APIも考えましたが、フロントに影響するプラグインが使えなくなる事やフロントを完全に切り分けてしまうのであれば、WordPress自体から離れた方が金額面、学習コストの面において良いのではないかと思ってあまり現実的では無いなと感じました。またクライアントサイトで制作する場合は年単位でメンテナンスする可能性の方が高い事もあり、フロント側のメンテナンスとWordPressのメンテナンスの二つを行う必要があるので移行手段としては採用が難しいと感じました。
