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

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

作業自体はそれなりに大変でしたが、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.

クライアントからの制作依頼、次のサービスの構想、ブログの記事を考えたり、地域振興で関わりのある祭りの準備。どれも大事で、どれも途中で、どれも少しずつ動いています。

最初は普通のタスク管理で整理しようとしていました。ToDoリスト、メモ、スプレッドシート。
でも、しばらくすると気づくんですよ。
仕事というのは「並んでいるもの」ではなく、「回っているもの」だということに。

あるものは「毎日触る」
あるものは「月に一度だけ動く」
あるものは「しばらく放っておくと突然思いつく」
まるで、それぞれが違う「軌道」を持って動いているみたいな感じで。

そこで、ふと思った。
もし仕事を「タスクの列」ではなく、太陽系のような構造として整理したらどうなるだろう。

中心には意思決定の場所があり、その周りを、役割の違う仕事やアイデアがそれぞれの軌道で回る。そのイメージから生まれたのが、私が「Orbite（オルビット：軌道【仏語】」と呼んでいる思考モデルなんです。

私のOrbiteでは、まず中心に**Soleil（太陽）**がある。ここは特定のツールやアプリの名前ではなくて、もっと単純に、「最終的な判断が行われる場所」のことです。

仕事をしていると、必ずどこかで決断が必要になる。「この案件を受ける？」「この方向で進める？」「このアイデアを本当に形にする？」

どんなにタスク管理を整えても、最終的に決めるのは自分自身。。。
だからOrbiteでは、すべての軌道の中心に Soleil = 意思決定の中心 を置いている。

その周りには、いくつかの「惑星」があって、制作や実務を担当する場所になってる。
コミュニケーションが集まる場所。
アイデアが漂う場所。
実験的な開発を行う場所。

それぞれが役割を持ち、同じ距離ではなく、
それぞれの軌道でSoleilの周りを回っている。

この構造で仕事を考えると、不思議なことに、タスクの量に振り回されるのではなく、「これはどの軌道の仕事なのか」が見えるようになる。

Orbiteは、まだ完成した理論ではない。
むしろ、自分の仕事のやり方を整理する中で、少しずつ形になってきた考え方だ。

このブログでは、その思考の過程や、そこから生まれたツールや仕組みを少しずつ書いていこうと思います。

最近作り始めた「Account Observer」も、このOrbiteの中で生まれた小さな観測装置の一つなんです。

Orbiteの惑星たち

惑星たちのご紹介をさせていただきます。

こんな感じで、自身の太陽系を勝手に作りました。

今回、最近作り始めた「Account Observer」については別の記事で説明させていただきますが、こういう星系を思い浮かべながら、自身の「一人仕事をうまくコントロールしよう」と思い考え出したのがこの、「Orbite（軌道）概念」。

Orbiteは全然完成した概念じゃないし、これからも自身の業務を鑑みながらそれこそ軌道修正をして、安定した運行を目指すものです。

このブログでは、Soleilの周りを回るいくつかの惑星や、そこから生まれた仕組みについて、少しずつ書いていこうと思います。

The post 仕事を太陽系として考える ― Orbiteという思考モデル first appeared on 株式会社Soleil.