TSKaigi 2025 の Ask the Speaker で azu さんに質問できた

2025/5/23-24に開催されたTSKaigi 2025に参加・登壇しました。

2日目のazuさんの発表「技術書をソフトウェア開発する - jsprimer の 10 年から学ぶ継続的メンテナンスの技術」を聞き終わり、即座に Ask the Speaker の場所に向かいました。

自分は2人目だったのですが、すぐに多くの方が集まってきて、azu さんへ「JS Primerを読んでエンジニアになりました！」や「スポンサーしてます！」という感謝や応援の言葉が飛び交いました。その中で自分の番が回ってきたので質問をしました。

「自分は本を本として、ソフトウェアをソフトウェアとしてしか見たことがなかったです。azuさんはどこから書籍をソフトウェアとして捉えるという着想を得られたのでしょうか」

azuさんの回答は以下のような内容でした（すぐメモを取ったのですが一語一句その通りというわけではないです）。

パラグラフライティングは、文章をシンプルに書くこと。これはソフトウェアのコードと同じ。ソフトウェアはアーキテクチャであって、深掘りすれば建築にたどりつく。建築は汎用性をめざす。

発表の中で言及した「既知から未知に進む」はコードも書籍も同じ。例えば、コードにimport a と書かれていたら、aはそのimportの下で使われていてほしい。反対にaの下にimportがあったら未知から始まってしまう。もしaを辿ったとしても、その先はaに関する内容だけ書いていてほしい。

この話を聞いて、「コードは文章に似ていると自分は考えたことがある。反対にazuさんは文章をコードに、ソフトウェアに似ていると考えていたのだ」と理解しました。同時に、自分はラッパーのZORNが言う「韻の飛距離」という言葉を思い出していました。

韻の飛距離とコードとしての文章

日本語ラップの世界では韻（rhyme）が重視されます。そして韻を踏む言葉の組み合わせには良し悪しがあります。ただ母音を合わせて韻を踏むだけでは良い歌詞にはなりません。では良い韻、面白い韻とはなんでしょうか。それはZORNは「飛距離が遠いこと」と例えました。

ZORN：そうなんだよね、韻には飛距離があるんだよね。

（中略）

R-指定：「A」という言葉と「B」という言葉で踏もうとしたら、「A」と「B」の言葉の響きは近ければ近いほどいい。でも、その内容がかけ離れていれば離れているほど、韻として面白いというか。

詳しい解説はこちらの記事に譲ります。 この記事で挙げられている例は下記のようなものです。

表参道のオープンカフェより/も嫁さんとの醤油ラーメン （Have A Good Time／ZORN feat. AKLO）

以下のように母音が揃っています。

表参道(ooeano)の(o)オープンカフェ(ounae)

も嫁さんと(ooeano)の(o)醤油ラーメン(ounaen)

「飛距離のある韻」と「文章をコードとして捉える」こと。どちらにも通じるのは、一見関係のないように思える具体的な事物の中に、構造の類似や関係性を見出すというアナロジーです。そして「書籍はソフトウェアである」「文章はコードである」という表現は、自分にとって「飛距離が遠い」、しかし一度言われてみると確かに似ていると思えるメタファーでした。

自分は WordPress を触るところからソフトウェアエンジニアとしての道を歩み始めました。WordPress の哲学の一つに“Code is Poetry”というものがあります。自分はこの一文を知ってから「コードを文章のように捉える」ことを好んでいます。

しかし、自分はこの関係性の矢印を反対方向に向けることはありませんでした。文章の一文一文をコードの一行のように、各パラグラフをコードの各ブロックのように、一つの章を一つのファイルとして考えることはなかったのです。

発表スライドに「静的/アクティブな状態（依存の有無）」という言葉が盛り込まれていて、この考え方こそが文章をソフトウェアとして捉えるキーであるように思います。

自分がソフトウェアエンジニアになってから何年も経ちました。そして今やっと「文章とはコードである」という考え方を手に入れました。自分は世界に対する見方が変わるこの瞬間が好きです。そのきっかけを与えてくれたazuさん、TS Kaigi 2025に感謝しています。

（全日を通した参加記事はまた別で書きます）

参照

• textlintで日本語の文章をチェックする

(2025/5/25追記)

コードを書くように文章を書くという視点が書かれていました。一部引用します

この辺は文章でもそうですが、プログラミングでも関数やモジュールという単位でアウトラインのように遠めに見ながら進めるタイミングと中身を見ながら進めるフェーズがあります。

技術書はif文が書きにくいコード、みたいな感じで書いていくのが感覚と近いのかもしれないですね。

なるほどなあと思いました。

TSKaigi 2025で「技術書をソフトウェア開発する」という発表をしました

mastraのいい使い方を思いついた

mastraのいい使い方を思いついたので簡単に書くことにした。アイデアの内容を紹介するよりも、アイデアが生まれた過程を書き留めておきたいと思ったので。

個人的な内容なのでサッと箇条書きで書く。

• 2024年11月にAIを協働させるというアイデアを知った
  • 「AIの女の子がわいわい競馬予想するシステムを個人展示したら倍率2000倍の馬券が当たってしまった (1)設計思想編」 という記事を読んだ
  • 「なんでも生成AI展示会」で展示したシステムとのこと
  • AIを協働させるのはなるほどと思ったが、プロンプトたくさん書くのが大変そうだな〜というのと自分で何かこれをやりたいというアイデアが思いつかず
• 2月中旬にDevelopers SummitでAIエージェントの協働を知った
  • LangChain + LangGraph を紹介したセッションがあった
  • 面白そうだけど Python だし、概念いくつかあるしややこしいな〜と思っていた（Pythonは5年前に競プロで書いた以来やってない）
• 3月頭に mastraというAIのワークフローを構築するツールがあると知った
  • LayerXの松本さんがツイートしていたので、こういうものがあるんだと知った
  • mastraはGatsbyJSを作ったチームが制作している
  • GatsbyJSは静的サイトジェネレーター（自分の前のブログはGatsbyJS製だった）だが、GraphQLがここまで流行る前から取り入れていた。今回もAIワークフローを構築するためのツールを提供して人気を得るのは、さすが先見の明があるなと思った
• 4月上旬に mastra をサンプルコードで動かしてみた
  • ローカルのチャット画面で、住んでる地域の天気を教えてくれた
  • TypeScript製で、ある出力を次の入力にすることが簡単にできるんだとわかった
  • 仕事で役立つアイデアが何か得られるかなと思ったが思いつかなかった
  • mastraを使うコード自体はAI Agentに書かせればいいなと思った

で、今日mastraのいい使い方を思いついた。

mastra の自分なりの使い方

きっかけは先週のPHPカンファレンス小田原で話したまつぴーさんのXのポスト。まつぴーさんはおいラジオをされていて、ラジオの編集にGemini使ったら楽ですよと伝えた。

https://x.com/Panda_Program/status/1913858689624379565

その後ジムに行って一汗かいてシャワーを浴びていたら、ハッと閃いた。これ、自分のラジオ の音声をブログ化するのに mastra が使えるなと。

前々から、ラジオをブログ化するのはやりたいと思っていた。しかし、プロンプトを書いたりAIが出力した記事のチェックをしたりするのが面倒だったのと、色々他にやることがあって優先順位が低かったので着手できずにいた。ラジオ音声から記事化する検証自体は終えていた。

そこで、以下の手順でワークフローを構築したらやりたいことが簡単にできると気づいた。

1. Gemini にラジオの mp3 を渡して文字起こしをさせる（音声処理はGeminiが強い。Google Drive から音声を渡せないか調べる）
2. Gemini か何かのモデルに文字起こししたものを記事にしてもらう
3. GitHubのAPIを使って、ブログのレポジトリに記事作成の PR を作ってもらう
4. これを3日おきに繰り返す

あとは自分がGitHub上でレビューするだけだ。マージしたら自分自身のコンテンツから1記事を作成できる。

まあ、ここではアイデアを出しただけ。先に記事を書いてこれが実現できるかこれから調査、検証する。なので上記の通りにはできないかもしれない。たまには気軽に記事を書くことにする。

アイデアは直線的には降ってこない。紆余曲折あるし、ある時繋がってひらめきが起きる。時には待つことも大事。

mastraって語感がmasterに似てる。マントラとかマンダラ（曼荼羅）にも似てる。マンダラは仏教の密教（真言宗）で、中心に大日如来としてその周辺に諸仏を配置する（はず）。AIエージェントの協働はマンダラ上に描かれた諸仏の連携を思い起こさせる。こうやってあるものと別のものを繋げる（イノベーションの語源は「新結合」）とサイバーパンク感もある。このテーマでChatGPT o3に画像生成してもらって筆を置くことにする。

PHPカンファレンス小田原2025に参加して

2025/4/12 開催の PHPカンファレンス小田原 2025 に一般参加しました。

去年の同カンファレンスに参加した同僚たちが「すごく楽しかった」「小田原のカンファレンスは最高だ」と教えてくれたり、「夏には小田原にキャンプに行きたい」「小田原への移住を本気で検討している」とまで言っていたので、来年は参加してみようと考えていました。

結果、2025年に自分も参加して本当によかったです！

印象に残ったセッションと交流

セッションはどれも聞き応えがありました。初登壇の方の資料は丁寧で、何度も登壇されている方の発表は本当に聞きやすく、たまに登壇する身の自分としても学ぶことがたくさんありました。

高町さんのキーノートの「OSS活動はIssueを立てるだけでも貢献になる」「自分にとって未知の領域にチャレンジすることの大切さ」というメッセージを始め、本当に良い発表が盛りだくさんでした。いくつか抜粋して感想を書きます。

• 吉田あひるさん「恣意性から考える、変更に強いモデルの作り方」
  • 吉田あひるさんのことは、当時の自分の同僚の @tenjuu さんを通じて5年以上前から知っていて「あひる焼肉」のことも聞いていたのですが、自分が行っても高度な話についていけないだろうと思って参加できずでした。ひたすら楽しそうな感じは伝わっていました
  • 直接お会いしたことがなかったので、この機会にと思ってセッションを聞きに行きました。会場で委員長のasumikanさんのお願いに従って最前列に座ったところ、隣の人が PHPerKaigi 2025 で登壇したときに自分にマイクを渡してくれた青ごへいもちさんでびっくりしました
    • しかも、その隣にはまつぴーさんが座っていました。前日の「スタイルガイド本」の読書会に参加してくれた方が「明日、弊社のまつぴーさんという方が小田原に行くそうですよ」と教えてくれていたので、まさかここで会えるとは驚きでした
    • よく「界隈は狭い」と言われますが、その界隈という人と人のネットワークの網に自分も乗った感覚（ノードになれた感覚）があり、感慨深かったです
  • 発表内容は、「ビジネスロジックは安定しており、それを書くためのドメインモデルも安定している」というあまりにも一般的な前提を「恣意性」という視点から疑ってかかるという野心的なもので、とても刺激になりました
  • 前提を当たり前に思っていた自分にとっては素晴らしい内容で、同時にこのような骨太な前提を切り崩していくような発表を自分もしたいんだよな〜と思いました。という気持ちを懇親会で直接あひるさんに伝えることができてよかったです！
    • 懇親会ではあひるさんとインターフェースやモジュラーモノリス、クソデカ集約や組織の話をしたりと、思い出に残る楽しい時間を過ごしました！
    • 自分のことも知ってくださっていて、「質の高い記事を書く人だと思っていました」と言って貰えてとても嬉しかったです
  • あひるさん、青ごへいもちさん・まつぴーさんとやられてるおいラジオ聞くので、自分と友人の問答ラジオも聞いてみてください笑
• meihei さんの「改めて学ぶ Trait の使い方」
• 前半の釣竿の例が野心的でよかったです！
  • 自分はそもそも Trait というのは現実世界には存在しない概念だと考えているのでその辺りは議論してみたいですw
  • 釣竿のリールに関しては「糸を伸ばす」「糸を巻ける」という抽象的な振る舞いが契約（インターフェース）であり、手で巻くか電動で巻くかという具体的な実装こそがトレイトなのではないかと思いました
  • ただ、この例でも「手巻き」「電動巻き」は着脱可能ではないので、そもそもインスタンスしか存在しない現実では、クラスに着脱可能な実装という例が思いつかず
• 実は meihei さんがBASEに入社されてから、半年ほど同じチームで働いていました（今は別チーム）。自分がメンター、meiheiさんがメンティーの関係です。
• Trait については meihei さんが書いたこちらの記事がとてもよくまとまっているのでぜひ
  • PHP の Trait の使いどころと、テストパターン
• SAW さんの「PHP で学ぶ OAuth 入門」
  • 初登壇とのこと。発表開始前に温かい声援が飛んでいて、やっぱりこういうカンファレンスってスピーカーと参加者の距離が近くていいよなあと実感しました
• 長谷川さんの「低レイヤを知りたいPHPerのためのCコンパイラ作成入門」
  • 内容もさることながら、発表の進め方がわかりやすいのなんの。難しい内容のはずなのに、文章のシンプルさ、コードの見やすさ、テンポの良さから脱落せずに話の筋が追えました。本当にすごいです

当日参加したセッションの資料は、改めてちゃんと読ませてもらおうと思います。スピーカーの皆さんスライドを公開してくださって感謝です。愛用の Heptabase に突っ込んでおります。

強いていえば、「BASE から5名登壇しています」に載れなかったのはちょっと悔しいような、惜しいような気がしました。プロポーザルは2つ出して両方落ちてたので、今度からはもっと皆さんに聞いてみたいと思ってもらえるようなプロポーザルを出そうと思います。今回のカンファレンスの皆さんの発表内容を見て、プロポーザルの内容自体をガラッと変えてみようと思ったのでまた次に繋げます。

小田原大合戦とカンファレンスの温かい空気

ただ、小田原大合戦は2位だったのでよしです。めっちゃ嬉しいです。かまぼこ楽しみです！

同じチームだったおぎさんとは PHPerKaigi 2025 で初めて知り合った方です。まさか同じグループになるとは驚き。すごい確率。DI”Y”Container の登壇もとてもよかったです！しかももう一人はペチコン新潟の運営の方 akshimoさんで、おぎさんはペチコン新潟に登壇するそう。これもすごい偶然です。

今回のPHPカンファレンス小田原2025では、カンファレンスって本当にいいなと思った光景がいくつもありました。

• 高町さんのキーノートで「なんとかなる」精神が身についたという話で、OSS貢献にチャレンジすることを会場のみんなに後押ししていたところ
• ひがきさんの発表後の Ask the Speaker で、武田さんが巨大テーブルに対するテクニック（単一テーブル継承、STI）を「こういうときはこういうやり方があるんだよ」と笑顔で伝えていて、ひがきさんが「おお！やばいっす、脳汁出まくってます」と感謝していたところ（周りで聞いていた人たちも笑顔になりました）
• 懇親会でことみんさんが、meihei さんの後輩にカンファレンスで登壇することを熱く勧める
  • 大学の部活で上回生やOB、OGが悩める現役を励ます姿と重なって微笑ましかったです
• PHPerKaigi 主催者の長谷川さんからカンファレンスの美しさを学んだ という asumikan さんが、小田原大合戦という一大企画で長谷川さんを唸らせていたところ
  • あとでXを見たところ、武田さんも言及されていました

誰かが誰かの後押しをする、応援する、これが自然にできている。小田原大合戦のクロスワードにFlameという回答がありましたが、まさに人から人に伝わる情熱の炎だと思います。見返りを求めずに、与え合う。与えられた人は持ち帰って、また別の人に伝える、与える。与えるのは有益な情報だけではなく、人が誰かに何かを伝えるその熱意も伝播する。カンファレンスの美しさもさることながら、まさに人間の美しさだと思いました。これこそが人間性なんだと言いたくなるような。

カンファレンスに現地で参加する意義と楽しさがはっきりわかる。家でスライドを読んでいるだけだとこの熱気は絶対に味わえません。

委員長のasumikanさんを始め、スタッフの方々、スピーカーの方々、スポンサーの方々のおかげで参加者として楽しむことができました。

前日に少人数の読書会をしていたのですが、それでも日常業務をする中でする準備が大変で、会場の机を移動したりモニターの準備をしながら「4,5人の勉強会でも大変なのに、100人を超える規模のカンファレンスの準備、当日のオペレーションってどれだけ大変なんだろう。本当に運営の方々に頭があがらない」と痛感していました。

運営への感謝と、伝説となったカンファレンス

来年の開催はないとのことで残念ではありますが、今回参加した人たちは「ペチコン小田原はよかった」と口にすることと思います。数年経っても、当時の参加者たちが「あのカンファレンスはよかった」とまだ見ぬ若い人たちに伝える姿が想像できます。

知る人ぞ知る伝説のカンファレンスになったのではないでしょうか。その伝説の一コマに参加できたことを嬉しく思います。「ペチコン小田原は〜」と誰かが笑顔で話すとき、きっと梅丸もスマイルまーるまるで喜んでくれることでしょう。

PHPerKaigi 2025 にプロポーザルを出しました

同僚が実行委員長を務めた PHP Coference Japan 2024の参加熱が未だ冷めやらぬ昨年末、「来年は登壇や発信をがんばろう」とPHPerKaigi 2025にプロポーザルを出しました。プロポーザルを提出するにあたり、一番腰が重い部分は文章の作成です。

そこでまず、ChatGPT上にカンファレンス用のプロポーザルを作成するプライベートなGPTsを作りました。AIに手伝ってもらい、自分が話したいこと、話せそうなことについて3つのプロポーザルを出しました。

• オブジェクト指向を活かす！React入門
• 毎週進化するスクラムチームの作り方: スプリントゴールと振り返り編
• 「オブジェクト設計スタイルガイド」に学ぶ、モダンなオブジェクト指向のベストプラクティス

全部落ちました。すまん、ChatGPT。お前の消費した電力は無駄だった…。終わり。第三部完。

ではなくて、さすがに去年のPHP Conferenceのプロポーザルも全部通らず、こちらも通らないではどうにも居心地が悪くてですね、しかもプロポーザルの2次募集があるということではないですか。ということでやってしまいました。

モジュラーモノリスでスケーラブルなシステムを設計・開発する

テーマ、デカいって…。

今までの勉強会での発表内容やプロポーザルは「自分が話したいこと、話せそうなこと」を出してたんですよ。でも、会社としてもモジュラーモノリスで開発してることは発信しないといけないとずっと思ってて、でもそれをする中心人物たるアーキテクトがそれをする暇がないんですね。「あー俺時間ないわ」という地獄のミサワならいざ知らず、多忙で本当に時間がない人の「時間が足りません」という言葉は重いんですよ。

以前「弊社がレガシーコードだけで開発してると思われてるかもしれないので、開発者の間のイメージを新しくしたいんですよ」とアーキテクトに話したら「サポートするのでどんどんやってください」とのことだったので、自分も新しいトライだと、停滞は衰退の始まりだということでこういう重厚なテーマに挑戦することになりました。

そこで話せそうな素材をChatGPTに突っ込んで、プロポーザルとしてしっかりした形に仕上げてもらいました。ちょっと長いですが引用します（飛ばしてもらってもいいです）。

モジュラーモノリスは近年、マイクロサービスの代替として注目を集めています。このトークでは前半で設計の話を、後半で開発の話をします。

私が所属するBASE社では10年以上モノリシックなサービスでの開発が続いていましたが、デプロイ時間の増加や依存関係の複雑さにより機能提供のスピードに課題が出てきました。その課題を解決するためにモジュラーモノリスの新システムへの移行が始まって丸4年が経過しました。

本トークでは、モジュラーモノリスの基本的な設計概念から、その実現する方法論、また実践例について解説します。モジュールはコアドメインとサブドメインの考え方に基づいて区切られており、各モジュールの中ではアプリケーション層とドメイン層が分かれており、UnitOfWork での永続化管理やドメインイベントを用いた実装が可能になっています。

また、モジュラーモノリスを選択した際の利点とトレードオフについても議論します。具体的には、テストのしやすさ、デプロイの単純化、チーム間のコミュニケーションの向上など、エンジニアリング全体に与える影響を掘り下げます。メリットは多くありますが、それでも生じる課題についても触れていきます。

このトークを通じて、モジュラーモノリスというアーキテクチャの現実的な価値を理解し、チームやプロジェクトの規模に適したアプローチを選ぶための指針を得られれば幸いです。

しっかりしすぎじゃね？これ自分の能力超えてるわ…と思いながらプロポーザルを提出。採択されたら大変なのは目に見えてるし、採択されなくてもうーん、というダブルバインドを抱えながら日々を過ごしていたところ、ある朝メールボックスを開くと1通のメールが目に止まりました。

「PHPerKaigi 2025: トーク採択のお知らせ」

おはぎゃあ というわけで、カンファレンス登壇駆動の発表準備と相成りました。

PHPerKaigi 2025 の登壇資料を作りました

1月7日に採択メールをいただきまして、2ヶ月以上もあれば準備に十分時間があると思ったのも束の間、もう登壇１週間半前となりました。なんで？現実がタイムリープものだからです。

まあもちろん何もやってなかったわけではないんですよ。社内で大きめのプロジェクトに携わるようになった一方、1月は永平寺に行って座禅組んだり、雪の白川郷に行ってなぜか韓国人男性と友達になったり、同僚と伊東の貸切宿へ青春旅行をしたりと忙しかったんです。

じゃあ2月はというと、CodeZine様の連載記事を入稿したり（お仕事ありがたい…）、Developers Summit 2025で登壇させてもらったり（ありがたや…）、『オブジェクト設計スタイルガイド』の読書会を開かせてもらったり（ありがたい…）と忙しかったんです。

3月はTOEIC受けたり（スコアは925でした）、おくださんとラジオ収録して音声編集したり（最近はGeminiで少し楽できてます）、春休み中の弟に懇願されて困った親に自分が懇願されて、中国は重慶への4泊5日の弟との二人旅を企画、予約、手配、あれこれと忙しかったんです。…あれ？ぼくの時間、どこ…。

1月にプロポーザルが採択された時点で、弊社のアーキテクトには「骨太な内容になるので早めに目次作って送ります！」とSlack で DM してたんです。で、2月になって「まだできてないです、すみません」と詫びを入れ、3月頭になって「今週作って送ります」と書いたら社内プロジェクトが忙しくなり送れず、さすがに焦りました。言い訳してもいいわけないんだけどね…。

そして忘れもしない3月12日水曜日。重慶に出発するために有給を取っていた日の午前中に、（本当に）泣きそうになりながら「まだ何もできてなくて、登壇日は再来週の日曜日なんです…。」と午前中に Slack でアーキテクトに DM したら、「今からハドルしますか？」と言ってもらえて、Figjam上で「話したいことはなんですか？」と自分がその時考えていたことを整理してもらい、「ではこういうことを盛り込みましょう」と内容のアドバイスを貰いました（重要な箇所のスライドの文言も考えてもらえました…）。最後の方に言われた「ちなみに、私は登壇の時は準備に2ヶ月かけています」というお言葉は心に沁みました…。

（さすがにアーキテクトに迷惑と心配をかけてしまったことと、ここまで登壇などの関連で切羽詰まったのは本当に初めてだったのでかなり後悔しました。そもそもなぜ自分で旅行日を決められたのに、PHPerKaigiの登壇が終わってからの3月最終週にしなかったのかが本当に謎で、妻に「タイムスリップして戻りたい」と旅行の出発日に3回言ってました。キュアップラパパと魔法の言葉を言っても時間だけはどうしようもない…。）

出発日の午後、実家から新幹線に乗ってきた弟に会ったときに、自分が引きつった顔で「行きの飛行機の中で仕事するわ…」と言ったのを覚えています。ただ、その飛行機の中で、アーキテクトの作った2年前のスライド「BASE大規模リアーキテクチャリング」を、自分の新しい相棒の Heptabase 上でひたすら読み解いていたら、なるほどこういうことだったのかと理解し、光明が見えました。

ここでまとめたカードをそのままスライドに採用しました。80枚以上あるスライドの要約はこれだと言い切るのはかなりドキドキしましたが、帰国後にアーキテクトから「だいたいあってる」とお墨付きをもらい、レビューでの指摘もなかったので Heptabase のおかげだと思いました。

アーキテクトの作成したスライドをまとめていた行きの飛行機の中で「これは行ける」と確信を持ったため、現地到着時点で気分は晴れやかに。頭を完全に旅行に切り替えられました。Heptabase はマジ神ツールです。絶対ブログ記事書きます。

最終的に、中国旅行の3日目、電車に揺られてぼーっとしている時に、ふと「この構成にすれば筋の通ったストーリーになる！」と閃きました。それが今の章立てです。3月17日の日曜日夜に無事帰国し、その後はひたすらスライドを埋める作業をしていました（なお、弟との旅行中は毎日旅行記を書いていて、帰国後に数えたら4万字になってたのでどこかで公開したいとは思ってます）。

登壇前々日の金曜日にアーキテクトにスライドを見てもらって、レビューコメントの対応をしつつ、登壇の練習をしました。良い子は真似しないでね、どころか自分も今後もう体験したくはない過密スケジュールでした。

PHPerKaigi 2025 に参加しました

PHPerKaigi 2025は中野セントラルパークカンファレンスで開催されました。金曜日が day0 で、同僚がコードゴルフのバトルに出て準々決勝まで勝ち進んでました（すごい、お疲れさまです！）。土曜日は day1 で、自分はこの日から現地で参加しました（ビールの銘柄がバドワイザーだったので推し漫画だったアンデッド・アンラックを思い出しました。アンディ…）。

当日は会場の熱気もすごく、たくさんの人で賑わっていました。休憩スペースでは軽食が出されていたり、ペットボトルのドリンクが無料配布されていたり、ビールも飲めたりとすごいな〜と思いました。

気になっていたセッションに参加したり、現地に来ていた同僚と話したり、PHPコミュニティに参加している前職の元同僚と久闊を叙したり、Capiさんにおぎさんを紹介してもらって話したり、翌日の登壇スライドに関してアーキテクトからリアルタイムのレビューを受けたりしていました。

当日参加したセッションは以下です。感想は別の記事に書きますね（会社の参加ブログの方で書きます）。

• PHPでアクターモデルを活用したSagaパターンの実践法
• プロダクトコードとOSSに学ぶ例外処理の選択肢 — キャッチするのか、投げっぱなしにするのか
• ソフトウェア開発におけるインターフェイスという考え方
• 再演: The PHPer’s Guide to Daemon Crafting, Taming and Summoning

会場の皆さんの熱量を感じて、自分も発表内容をしっかり伝えたいと意気込みを新たにして帰宅しました。

PHPerKaigi 2025 で登壇しました

モジュラーモノリスでスケーラブルなシステムを設計・開発するというタイトルで、Track Bで登壇しました。

青ごへいもち さんにマイクを手渡してもらって、「2019年のイベント「大改修！PHPレガシーコードビフォーアフター」 で登壇されていた、あの青ごへいもちさんだ…」と内心思っていました。同僚の02さん もスタッフとして自分のセッションを担当してくださっていたので安心しました。

朝一の10:30からの早い時間の発表だったので（10:30って早いですよね？）、人が来てくれるか少し不安だったのですが、話している間にだんだん入ってきてくださって、最終的にはありがたいことに満席になっていたようです。

40分枠の登壇で、モジュラーモノリスの話をするために伝えなければならないことを前半と中盤に盛り込んでいました。しかし、皆さんに面白いと思ってもらえそうだなと思う内容がどうしても後半から終盤、時間にして30分経ったあたりからだったので、そこに行くまでに飽きないようにする工夫がいるよなあと話しながら考えていました。今度から何か工夫します。

内容としては、モノリス、マイクロサービス、モジュラーモノリスの変遷という歴史の一般的な話、BASEのリアーキテクチャがなぜ実施され、何を目指し、なぜモジュラーモノリスを採用したのかというコンテキストの話を前提として盛り込みました。

その後、モジュラーモノリスの基盤部分の技術的な話、各モジュール内の特徴や開発チームの話、最後に4年前から続くBASEのリアーキテクチャの狙いは今どういう評価なのか、開発組織の観点からお話ししました。

登壇後の Ask the Speaker でも色々なご質問をいただき（最終的に1時間くらい話し込んでました）、BASEのアーキテクト本人も来てくれて深い話をしてくれるなど、自分にとっても学びのある時間となりました。そのままその場にいたBASEのアーキテクト、toshioさんとebinaさんの4人でランチに行きました。

day2 は以下のセッションに参加しました

• パスキーでのログインを実装してみよう！
• PHP8.4におけるJITフレームワークIRと中間表現について理解を深める
• IRT「何が綺麗なコードなのか」（出張ぺちパーティナイト、アンカンファレンス）
• LT大会

懇親会ではインターフェースのお話で登壇された@k1LoWさんや「スタイルガイド本の勉強会に参加しました」と言ってくださったrikuto さんとお話したり、大阪から来られた方が社内で改善活動を頑張っているという話を伺ったり、ななうぇぶさんから鋭い質問を頂いたり（「私、モジュラーモノリス2回作ったことあるんです」と伺ってびっくりしました）、色々な方と話せて充実した一日となりました。

個人的なことですが、大学の時からずっとパーティ形式の懇親会に苦手意識があります。ただ、PHPerKaigi の懇親会は本当に皆さんフランクで温かい空気だったので安心感がありました。自分からももっと色々な方に質問して話しかけたらよかったな〜と思ったのと、もう人見知りとか言ってる場合でもないのでぜひどこかでトライしてパーティ形式の苦手意識を払拭したいなと思いました。

懇親会後、同僚と集合写真を撮って解散しました。みんな笑顔でいい写真でした！

PHPerKaigi 2025 を楽しみました！

PHPerKaigi 2025、とても楽しかったです！

実は PHPerKaigi の登壇は2022年以来2回目だったのですが、前回は引越しも重なり、自宅からアンカンファレンスでの登壇でした。

また、2018年に自分が転職してエンジニアになった時に、先輩から「PHPerKaigiという技術カンファレンスがあって、あそこに参加するのはPHPを使う人たちの中でもすごい人たちなんだ」と教えてもらった記憶が残っていたため、PHPerKaigi 初の現地参加は自分にとって特に感慨深いものとなりました。すごい人たちがいっぱいいるので自分はまだまだですが…笑

クロージングで長谷川さんが「スピーカーのみなさんとスポンサーのみなさん、そして参加者のみなさんのおかげでこのイベントがある」と仰っていましたが、いちスピーカーとしてはまず以てオーガナイザーの長谷川さんをはじめ、カンファレンスのスタッフのみなさんへの感謝があります。

参加者の方が集まれる場、登壇する場を用意してくださる方々のおかげで登壇という機会を貰えますし、PHPコミュニティの盛り上がりが肌で感じられます。また話を聞いてくださる方のおかげで、登壇、発信が成り立っているのだと改めて思いました。スタッフの方々、参加者のみなさん、本当にありがとうございました。

くぅ～疲れましたw これにて私のPHPerKaigi 2025 参加記事は完結です！驚いたことに自分のセッションの登壇中、中盤ごろに息切れしはじめたので、今年の残りは週一くらいでジムに行こうと思います。

次は4月のPHP Conference 小田原に参加します！またお会いしましょうノシ

はじめに

昨年末にこんなツイートをしたら、ちょっとバズってしまいました。aaa

https://x.com/Panda_Program/status/1864333831886786971

色々コメントを頂くことで考えを深めてブログを書きますと言っていて、まだ着手していなかったのでざっと書くことにします。ただ、今日はクリーンアーキテクチャが対象です。

簡単に自己紹介をすると、私は現職でフルスタックエンジニアをしています。また、「バックエンドのためのフロントエンド入門」 というテーマで登壇をしたり、自分のエンジニア人生を変えた書籍リストにクリーンアーキテクチャを挙げており、TypeScript でクリーンアーキテクチャを実践する という記事では Web からでも CLI からでも動かせるアプリケーションを作ったことを記事にしています。

このためバックエンドの考え方とフロントエンドの考え方はある程度理解していると思います。

結論

さて、結論から書くと、クリーンアーキテクチャとフロントエンドの関係は以下です。

• クリーンアーキテクチャは、ソフトウェアの中で変わりやすく重要でない部分と変わりにくい重要な部分を、オブジェクト指向プログラミングの機能を使ってオニオン型のレイヤーで分けようというアプローチ
• クリーンアーキテクチャでは、フロントエンド（UI）やフレームワーク、Web、CLI といった外部と、ビジネスルールを表現する内部を分離、独立させることが重要と説いている
• モダンフロントエンドは、HTML/CSS/JS をセットにした小さいコンポーネントを組み合わせた UI 管理のためのフレームワークを使って、単方向なデータフローでスケーラブルなアプリケーションを作るというアプローチ

両者を比較するだけでも、UI 構築を主戦場とするフロントエンドにクリーンアーキテクチャを持ち込むという発想自体がナンセンスであることがわかります。

クリーンアークテクチャと UI ライブラリ React の定義を比較する

さらに、React 公式ドキュメントは React 自身を以下のように定義しています。

The library for web and native user interfaces

ウェブとネイティブのユーザーインターフェース（UI）のためのライブラリ

そしてこちらはボブおじさんの記事 The Clean Architecture から引用です。

Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.

UI から独立していること。UI はシステムの他の部分を変更することなく容易に変更可能です。例えば、ビジネスルールを変更することなく、Web UI をコンソール UI に置き換えることができます。

両者を合わせると、ボブおじさんがいうクリーンアーキテクチャは、ウェブでもネイティブアプリでもそれ以外でも、UI に左右されないビジネスルールを UI やフレームワークから独立させることが主眼です。繰り返しになりますが、フロントエンドにクリーンアーキテクチャを持ち込むとは、そもそも無理筋な発想なのです。

しかし、ビジネスルールがフロントエンドにもあるのではないか、もしそうであればクリーンアーキテクチャを適用することは理にかなっているとも考えられると思います。そこで、フロントエンドにビジネスルールがあるかを次に検討します。

なお、ビジネスルール、ビジネスロジックとはソフトウェア上で業務ルールを表現し、データの整合性を保つためのロジックとここでは定義します。

ビジネスルールは React などの UI フレームワーク側にはない

クリーンアーキテクチャの記事の中では View も Presenter も詳細（details）とされており、また書籍では Humble Object として紹介され、守るべきビジネスルールとは区別されます。

ではフロントエンドにビジネスルールはないと言えるのでしょうか。これこそ本質に迫る問いであり、もしフロントエンドにビジネスルールがあれば、それは UI やデータベースから独立させるべきものとなり、クリーンアーキテクチャを適用することも考えられると思います。

まずフロントエンドの役割を見ると、以下の 3 つに分けられます。

• 状態管理
• イベントハンドラ
• プレゼンテーションロジック

一つずつ見ていきましょう。

状態管理

状態管理をするのにも React 周りで変遷があります。React 公式が提供している状態管理の方法以外にも、各種ライブラリが独自の状態管理の方法を提供しています。

• クラスコンポーネントの setState
• Redux
• useState
• XState
• Recoil / Jotai / Zustand etc.

最近 Recoil がアーカイブされ、他の状態管理ライブラリに乗り換えたという話を聞きます。このような変更の影響を受けずに独立させたい、何なら Vue でも Svelte でも他のフレームワーク上でも同じように使いまわしたいロジックがあれば、それはビジネスルールである可能性があります。

ただし、UI ライブラリは状態管理をパーツの表示制御など UI のために使われることが一般的であり、その場合はビジネスルールではなく単に UI 管理のためのロジックであると思います。

イベントハンドラの中のロジックも同様だと思われます。イベントはユーザーがブラウザ上やスマホの画面上で起こす、クリックやドラッグアンドドロップ、タップやスワイプといったあくまでも機械的な操作イベントです。これらのイベントに応じて発火するロジックは、業務ルールとそれに付随するイベント（ドメインイベント）とそのリスナーのロジックとは別物として考えると良いだろうと思います。

プレゼンテーションロジック

React 以外の各種 UI ライブラリでも同様に使いまわせるロジックがビジネスルールの可能性があると上記で書きました。しかし、そのほとんどがプレゼンテーションロジックに分類されると思います。

プレゼンテーションロジックは以下のようなものです。

• 相対的な日時での表示（ex. 1 ヶ月前）
• 文字の省略表示（ex. 80 文字以上なら … で省略する）
• フォームのバリデーションエラーの表示
• ログインしていない場合は記事の本文は途中までしか読めない（状態管理+表示） etc.

他にもバリデーションのロジックは一見ビジネスルールのように思われます。しかし、フロントエンドでフォームのバリデーションをするのはエラーメッセージを表示したいという UI 管理に直結した要求があるからです。

フロントエンドでバリデーションを書いた上で API サーバーのバックエンドでも、同じバリデーションを書くことがある理由は目的が異なるからです。前者は UI 管理のため、後者はデータの整合性を保つためです。

また、現代ではフロントとバックエンドは密結合ですが、Web API とは本来どのようなクライアントからでもコールされる可能性があります。ここまで考えると「フロントエンドでバリデーションをしているから、バックエンドでは不要」というアイデアは簡単に捨てられるでしょう。

データフェッチの方法

データフェッチの方法にも触れると、React とその周辺ライブラリだけでも以下のように変遷しています。

• componentDidMount
• useEffect
• SWR / React Router
• Relay / Apollo Client
• Server Component

Next.js でもデータフェッチの方法はダイナミックに変わってきました。

これらのデータ取得の変更の影響を最小限にするために、データフェッチのためのレイヤーを設けることが一般的です。fetcher には JSON からコンポーネントで使いたいデータを抜き出すデータマッピングの役割を持たせることもあります。

しかし、それは単なる 1 レイヤーであり、データマッピングのロジックもデータフェッチや例外に関するロジックもビジネスロジックではないことは明らかです。

よって、これまで見てきた「状態管理」「イベントハンドラ」「プレゼンテーションロジック」「データフェッチ」のどこにもビジネスルールはないと思われます。

ただし、ビジネスルールがフロントに存在するケースはあるはず

ただ、フロントエンドにはビジネスルールが全くないとまで言えないのではないかとも思います。

例えば、Supabase では API のスキーマがそのままデータベースのスキーマになっています。例えば、あるエンドポイントに POST リクエストで JSON を送ると、その JSON はそのままテーブルに 1 レコードとして挿入されます。このように API とデータベースを近づけたサービスでは、ビジネスルールもフロント側に存在するのでしょう。

なお、ブラウザゲームやデザインツールの Canva、Web サイト構築ツールの Studio ような、フロントエンドこそがビジネスの競争力だというソフトウェアであれば、上記の議論は当てはまらないだろうとも思います。

この項の見出しは「ビジネスルールは React などの UI フレームワーク側にはない」というものですが、素の JS/TS にはそれが存在する可能性があります。ただ、筆者の経験が乏しくこの辺りは詳しく語れません。この点は今後の課題です。

クリーンアーキテクチャとフロントエンドの時代背景

さて、クリーンアーキテクチャが提唱された時代とフロントエンドの歴史、当時の時代背景に少し触れてみましょう。

私は歴史が好きです。旅行では歴史的な史跡や歴史博物館を回ることが趣味です。歴史を知ることは現代に対する多角的な視点を手にいれ、今をよりよく理解することに繋がるからです。

まず、クリーンアーキテクチャがボブおじさんのブログで発表されたのは 2012 年です。当時、自分はまだソフトウェアエンジニアではなかったので時代を測るしかないのですが、この時は Rails をはじめとした MVC フレームワーク隆盛期です。

2010 年に Rails のバージョン 3 が公開されたり、2011 年に CakePHP の 2.0 が公開されたりと、Rails に影響された様々な MVC フレームワークが生まれ、育ち始めた時期です。この当時はどのスタートアップも Rails Way に乗ってスピード感のある開発をしていたのだろうと思います。

MVC フレームワークの強い影響はフロントエンドにも及びます。当時のフロントエンドの状況を見ると、Backbone.js, Angular.js, Ember.js などの MV＊フームワークが登場したとのことです（参照: React 研修（2024））。

MV＊フレームワークとは、バックエンドの MVC フレームワークに触発されてフロントで MVC, MVP, MVVM といった構造を持ち込むことで、フロントエンドに秩序をもたらそうというものです。しかし、現代では非 MV＊フレームワークである React が主流であるため、この取り組みは時代から選ばれなかったことがわかります。

バックエンドに MVC フレームワークを取り入れたスタートアップはビジネスが拡大し、Fat Controller や Fat Model を生み出すのはまだ先の話です。このような時代背景の中で、ビジネスルールをフレームワークから独立させよというボブおじさんの主張には先見の明があったと言えるでしょう。

最後に

ソフトウェアエンジニア 3 年目あたりでクリーンアーキテクチャ本を読んだ時と、その後頻繁なプログラミング言語やフレームワーク、ライブラリのバージョンアップを間近で見ている今だと、重要なビジネスロジックを外部の変更から守ることの重要性に対する実感は全く異なります。そして 10 年以上フロントエンドで最前線を張っている弊社のテックリード曰く、「フロントエンドは全部置き換えられるから、ちゃんと作ったとしても結局は書き捨てに近い（だから適当に作っていいということではないけど、後生大事に守るという態度も違う）」とのことでした。

バックエンドで書かれたコードは 10 年前のコードであっても基礎に近いほど当時と同じコードで動いています。しかし、フロントエンドで 10 年前に書かれたコードが今もあるでしょうか。フロントエンドは JavaScript/TypeScript の進化、エコシステムの発展、デザイン刷新プロジェクトと、バックエンドよりも変更に対する力が強く、カジュアルに変更されます。ビジネスルールは変わりにくいが、フロントエンドは変わりやすいのです。

さて、先週ある方から、2/28 開催の勉強会で t-wada さんがこのテーマで発表をされると聞きました。年末から放置していた自分の宿題を片付けることと、記事を先に出してから和田さんの発表を見ることで答え合わせをしたいと思って、臆見を記すことにしました（念のためですが、ビーフとかでは全くありません）。

勉強会の空き枠はまだありますので、ぜひオンラインでも参加してみてください。

（3/1 追記） t-wada さんの発表は YouTube 上でアーカイブされています。ぜひこご覧ください。JSConf.jp おかわり Node 学園 46 時限目