WordCamp Kansai 2025でブロックテーマを題材に登壇してきました #wckansai2025 #wckansai
2025年11月2日に、WordCamp Kansai 2025で「ブロックテーマ実践記 – 本当に使いやすいWordPressの作り方」というタイトルで登壇させていただきました！
当日のスライドはこちら
セッションのアーカイブ動画はこちら
私のセッションの実況まとめはこちら
元々、社内的に「公募出せ」とは言われていたんですが、開催時期的に妊活大詰めで多分メンタル死んでるからということで今回は見送っていました。
………が、公募が終わった後くらいに、急にとろゆにさんからSlackで「ダメ元で聞くんだけど、ワンチャン WCK 2025 でブロックテーマネタで登壇しない？ 40分。スライドとかは俺も手伝うとしたら」と珍しく（？？）頼まれまして、直接頼まれたら致し方ない………スライド手伝ってくれるって言ってるし………会社の名前背負って出るからスライドも業務時間内でやればいい（でかい！）とも言ってもらったので、急遽登壇が決まりました！私のセッションがしばらく「タイトル未定」になっていたのはそういうわけです。
セッション内容を詰めていく
一応10月頭までにはセッションタイトルは出さねばということで、さっそく通話で「何しゃべる？」を詰めていくことに。
その時の通話メモの一部がこちら！
とろゆにさんとの通話メモ
- クラシックテーマとブロックテーマのちがいってなあに〜？みたいなのはいらない
- 実戦でやってる話をする。やってる人間としてブロックテーマの話をする
- 実戦投入した上でやったこと、改善したこととかのスタンス
↑前提
- 「お客さんがどう触るか？」を意識
- CMSやる上で前提なんだけど、より意識するようになった
- UXが根底にある。それを実現するための手段がTailwind
- 実装にフォーカスする。
- UXはオチに使うのがよさそう。「なんでここまですんの？」のオチ
- 全部のコンテキストお客さんが更新できないとだめでしょ？？
具体的にどういう意図をもってどういう実装を選んだ？
解決できたこともあるしできなかったこともある（どうせ全部は解決できてない）
- ユーザーが使いにくいからやめよう
- キラーフレーズをまず考える。手段も大事、口だけではなんともならない
- UXが高いWordPressテーマってどういうこと？？
- これを深掘りする。
- 簡単に更新できる？迷わない？？
- DXが💩だからUX考えないはだめ
- ブロックテーマごりごりやって、経験ベースの話
- ブロックテーマそんな作りづらいの？って話。ブロックテーマになったから大変になったはほんまか？
- PHP書かんでいい、パターンでカスタムブロック作らんでよくなった
- テーマにしぼる。カスタムブロックはノイズになる
HTMLの再利用の方法はたくさんある。整理して話す
全部ブロックつくればいいやーん->追いつくのが大変
パターンだけで完結するならそれに越したことはない
- パターンでだいぶんブロック作らなくてよくなったって話はしてもいいのかも？
- ブロックある程度作ってる人じゃないとわからん話だからスルーしてもいいかも
ゼロから始めるにあたってどうすればいいのか？っていう目線
あくまでテーマだけ
単純なボタンですらCSSがいる（矢印とか）。ホバーもCSS
あとあとコアに実装されるかもしれないから安易にプラグイン突っ込むのが嫌
安易に複雑な機能をぶち込むことでメンテナンス性が下がる
いまのところこんなことやってる
べき論より「どうやったの！？」ってなる
UXに関しては感じたことをそのまましゃべったらいい
ブロックテーマの話聞きたくてくる人ってどんな人？
Create block themeご存知ですよね〜？？パターンご存知ですよね〜？？のスタンス
右の設定パネルは最初出てないからわかりにくい。->パターンでやりたいっていう意図
タブの中にタブのUI💩
パターン単位で物事考えますよね？という話。デザインデータとかもそうだよね
atomic design：実装レベルからでてきた
パターンを設計の中心に据えている。テンプレート作るよりパターン（テンプレートパーツ）をつくる
UX軸はOK。あとは具体論をどれだけ積めるか
パターンも大事、パーツも大事はハイブリッドでも変わらん。
ブロックテーマの方が優れてるけどハイブリットもやることある。結局パターンいっぱい作った
->話の最後につけてもいいかも。ハイブリッドでも変わらん
ナビゲーションはつらいけど全体からすれば重箱の隅（あえてやらなくていい）突っ込まれたら「CSSでがんばれば？」
何を大事にしたからこういう設計をするのか？？
スターターページは言及する？
パターンとパーツの使い分け 時間があったらする
BtoBtoC
UXにふたつのユーザーがいる
1. 依頼主であるウェブサイトの管理者
2. そのサイトに訪れる人
ビジネスの流れでいくと、2の人にコンテンツを届けれる仕組みを作らないといけない
-> これがウェブサイトの価値
- 問い合わせ件数はどれくらい？
- 広告収入どれくらい？
これにつながるWebサイトを依頼主はほしがっているはず
っていう視点はUXとして必要。１のユーザーだけ見てると自己満足サイトをつくっちゃう
１のユーザーとやりとりするからばーーーって要望言うけど、それが1のユーザーのためなのか２のユーザーのためなのか検証してる？
「この検索の機能はむずいけど、サイトに必ず必要・・・」みたいな視点は１を通して２を見てる
「きれいなカルーセルほしい」「スクロールジャックほしい」💩 -> それがユーザーにとっていかに必要なのか？がわかればやる
コストかけないって視点だとカスタムブロックは明らかにコストかかるからパターンでできるならそっちのがよろこばれるよねー
---
目標：エンドユーザーに情報を届けること
問題：コンテンツ作成がむずかしい（例）
核となる考え：CMSのユーザーってだれ？
変化：その考えに合わせてどういう変化を自分がしたか？（デザインシステムのはなしとか
行動：だから聞きにきたみんなにもこうしてほしい
BtoBtoCの話なんかは夫とやりとりしてます。だいぶん過激な単語は💩アイコンでぼかしましたが、赤裸々に晒すとこういうやりとりを経てセッションタイトルを作りました。
これを元に、Claude CodeとチャットしてADRとしてまとめたものがこちら。
めちゃくちゃ長いのですっ飛ばしてもらってOKです。
Claude CodeとまとめたADR
# Architecture Decision Record: WordCamp Kansai 2025 登壇内容
## 基本情報
- **イベント**: WordCamp Kansai 2025
- **登壇枠**: 40分（招待枠）
- **タイトル**: ブロックテーマ実践記 - 本当に使いやすいWordPressの作り方
- **日付**: 2025年作成
- **ステータス**: 承認済み
## コンテキスト
WordCamp Kansai 2025で40分の登壇枠でスピーカーとして登壇することになった。
聴衆はWordPressに詳しい層が中心で、ブロックエディターの基礎知識はある前提で話せる環境である。
実際の案件でブロックテーマを多数制作・運用してきた経験から、現場で得た知見を共有する機会となる。
## 決定事項
### 1. 基本方針
- **実践ベース**: 理想論ではなく、実際の案件での経験を話す
- **問題解決型**: 「べき論」ではなく「どうやったか」を中心に
- **押し付けない**: 「私たちなりのやり方」というスタンスを貫く（オブラートに包んでるけど言ってることは厳しい）
- **現場主義**: 血反吐を吐きながらたどり着いた現実解を共有
- **UX軸の徹底**: 開発体験（DX）の話に引っ張られず、ユーザー体験（UX）を軸に語る
### 2. 対象者設定
#### メインターゲット
- ブロックテーマを作り始めて壁にぶつかっている人
- 実践的な知見を求めている制作者
#### 前提知識
- Create Block Themeを知っている
- パターンの基本概念を理解している
- ブロックエディターの基本操作ができる
#### 対象外
- Classic Editor使用者
- ブロックエディター未経験者
- WordPressを始めたばかりの初心者
### 3. コンテンツスコープ
#### 話すこと
**メインコンテンツ**
- BtoBtoC構造におけるCMSの本質
- パターン中心の設計思想と実装
- パターンとテンプレートパーツの使い分け
- 実際にぶつかった課題と対処法
- メンテナンス性と使いやすさのバランス
**サブコンテンツ**
- theme.jsonの活用方法
- CSSの最小化アプローチ
- プラグインに頼らない理由
- 解決できなかったことも含めた現実
- ハイブリッドテーマでも同じアプローチが有効
#### 話さないこと
- クラシックテーマとブロックテーマの違い（基礎知識）
- 「ブロックテーマは作りづらい」論争（DX視点の話題）
- カスタムブロックの詳細な作り方（ノイズになる）
- ナビゲーションブロックの細かい問題（重箱の隅）
- FSEの将来性や是非論
- ブロックエディターの基本的な使い方
### 4. キーメッセージ
#### メインメッセージ
「全部のコンテキスト、お客さんが更新できる」を実現する
#### UXの二層構造（BtoBtoC）
- **依頼主（管理者）**: コンテンツを更新する人
- **エンドユーザー（訪問者）**: 価値を受け取る人
- 管理者が更新できなければ、エンドユーザーに価値が届かない
- 1のユーザーだけ見てると自己満足サイトを作ってしまう
- これがCMSの本質であり、すべての技術選択の判断軸
#### サブメッセージ
- DXの問題を言い訳にUXを犠牲にしない
- カスタムブロックを作りすぎない勇気
- パターンを効果的に使えば、ブロックテーマは作りづらくない
- コストを考えるとパターンでできることはパターンで
#### キラーフレーズ候補
- 「全部のコンテキスト、お客さんが更新できないとだめでしょ？」
- 「全部ブロック作ればいいじゃん、と思っていた時期が私にもありました」
- 「PHPほぼ書かなくなった」
### 5. 発表構成（40分）
#### 1. イントロ（5-7分）
- CMSの本質：BtoBtoC構造の説明（3-4分）
- 依頼主（管理者）とエンドユーザー（訪問者）の二層構造
- 管理者が更新できなければ、エンドユーザーに価値が届かない
- **これがWordPress（CMS）の存在理由**
- 1のユーザーだけ見ると自己満足サイトになる
- **だから「全部のコンテキスト、お客さんが更新できる」が必要**
- ブロックテーマでこれを実現してきた実践の話をする（1分）
- 理想論じゃない、血反吐を吐いた現実の話
- 今日のスタンス宣言（1分）
- 押し付けない「私たちなりのやり方」
- 解決できたこと・できなかったことの両方を話す
#### 2. 新しい課題の提示（7-8分）
- ブロックテーマになって何が変わったか
- 「お客さんが自由に編集できる」が現実になった
- でも、それは同時に新しい課題を生んだ
- 現場で実際にぶつかった問題（具体例必須）
【以下、具体例を3つ程度準備する必要あり】
例：
- 自由すぎて、デザインが崩れる可能性
- テンプレートパーツとパターンの使い分けが難しい
- プラグインを入れるべきか、テーマで対応すべきか
- 本当の問題：選択肢が増えたからこそ、設計が重要になった
- 「自由にできる」≠「使いやすい」
- どこまで自由にして、どこを制限するか
#### 3. 私たちなりのやり方（15-20分）
**技術的詳細のメインセクション**
【ストーリーライン】
「お客さんが更新できる」を実現するために、私たちは3つの軸で設計している
■ 軸1：パターン中心の設計（7-8分）
- なぜパターンを中心に据えるのか
- カスタムブロックよりコスト低い
- お客さんが理解しやすい
- メンテナンス性が高い
- 具体例：【ここに実際のパターンを見せる】
- Before（カスタムブロックだらけ）
- After（パターン中心）
- お客さんの反応
- パターンとテンプレートパーツの使い分け
- 使い分けの基準：【明確な基準を示す】
- 具体例：【実際のコードorスクリーンショット】
■ 軸2：theme.jsonとCSSの最小化（4-5分）
- theme.jsonで何をコントロールするか
- 色、フォント、スペーシング
- お客さんが触れる範囲を設計する
- CSSの最小化アプローチ
- なぜ最小化するのか（メンテナンス性）
- 具体例：【Before/After】
■ 軸3：プラグインに頼らない理由（3-4分）
- なぜプラグインを避けるのか
- メンテナンスコスト
- 将来的なコア実装への期待
- お客さんの混乱を避ける
- でも、使うべきところは使う
- 判断基準
#### 4. 結果と学び（5-7分）
■ 解決できたこと（2分）
【具体例を3つ程度】
例：
- パターン数を◯個に抑えることで、お客さんが迷わなくなった
- theme.jsonで色を制限したことで、ブランド一貫性が保たれた
- プラグイン数を減らしたことで、サイトが軽量化した
■ 解決できなかったこと（2分）
【これが重要。正直に語る】
例：
- ナビゲーションブロックの◯◯はまだ難しい
- ◯◯のパターンはどうしてもカスタムブロックが必要だった
- お客さんの◯◯という要望には応えられなかった
■ お客さんの声（1-2分）
【定量的 or 定性的データ】
例：
- 「前のサイトより更新が楽になった」
- 更新頻度が◯倍になった
- 問い合わせが◯件減った
■ （時間があれば）ハイブリッドテーマでも同じ（30秒-1分）
- パターンとパーツの考え方は変わらない
- ブロックテーマだけの話じゃない
#### 5. まとめ（2-3分）
- 振り返り：3つの軸
- パターン中心
- theme.json+CSS最小化
- プラグインを避ける
- でも、手段は変わっても目的は同じ
- UX（お客さんが更新できる、エンドユーザーに価値が届く）
- 「なぜそこまでするのか？」
- BtoBtoC構造に立ち返る
- これがCMSの存在理由
- Q&A誘導
- 「どうやったの？」という質問、大歓迎です
- 「うちではこうしてる」という共有も歓迎
### 6. トーン＆マナー
- **姿勢**: 上から目線にならない、教える→共有する
- **温度感**: 優しく語る厳しい現実
- 表面：「私たちなりのやり方なんですけどね〜」
- 本質：「でもこれやらないとUX死ぬよね？」
- **言葉遣い**: 技術的に正確でありつつ親しみやすく
### 7. 成功指標
- 聴衆が「自分もやってみよう」と思える
- 具体的な実装のヒントを持ち帰れる
- ブロックテーマへの苦手意識が減る
- 「どうやったの？」という質問が出る
- UXの重要性を再認識してもらえる
## 理由
### なぜこのアプローチか
1. **差別化**: 他のWordCamp登壇でよくある入門的内容との差別化
2. **価値提供**: 実際に手を動かしている人だからこそ話せる内容
3. **実用性**: 聴衆が翌日から使える知識の提供
4. **信頼性**: 実案件での経験に基づく説得力
5. **本質への回帰**: DX論争ではなく、CMSの本質（UX）から語る
### なぜBtoBtoC構造を明示的に語るか
1. **Why（なぜ）の明確化**: 技術選択の判断軸を示す
2. **説得力の向上**: 「なぜそこまでするのか」に答える
3. **差別化**: 単なるHow-to話ではなく、思想のある話にする
4. **普遍性**: ブロックテーマに限らず、CMS全般に通じる本質
### なぜパターン中心か
1. **現実的**: カスタムブロックを作る人は少数派
2. **メンテナンス性**: 将来的な保守を考慮
3. **学習コスト**: 新しいメンバーでも理解しやすい
4. **柔軟性**: デザインの再利用性が高い
5. **コスト**: カスタムブロックよりパターンの方が低コスト
### なぜ「作りづらい」論争を避けるか
1. **軸のブレ**: DX（開発体験）の話に引っ張られる
2. **本質のズレ**: 語るべきはUX（ユーザー体験）
3. **ポジショニング**: 「作りづらいか」の議論ではなく「使いやすいサイトをどう作るか」という次元で語る
## 今後の作業
### 詳細化が必要な項目
1. **技術的詳細**
- パターンの具体例
- パターンとパーツの使い分け基準
- theme.jsonの活用方法
- CSSの最小化アプローチ
2. **具体例の準備**
- 実際のコード片
- Before/After
- スクリーンショット
3. **解決できなかった問題の整理**
- 何がうまくいかなかったか
- どう妥協したか
### 作成方針
- **入れたい要素は全部入れる**: 練習で時間オーバーしたら順次削る
- **技術的詳細が目玉**: 後でスライドに組み込む
- **具体例重視**: 抽象論だけで終わらせない
## リスクと対策
### リスク1: 技術レベルのばらつき
**対策**: 基礎は前提としつつ、専門用語は適度に説明
### リスク2: 40分で収まらない
**対策**: 入れたい要素を全部入れてから、練習しながら削る
### リスク3: 「それはあなたの会社だから」という反応
**対策**: 「私たちなりのやり方」と最初から明言
### リスク4: 具体例が足りない
**対策**: 実際のコードやスクリーンショットを準備
### リスク5: BtoBtoCの説明が重い
**対策**: 図解で視覚的に、テンポよく説明
## 参考資料
### 前提となる資料
- https://speakerdeck.com/chiilog/nantonakuwakatutaqi-ninaruburotukutemaru-men
- https://speakerdeck.com/torounit/2025-dot-09-dot-13-at-shinshu-wordpress-meetup
## 更新履歴
- 2025/09/29: 初版作成
- 2025/09/29: タイトル・概要文確定
- 2025/09/29: ADR作成
- 2025/09/30: 冒頭部分の方向性確定
- BtoBtoC構造を明示的に語ることを決定
- 「作りづらい」論争を避け、UX軸から入ることを決定
- トーンを「優しく語る厳しい現実」に調整
## 備考
- スライドはこのADRに基づいて作成する
- 発表練習時にこのADRを見返して軸がブレていないか確認する
- Q&Aで想定外の質問が来た場合も、このADRの方針に沿って回答する
- 技術的詳細は後で段階的に追加していく
結果的にADRにまとめたものの半分くらいの話しかしてないです。初稿とか70P以上あって、今見返すと各セクションの説明もくどかったです。
BtoBtoCの話とかガッツリなくしましたしね！
当日話してみて
スライドの中身自体は私がしっかり「どういうことを伝えたい？」「何を話したい？」からまとめました。
とろゆにさんにはすごく丁寧にレビューしてもらい、いろんなところを 削いで、削いで、削いで、 最終版手前は40Pになったんですが、さすがに削ぎすぎて時間があまりそうだったので、そこからさらに肉付けをして、削いで、をやって、結果的に50Pに収まりました。
正直、実践記と言うには内容薄くないかな？とか、こんな内容でいいのかな？ってめちゃくちゃ不安だったんですが、当日は大部屋に満員御礼ですごく嬉しかったです！（めちゃ緊張してちょっと声震えました）
登壇後も番台さんに居たら数人の方が質問に来てくださったり、スタッフさんが「今日参加したセッションの中で一番面白かったって言ってたよ！」って教えてくれたり………ありがたい話です！
懇親会でも「方向性間違ってなさそうでよかった」とか「ここはどうします？」とかご質問いただいたりしてました。Tailwind使っている方もちらほら居て、「ここしんどいですよね〜」ってところで盛り上がったりもしました！
なお、より開発に寄った内容はとろゆにさんがWordPress Meetupで話されてるのでよければこちらも見てみてください。
Tailwind使う時の困りポイントとかハックは近々ブログにまとめておきたいなと思っています。乞うご期待！
まとめ
私の話を聞いて「ブロックテーマやってみよう」って思ってもらえたら幸いです。
何人かに「どう始めていくのがいいですかね………」ってお悩みを聞いたので私なりの回答ですが、 いきなりブロックテーマで全部やっていこうなんて思わなくていいです。
ブロックテーマの話しておいてお前は何を言っているんだという感じだと思いますが、いきなり転換するのは大変です。
私はGutenbergがコアに搭載される直前からずっとブロックを触ってきているので、ある程度の慣れがあります。
みんな言ってると思います。「慣れたらこっちのほうがいい」って。
テーマ側はPHPで、エディターだけブロックエディターを取り入れる、いわゆるハイブリッドテーマから進めていくのがいいのではないでしょうか。これが一番現実的だと思います。
- エディターをブロックエディターにする。theme.jsonを取り入れる
- テーマ側の一部を、ブロックのパーツにしてみる（サイドバーとかフッターとか）
- ブロックテーマにしてみる
ざっくり書くとこんな感じでしょうか。
私も実質こうして身につけてきたので、段階を踏んでやっていくと理解が深まって良きかと思います。
ただ、PHPのテーマを触ったことがなく、これからやりたいです！という方はブロックテーマでやっていくのをお勧めします。PHP使わなくていいならそれに越したことはないんですよね！！！
デフォルトテーマを触るもよし、WordCampやWordPress Meetupで知った高品質なブロックテーマを触るもよし。悩んだらお近くのWordPress Meetupで相談してみましょう！！！！
Discussion