WRITTEN BY
鵜飼 聡至
執行役員
2009年にライオンハートへ新卒入社。2016年にはフィリピン子会社の立ち上げを経験し、仕組み化による組織改革の醍醐味を知る。「現場」と「カイゼン」を軸に、同社の鋭い企画を最適な技術で具現化・高品質化させるグループの心臓部を担う。多様な才能が混ざり合い、常に探求し続ける強い組織づくりを目指す。
BLOG
ブログ
ライオンハートでは、ブランディングを「特定の誰かにとって特別な存在になるために、意図的に印象を構築し続けるプロセス」と考えています。理念やロゴを決めて終わりではなく、Webサイトのように日々更新される接点でも、決めたことが正しく反映され続けて初めて意味を持ちます。
そのための仕組みとして、WordPressのプラグインを3つ自社開発し、WordPressの公式サイトで公開しました。WordPressは、Webサイトの作成や更新を管理画面から行えるソフトウェアで、多くの企業サイトで使われています。プラグインは、そのWordPressに機能を追加するためのプログラムです。
この3つのプラグインは、機能だけを見れば既存のプラグインでも実現できます。それでも自社で作ったのは、設定をどこで管理するかという点に、既存のやり方では解決しにくい問題があったからです。
3つとも、設定はすべて、サイトの見た目やページの構成を決めるプログラム（テーマ）に書いています。WordPressが情報を保存するデータベースには設定を残さないため、管理画面に設定ページもありません。
WordPressのプラグインでは、管理画面から設定を入力し、その内容をデータベースに保存するのが一般的です。手軽な反面、開発の現場では困ることがありました。
一つは、本番環境と開発環境で設定が食い違うことです。テーマのプログラムは、変更の履歴を記録して共有する仕組み（Git）で管理していても、プラグインの設定はそれぞれの環境のデータベースに入っています。開発環境で変えた設定を本番環境に反映し忘れたり、本番環境で直接変えた設定が、開発環境では変わっていなかったりします。プログラムは同じなのに、環境によって表示や動作が違うということが起きていました。
もう一つは、複数人で開発するときの設定の共有です。誰かが管理画面で設定を変えても、その変更は他のメンバーの作業環境には届きません。手順書にまとめたり口頭で伝えたりして揃える必要があり、手間がかかるうえに漏れが出ることもあります。
どちらも原因は同じで、プログラムはチーム全員が同じものを使えているのに、設定だけは一人ひとりが管理画面で手入力していたことにあります。たとえば、SNSでシェアされたときに表示される説明文を見直したのに、公開中のサイトには古い文言が残っている、ということが起こり得ます。ブランディングで意図して決めたことが、運用の中で少しずつずれていく状態です。
先ほど触れたように、WordPressは設定を管理画面から入力してデータベースに保存する前提で作られています。設定をテーマのプログラムに書くやり方は、この設計の考え方からは外れます。
それでもテーマに寄せたのは、AIがプログラムを書くことが前提になったからです。これまでは管理画面で項目を選んで入力するほうが、プログラムを書くより早く確実でした。今はフォームの項目や検索エンジン向けの情報の出し方を伝えれば、AIが設定まで含めてプログラムとして書き出せます。管理画面で一つずつ入力するより、AIに書かせて手直しするほうが早くなりました。
設定がプログラムの一部になれば、変更の履歴が残り、他のメンバーが変更内容を確認でき、どの環境にも同じ設定を再現できます。前の節で挙げた2つの問題は、これで解消されます。そこで、AIで設定まで書くことを前提にしたプラグインを、自社で開発することにしました。
設定ページはなくしましたが、WordPressの管理画面はそのまま活かしています。多くのサイトで使われ、慣れている人も多い管理画面に、設定内容を確認するための画面を用意しました。テーマに書いた設定や各ページへの反映のされ方を確かめられ、フォームで使うページが見つからない、ページの転送設定が重なっているといった問題があれば警告も表示されます。管理画面を、設定を入力する場所から、意図通りになっているかを確かめる場所に変えた形です。
TONKATSUが出力する構造化データは、会社名や所在地、サービスの内容、記事の情報などを、検索エンジンやAIが読み取りやすい決まった形式で書いたものです。人が見るページの表示には現れず、機械に向けた情報としてページに埋め込まれます。
最近は、検索結果に表示されるAIの回答の中で、自社がどう紹介されるかを気にされるお客様が増えています。検索結果やAIの回答でサイトがどう扱われるかは、人が読む文章やデザインだけでは決まりません。機械に向けた情報も、ブランディングで決めた内容と食い違わないようにしておく必要があります。構造化データの設定をテーマで管理しておけば、ページを追加したり構成を変えたりしても、その一貫性を保ちやすくなります。
すべてをプログラムに寄せたわけではありません。記事の種類やURLの形、検索エンジン向けの情報の出し方といったサイト全体の構造は、テーマで固定します。一方で、記事ごとのタイトルや説明文のように日々の運用で更新する内容は、記事の編集画面に追加した入力欄（カスタムフィールド）などから、編集担当者が更新できるようにしています。
構造はプログラムで守り、中身は運用で更新していく、という線引きです。
ここまで利点を中心に書いてきましたが、どんな場面でも既存のプラグインより優れているわけではありません。サイト全体の設定の更新頻度が高く、管理画面から自由に変えたい場合や、運用側にエンジニアがいない体制には向いていません。どちらの方式が合うかは、お客様の運用体制によって変わります。
3つのプラグインで変えたのは、設定を置く場所です。管理画面からテーマに移したことで、設定にも変更の履歴が残り、どの環境でも同じ状態を再現できるようになりました。管理画面は、その設定が意図通りになっているかを確かめる場所として使っています。
ブランディングで決めたことは、サイトを公開した後も、ページの追加や構成の変更、複数人での更新を経ながら保たれていく必要があります。それを人の注意だけに頼らず、仕組みで支えるための判断でした。
ライオンハートのブランディング支援では、理念やビジュアルの策定だけでなく、Webサイトなどの接点への実装と、公開後の運用までを一貫して行っています。今回のプラグインは、その実装と運用を支える仕組みの一つです。
本記事で紹介したプラグインは、お客様の案件で使いながら改善を続けているもので、WordPressの公式サイトで公開しています。
