これからのWeb制作を考える【WordPress 5.9 FSE からの変化】
こんにちは、フロントエンドエンジニアの佐川(@fumi_sagawa)です。
2022年1月25日、ついにWordPress5.9がリリースされました。
これに伴いデフォルトテーマtwentytwentytwoとともにFull Site Editing(以下FSE)の機能が解禁されます。このFSEは主にデザイナーや編集者が自由なWEB制作をするための機能であり、ノーコードツールに近い使用感が得られます。
どのようなものかアニメーションを用意しましたのでぜひご覧ください。ざっくりまとめると、これまで「ブロックで記事ページを作成していた手法が、固定ページやテンプレートまで対象になる」というものです。
参考リンク：WordPress5.9チュートリアル|フルサイト編集チュートリアル
一方で、FSEの登場は従来のWEB制作フローから大きな変更点が生まれるということとなります。
本記事ではFSE標準化に伴い今後のWEB制作がどのように変わっていくかを考察します。
開発の難解な用語は用いませんので、ビジネスサイドの方、デザイナー問わずご覧いただければ幸いです。
念のためWordPressのおさらいをはさみ、その次に比較へと移ります。
■WordPressとは
WordPressはシェアが最も高いコンテンツ・マネジメント・システム(CMS）であり以下の特徴があります。
・レンタルサーバーによる簡単なWEBサイトの立ち上げ
・豊富なプラグインによる迅速な開発
「簡単インストール」などを用いてセットアップを済ませ、プラグインを使用しフォーム・関連記事などの実装を終えれば、すぐにWEBサイトを公開できます。これもシェアが高いからこその恩恵かもしれませんね。
そして、もちろんCMSですので静的なページだけでなくブログやお知らせのような投稿が行えます。
「ページ」について仕組みを少しだけ深ぼっておきましょう。
WordPressには主に固定ページと投稿ページが存在します。
固定ページは「ホーム」「企業の歴」「お問い合わせ」など文字通り情報が固定されており、追加があまり起こらない部分です。
対して投稿ページはブログやお知らせのによって増え、一つのテンプレートを雛形として管理者や編集者により追加されていきます。
WEBに関わる方ならご存知かもしれませんが、この投稿ページについて数年前に少し大きな変更がありました。Gutenbergブロックエディタです。
Gutenbergリリース以前は投稿ページは単純に上から「文章を書く場所」でした。
それがリリース後はブロックを二次元に配置できるようになり「文章と少しのデザインができる場所」へと変貌しています。
■FSE登場による制作フローの比較
投稿ページに続き、FSEの登場により今回は固定ページの自由度が増えることとなりました。
しかし、よく考えてみると追加していく記事ページと異なり固定ページは開発が終了した段階ですでに出来上がっているはずです。
それではこの疑問を明らかにすべく、早速比較を行なっていきます。
まずは従来の開発フローです。
WEB制作の基本的な流れであり
・コンテンツを作成する
・デザインを作成する
という工程を踏んだ後、HTMLファイルの代わりにエンジニアがphpファイルを作成します。
phpファイル内部ではテンプレートタグを用いた条件による出し分けや、せっかくCMSを導入していますので記事ページサムネイルなどリスト表示を行います。
そして、FSEの開発フローです。
はじめにデザイナーがコンポーネントとWebページのデザインを作成。
その後、エンジニアがコンポーネントとページテンプレートの作成をhtmlファイルで行います。
最後にディレクターやライターが固定ページ上でコンテンツを制作しつつ、デザイナーがデザインを調整することが予想されます。
■FSEの理解と制作のポイント
従来から大きく制作方法が変わりました。
これは全てWordPressがFull Site Editingでブロックを主体としたページ制作を目指しているからです。
これまでの制作はコンテンツの全体をデザインに起こし、それをそのままHTML・CSSにするフローでした。しかしこれは、そのまま1枚のHTMLファイルとなってしまうためブロックとの相性が良くありません。
したがって、
1. デザイナーが用途に分けたブロックのデザインを構築し
2. それをそのままエンジニアがパーツにする
3. 最後にデザイナーとコンテンツ制作者が協力し完成させる
というフローがフィットする結果となります。
現にWordPress 5.9 FSEからtheme.jsonというファイルが新たに追加されており、ここにパーツやテンプレートを登録していく運用となっています。
他にもtheme.jsonにはWorPress上から操作できる色・フォントが登録でき、WordPressのノーコードツールとして進化していく意思が強く感じ取れるはずです。
■WordPressとの付き合い方を考える
幸いにも、FSEは対応テーマを使わなければ有効化されないためしばらくの間は従来のワークフローを続けられるはずです。
しかし、この大きく変わったWordPressのスタンスについて私たちはきちんと受け止める必要があると思います。
今回の変更には賛否両論あるかと思いますが、まず私が思い付いたことは「これはすでにあったアプローチがデフォルト化されただけではないか」というものです。
WordPressの有名なプラグインやテーマとして、
・Lightning
・Snow Monkey
などが存在します。
ブロックエディターを主としたテーマ・プラグインであり、数多くのサイトで利用されているものです。
私自身、まだ開発を学んでいない頃にはこういったブロックエディタのプラグインをよく用いていました。
WEBサイトの目的はあくまでお客様に情報を伝えることですから、全てのサイトに凝ったデザインとそのHTML・CSSが必要なわけではありません。
その点FSE 機能は開発力がなくともWEBサイトの構築を可能とするものであり、WEBを作りたい方の強い力となってくれるはずです。
一方で、HTML・CSSを拡張するCMSとして考えるには、相性が悪い一面もありそうです。
差別化するにはより良いデザインが必要であり、デザインが全体設計である以上ブロックではまかなえないケースが発生します。
また、一概にはいえませんが、コンポーネント志向で開発するのであればJavascriptフレームワーク（React.jsやVue.js）の相性が良く、新しい学習コストを払ってWordPressを使い続けるメリットは感じにくいかもしれません。
■おわりに
WordPress5.9の発表を受け新機能であるFSEとそのワークフローを見てきました。ここまでお付き合いいただきありがとうございます。
まとめると、
「ノーコードツールとして進化する一方で、デザインの再現と開発を見据えると長期的なコストを考慮しなくてはならない」
という結論になりそうです。
幸いにもCMSでは他にMovableType、昨今だとJAMStackといった構築手法やノーコードではSTUDIOやWix, Webflowなどが存在します。
これを機に他の制作手法に触れてみるのも良いかもしれませんね…！
佐川史弥 / フロントエンドエンジニア
Twitter: @fumi_sagawa
参考リンク