【問題点の発見と標準化】WordPressサイトメジャーアップデートした話②

前回に続きジムサイト（店舗サイトにも有効）のWordPressサイトのメジャーアップデートについてのコラムです。軽く前回のおさらいですが、要は「アップデートを想定せずに作られがちなオリジナルテーマを、拡張前提の構造へ作り直す」という内容でした。

 お話の前に「標準化」について触れておきたいと思います。

標準化とは？

Soleilでは標準化というのを2つの意味で捉えています。

と言う感じで認識を分けているイメージです。

その基準に則って、ジムサイトの設計を実際の形に落とし込んでいきました。今回は特に、

• ChatGPT（当社では「乃木さん」と呼んでいます）
• エージェント作業員の「Codex」

この2つをフルに活用しながら、構造を整理した実例の紹介です。

作業自体はそこまで複雑ではありませんが、👉 「どう分解して、どう進めるか」ここを間違えると一気に面倒になります。逆に言えば、この部分を整理できれば、👉 オペレーションはかなり楽になるはずです。一人でも5人分くらいの作業短縮！今回は、そのプロセスを実例ベースでご紹介していきます。

まずは作業場所を作ります

今回の作業は案件の時間的に余裕がありましたので、すべてローカル環境で行いました。WordPressの修正や構造変更を直接本番環境で行うと、意図しない表示崩れや不具合がそのままユーザーに見えてしまうためです。そりゃそうですわ。

特に今回のように、「構造の見直し・テンプレートの変更・カスタム投稿の追加」といった作業を行う場合は、👉 ローカル環境で検証しながら進めるのが前提になります（にしておいた方が絶対いいです）。

小規模な制作では、そのまま本番で触るケースも少なくないと思いますが、今回のように「標準化」や「構造整理」を行う場合は、ローカル環境を用意しておくことで、👉 安心して壊せる状態を作ることができます。

入れるソフトウェアはこれがおすすめ

場所ができたので、状況と工程を整理しましょう

場所ができたので、実際にやる工程を説明していきます。工程を知れれば、物事は処理しやすいですよね。工程は全部で6つです。

工程数	やること	内容
工程1	Codexにサイトの状態を確認してもらう	ターミナルやコマンドプロントでCodexをインストールしておく必要がありますが、ディレクトリをターミナルで監視させてCodexを動かす感じで、プロンプトさえしっかりしていれば、ちゃんと整頓やファイル作りをやってくれます。mdファイルに決まり事を作っておいて、いつでもCodexに必ず読むように指示を入れると、ブレずに進めてくれますよ。
工程2	Codexに出してもらった結果から分解方法を検討	何回もやりとりします。Codexが返してくれる反応から、次のプロンプトを検討して、「じゃあそれはSCSSのvariableにして、コレは独立した別ファイルにしよう」とか、この機能は一度無視して子テーマに持っていくようにしよう（メモメモ みたいな感じで進みます。
工程3	新機能を追加する前に、SoleilとWPの標準化にプログラムやテーマを対応させます。	そんなやりとりを何度かやると、テーマフォルダがきれいになっていきます。今まで親テーマフォルダにはたくさんのphpファイルが乱立してましたが、気づいた頃には、スマートに整頓された役割ごとフォルダに分かれてきています。これで、ファイルの責任所在が明確になり、更新の事故を未然に防げるようになります。
工程4	親テーマ・子テーマに分けて、こいつは親テーマ。こいつは子テーマといった感じで役割を分けるとともに、主たる機能の部分はmu-Plugin（必須プラグイン）にするように計画します。	継続して分けていくと、プラグイン頼りだった機能を「mu-plugins」に割り振ろうと言うムーブが起きます。mu-pluginに関しては別でご説明。 サイトによってはmu-plugin化することが望ましい場合も多く（カスタム投稿とかが店舗情報の登録の場合、ぜったい削ることはないような案件であればそうする）、都度求められる機能に合わせて加工しています。
工程5	計画に基づいて実装（mu-plugin・子テーマのカスタマイズファイル）します。	ここからはその計画を今までCodexと乃木さんに共有し続けているので話は早い。早速組んでくれと言う流れで、共同作業を行います。 「乃木さん→プロンプト作成」「Codex→指定したコード組み上げ」「私→仕上がりを確認」といった感じで、ちょっと私もコーディングしたりします。
工程6	実装後の登録やレスポンスを見たり、狙った表示ができるかチェックします。	ここからはもう私の仕事です。要はデバックです。地道な作業です。

工程1〜3はもどかしいが基本的には「調査・考える」時間。工程4〜5から実装の工程。工程6は一人でデバック。こんな感じに進めていくのが修正・標準化の工程ですかね（一般的と言うか社内ではこうって言う感じです）。

この全工程で起きること

工程として分解してますが、やっていることは全て「標準化してから機能追加（検討・実装）」の繰り返しです。その機能はどこにつける？を常に検討しながら進んでいます。

WordPressは便利です。自由度が高すぎるくらい高いので、あまり言うべき言葉じゃないですが「なんでもできちゃいます」。まあその分労力とお見積りが、、、、と言うのもありますけどね。ただ前の記事でも言いましたが、WordPressに全振りや、プラグイン依存、親テーマ依存なんてことになると、とても危険なので、やはりやり過ぎにならないように安全な設計が必須です。

なので、「標準化してから機能追加（検討・実装）」が大切なのですね。実際こうやって標準化しておいたので、後述になると思いますが、店舗情報の追加やカスタマイズなどの拡張性は抜群になり（200店舗とか登録する！ってなっても問題は起きなそう）、店舗ページのデザイン変更をしても本体のスタイルに邪魔をしないなど、運用者にも制作・保守側にも利点の多い更新となりました。

まとめ

工程はこんな感じですが、次回はもう少し突っ込んだ各工程の伝えたいことをご説明したいと思います。今回紹介している修正は、SWDというサービスが始まる前の事案です。ですが、この時点でSWDの基準のような仕組みはできていて、サービスとして展開しているSWDと同じことをやっているよ言える内容です。

自身のサイトや自社のサイトの健康診断・エラーが発生する前にやっておけば安全な対策として、ぜひSWD（Soleil WordPress Dock）をご利用・ご検討いただければと思います。