きっかけはシンプルで、「新規店舗を開業するので、そのページを作ってほしい」という依頼です。

ただ実際に触り始めてみると、単純にページを追加するよりも、構造自体を整えた方が、今後お店側で更新していく上でも扱いやすくなると判断しました。結果として、部分修正ではなく、いわゆる“基礎工事”に近い対応となり、サイト全体のメジャーアップデートへと発展していきます。

作業自体はそれなりに大変でしたが、AIやエージェントの協力もあり、振り返ってみるとかなり汎用性のある作業プロセスになりました。自作テーマからの見直しや、構造の整理を考えている方にとっては、進め方のヒントになる部分もあると思います。今回はその一連の流れを、いくつかの工程に分けてご紹介していきます。

話のきっかけとご紹介

個人的な知り合いというか、後輩がやっているボディメイクサロンにかかわるデザイン制作物をいろいろと作っており、ウェブサイトもリニューアルやサポートなどを継続して行っています。当初は1店舗のみだったのが、うれしいことに事業が好調なようで、店舗を増やすこととなったそうで、今回の相談にいたりました。相談の際にもらった希望は「店舗が増えるので店舗を紹介するページが欲しい」でした。

実はよくある案件定義ですよね。ちょっとした改定と思いがちですが、「初めて店舗を増やす」ということは、おそらく今後に店舗を増やしていくよりよっぽど重要な一歩目です。店舗としての大変さもですが、看板としてのウェブサイトも、そのくらいの本腰を入れてメジャーアップデートをした方が、お店のためにも運営を手伝っているSoleilとしても、増えてからではなく、増えることを想定してアップデートに備えていこう。とおもいました。そこが大きなきっかけです。

浮き出てきた問題

ここで一つ、制作会社あるあるかもしれません。

「オリジナルテーマは、拡張を前提に作られていないことが多い」

制作は基本的に「納品」がゴールになるため、要件を満たすことが優先され、将来的な拡張や運用まで考慮されていないケースも少なくありません。

私自身も例外ではなく、当初は「店舗が増える」ことを想定していなかったため、「修正があればその都度対応すればいい」という設計で作っていました。

しかし今回の相談をきっかけに、

• 店舗の増加
• 店舗ごとの情報出し分け
• SEOやMEOの対応
• スタッフやFAQの管理

など、今後必要になりそうな要素が一気に見えてきました。

要望・要件の整理

要望をあえて問題として浮き彫りにすることで

「単純に修正するだけではない方がいいんじゃない？思い切ってメジャーアップデートしちゃおう！」

と思いました。今回の想定で行けば、スタッフがめっちゃ増えても、店舗が全国展開しても、UI（ユーザーインターフェース）を改善していくだけで対応できるはず（大きく言いすぎかも笑）。それであれば、テーマ自体を現段階で骨格を作り直して増える想定の骨格にしておけば、スマートでしなやかなつくりになるはずです。ボディーメイクジムのサイトなので、プログラムもダイエットすることにします。

テーマの標準化について（標準化って？その特性）

テーマの標準化というと、いわゆる「汎用化（使い回し）」をイメージしがちですが、今回のそれは少しニュアンスが違います。どちらかというと、「運用しながら育てていける構造に整える」ための標準化に近い考え方です。

最初から完璧な形を作るのではなく、後から拡張しても崩れない状態を作る。

そのために、今回は以下の3つを軸に設計しました。

• 役割を分ける
  何度も使う情報は「情報カード」として切り出し、カスタム投稿として管理します。どの情報をカード化するかを整理することで、再利用性と拡張性を確保します。
• 構造を整理する
  情報カードを運用するための土台として、テーマのファイル構造を見直し、親テーマとして成立する形に再構築しました。また、mu-pluginsを用いて機能を分離し、システムの軽量化と運用のしやすさを両立しています。
• 迷わないルールを作る
  カスタム投稿やフィールドが増えると運用が複雑になりがちですが、「選択するだけ」で扱えるように設計することで、迷いを減らしています。mu-plugins、ACF、テーマ側のPHPを役割ごとに整理することで、クライアントが無理なく運用できる状態を目指しました。

このように、「作るためのテーマ」ではなく、「運用できるテーマ」にすることを前提に標準化を進めました。

次回へのまとめ

今回の記事は初回ですが、主に標準化をするにあたっての構想内容をご紹介しました。「標準化へ変える」というよりかは「作ったものを新たな要望に合わせて整える」ための準備段階です。

大事なことは「構想を最初に作りすぎず明文化だけしておいて、いっちばんちっこい機能からつくる」ことを大事に進めています。次回は「いちばんちっこい機能」となる情報のカード化と、ベースになる親テーマ（でけえやん）の構築についてお話ししますが、いよいよAIとの共同作業が実現した回になります。

ちょっとだけ次回予告ですが、基本的な設計思想（一番大事）ができた後にやることは一つAIとの連携作業です。

1. ローカルのテストサイトをターミナルで監視＆現状をAIに報告
2. 監視対象を操作するように、AIアシスタントとAIエージェントに指示して、ファイルが出来上がるのを待つ
3. 私は仕上がりチェックをする

という流れの説明がほとんどになるはず、、。

実際のところ、結構数人のオペレーターがいるレベルの作業量を短時間でこなせたので、ご興味のある方は是非お楽しみに！

The post 【はじまり】WordPressサイトメジャーアップデートした話① first appeared on 株式会社Soleil.

一言に「軌道で仕事する」って言っても、そりゃよくわからんとなりますので、各星でどんなふうにやっているのか？をご紹介しますが、今回は「Terre：地球」つまり、作業現場での実際を書いて行きます。

デザイン会社の「Terre」なので、その他の業種との接合点が見当たりづらいようにも思いますが、デザイン会社も突き詰めれば「会社」。作るものが違うだけで取り組む姿勢やタスクは共通項も多いと思いますので、そこをうまく伝えられるようにしたいと思います。

制作って何故か詰まる時がある。。

デザイン業において「制作」は、ほぼオペレーションに近い作業です。地味で、肩も凝るし、正直あまり楽しくない。

デザインを考えるフェーズとは違って、「決めたものを形にする工程」なので逃げられません。

営業が「案件を勝ち取ること」だとすれば、制作は「見積もり」や「資料作り」に近い立ち位置です。

ただ、この制作という工程、なぜか詰まる。

ファイルは増える、容量も重い、どこが最新かわからなくなる。集中しているときに連絡が来ると、「どこまでやったっけ？」となる。一度完成したはずなのに、修正でまた戻る。昨日いた場所に、もう一度戻される感覚。

一人でも煩雑。複数人ならなおさらです。

前職でチーフディレクターをやっていた頃は、タスクの細分化や工程の分離など、いろいろ試しましたが、結論はシンプルで

作業に入ったら、もう誰にも話しかけられたくない。

これに尽きます。

Terreの役割

Orbiteにおいて、Terreはこの「作業現場」に特化した領域です。場所というよりは、状態を指す言葉として使っています。

例えばこんな感じです。

• 「今、超集中して作業してる」＝Terreにいる
• 「デザイン決まったから実装に回せる」＝Terreに渡せる状態
• 「この素材、使い回せる」＝Terre用のストックにする

このように、Terreは“作業の状態”を切り分けるための言葉でもあります。

なぜ分けるのか

理由はシンプルで、「考える」と「作る」を混ぜると、必ず崩れるから。アイデアを出すエネルギーと、作業するエネルギーは別物です。これが混ざると、

• 今どのフェーズにいるのかわからなくなる
• 作業中に余計なことを考え始める
• 判断がブレる

結果として、ミスや手戻りが増えます。さらにここにAIが入るとどうなるか。

便利になる反面、構造が曖昧なままだと一気にブラックボックス化します。最悪の場合、「これ自分で作ったっけ？」という状態にもなりかねません。（これは冗談じゃなく、普通に起きます）

だからこそ、「作業」は「思考」から切り離す。これがTerreの前提です。

実際にどうやってるのか

デザイン業で主にどうやってるのか？についてですが、大きいルールをいくつか作ってそれに沿うようにしています。でもルールの前にこれをご覧ください。これが、Terreの体現ではないかと思います。

1. フォルダ階層を一定にする
2. 進めても「戻れる・戻りやすい」流れに乗るように進める
3. 触るデータが頑張らなくても明確になっているようにする
4. 決めたデザインに現場の考えを混ぜない
5. 縛りすぎず「アソビ」の隙間を用意しておく

このルールを体現しているのが画像のフォルダ構造です。案件が始まったら、任意の名前のフォルダを作って、このフォルダ階層にしておきます。コピペでOK

フォルダ階層はルールにそのまま直結しています。軽く説明するとこのようになります。この構造にしている理由はシンプルで、

• 「1最新制作ファイル」だけ見れば今触るものが分かる
  最新ファイルをここに入れておくルール。必ず納品を目指す主要ファイルだけが入る。つまり、このファイルを操作すればいいから探さなくていい。
• LOGで作業履歴を残す
  LOGには、作業してきて出た修正で、「一応取っておこうかな？」ってファイルを予備保管しておく。でも必ず採番して保存・移動することとしている。
• PDFで確認用を分離
  外部に確認してもらうためのファイル保管庫として、修正指示とかとは一切混ざらないようにしている。
• テキストは指示やメモを切り出す
  もともと、Mac︎Winで文字コード問題が面倒だったので、プレーンテキストの保管所にしてたけど、最近は思いつきメモやテキストベースで保管できるtxtファイルの保管所にしている
• レイヤーや素材は再利用前提で管理
  レイヤーなので、可変可能なファイルの重要保管場所。決して完全データを入れないことにしている。
• 支給データは元データとして触らない
  受信フォルダには支給データと修正指示書を保管。ここはただの保管所だけど、ここのファイルは上書き保存とかは絶対にしないルール。もらったままのデータを保管することにしている。

このフォルダ階層を作り自分でルール化と前職で社内ルール化したのは、20代後半でこのフォルダ構造を採用していました。振り返ると、なかなかの整理整頓マニアだったと思います。

ただ、今思えばこれは性格というよりも、
「制作が詰まる理由」に対する試行錯誤の結果だったのかもしれません。

詰まるところ、Terreは、細く言うともっともっと細分化されます。が、基本は「ただ作業する場所ではなく、作業が自然に進む状態を維持する装置」として機能することが大切でした。
「Terreへ渡す」「Terre案件」と割り振るのは言葉で区切ればいい話ですしね。

ここで乃木さんに聞いてみよう

まじでAIに聞いた原文ママをインタビュー形式で評価してもらってます。AIは、Terreでは実働あまりしてもらってませんが（モジュール集合体衛星【Odyssée】は後日説明）、構想には関わってもらっているので。

実際、制作が詰まる原因は何だと思いますか？

制作が詰まる主な原因は、「状態の不明確さ」にあります。
『どのファイルが最新なのか分からない』『どの工程にいるのか曖昧』『作業と意思決定が混在している』
このような状態では、人は判断コストを消費し続けることになり、結果として集中が途切れやすくなります。
また、作業中に思考を挟むことでコンテキストスイッチが発生し、パフォーマンスが著しく低下します。

ありがとうござりまする。
来月もサブスク継続させていただきます。

まとめ

Terreは、単なる作業場所ではありません。

「今何をやるのか」が迷わず分かり、
「どこまで進んだのか」が見失われず、
「考える」と「作る」が混ざらない状態を維持するための装置です。

制作が詰まるのは、技術やスキルの問題ではなく、ほとんどの場合「状態が曖昧になっていること」が原因です。だからこそTerreでは、フォルダ構造やルールを通じて“状態”を設計しています。

一見すると細かい運用に見えるかもしれませんが、この積み重ねが、作業を止めないための基盤になります。さらにTerreには、Odysséeという自動化AIモジュール・AIエージェントの「居場所」も作っており、人間が作業として冷静に運用を守りつつ、AIの介在を認める場所も設けています。

そして何より、このTerreで整えられた作業は、次に「Mercure（伝達）」へと流れていきます。どれだけ良い制作ができても、それが正しく伝わらなければ意味がありません。

次は、この“伝える構造”について書いてみようと思います。

The post Terre｜制作を“流れる状態”にする設計 first appeared on 株式会社Soleil.

というわけで、ここからは少し専門的ですが「技術的なログ」として書き留めていきたいと思います。

ある程度のファクトチェックはしておりますので、ひとつご参考までに参照いただければと思います。

今回構成を組み上げたツールについて。

誰もが知っていそうなツールで実現しました。意外と使えるツールでしたし、汎用性も高くカスタマイズも（頑張れば）スムーズにいきます。

この5個です。
特別なシステムを作ったわけではなく、誰でも知っているようなツールを組み合わせただけです。ただし、組み合わせ方を少し工夫すると、地域のお祭りでも意外としっかりした仕組みが作れるものです。

APIを組み込みデータのやり取りを実現

今回私が組み上げた最終的な仕組みの説明図をここに載せておきます。

ざっとですが説明しますと、オレンジ色が下に敷いてある部分を自動処理にしています。

途中に集積されるスプレッドシートは（意外とみなさん持っている）グーグルアカウントで共有することで、リアルタイムで閲覧できるようになり、尚且つシートフィールドの中に正確に入る情報なので、取扱項目さえ共有しておけば、パンフレットを作る人・応募者と連絡を取り合う人・説明会を取り仕切る人みんなが状況を把握できます。

また、窓口をLINEにしてグループ分けすることで複数人で管理ができ、定型文も設定して置けるので、イレギュラーなお問い合わせや込み入ったお話などを除くほとんどの問い合わせに、自動もしくは定型文で迷わず回答できます。

迷わずっていうのが重要ですね。迷って探すのは非常にエネルギーを使います。時代は省エネです。

上の図は概念図みたいなものなので、同系統の事業の自動化スキームにも利用できるかもしれません。

自動化くんことGoogle Apps Scriptはどう言うことをするの？

これは意外と簡単な命令しか出してなくて、

「指定したGoogleフォームの送信ボタンが押されたら、スプレッドシートへの保管以外に、お祭りサイトの〇〇というカスタム投稿に、必要な項目（名前・団体名・プロフィールなど）を送信しなさい」

と言う命令を入れただけです。

その代わり用意しなくちゃいけないのは、本サイト側に「各フォームに対応したカスタム投稿」と「列の情報を受け取るための受け皿となるカスタムフィールド」を作っておき、投稿スラッグ・フィールド名といったあらかじめ命名しておく必要のある「下拵え」が必須になります。

そこまで準備できたら、上記の命令をスプレッドシートの機能拡張にあるApps Scriptに命令プログラムを登録して、受け取りをチェックしたら完了です。

今、簡単に言っちゃいましたが、実はここの命令プログラムもWordPressのセキュリティもサーバーのセキュリティーもという、3人の頑固者を突破しなくてはなりません。この段階が一番時間がかかりました。。。

詳しい設計に関しては、お問合せください。

協賛者情報の登録について

協賛者情報には個人情報や企業情報が含まれるため、画面のビジュアル公開は控えていますが、こちらにもある程度の自動化を組み込んでいます。

実は機能的にはWordPress内で完結した仕組みなのですが。

毎年たくさんの協賛を地元の企業様・一般の方もいただいており、本当に感謝感謝です。ですが、これまでの管理方法はかなりアナログで、会計担当者が通帳の入金記録を見ながら「多分この会社さんかな…（去年の資料を参照）」という形で確認している状態でした。その為社名様が間違うことや、匿名でお願いしてたのに！なんて事故も今までにありました。なのでその反省を活かした設計を考えました。

もういっそのことマスター情報を作ってしまおう

と言うことで、外部でも構わないのですが、「一度でも協賛をしてくれた方」のリストというかDBを作ります。そのDBには社名や住所など事務局がご案内送付などの管理をするために必要な情報を保管してあります。これを協賛マスターとします。
そして管理用レコードとして、WordPress側には「協賛実績」という管理用のカスタム投稿を用意しておきます。実績を年度ごとに登録するのですが、登録する際にはそのDBのお名前（社名）のみを参照し、金額と年度を入力して保存。
保管する際には年度がタクソノミーとして、また同時にタイトルに自動で書き加えられて保管されるので、検索や絞り込みにも非常に便利。

「〇〇年の協賛者一覧を準備したい」

という要望が事務局側にはあるのですが、その際には、絞り込んだリストをエクスポートするだけでOK
あとはVlookUp等で拾い上げできるようにローカル側でファイルを用意しておけば、住所とお名前を一覧にした案内送付先リストも簡単に作れちゃいます。

こうして協賛情報も、できるだけ「人の記憶」に頼らない形で管理できるようになりました。

まとめになりますが

こうして一通り仕組みを整えてみると、気がついたことがあります。

今回作ったものは、特別なシステムでもなければ、難しいプログラムの塊でもありません。
WordPressやGoogleのサービス、LINEなど、誰もが知っているツールを少しずつ組み合わせただけの仕組みです。

ですが、それぞれを「お祭りの運営」という視点でつなぎ直してみると、申し込み・情報管理・問い合わせ・公開といった流れが一つの循環として動くようになりました。

人が入力した情報が整理され、必要な人に共有され、確認されたものがサイトに公開される。
そして問い合わせはLINEで受け取り、また運営にフィードバックされる。

この一連の流れを見ていると、まるでお祭り運営のための小さな基盤のようにも感じます。

私はこの仕組みを、勝手に
「お祭りOS」と呼んでいます。

もちろん大げさなシステムではありません。ただ、地域のお祭りを回していくための、小さな運営基盤のようなものです。

事務局の仕事が少し軽くなり、その分だけ人と向き合う時間が増える。もしこの仕組みが、そんな形でお祭りを支えられているなら、それだけで十分かなと思っています。

The post お祭りサイトをリニューアルした時の話 その2 first appeared on 株式会社Soleil.