【雑記】打倒WordPressなJAMstackメディアの未来
※本記事はWordPress自体を否定しているのではなく、WordPressを使ったメディア開発が一般的なSPA開発に比べてDX(開発体験)が悪いので、フロントエンドエンジニアとしてはそういった現場を減らしていきたいという気持ちがあります。WordPress大好きな方や、今後も当分WordPressを生業として行くつもりな方はもしかしたら気分悪いかもしれないので回れ右してください。
※フロントエンドエンジニアと一口に言ってもデザイナー的な人もWebpack職人も色々いるので、その中でも特にSPA開発に特化している人を一旦この記事内ではSPAエンジニアと呼びます。でも別に一般的なワードじゃないのでこの記事以外では呼ばんぞ
はじめに
WordPressは世界のサイトの30%以上で使われているらしい。シェアすごい!
昨今の"Webメディア開発に携わるSPAエンジニア"の口癖は「これからのメディアはSPAで作るべき!「ヘッドレスCMS最高!」「JAMstackで行こう!」なのですが、内輪でワイワイやっているだけで全然WordPressの株を奪えている実感がありません😇もちろん自分たちの手の届く範囲ではみんな頑張って脱WordPressしてますが。
つまりまだまだ話題になって普及しているのは仲間内だけなんですよね〜
JAMstack?ヘッドレスCMS?なにそれって人のための章
JAMstackとは「JavaScript, API, Markup」の頭文字をとったそれらで構成するWebサイトのアーキテクチャの総称です。
WordPressはメディアのコンテンツ管理と、表示する機能を同じサーバーですべて一括管理するのとは対象的に、JAMstackでWebメディアを作るとしたら
- JavaScriptでコンテンツの出し分けを行い
- コンテンツはAPI経由で取得し
- 静的なページについてはMarkup、つまり事前にhtmlを生成して静的サイト化しておく
という構成がJAMstackになります。React.jsなどのSPAライブラリを利用してルーティングの管理を行うので基本的にはSPAとセットです。
そしてヘッドレスCMSとは、そういった構成のAPI部分を提供する「メディアのコンテンツ管理を行う専用のサービス」となります。
現状
Contentfulというサービス等を中心として、ヘッドレスCMSは結構展開されて利用もされています。
しかしコンテンツ管理を分離できてJAMstackサイトを作ろうにも、結局表示部分はエンジニアがいないと何も作れないのが現状です。
結局管理と表示を分離したいって言ってるのはエンジニアの都合であって、管理者にとっての短期的なメリットがあまりないです。(もちろんセキュリティが〜とかの長期的なメリットは多々あります)
閲覧者にとってはGatsby.js(JAMstack用ライブラリ)等でできたサイトは基本的に表示や遷移が早いので多少のメリットはあります。
しかしWordPressのようなMPAサイトでもキャッシュをしっかり設定すればSPA・静的サイトと遜色ないレベルに持っていける(もちろんある程度のエンジニアリングは必要ですよ)ので、Webサービス開発と違いWebメディア開発にいたってはSPAサイトでもMPAサイトでもUXは大きく変わらず、大した差がないわけです。
そんな状態でエンジニアの都合だけでWordPressをやめてSPAにしたいと言ったってしょうがないというのが現状です。そんなこんなでWordPressの天下をいつまで経っても揺るがせないのです。
そんな中SPAエンジニアとしてWebメディア開発にどう関わっていけば良いのか
基本的にはSPAエンジニアにとってはSPAのほうがDXが良いので推進していきたいですよね!
あくまで「フロントエンドエンジニアとしてのメリットが大きい」というのを隠さず真摯に導入を進めていければいい気がします。
SPAの技術選定については最近の花谷さんのスライドが非常によくまとまっているので、これを参考にしましょう。
今後JAMstack&SPAを推進するためにどうしたらいいか、どんなサービスがあったらいいか
そんで、僕らSPAエンジニアとしてはもちろんJAMstackを普及させていきたいわけですが、そんなのエンジニアの都合だけであってメディア管理者のメリットがあんまりないからはっきり言って微妙という話はしました。
なんならエンジニアリングをまったく必要としないために、Webメディアを作る上で「結局noteやはてブロでいいんじゃないか」っていう選択肢が出てくるのはホントそう。(プラットフォームとしての役割もあるので、メディア展開するときにその辺の効力は無視できないですよね。)
元々WordPressユーザーは結局カスタマイズ性を(今までの資産を流用するという意味でも)求めていて、それと同じものをSPAでつくろうにも、SPA開発の敷居が非フロントエンドエンジニアには高いので厳しいという現状ですね。
そこで期待しているサービスの一つがSTUDIOです。
Webサイトを完全GUIでデザインカスタマイズしつつ作れて、来年あたりにAPIでのコンテンツ表示に対応する予定。そうなってくると、うまく行けばWordPressのようなカスタマイズ性を非フロントエンドエンジニアでも手に入れられます。
そういうサービスが出てきてやっとヘッドレスCMSという存在がエンジニア以外にも本領を発揮できて、管理者にとってのメリットを発揮したサービスとしてWordPressと戦える土俵に上がってくると思います。(もちろんSTUDIO CMSみたいなのが出てきて連携を密にできるから他のヘッドレスCMSいらなくなるという可能性もあるけど)
ヘッドレスCMS自体はぐんぐん伸びているし、Contentfulが出資を受けたりしているのはそういう期待だと思いますが、私としてはヘッドレスCMSだけではWordPressを倒すのには片手落ちだと思っていて、STUDIOのようなサービスがドンドコ出てきてやっと戦争を挑めると思っています。
ヘッドレスCMSを使うメリットとして
- コンテンツの管理のしやすさ
- 記事の書きやすさ
- 共有のしやすさ
が出てきて(もちろんサービスに依存しますが)、STUDIOのようなサービスがそれを表示する事に対応すると
- サイトのカスタマイズ性
- それに対するエンジニアリング不要な環境
があわさってWordPressロックインから外れて、なおかつ少ない工数で実現できるメディア開発が一般的になっていくといいな〜と思っています。
...
...これだけだと将来的には「メディア開発にSPAエンジニアは不要」論ですねこれw
まぁそんで上記の流れでヘッドレスCMSというものがガシガシ普及していって、「まずWordPressで作ろう」ってのがなくなっていって、その後STUDIOなどのサービスから足が出るような拡張・開発を行いたいってときに初めてSPAエンジニアがJAMstackで作っていけばいいのかな〜と思います。
デザインのカスタマイズについて
ほんで、ちょっと話は戻るんですが、STUDIOはメディア以外にもあらゆるWebコンテンツのガワを担うサービスになっていくと思います。
API対応によって、ShopifyでECサイトを作れたりもすることになるわけですから。そういうサービスにとってはデザインカスタマイズの自由度は非常に重要です。(このあとの文章においてSTUDIOを否定したいわけではないというための弁明です。笑)
しかし"文章中心のWebメディア"というものに関して、デザインの差別化はどうでしょうか。スマホでの閲覧が主になってきている現代の「スマートフォンで文章を読む」というUIにおいて、はっきりいってどのメディアも大きな差がない。というのが現状ではないでしょうか。むしろ全メディアで読み心地が統一されている方がユーザーにとってメリットが大きかったりするのではないでしょうか。
Webメディアにとって、デザインのカスタマイズは基本的に右に倣えで独自性を押し出す必要が無いんじゃないかと感じています。
そうなって来るとSTUDIO以外の選択肢として、デザインに関してはカスタマイズ性よりもむしろきれいなテンプレにぽいっと丸投げできることようなサービスが必要になってくるんじゃないかと。
そんな「ヘッドレスCMSを使って、非フロントエンドエンジニアでもWebメディアを立ち上げられるサービス」が今後のWebメディア立ち上げの中心になっていくんじゃないかと言うのが私の持論です。
そういったサービスに既存のWordPressユーザーが流れていって、初めて打倒WordPressに一歩近づくのではないでしょうか。JAMstackからはちょっと文脈が離れてしまいましたが笑
おわりに
ただ書きたい文章という感じで、とりとめもないのに最後まで読んでくださってありがとうございます!
Webメディア開発の未来について一言言いたい!って方はどうぞ私のTwitterまでご連絡ください〜
JAMstackで打倒WordPressや!って旗を掲げたい方はお話したいのでランチでも誘ってください〜
私としてもNetlifyやmicroCMSを応援しています!もちろんSTUDIOの今後もすげー楽しみです。
あとは「ヘッドレスCMSを使って、非フロントエンドエンジニアでもWebメディアを立ち上げられるサービス」って言ってるけど、それ欲しいからお前が作れよ!って思った方はどうぞTwitterでリプライしてください。↓たくさん来たら考えます。笑
おわり〜もう11月終わるとか嘘やろ〜こんなときに駄文書いている暇なんかあったのか俺〜