これまでWordPressを用いたWebサイト制作を多く手掛けてきましたが、フリーランスの方や他社様と制作業務をご一緒させていただくこともあります。

一口にWordPressを用いたWebサイト制作といっても、想定している進め方やレギュレーション、習得具合や期待などの認識がずれる懸念もありますので、このあたりを確認するとお互いのギャップが減るのではないかと質問事項を考えてみました。

この内容はWordPressでのサイト制作を行うエンジニア採用においても転用できる部分があると思います。

また、質問の意図を補完する意味で私の場合の回答例も記載しました。
この回答が正しいとも限りませんが、何を聞きたいかのイメージがしやすいかと思います。

質問事項

CMS選定について

サイトのリニューアルを行う際に、WordPressを継続利用するかどうかも含めて提案して欲しいという要望があった場合、どのような観点で他のCMSの選定、もしくはWordPressの継続利用を判断しますか？

回答例

下記の観点でヒアリングし検討します。

運用担当者の方のリテラシーや慣れ
システムの要件・要求
予算とスケジュール

昨今ではヘッドレスCMSとJamstackを用いた構成が話題になることが多いですが、これまでの経験上、下記のような理由からWordPressを継続利用するケースが多かったです。

運用担当者はWordPressの管理画面には慣れていることが多く、新しい担当者を迎える場合もWordPressの利用経験を持つ人材は確保しやすい
既存サイトがWordPressの場合、データ移行やマイグレーションコストが低い
Jamstackでの構築の場合、更新のプレビュー確認などWordPressで標準的な動きを実現することが難しい
Jamstackでの構築の場合、サイト内検索や動的な機能構築には工夫が必要となる

一方で、要件がシンプルで複雑化しにくい場合や、静的ファイルとして高速化が主な目的の場合はJamstackのような構成が適している場合もあるでしょう。

開発環境について

どのような開発環境で制作や確認を進めていきますか？

回答例

@wordpress/envを用いてDockerインスタンスを起動し、その上で動作させながら制作・開発を進行していきます。

開発メンバーがDockerに不慣れな場合はLOCALを用いる場合もありますが、関係者全員が統一された環境で動作させるには @wordpress/env のほうがPHPバージョン設定などがコードとして定義されるため、IaC的観点からもメリットが大きいと考えています。

エディタモードの選択

新規にWordPressサイトを構築する際にブロックエディタ（Gutenberg）とクラシックエディタ（Classic Editor）どちらにするべきか提案してほしいという要望があった場合、どのような基準で選定、推奨しますか？

回答例

CMS選定と同様となりますが、下記の観点でヒアリングし検討します。

運用担当者の方のリテラシーや慣れ
システムの要件・要求

ブロックエディタは2018年12月からWordPressに採用され、十分な期間を経て主要なプラグインも対応しているため、基本方針としては特別な理由がない限りブロックエディタを採用するのが妥当と考えています。

一方で、記事内の記述は簡素で付随するデータを決められたフォーマットでいくつも入力が必要な場合は、クラシックエディタのほうがインターフェースとしては適している場合もあります。

作成テーマの種類

特に指定がない場合はクラシックテーマとブロックテーマのどちらで制作しますか？
また、その判断基準はどのようなものでしょうか？

回答例

現時点では、下記の理由から特に指定がない場合はクラシックテーマでの開発を前提に考えています。

クラシックテーマでの構築のノウハウが社内に確立されており、世間一般でも広く普及している
ブロックテーマ制作はPHP以外にもJavaScriptを中心としたフロントエンドの深い知識が求められるため開発メンバーの確保が難しい
クラシックテーマでもテーマサポートやtheme.jsonファイルを介して、ブロックエディタやブロックコンテンツに構成やスタイルオプションを提供する機能がある

フロントエンドの実装

フロントエンド関連のビルドツールは導入しますか？
また、CSS記述にはFLOCSSやBEMなどの設計ルールを適用しますか？
TypeScriptを導入しますか？

回答例

ビルドツールを導入せず、プレーンなCSSでサイト構築するのは生産効率や保守性が著しく低下するため、TailwindCSSやSassを導入したいと考えています。
ビルドツールは、導入する技術や関わるメンバーの知見によって変わると思いますが、現時点ではViteやwebpackが有力候補になりそうです。¹

TailwindCSSなどのユーティリティーファーストのCSSを用いる場合は、それに準じたお作法、Sassでセマンティックな命名を行う場合はメンバーの習得具合によってCSS設計ルールを適用します。

経験上、WordPressのCSSはbody_classから付与されるクラスを元に制御・分割することで、軽量の設計ルールでも運用できると考えています。

クラシックテーマ開発に限ると、簡易なJavaScript処理だけで、TypeScriptは少し過剰となり、プレーンなJavaScriptで少しのコードを記載することが多いです。²

デプロイについて

普段はWordPressを用いたWebサイトのデプロイをどのように行っていますか？

回答例

案件の特性や条件によりますが、リリース後の運用フェーズであれば、GitHub ActionsなどのCI/CDツールを用いてビルドとデプロイを設定することが多いです。

開発中においては、テーマファイル以外にメディアやプラグインなども別サーバーへ設置したり取得したいことがあり、WordMoveなどのツールを利用することが多いです。

CI/CD設定

WordPressでのサイト制作や運用において、どのようなCI/CD設定になることを想定していますか？

回答例

コードの可読性維持とヒューマンエラー回避のため、PHP CodeSnifferを用いたWordPressコーディング規約のチェックを行い、テストをパスした場合にのみマージ可能な設定がとても便利でしたので導入可能であれば同様の仕組みを入れたいと考えています。

また、各ブランチにあわせて本番やステージングへのデプロイ設定も行いたいと思います。

キャッシュ計画

サイト運用において、キャッシュの設定はどのようにどこで行いますか？
また、CSSやJavaScriptファイル更新時にブラウザキャッシュによるレイアウト崩れが発生する懸念にどのように対応しますか？

回答例

サイトを運用するインフラ構成や想定される訪問数などにもよりますが、一般的にはCloudFrontによるキャッシュやNginxのキャッシュ、また必要に応じてデータベース上にキャッシュを持つ Transients API などの検討も可能と思います。

CSSやJavaScriptの更新時のキャッシュを破棄する対応方法としては、wp_enqueue_styleや wp_enqueue_script関数を用いて、テーマのバージョン番号³を引数で指定することで、パラメータが付加されるためWordPressの規約に則ったかたちでキャッシュ上の古いアセットを読み込む問題を回避します。

また、CI/CDの設定でテーマバージョンの末尾に自動的にコミットハッシュを入れることによりテーマバージョンの上げ忘れでのキャッシュによるレイアウト崩れも回避可能です。⁴

初期構築の手法

WordPressのテーマを新規構築する際、最初にどのような手順ですすめますか？

回答例

WP CLIのwp scaffoldコマンドを用いて、underscoresベースのテーマ雛形を作成し、そこから不要部分の除去とリファクタリングを実施し、要件にあわせた機能追加を進めていきます。

プラグイン制作実績

公開・非公開を問わず、WordPressプラグインの開発経験はありますか？

回答例

一般向けに公開を目的としたWordPressプラグイン制作実績はありませんが、下記の目的のために内部向けの制作補助ツールとして開発を行うことがあります。

既存サイトからのマイグレーションツール（RSSやWebサイトクロールでデータ取得しインポートする機能）
商品データのインポートシステム（数千件の商品データをExcelで整形し、JSONファイル化したものをインポートする機能）
検証ツール（sitemap.xmlを元に全ページを巡回し、エラーなど特定の語彙を検出）

最後に

ひとまず、回答例を書いてみたものの、総じてケースバイケースであり、単純に回答することが難しいと思いました。
だからこそヒアリングや要件の整理が重要となります。

特に想定するエディターモードと作成テーマの種類をどうするかは、開発手法や制作メンバーへ求めるスキルセットに大きな影響があるため、慎重になる必要があります。

また、ブロックエディタの実装においても様々なアプローチ⁵があるため、制作メンバーであらかじめ認識あわせが出来ると良いでしょう。

案件の特性や、関わる人にあわせて様々な選択肢から最適な組み合わせが出来るよう、私も日々キャッチアップしていきたいと思います。

ブロックテーマ開発前提であれば、wp-scriptsでESNextとJSXでの開発になるでしょう。 ↩
もしヘッドレスCMS前提で、フロントエンドはSPAで構築などであれば、TypeScriptは導入することになるでしょう。 ↩
wp_get_theme()->get( 'Version' ) のようにバージョン番号を取得することが可能です。 ↩
Version: 1.1.__COMMIT_HASH__ のような記載の __COMMIT_HASH__ をデプロイ時のコミットハッシュ時に置換などの対応します。 ↩
例えば、@wordpress/scriptsやACF Blocks など。 ↩