渋谷のとある会社で「テクニカルディレクター」という役職で働いています。今所属しているこの会社では幅広い（空間とかイベントとかコミュニティとかなんかもう所属してる人間でもジャンルが違うとわからないくらいの）プロジェクトを抱えていますが、その中にはウェブサイト制作案件もあり、私はそこで技術的サポートや開発担当者とのコミュニケーションをメインにしています。
序盤はインフラ周りの情報やサーバについて調査・ヒアリングした上でクライアントと調整したり、CMSや関連サービスの選定に技術的な面から意見出ししたり、開発中に問題が発生したときには原因調査して対応方針を決めたり、本番環境でのローンチ作業をしたりと、案件の初めから最後まで裏方で色々と動く役割です。

これは、そんないちテクニカルディレクターがWordPress案件で「どうにか構築フェーズでラクできんか」と頑張ってみた記録です。

グラフィックとライティングにお金を使いたい

いきなり「どうにかラクをしたい」という不真面目な切り出しですが、これには理由があります。

会社でWordPressサイト制作を行う案件の規模は、おおよそ数十ページのものから数百ページ、時には1000ページを超えるものまで大小さまざまです。しかし、規模の大小はあるもののそれらのプロジェクトにぼんやり共通しているのは「最後のほうでスケジュールと予算が枯渇しがち」という点。
ウェブサイト制作に関わらず、複数のフェーズで構成されるプロジェクトを経験している人にはなんとなく遠い目になりながら「ああ…」と深いご理解をいただけそうな気もしています。
限りある予算の中でどこに費用とスケジュールを割り当てるか。均等に割り当てるのか、あるいはどこか一部の品質を上げるためにリソースを集中させるのか。そういった葛藤が発生することも少なくありません。というか、ほぼ毎回です。やがて私はこう思い始めます。

「構築でラクをしたい」

これは別にサボりたいとかそういうことではなく「構築にかけるコストをクリエイティブやコンテンツ制作に回してそちらの品質アップに振り分けたい」という、わりと真面目な悩みです。

これはあくまでも個人的な考えなのですが、限りのある予算の中で「サイト制作のどこにスケジュールを割くか」で最も優先されるべきは要件定義と情報設計、「どこに費用をかけるか」の場合はそれがクリエイティブとコピー・ライティングではないかと思っています。
実際に先の「最後のほうになるとスケジュールと予算が枯渇しがち」という経験則とも一致しているので、おそらくこの感覚はそこそこ合っているのでしょう。
しかし、毎回構築フェーズでスケジュールと費用の二重苦を背負うのは辛く悲しいものがあります。常に終盤余裕がなく、プロジェクトメンバーだけでなくステークホルダまで巻き込んでギスギスした気持ちで制作を進めるのはメンタル的にも良くありません。であればどうするか。

「構築ではできるだけラクをする」

これです。
予算に限りのあるプロジェクトでは特に、WordPressのサイト構築ではできるだけコストを軽くする。ラクをするのです。

カスタムフィールド多すぎる問題

2018年12月にリリースされたバージョン5.0から、標準エディタがブロックエディタに変わりましたが、リリース当初はブロックの種類もとても少なく、カスタムフィールドで構築する自由度の高さに比べてできることがあまりにも少ないものでした。
会社の案件ではデザインを作り込む制作が多かったため、結局はプラグインで旧型のリッチテキストエディタにわざわざ戻した上でACF（Advanced Custom Fields）によるカスタムフィールドセットとグループを作ることがほぼ必須という状況がかなり長く続きます。

特に量産系の下層ページのテンプレートは、デザインのモジュールに合わせたカスタムフィールドセットを作り、任意の順番で設置できるようリピーターフィールドを設定し…と、なかなかマッチョなテンプレートになりがちです。
それだけではなく、フィールドが多いことによってページ編集画面が重くなるのも悩みでした。編集画面で全てのフィールドを使用有無に関係なく毎回呼び出すため、コンテンツが長くなるとその分編集画面の生成が重くなってしまうのです。高スペックつよつよサーバであればそういう心配はないかもしれませんが、大体において、WordPressの案件は予算に余裕がないことも少なくないです。

そしてこれだけ多くのフィールドセットがあっても、多くのページでは基本の数セットしか使わないことがほとんどです。せっかく作ったのに…。
数百ページあるサイトで、特定の１ページで使うためだけにカスタムフィールドセットを作ったこともあります。

カスタムフィールドでどんなデザインでも再現できるという自由度の高さがある反面、情報設計やデザインもゼロベースで自由に作ることができてしまう。もちろん悪いことではないのですが、それらすべてについて1からコーディングと開発を行う必要があるため、結果としてサイト規模に見合わない制作コストがかかってしまうこともままありました。

もう全部ブロックエディタでいいんじゃないかな

最初はなかなか使いづらさが目立っていたブロックエディタも、やがて独自のブロックを追加するプラグインや、カスタムブロックとセットになったWordPressテーマが数多くリリースされるようになりました。
今では、これまでカスタムフィールドで作っていたものと同じかそれ以上に多様なパーツが、テーマやプラグインを利用することによって簡単に利用できるようになっています。

そんなある日、とある案件のCMS選定中に私は思いました。

「今なら全部ブロックエディタでいけるのでは？」

ブロックエディタとテーマを使った制作をしてみた

これまでのカスタムフィールドを多用したWordPressのサイト制作は、以下のような流れでした。

1. 情報設計をしてワイヤーフレームを作る

2. ワイヤーフレームをベースにデザインを作る

3. デザインを再現する静的なHTMLページをコーディングする

4. コーディングを再現するようにカスタムフィールドを作り、テンプレートを実装する

これに対して、ブロックエディタを使った制作の場合は既に「ブロック」というパーツがあります。カスタムフィールド制作の時はひとつひとつのパーツを設計・デザイン・コーディングしていましたが、ブロックエディタの場合はそれらが最初から用意されているのです。
選択肢が（予算の範囲内で）無限だったゼロベースでの設計と違って、最初からブロックを使うことを前提とするため、設計作業がかなりシンプルにできました。

ワイヤーフレームはブロックの組み合わせで作り、デザインはそのブロックに適用できるように作っていく。HTMLページも静的にコーディングする必要がなくなりました。

さらに、ブロックと互換性のあるデザインテーマを同時に採用すれば、テーマ側であらかじめブロックに必要最低限のデザインが適用されているというメリットもありました。下層の量産系ページはテーマのデザインをベースに色変更やあしらいの調整など必要最低限の調整にとどめておき、トップや主要ページといった重要度の高いページ・テンプレートのデザインに制作のリソースを振り分けることができるようになるのです。

ブロックを提供するプラグインの中には、一部の多機能ブロックは特定のテーマとの組み合わせでないと動作しない（あるいは動作を保証しない）というものもあります。
こういったものは無理やり保証外の環境で動かそうとしてもうまくいかないことが多いので、そういう意味でも素直に対応テーマとセットで導入するするのが無難かなと思います。

注意が必要だったポイント

テーマ選定のタイミング

サイトを制作するとき、最初に情報設計とワイヤーフレーム設計をします。
各テンプレートにおいてどんな要素を、どんな順番と優先度で配置していくかを決める工程ですが、テーマを使用する場合はこの段階で必要な要素が網羅されているブロックがあるかどうかをポイントにテーマを選ぶことになります。
採用したいテーマに該当のブロックが足りない場合は、テーマを変えるのか、情報設計を再考するのか、その部分だけ別のブロックプラグインを探すのか、あるいはテーマを使わずにブロックプラグインだけを導入するのかをを検討します。
とはいえ、できるだけラクをしたいのでプラグインだけを導入するのはあまり…やりたくないですよね…ブロックの追加設定バリエーションまで考慮してデザイン考えるのめちゃくちゃしんどい。

コストとスケジュールの関係で構築を最小のリソースで行わなければならない、などの制約がある場合は、Astra Proのようにあらかじめトータルデザインが完成しているテーマとブロックプラグインを最優先で選ぶこともありました。

ブロックにある要素を基準にワイヤーを書く

ブロックエディタを使ったサイト制作の場合、ワイヤーフレームはそれぞれのブロックが持っている要素の組み合わせで書くことになるため、慣れないうちはかなり戸惑いました。

「このブロック、ここに自由入力でラベルが表示できればいいのに…」みたいなちょっとした不便も出ます。カスタムフィールドでの制作なら表示したいラベルを入力するフィールドを追加すればいいだけなのですが、ブロックではそうはいきません。
あくまでもブロックが持っている要素だけで構築する必要があるので、ちょっとした追加ができないことに最初はかなりストレスやもどかしさを感じました。

もちろん「ブロックを専用に開発する」ことでカスタムフィールド相当の自由度を得ることはできますが、専用ブロックの開発とメンテナンスにかかるコストと期間を考えるとかなり大規模なサイトでないと見合いません。

このジレンマに襲われたとき、「そうだ、自分は構築ではラクをしたいんだった」という初心に（初心？）立ち戻ってみると意外と解決します。
ラベルを１つ追加することに情報設計上の非常に重要な役割があるのなら、優先度を上げてそこだけ専用の実装を検討するのが必要な場面だと判断できますし、そうでないなら潔く諦めることで将来かかるかもしれなかったコストを削減できると考えるようにしています。

ブロックでできることをデザイナーに共有する

デザインの段階で一気にサイトの見栄えが完成系に近づきます。
ワイヤーはあくまでも情報設計を基にした「要素の組み合わせ」です。デザイナーは、ワイヤーに記載された要素を基にサイトコンセプトやトンマナを加味してページデザインをおこないます。

このとき、デザイナーが考慮するのは「ワイヤーに書かれた要素の組み合わせ」と「情報のボリューム・優先度」です。ワイヤーにも暫定で要素が配置されていますが、上下左右や大きさといったレイアウトについては本来デザインの領域なので、ワイヤーから大きく飛躍することがあります。

このとき、デザイナーに注意してもらうのは「要素の追加」です。
本来画像がなかったところに画像を追加する、アイコンがなかったところに装飾としてアイコンを追加するといったことはデザインにおいて当然に行われることです。しかし、ブロックベースの制作の場合、追加される装飾がユーザの入力に依存する要素でないかどうか＝ブロックに追加の入力フィールドが必要なものでないかには十分に注意します。
とはいえ、要素の追加でもCSSやJSで対応できるものであれば問題ないため、なかなか判断が難しいところではあります。

デザイン制作に入る前、ワイヤーフレームの読み合わせ時にデザイナーとの打ち合わせで「何ができて何ができないのか」を事前にインプットしておくか、逆にデザイナーには自由にデザインしてもらい、どうしても再現できないと判断したものだけ修正を依頼するといったハンドリングが必要です。

テーマごとのブレークポイントを理解する

WordPressテーマの多くは、モバイル/タブレット/PCの表示切り替えのため、ブレークポイントを2箇所持っています。これは採用したテーマによって値がまちまちです。px指定のものもあればem指定のものもあります。

ブレークポイントの数はデザイン制作の際の作業ボリュームとスケジュールに影響するため、デザイナーと事前に確認が必要です。
複雑でないシンプルな１カラムのセクションについてはPCとタブレットを共通化したり、複数カラムを持つ箇所は表示カラムの数だけをデバイスで切り分けて基本デザインは同じにするなどで省力化するだけでなく、デバイスごとに異なるレイアウトにしたい箇所は明確に提示して制作時の混乱が起きないように指示をまとめます。

ブロックごとの「追加設定」に注意

ブロックには「追加設定」という詳細メニューがあります。
ブロックによっては、この追加設定でブロックのレイアウトや装飾を変更することができます。

トップやコンテンツカテゴリトップのページなど、ワンオフで制作するページのブロックであればバリエーションを考慮する必要はあまりないですが、下層の量産系ページのデザインではブロック個々の装飾やレイアウトにはなるべく手を加えないといった判断も必要です。

カラーパレットは（できるだけ）カスタムする

ブロックエディタでは追加設定でブロックの背景色やテキスト色が自由に設定できてしまいます。そのため、運用ユーザー側でとっ散らかった色を指定してしまうリスクがどうしても避けられません。
無差別に多種多様なカラー指定をしてしまうとサイトのデザイン・トンマナが崩壊してしまうので、できるだけサイトデザインに合った色を選びやすくする工夫として、デザイン制作時に専用のカラーパレットを作成し、ブロック追加設定のカラーパレットにカスタム指定することを推奨します。

複雑な表組みはプラグインを使う

ブロックエディタには「テーブル」というブロックが標準で用意されています。
しかし、このブロックは非常にシンプルで、セルの結合ができない、見出し列の設定ができないなど、複雑な表組みの作成にはやや難があります。
特に日本の企業や公共機関のウェブサイトでは魔境のようなセル結合がされた表組みが必要なことがまだまだ多いため、表現したい内容に応じて適切なプラグインを導入するのが無難です。

私は、複数行の見出し行列やセルの多重結合など見た目が入り組んだ表組みが必要な場合は「Advanced editor tools」でクラシックエディタブロックを有効にし、セルの検索機能が必要な場合は「TablePress」で作成した表組みを利用しました。

Advanced Editor Tools (previously TinyMCE Advanced) – WordPress plugin

TablePress – WordPress plugin

音声読み上げなどアクセシビリティの面でも複雑な表組み自体をどうにかしたほうがいいと思うのですが、感触としてその視点からはまだ理解を得るのがなかなか難しいなあというのが正直なところです。

カスタムフィールドも使う

ページそのものに設定したいカスタムの属性情報であったり、標準の「カテゴリ」やカスタム投稿タイプでは分類がしづらい情報など、ブロックではどうしても取り扱いできないものも当然出てきます。
こういう時は普通にカスタムフィールドを使いました。

回避したいのはあくまでも「極端に複雑なカスタムフィールドセットの乱立」なので、適切な場所で適切な形でカスタムフィールドを使うことまで無理にやめてしまう必要はないです。
ブロックとの役割をきちんと使い分けて、カスタムフィールドが適していると判断したところには積極的に使っていけばいいのです。ラクをするために。

実際ラクはできたのか？

最初にブロックエディタベースの制作をした時は、「これブロックでできるんだっけ」と確認しながらだったり「これができないなんて…」という戸惑いとストレスに直面しました。
そのうちブロックの内容を覚え始めて、CSSでどこまで拡張していいかが掴めてくると、「できること」「できないこと」「やりたいこと」の整理・割り切りが進み、スムーズに判断できるようになります。
慣れが進むにつれてリソースのかけ方がいい意味で偏って、トータルの作業量は同じでも「今ラクができている」と感じることが多くなりました。

特に、下層ワイヤーの検討にかける時間が減ることと、HTMLコーディングがなくなったのがインパクトとしては大きいです。ただしこれはあくまでも個人の感想なので、人によってメリットを感じる場所は違うとは思います。

ブロックエディタはそれ自体が非常に柔軟性の高いモジュールなので、設計時にあれもこれもと全部盛りにするのではなく、取捨選択とシンプルさを意識するのがブロックエディタとうまく付き合うコツです。
今のブロックエディタも改善や仕様変更は今後も起きるでしょうし、今のやり方がベストというわけではないですが、クラシックエディタとカスタムフィールドから卒業したいと考えている人の参考になれば幸いです。