2025/03/25

Laravel Podcast Season7 Episode 3 - 前編

Matt Stauffer(Tighten CEO) x Joe Tannenbaum(Laravel オープンソースチーム エンジニアリード)

https://www.youtube.com/watch?v=3xaMOzUN3fQ

Intro

Matt)
やあ、Laravel Podcast シーズン7へようこそ！ホストの Matt Stauffer（Tighten の CEO）です。このシーズンでは、毎回 Laravel チームの誰かをゲストに迎えて話していくよ。

今日は、Laravel のオープンソースチームのエンジニアリングリード、Joe Tannenbaum に来てもらってる。
Joe、ちょっと自己紹介と Laravel でどんな役割をしてるか教えてもらってもいい？

Joeの自己紹介とLaravelでの役割

Joe)
もちろん。名前は Joe Tannenbaum、Laravel のオープンソース担当エンジニアリングチームのリードをやってるよ。
ふだんは、リポジトリが最新の状態になってるかチェックしたり、PR（Pull Request）の対応、issue の整理、あとはパッケージとかプロジェクトに追加したい新機能の開発にも関わってる感じかな。

Matt)
言ってなかったんだけど、ちょっと聞いてみたいことがあってさ。
実は僕、Valet を昔けっこうメンテしてたんだよね。最近は Herd の方に注目が集まっているから、前ほどじゃないんだけどさ。まあ、それはそれでいいんだけど。

ある時 Taylor が「うちのチームで issue や PR 見てくれる人がいるよ」って言ってて。
それでちょっと気になったんだけど、今ってそういうメンテナンス周りって、どのくらい Joe のチームがやってて、Taylor はどれくらい関わってるの？

Joe)
メインフレームワークに関しては、Taylor がいまだにがっつり関わってて、PR に関してはほぼ全部彼が最終判断してるって感じ。

それ以外の部分については、うちに Mior っていう仲間がいて、彼が issue のトリアージ（優先順位付け）を担当してくれてる。彼が数字を見たり、全体のバランスがちゃんと取れてるか確認してくれてて、めちゃくちゃ大事な役割を担ってる。

で、うちのチームも PR のレビューや issue の対応をできる限りやってるけど、Taylor は本当にアクティブで、もう引きはがせないんじゃないかって感じ。
むしろ Taylor はオープンソースチームの中心メンバーだよって言ってもいいくらいだね笑

Matt)
それ、めっちゃ納得だし、正直みんなそうあってほしいって思ってるよね。Taylor にはできる限り関わっててほしいって。

Joe)
ほんとそれ。みんなそう願ってると思うよ。

Joeのバックグラウンド

Matt)
さて、Laravel の話に入る前に、Joe 自身についてもうちょっと教えてほしいな。どこ出身で、プログラミングとの出会いは？そして Laravel に関わるようになった流れとかも含めて。

Joe)
うん、たぶん僕の経歴はけっこう変わってる方だと思う。

出身はニューヨーク州の北部にある Oneonta（オニオンタ）っていう小さな町で、大学が2つあるんだけど、それらが学期中だけ人口が倍になるくらいの小さな町なんだよね。
自然も多くて、ちょっとアートっぽい雰囲気もある町で、僕はめちゃくちゃ気に入ってる。「丘の街」って呼ばれてるくらい、緑と坂がいっぱいあるんだ。

子どもの頃は、めちゃくちゃアート寄りで、演劇やったり、ダンスやったり、あらゆることをやってた。…歌だけは除いて（笑）。自分では歌えると思ってたけど、実はまったくダメだったんだ。今ちょっと練習中だけどね（笑）。

で、うちの父がかなりテクノロジー好きで、もともとはプログラマーを目指してたんだよ。でも「一日中スクリーンに向かってるの無理」って気づいて医療の道に進んだ人なんだけど、プログラミングへの興味はずっと持ってたから、趣味でちょこちょこコード書いてたのね。
それに僕も引き込まれて、気づいたら一緒に HTML とか CSS、JavaScript とか触ってたんだ。

インターネットがまだ「赤ちゃん」だった1990年代中盤に HTML と CSS 学んでて。

Matt)
「CSS？え、HTMLのstyle 属性に直接書くだけじゃなくていいの!?」みたいな時代だよね？（笑）

Joe)
そうそう（笑）。
AngelFire とか GeoCities 覚えてる？

Matt)
GeoCities！！覚えてるよ！（笑）

Joe)
そう。AngelFileにいる人達にちょっとしたWebサイト作っててさ。「ちょっとコードいじればもっと自由にできる」って気づいて、その当時はCSSってそんなに重要視されてなかったから、JavaScript とか HTML タグを独学で学んでた。

それで次は「動的なサイト」を作りたくなって、PHP に出会ったって流れ。
当時 WordPress があったかどうかも覚えてないけど、自作で簡単なミニフレームワークみたいなものを書いてた。

で、大学では演技を専攻して BFA（芸術学士）を取って、今は「開発者っぽく演じてるだけの俳優」って自称したりするんだけど（笑）。

Matt)
（笑）

Joe)
でも大学でのアルバイトが劇場学科のウェブサイト制作で、そこでプログラミングの実務に関わるようになったんだ。卒業後、友達はみんな飲食店でバイトしてたけど、僕はフリーランスのウェブ開発をやってた。
そっちの方が自由効くし、時間も少なくて済んで、わりと稼げたんだよね。まぁ、友達の中には有名レストランでめちゃくちゃ稼いでた人もいたけど（笑）。
でも、大体はフリーランスのウェブ開発のおかげでバイトの時間も少なく済んだって感じだと思う。

で、ある時「あ、たぶん演技は長期的にやっていけないな」って思って、本格的にウェブ開発の道に進んだって感じ。完全に独学でここまで来たよ。
たまにコースは受講してみたりするけど、CS(コンピューターサイエンス)の学位は持っていないし、独学なんだ。

Matt)
なるほどね、最近友達と話してたんだけど、「業界っていろんなフェーズを経て発展してくよね」っていう話をしてて。

最初のフェーズは「ブルースカイ」な時代。何もかもが未開拓で、「この問題解ける人すごい！」って感じの時代。
でもそれがだんだん成熟してくると、昔からいた人たちが「グレイビアード（長老）」になって、経験だけで一目置かれるようになる。僕も「CSSが登場したときから触ってたし、WordPressができる前からPHP書いてた」ってだけで、気づいたらグレイビアード(長老)になってた（笑）。
実際にヒゲに白髪もあるけどね！
でもただ基本的には起きていたことを見ていただけなんだよね。

Joe)
昔はCS(コンピューターサイエンス)の学位がないってことに引け目を感じてて、毎回「自分の価値を証明しなきゃ」って思ってた。でも今は逆にそれが強みになってる気がする。
もちろん、めちゃくちゃ技術的な話になると「ん？」ってなることもあるけど、「あーこれってこういうことだよね」って変換できるくらいの理解はある。

それに、演技を学んできたことが今の自分の武器になってると思ってて、人とのコミュニケーションや空気を読む力がめちゃくちゃ活きてる。
僕のポケットに入っているちょっとしたトリックみたいなね。（笑）。

Matt)
めっちゃわかる！僕も大学で英文学を学んでたんだけど、要は「人を理解する」「コミュニケーションを取る」っていうスキルは共通だもんね。技術的なところはあとからなんとかなるし。

Joe)
うん。ほんとそう思うよ。

JoeがLaravelにジョインした経緯

Matt)
で、そこから Laravel チームに入るまでの流れってどうだったの？
SNSとかで徐々に注目されていった感じ？それとも、ある日突然連絡が来た感じ？

Joe)
うーん、「徐々に、でも一気に来た」って感じかな（笑）。

Web 業界で働き出してからは10年近くになるんだけど、その間フルタイムで働いた時期もあれば、フリーランスもあったし、いろいろやってた。
SNSではちょこちょこ見てたけど、自分から発信するタイプじゃなかった。いわゆる「ROM専（読むだけ）」ってやつで、コミュニティにがっつり入ってたわけじゃなかったんだよね。

でもある時、「もっと開発者仲間と技術の話がしたい」「誰かと意見交換したい」って気持ちが強くなってSNSで投稿を始めたんだ。

ちょうど Terminal スクリプトにめっちゃハマってた頃で、JavaScript の clack（プロンプトを作るライブラリ）が超カッコよくて、「これ Laravel に欲しいやつだわ！」ってなって。
だから「じゃあ PHP で clack 作っちゃおう」って思って、進捗を Twitterに投稿してたんだよね。

そしたら突然、170人フォロワーがいない僕にTaylor から DM が来たんだ。「やあ、君がやってること、すごく面白いね。実は、こっちでも似たようなことやってるんだ。でも君の方向性もいい感じだから、そのまま進めていいと思うよ！」って。

もうさ、正直ビビったよ。「え？Taylor Otwell？本人から？うそでしょ？」みたいな（笑）。

それがキッカケで生まれたのが、Laravel Prompts だった。

で、Prompts を公開したあとも、自分でいろいろターミナルの実験をしてて、それが意外と好評だったんだよね。

そうこうしてるうちに、Taylor とのやりとりも増えていって、「もし Laravel チームで人を募集することがあれば、僕を雇ってくれない？」って自分から言ったんだ。
こんなこと言うタイプじゃないんだけど、当時は就職市場も厳しくて、「もし他の誰かの下で働くなら、Laravel チームしかない！」って思ってたから。

だから思い切って言った。「やりたいことはこれだし、言ってみるしかない」って。

そして、今ここにいるってわけ。

Laravelにジョインしてからの業務

Matt)
すごいなぁ！で、Laravel チームに入って最初のプロジェクトって何だったの？最初からオープンソース関連だったの？

Joe)
実はね、最初は「Laravel Cloud」をやる予定だったんだ。
だから「何でもやります！投げ込んでください！」って感じだったんだけど、初日に「やっぱオープンソース担当でよろしく！」って言われて（笑）
「了解！やりましょう！」って感じでスタートした。

「PHP 開発者として Laravel に雇われたのに、入社してからTypeScript しか書いていない」っていう冗談を言ったりするんだ（笑）。
でもね、楽しんでるよ。
TypeScriptを嫌っている人もいるのは知っているけど、95％くらいは TypeScriptを楽しんで書けてるよ。唯一ちょっと面倒なのが、型チェックがうるさいとき。「いや、これ絶対合ってるから！」って思ってるのに怒られるやつ。1時間前も遭遇したんだけど。

でも全体的にはすごくいい経験だよ。
で、Laravel に入った最初の日は、Taylor が「これとこれとこれが今気になってる。君もアイデアあったら出して。全部まとめて優先度つけよう」って言ってくれて。

で、1週間くらいかけてブレインストーミングして、最終的に上にあがったのが「VS Code 拡張」と「Inertia 2」だった。

ということで、僕が Laravel に入って最初にやったのは、Inertia のコアの書き直しだったんだよね。
最初の3日くらいは手が震えてたよ（笑）

Matt)
それはすごいな、、

Inertia 2の開発

まずInertiaの作者のJonathan Renikに連絡して、「僕たちはこういったことをしたいんだけど、今のライブラリの状態だと実現できないんだ」って伝えたんだ。
そしたら、彼は「僕は今のライブラリの状態についてこだわっている部分はないよ。以前動いていたものがそのまま動いて、機能が追加されるなら歓迎さ」って言ってくれたんだ。

それで、Inertia の作業で最初にやったのは、router ファイルの読み込みだったんだ。
そのファイル、めちゃくちゃ長くて、何年もかけてフランケンシュタインみたいに継ぎ接ぎされてきた感じでね。

最初は「必要最小限の変更で async request を追加できないかな」って考えてたんだけど、どんどん汚くなっていくのがわかってきて、「これはダメだ、止めよう」って。

だから、一旦まっさらな VS Code ウィンドウを開いて、元の router ファイルの全行をひとつずつ「この行は何をやってるか」ってノート取っていったんだ。
だって、Inertia の内部構造をちゃんと理解してなかったし、いきなり壊したくなかったからね。

ファイルを削除して、新しい状態で書き直す前に、そうやって全行を理解したんだよ（笑）

Matt)
まじか、、

Joe)
うん、それで、inertiaのコアを少し書き直して、async リクエストを扱えるようにしたのが最初で、そこから色々な機能が膨らんだ感じだね。

Matt)
うわ、それすごいね。
よく「本を書くと深く理解できる」って言うけど、実際には「全部最初から書き直す方がヤバいほど理解できる」ってことだよね（笑）

Joe)
ほんとにそう。
コードの中にあるちょっとした if 文とか、普通は見逃すようなニュアンスも全部見えてくる。
これがソースコードのダイブ（source dive）が有用な理由だと思うよ。

Laravelについて大好きなところなんだけど。Laravelってソースコードが追いやすいと思うんだ。
コマンド+クリックで実装に飛べるし、新しい VS Code 拡張があればさらに楽になるし。（笑）

まあそれは置いておいて、今回の作業はまさに「ソースコードのダイブ」の極致だった。
書き直すために、全部理解する必要があるって感じだったから。

Matt)
Tighten（僕の会社）では、コードに注釈を残せて、それをリポジトリ内の別ファイルに共有できるような VS Code 拡張を作れないかなって話していたことがあるんだ。Andy Newhouseが言っていたんだけど。
その話、君のノートをとっていく話を聞いてて思い出したよ。
Andyもそういうことを言いたかったのかもしれないな。

Joe)
それ、開いているファイルに応じて他のファイルに書いてある注釈を表示するってことだよね？
めっちゃいいね。

Matt)
うん。もしくは注釈を SQLite に保存してみたり、やり方はいろいろあると思うけど。
で、同じ拡張を使ってる人同士で注釈を共有できるとか。

Joe)
うん。とても良いアイデアだと思う。

VSCode拡張はTypeScriptで書かれているのか

Matt)
それで、君はジョインしてからTypeScriptを多く書いていると言っていたけど、VS Code拡張もTypeScriptで書かれているの？

Joe)
うん、VS Code の拡張は技術的にはどんな言語でも書けるんだけど、TypeScript 用の SDK が用意されてるから、たいていの人は TypeScript で書いてると思う。
うちの拡張も TypeScript で書いてあって、そこにちょっとした PHP のスクリプトをいろいろ組み合わせてる感じ。

あとは、アプリの情報を収集するためのちょっとした手書きスクリプト（handwritten scripts）をたくさん動かしてて、そういう部分もあるんだけど、コアの部分は完全に TypeScript だよ。

複数プロジェクトの進め方について

Matt)
へぇ、面白いね。
ところで Inertia の 2.0 って、正式にリリースされたのっていつだったっけ？結構最近だったよね？

Joe)
うん、去年の年末に正式に 2.0 として安定版を出したよ。ベータ版は…たしか10月1日あたりに出したと思う。

Matt)
なるほど。じゃあその頃って、Inertia と VS Code の拡張、両方を同時に進めてたってこと？

もしそうなら、VS Code、Inertia、そしてオープンソースの管理業務っていう3つを、どうやって1週間の中でバランスとってたのか気になるな。

Joe)
うーん、正直に言うと、まだそのバランスの取り方は試行錯誤中なんだよね。やることが山ほどあって、空中にボールをいっぱい投げてる感じで（笑）。で、正直に言えば、たまに落としちゃうこともある。でもそれでいいと思ってる。人間だしね。でもまあ、ほとんどのボールは今も空中に浮いてるし、なんとかやれてる。

で、そのときどうしてたかっていうと、たしか Inertia に4週間集中して、2.0のベータ版を出す準備をしてたんだと思う。そのあとで VS Code に4週間集中してた。これは全部 Laracon US に向けた準備の一環だったんだ。

で、さらにそのあと1ヶ月くらいは、Inertia と VS Code の両方を「ちゃんと公開できる状態にするには何が必要か」っていう整理と最終調整に使った。ちゃんとデモできる形にしたり、リリースできるようにしたりね。

だから、ざっくり言うと、Inertia に1ヶ月、VS Code に1ヶ月、そのあと両方を調整する1ヶ月。で、その後 Laracon US があって、そのあと一気に全部を仕上げて、10月に両方リリースした、って感じ。（笑）
ダブルリリースは楽しいね！（爆笑）

Matt)
大変だっただろうことが想像できるよ。

Joe)
うん、実際なかなかハードだった（笑）。

で、それに加えて、その頃ちょうどチームリーダーになったばっかりだったから、オープンソースのワークフローとか、既存のプロセスをちゃんと理解しなきゃいけなくて。だからいろんなことをドキュメント化したりもしてた。

今は「ワークサイクル」っていう形で進めてて、かなり集中してる状態。今後数週間でやるべき5つのことにフォーカスしてて、それが終わったら、PR や issue の整理とか、技術的なクリーンアップに入る予定。
回答になったかな？

オープンソースチームのマネジメント

Matt)
うん。なってるよ。
こういうのって、人によって全然やり方が違うから、その話を聞くのって面白いんだよね。
業界が違っても「これだけは永遠に終わらない仕事」っていうのはあるし。

たとえば Taylor は「朝一で issue に向き合って、それを X 件以下にするまで他のことはしない」って言ってたし、
他の人は「毎朝1時間だけオープンソースの作業をして、その後で他の仕事に取りかかる」ってスタイルの人もいる。

だから、Joe がどうやってバランスを取ってるかを聞くのはすごく興味深いよ。

ところでチームは3人だったよね？Joe と、Mior（ミオール）、それと… Tony だっけ？

Joe)
うん、Tony！

Matt)
じゃあ、チームリードとして「人をマネジメントする時間」と「自分の作業をする時間」、どれくらいのバランスになってる？

Joe)
Laravel のマネジメントスタイルって、かなり放任主義なんだよね。それが僕にとってはすごく魅力的だった。

就職前に何人かと面談したけど、全員が「僕たちはベビーシットはしない。自立した大人を採用して、信頼して任せるっていう文化なんだ」って言ってたんだよ。

だから僕も、チームメンバーとは2週間に1回くらい1on1をやってる。
必要があればそれ以外にも打ち合わせはするけど、基本的には僕のチームは会議も少ないし、
管理というよりは「何か困ってることある？」「順調？」って軽く声をかけるくらい。

チームのメンバーが何か必要なときは、ちゃんと自分から相談してくれると信じてるし、
僕から細かくチェックすることはしてない。とにかく、めちゃくちゃ信頼ベースなんだよね。

もちろん、今進めてるワークサイクルが終わったら、次のサイクルの計画とかも考えなきゃいけないから、
そのへんの準備はしてるけど…
いわゆる「人のマネジメント」って意味では、本当に放任型で、そこがみんなにとっても居心地いいみたい。

Matt)
いや〜、それいいね。とても素敵だと思う。

Inertia 2の裏側

Matt)
じゃあ、そろそろ Inertia の話をまとめて、VS Code の話に移ろうか。
Inertia、僕も使ったことはあるんだけど、ソースコードを深く読んだことってないんだよね。

Laravel のフルスタック開発者なら誰でも知ってるようなことじゃなくて、
「実はこんな仕組みになってる」とか「JavaScript で面白い発見があった」とか、
Inertia 2 を書き直す過程で「これは楽しかった！」「この技術初めて触った！」みたいな
ちょっとしたトピックがあったら教えてほしいな。

Joe)
うん、めちゃくちゃ楽しかったよ。
リファクタリングって、なんか自分の中で変な喜びがあって（笑）、
コードをきれいにする作業が本当に好きなんだよね。
脳みそのどこかにそれを愛する部分があるみたい。

で、一番驚いたのは最初に Inertia のコードに潜ったとき、
「え、こんなに薄いの？」って思ったこと。
JavaScript の部分ってほんとに少なくて、かなりスリムなんだよ。
でも、その薄いコードでけっこう重たい処理をしてるのが面白くてさ。

「これはかなり複雑なことやってるな」って思ってたんだけど、
実際は Axios でリクエストを送って、クライアントとサーバー間のやり取りを
お互いが理解できる形で整えてるだけ、みたいな感じ。

最初に驚いたのは「うわ、ほんとにコード少ないな」ってことだったね。
まあ今は前よりコード量増えてるけど、それでもまだ全然スリムな方だと思う。

で、今回開発の中で特に気に入ってるし、いちばん学びがあったのが
Jonathan（Inertia の作者）と一緒に作った「履歴の暗号化（history encryption）」って機能。

何に対応するための機能かっていうと、たとえばアプリでログアウトしたあとに
ブラウザの「戻る」ボタンを押すと、セッションが有効だったときのデータが復元されちゃって
本来見ちゃいけない情報が見えちゃうっていうセキュリティ的な問題があったんだ。

これはアプリというより、どっちかというと「ブラウザの仕様」の問題なんだけど、
ずっと気になってたし、ユーザーからも指摘が多かったから、ちゃんと対処したかった。

いろんな方法を試した結果、最終的にたどり着いたのが、
「window の history（履歴）に保存されている状態を暗号化して、
　暗号キーが一致したときだけ表示できるようにする」っていうアプローチだった。

だから、たとえばログアウトしたり、手動で履歴をクリアしたときにキーをローテーションして、
過去の状態は見えなくする。で、必要ならサーバー側から再取得して、
本当にその人がアクセス権を持ってるか確認できるようにしたんだ。

このアイディアは Jonathan のひらめきから始まったんだけど、
ある日ふたりでペアプロしてて、長いセッション中に彼がふと、
「待って、待って」って言い出してさ。（笑）
「こうしたらどう？」って Jonathan が言ってきて、
僕も「うん、それいいね！」って乗っかって。
そしたらそのアイディアをどんどん膨らませていく感じになって、
お互いが「じゃあ、これってどう？」「あ、それアリ！」みたいに、
すごくいいプログラミングの瞬間だったな。

で、初期のプロトタイプはたぶん1日くらいで完成したと思う。
Jonathan が「これだよ！」って言って、僕も「これだね！」って（笑）
もうすごく気持ちよかった。

もちろん、暗号化するとデータサイズが大きくなっちゃうから、
ストレージ関連でちょっと問題にぶつかったりもしたけど、
ブラウザに備わってる暗号化の機能を使ってるだけだから、
新しい技術ってわけじゃないけど、学びはめちゃくちゃあったよ。

Matt)
それ、めっちゃ面白い。僕、実はブラウザの暗号化まわりは
NFTとかちょっといじってたときに色々調べたことあるんだけど、
その辺の技術ってけっこう深いよね（笑）

で、素朴な疑問なんだけど…
前のページに戻ったときの「状態」って、どうやって保持してるの？
サーバーレンダリングのアプリだったら、
ブラウザの「戻る」ボタンを押したらキャッシュからページを引っ張ってくるでしょ？
Inertia の場合も同じような仕組みなの？

Joe)
うん。Inertia は、window の history state にデータを保存してるんだ。
つまり「ページを再表示するためのデータ」をそこに入れてるって感じ。

で、ユーザーが「戻る」ボタンを押したのを検知したら、
そのデータを使ってコンポーネントを即座に読み込んで再表示するようにしてる。
だから画面がパッと戻ってくる、みたいな。

面白かったのは、他のアプリも色々テストしてみたんだよね。
「他のアプリはどうしてるんだろう？」って思って。
で、GitHub とかでも試してみたら、ログアウト後に戻るボタンで
見えちゃいけない情報が見えたりした。
これは Laravel だけの問題じゃなくて、
結構いろんなアプリが抱えてる共通の課題だと思う。

で、さっき言った通り、windowのhistory stateに保存しているんだけどこの window のhistory stateって手動では消せないんだよね。
ブラウザが完全にコントロールしてるから、
「今表示してるページの状態」しか操作できない。

だから「戻る」でキャッシュからページが復元されるっていう挙動が
セキュリティ的にちょっと厄介だった、っていうのが今回の話の発端だった。

Matt)
なるほど、めちゃくちゃ興味深いね…。

Joe)
そう、これは解決するのがなかなか難しい問題だったよ。

Matt)
ほんとに面白いのは、Laravel が業界の最前線を走ってるっていうところなんだよね。さっきの話もそうだけど、GitHub をディスるつもりは全然なくて、GitHub は最高だと思ってるんだけど、それでも「うちの方が一歩先にやってる」みたいな瞬間があるのが楽しい。

PHP の世界ってさ、ちょっとアンダードッグ的な、「追いつかなきゃ」っていう雰囲気がずっとあったじゃない？パッケージマネージャーも、OOP も、いろんな面で他の言語やエコシステムに追いつこうとしてきた。

でもここ5年くらいで、Laravel はむしろリードしてる部分もあるなって感じてて。周りから「Laravel のやり方参考にしよう」って見られるようになってるのが、すごく嬉しいんだよね。

Inertia って Laravel 専用じゃなくて、他のフレームワークでも使えるけど、やっぱり「Laravel がこれをリードしてる」って言ってもらえるのはすごく嬉しいし、「Laravel ならもうその辺は解決してるよ」って言えるのも最高。

Joe)
おもしろいのが、この履歴の暗号化の機能を作ってるとき、正直「これニッチすぎるかな？あまり需要ないかも」って思ってたの。でも、やっぱりやる価値あるなって感じてたし、興味深い問題だと思ったから取り組んだんだよね。

でもいざ発表してみたら、思った以上に注目されて、他のエコシステムの人たちからも「え、それ何？履歴を暗号化？何それ？」って話題になって。もちろん、過去に誰かがやってたかもしれないけど、Laravel のやり方ってちょっとユニークだったと思うし、それに気づいてもらえたのが嬉しかったな。

PHP って確かに昔はアンダードッグ感強かったけど、最近はそうでもないよね。
「Laravel？知らないの？」って逆にこっちがびっくりするくらいだし（笑）
ほんと、今は色んな分野で先頭走ってる感じがあって、それがめちゃくちゃワクワクする。

Matt)
うん、それすごく分かる！

〜〜後編に続く〜〜

2025/03/25
〜〜前編の続き〜〜

Laravel Podcast Season7 Episode 3 - 後編

Matt Stauffer(Tighten CEO) x Joe Tannenbaum(Laravel オープンソースチーム エンジニアリード)

https://www.youtube.com/watch?v=3xaMOzUN3fQ

Laravel公式VS Code拡張の開発経緯

Matt)
で、次は VS Code の話に移ろうと思ってるんだけど…。

僕ね、Tighten の CTO を11～12年やってたときは「リーダー職ってもうコード書かないの？」ってよく聞かれてて、「いやいや、CTO だってプロジェクト入ったり OSS 書いたりしてるよ！」って答えてたんだよね。

でも CEO になった今は、マジでコード書く時間ゼロ。
唯一書いたのは Laravel 製のマーケティングサイト「Build with Laravel」くらいで、
それはビジネス的に重要だったし、「くそ、コード書きてぇ！」って思ってたのもあって（笑）

それ以来はほんとに全然コード書けてないから、Joe の VS Code 拡張も触れてないんだよね…。

でもね、実は僕、かなり長いこと Sublime Text 使ってて、
Caleb Porzio^[1]や他の人たちに「VS Code いいよ」って言われてようやく乗り換えたんだ。
今はほんとに VS Code 気に入ってる。設定もバッチリ。

で、Joe が作った機能を見てて、もうヨダレ出るくらい「うわー、使いたい！」って思ってるの（笑）
昔 PHPStorm も使ってたんだけど、PC が重すぎて耐えられなかったから離れちゃって。

でも今でも「いつかまた、あのレベルのコードインテリジェンス環境に戻りたい」って思っててさ。
だから今、Joe の拡張を使えないのが一番のフラストレーションなんだよね。

Joe、ちょっとその話、詳しく聞かせてくれる？
さっき「色んなアイディアを出し合って、優先順位つけてやってた」って言ってたけど、
あの VS Code 拡張って、そもそもどういうきっかけで生まれたの？
何を目指して作ったの？

Joe)
最初にアイデアを出し合ってたときは、「どうすれば Laravel や PHP のエコシステムに入ってくる人たちのハードルを下げられるか？」っていうのが大きなテーマだったんだ。

VS Code を使ってる人ってすごく多いし、無料で手に入る。でも正直、Laravel での VS Code の体験って、当時はあんまり良くなかったんだよね。

Laravel 用の拡張機能って6個とか10個とかあって、それぞれがいい仕事をしてるんだけど、「どれが正解なの？」ってなるし、何かうまく動かなくなったときに「今どの拡張が悪さしてんの？」って探すのが大変だった。

だから「これ一個入れとけばOK」っていう統一されたものを作りたかったんだよね。Laravel を始めたい人が「VS Code 使ってるなら、これ入れとけば90%、いやできれば100%はカバーできるよ」って言えるようにしたかった。

もちろん、PHPStorm + Laravel Idea(Laravel有料拡張) が今のところ最強なのは分かってるし、そこまで届かないかもしれない。でも僕らの目標は「VS Code の体験をちゃんと良くすること」で、それはもう実現できたと思う。

正直言うと、今はもうアプリケーションコードを書く機会ってあんまりないんだ。昔はずっとアプリばっか書いてたけど、今はライブラリとか拡張機能ばっかり書いてる。でも最近、ちょっとしたサイドプロジェクトを始めたんだよね。

で、久々にアプリコード書いてたら、「なんでこれ補完されてるの？なんでリンク飛べるの？」ってなって、「あ、これ俺が作ったやつか！」って（笑）
あれは面白かったね。

とくに “リンク機能” は意外とみんな驚くみたいで、僕がサプライズで入れたお気に入り機能なんだ。自分が気になってる部分をクリックするだけで、目的のコードに一瞬で飛べる。これ最高。

ルート見てて、「この Blade コンポーネントどこ？」って思ったときも、一発でたどり着ける。ほんとに気持ちいいんだよ。

VS Code 拡張についてどうやって作れば良いのか最初は全然知識なかったからかなり冒険だったんだけど、今では完全に「愛情込めて育ててるプロジェクト」って感じ。

毎回開くのが楽しいし、「ちょっとした改善」を入れるのが大好き。
たとえばこの前は、.env ファイルの Vite 用の変数を「VITE_」ってprefixをつけなきゃいけないのを、その場で変換できるショートカット機能を作ったんだ。
それは僕が嫌だなって思った作業だったから作ったんだよね。

要するに、自分が「これ嫌だな」って思ったことを、すぐに直せるのが楽しいんだよね。

Matt)
なるほどね。

Joe)
しかも嬉しいことに、フィードバックもめっちゃ良くてさ。「これは最高」って声がたくさん届いてる。

ただね……めちゃくちゃ大変だったのは、クロスプラットフォーム対応。これがもう、想像以上にやばかった（笑）
たぶん「世紀の控えめな言い方」ってくらいヤバい。

だって Mac があって、Windows があって、それぞれにアーキテクチャの違いがあるでしょ？
それに加えて、みんなの開発環境もバラバラ。

Docker 使ってる人もいれば、Laravel Sail 使ってる人もいるし、Valet 使ってる人もいる。
場合によっては Herd とか独自の環境もあるし。

で、その全部の環境で PHP をバックグラウンドで実行しないといけないわけ。
つまり、ユーザーの環境に合わせて「ちゃんと PHP を動かす」ってだけでも、かなり難しい課題なんだよ。

Matt)
あ〜、なるほど。なんでそんなこと（PHP を動かすこと）をやってるのか聞こうと思ってたけど、今ので納得したよ。PHP を裏で動かさなきゃいけないってことね。

Joe)
そう、PHP って PHP のことを理解するのがめちゃくちゃ得意なんだよね。だから今はそれを使ってるんだ。

Laravel を TypeScript で完全に再構築して、全部の仕組みを TypeScript 側で解釈できるようにしよう…みたいなやり方は現実的じゃないし。
だから僕たちは、「Laravel アプリから必要な情報を収集する小さなスクリプトを裏側でサクッと走らせて、その情報を拡張機能に渡す」っていうシンプルな仕組みにしてる。

もちろん、環境によっていろんな変数があるし、ちょっと特殊な構成してる人のケースでは例外もあるんだけど、
今のところはだいぶ安定してきてて、全体的にはかなりいい感じ。

フィードバックもすごく良くて、みんなの開発体験が前よりずっと良くなってるって聞けるのがほんとに嬉しいよ。

VSCode拡張の技術的な仕組み

Matt)
なるほどね。VSCode拡張について色々発表は見てきたんだけど、実際にまだ使ったこともないし、ソースコードも読んでないんだよね。
だから今回は純粋に好奇心で聞くよ。

最初に聞こうと思ってたのが、「たしか…なんて言うんだっけ… AST かな？」
つまり、DOM ノードに相当するような構造をプログラミング言語ごとに解析できる言語構文みたいなやつってあるじゃない？

Tighten でも、クラス定義とか関数定義を判別したり、Bladeみたいにまだ解析ツールが整ってないようなものに対応するために、いくつかのツールを作ったことがあるんだけど、
そういうのって一番ややこしいんだよね。

で、Joe 君はたぶんずっとそういう「この構文は何なのか」をシステムに教え込んでるんじゃないかと思ったんだけど、
この VS Code 拡張で PHP を使ってるときって、PHP 側でクラスをインスタンス化したり、リフレクションとか使ってクラスの構造を見たりしてるの？
PHP は具体的に何してるの？

Joe)
Joe：
うん、やってることは大きく分けて2つあるんだ。

ひとつは、僕らが「リポジトリ（repositories）」って呼んでる仕組み。これはアプリの情報を集めるためのもので、
たとえば「設定値は何があって、どこにあるのか」とか、「サービスコンテナに何がバインドされてるのか」、
あと「翻訳ファイルはどこに何があるのか」みたいな感じ。

で、この翻訳まわりがね、ある意味ダークホースだった（笑）。
Filament や Statamic みたいなパッケージって、めちゃくちゃ翻訳機能がしっかりしてるから、
その情報を集めてるとマジでメモリ足りなくなりかけたんだよね。返ってくるレスポンスが巨大すぎて。
これはかなり意外だったけど、今はまぁ解決できてる。たぶん（笑）

それがまず1つめの仕組み。アプリをバックグラウンドで素早く起動して、必要な情報を収集して、
でファイルが変更されたらその対象に応じてスクリプトを再実行して、情報を再収集するって流れ。

で、もうひとつが 君が言ってたような、「ファイルを開いてるときに、その中身を理解する」ための仕組みだね。

リンクを張ったり、ホバーで情報出したり、どのコードがどう繋がってるか理解したり…
そういうことをやるための処理なんだけど、開発初期の時点で「PHP 全体のインテリセンス機能は作らない」って明言してたんだ。

それは他のツールがやるべきことで、僕らは Laravel 固有の部分に集中したいっていう考え方でね。
だから PHP 全体を解析する必要がなくなって、そのぶん仕事が楽になってる。

で、Microsoft が出してる「フォールトトレラント PHP パーサー（fault-tolerant PHP parser）」っていうライブラリがあって、
これは不完全な PHP コードでもうまく構文解析して AST（構文木）にしてくれる。エディタ向けに作られてるやつ。

この VS Code 拡張を起動すると、まずそのパーサーのスタンドアロン実行バイナリを GitHub リポジトリからダウンロードして、
それを使って「このファイルで興味がある部分ある？」「あるならそれを教えて」って感じで解析して、
JSON 形式で VS Code 側に「ここが注目ポイントだよ」って返すんだ。

で、それを受け取った TypeScript 側が、オートコンプリート出したり、リンクつけたり、ホバー情報出したりする感じ。

Matt)
なるほどね。じゃあ既存の仕組みの上にうまく乗っかって処理してる感じで、
自分たちで上から全部作ってるってわけじゃないんだね？

Joe)
そう、その通り。AST（構文木）を解析する部分には外部のパッケージを使ってる。
でもそのパーサー自体も、けっこう骨のあるやつでさ。
一度でも AST に触れたことある人なら分かると思うけど、あの沼は深いよ（笑）
だからそこには結構時間をかけた。

Matt)
ああ、やっぱりね。それが作業の大部分なんじゃないかと思ってた。
となると、ちょっと気になるのは「アプリがちゃんと起動しないとき」だね。
たとえば何かバグってて、Laravel アプリが初期化できないような状態のとき、どうしてるの？

Joe)
ああ、それね。最初の頃は、エラーが発生するたびに小さなポップアップ出してたんだ。
「Laravel 拡張で何か起きました。詳細を見る？ エラーコピーする？」みたいなやつ。

で、アプリがちょっとでも壊れてると、
「ポンッ、ポンッ、ポンッ、ポンッ…」ってずっと鳴る（笑）
ユーザーからも「うるさい！」って言われて、「あ、これはダメだな」と思ってすぐ直した。

今は、アプリ自体が完全に起動できない状態だったらポップアップは出さないようにしてる。
「たぶん今デバッグ中で、本人もそれ分かってるでしょ」って前提でね。

でも、僕が書いたスクリプトの中で何かロジック的なエラーがあったとき、
つまり Laravel 側じゃなくて拡張側の問題だったら、そのときはポップアップ出すようにしてる。

まぁそれも今後はポップアップなしにして、ログだけ残すようにするつもり。
気になる人はログ見ればいいし、気にしない人は気にしなくていいように。

だから「アプリ自体が動かない」ケースと「拡張の中でエラーが出た」ケースでは扱いを分けてる感じだね。

Matt)
いやあ、めっちゃ面白いなあ。
もう今すぐ使ってみたくなったよ。実際に動いてるとこ見てみたい！

Joe)
えっとね、あんまり自分で自分を褒めたくはないけど（笑）、
でもほんとに役に立つと思うよ。
VS Code の中での開発体験がガラッと変わるくらい。
個人的にも「これはすごい」って思ってる。

Matt)
それが聞けて嬉しいよ。
っていうか、実際に僕も周りからいい評判しか聞いてないし。ありがとう！

Joeが次に取り組む予定のもの

Matt)
で、そろそろ時間が近づいてきたんだけど、
最後にひとつだけ聞かせて。
「今、次に取りかかる予定の仕事」って何かもう決まってる？

Joe)
うん、そうだね。今取り組んでることとしては、Inertia 関連のものが結構たくさん控えてる。

まずひとつは、Inertia の「無限スクロールコンポーネント」。これ、たしか4年前くらいに「作りたい」って言ってたやつなんだけど、いや違う、去年だったかな？
まぁとにかく Inertia 2.0 を作ってたときに、無限スクロールをもっと簡単に使えるようにしたくて、プロトタイプを作ったんだ。めちゃくちゃ簡単に使えるようにね。
で、今はそれをちゃんと仕上げて、React、Svelte、Vue にそれぞれ展開して、リリースしようとしてるところ。これは近いうちに出す予定。

それと、TypeScript 版の Ziggy^[2]を作ってるよ。Ziggy、ほんとに最高だからありがとね（笑）。
で、僕らがやってるのは TypeScript でルートを生成できるようにして、それを直接インポートできるようにしたり、ツリーシェイキングできるようにするっていうところに力を入れてる。これはかなり楽しみなやつ。

あと、2要素認証（2FA）を Starter Kit に戻す予定。これは大事だし、必要なことだからやらないとね。

それから VS Code の拡張については、ほんとにやれることが山ほどある（笑）まさに「ビュッフェスタイル」って感じ。
今の優先事項としては、Livewire と Volt のサポートをもっと良くすることかな。現状でも悪くはないけど、もっと良くできると思ってて。

あと、テストランナーも再統合したいんだ。実はベータ版出す前に一回無効にしたんだけど、それはちょっと安定性が足りなかったから。でも今はもう一度ちゃんと動くようにしたい。

VS Code 関連に関しては、正直「やりたいことリスト」がめちゃくちゃ長くて（笑）たぶん1マイル分くらいある。

で、個人的に気になってるのは Inertia を使ってるときの「双方向の IntelliSense」が今はそんなに良くないんだよね。
それをもっと良くしたいと思ってて、そこに関してもいろいろ動いてるところだよ。

Matt)
それはめっちゃいいね、最高だよ。Ziggy 関連の人たちと君を繋いでおくようにするよ。
今は Jacob がメンテナンスしてると思うんだけど、たしか彼が TypeScript 版も作ってたんじゃないかな。だからもうすでにあるかもしれない。

Joe)
そうなんだ、これは Tim McDonald^[3]が元々考案したやつなんだよね。
すでに存在はしてるかもだけど、良いものだし、もし連携できるならぜひやりたいな。

Matt)
了解。
おもしろい話なんだけどあ、Ziggy って Daniel Cobborn が作ったんだ。それで、

Joe)
えっ、それは知らなかった！

Matt)
うん、そうなんだ。
それで彼が Tighten にいたときに、「こんなアイデアあるんだけど、時間とお金かけて作っていい？」って聞いてきたんだよ。
それで僕が「自分で作るなら君の所有になるけど、Tightenの名義で作るなら、うちが費用出す代わりに公開してメンテも続けるよ」って答えた。

その後、何度も話し合いをして「何かを公開したら、それは数年間ずっと責任を持って抱えることになるよ？」っていう現実もちゃんと伝えた。

Tightenとして出せば、たとえ作った人が会社を離れても、Tightenがメンテし続けることになるからね。で、実際にそうなった（笑）

で、今 Ziggy のメンテをしてる Jacob は、Daniel が辞めたあとに引き継いでくれたんだけど、その Jacob も最近独立したんだ。でも彼は「Tightenのために Ziggy のメンテは続けたい」って言ってくれてね。

僕はもちろん「いいよ！」って言った。なんで断る理由があるのって（笑）

Tightenの中では、今後誰かがメンテし続けないといけないような OSS をいくつ抱えるかって、いつも慎重に考えてるんだ。
Jigsaw や Ziggy みたいに楽しいやつもあるけど、僕自身が小さな便利ツールをいっぱい作るタイプで、「はいこれ君たちの仕事ね！」ってなりがちだから（笑）

でも今は CEO だから、そういうのを定期的に整理して、要るものと要らないものを見極めてくのが僕の仕事でもあるんだよね。

Tighten社が公開しているOzzieについて

Joe)
ところでさ、「Ozzie」っていうやつ見たんだけど、名前あってる？Ozzie？

Matt)
うん、そうだよ。

Joe)
Andy がOzzie についてポストしてるの見たんだけど、めちゃくちゃいいじゃん。あれってオープンソースなの？

Matt)
そうそう、オープンソースだよ。
もともとは僕たち用に作ったんだけど、ある時 Spyが「これ使ってるよ」って言ってきて、それで「じゃあもうちょっとちゃんと整えようか」ってことになって、少しずつ改良してきたんだ。

今では他の人たちにも便利な形になってると思うよ。誰でも貢献できるし、フォークしてもいいし、自由に使って大丈夫。

主に使ってる目的は、オープンソースリポジトリの「健康状態」を把握すること。
毎週金曜日になると、すべてのリポジトリについて「ヘルススコア」みたいなのを出してくれるんだ。

で、そのスコアがある数値を超えてたら「このプロジェクト、ちょっと借金溜まってきてるよ」って感じで、issue や PR を処理しなきゃなってわかる。

プロジェクトが何十、何百ってある人にとっては、毎週すべてをチェックするなんて無理じゃん？
だからそれを簡単に見える化してくれるツールなんだ。
あとダッシュボードもあるから、プロジェクトごとに並び替えたり、スコアごとにフィルターしたりもできる。

Joe)
めっちゃ賢いね。とてもいいアイデアだと思う。
ちょっと自分でも試してみようかな。

Matt)
ぜひぜひ。誰かがOzzieにワクワクしてくれると、僕たちの側でも「じゃあ新しい機能追加しようかな」ってモチベーション上がるし。

最初は「自分たちにとって必要な機能だけで十分だな」って感じだったんだけど、誰かが「こういうの欲しい」って言ってくれると、それがいいきっかけになる。

特に僕はそういうリクエスト大歓迎。「タスクちょうだい！」って感じ（笑）
確か最初は僕が Ozzieを書いたんだけど、その時は単一ページ構成で、今のバージョンは誰かが複数ページ構成に書き直してくれてるんだよね。
「よっしゃ、じゃあ新バージョンのソース覗きに行く理由ができた！」って感じで、また楽しめるんだよね。

だから、Ozzieに手を加えるきっかけなら何でも大歓迎だよ！

Joe)
よし、いっぱい理由を作らせてもらうよ（笑）

Outro

Matt)
最高！毎回の話だけど、もう45分だから終わらせなきゃいけないんだ。最後に今日話した中で「これ話すつもりだったのに出なかったな〜」みたいなことってある？

Joe)
いや、話したかったこと全部触れられたと思うよ。しっかり伝えられたと思う。

Matt)
素晴らしい！チームワークだね！
今回 Joe をゲストに迎えられてほんとに楽しかったよ。
でも正直、予想してなかったんだけど…このシーズンに出てくれた人、みんな「また絶対出てもらいたい！」って思ってる（笑）

たいていは「このトピックについて話そう」って感じでゲストを呼ぶんだけど、Laravel チームのみんなってほんと面白いし、きっと半年後にはまた何か新しいことやってて話したくなるんだよね。

だから Joe にもまたすぐ来てもらいたい！とにかく今回はありがとう。全部すごく面白く話してくれて、
そしてもちろん、僕たちが日々恩恵を受けてるオープンソースのすばらしい仕事、本当にありがとう！

Joe)
こちらこそ呼んでくれてありがとう。楽しかったよ！

Matt)
よし、リスナーのみんなも最後まで聞いてくれてありがとう！
また次回！

脚注

1. Livewire、Alpine.js、Fluxの作者 ↩︎

2. ReactやVue等のフロントエンドライブラリでLaravelの名前付きルーティングを使えるようにするライブラリ。Tighten社が開発し、OSSとして公開している ↩︎

3. Laravel社のメンバーの一人。現在はLaravel Nightwatchの開発を中心に活動している。 ↩︎

2025/03/10

Laravel Podcast Season7 Episode 2

Matt Stauffer(Tighten CEO) x Tony Lea(Laravel オープンソースチーム)

https://www.youtube.com/watch?v=bX-8LO49Q4g

Intro

Matt)
Laravel Podcast シーズン7へようこそ！ホストのMatt Stauffer、TightenのCEOです。今シーズンは、毎回Laravelチームのメンバーと一緒にお届けします。
今日はTony Leaと話します。TonyはLaravelのオープンソース開発者をやってるんだけど、自己紹介がてら、どんな仕事をしてるのか話してもらえる？

Tony)
やあ、みんな！僕はLaravelのオープンソース開発者で、今の仕事を始めて4ヶ月くらいになるよ。
でも、ここに至るまでにはいろんなステップがあって、自分の個人プロジェクトとかも絡んでるんだ。そのあたりの話もあとで詳しく話すね。
今はLaravelのスターターキットやオープンソース関連の開発をしてる。公式サイト（laravel.com）やドキュメントにも少し関わってて、まあ、いろんなことをやってる感じかな。
まだ新しいポジションだから、とにかく「これやって！」って振られたものを片っ端からこなしてるよ（笑）。でも、それがすごく楽しいんだよね！

Laravelのチーム構成

Matt)
いいね、まだ手探りしながら進めてる感じが最高だよね。
今日はTonyのバックストーリーを掘り下げていきたいんだけど、実はこの話をするって事前に伝えてなかったよね（笑）。
でもちょっと気になったんだけど、君の肩書きって「オープンソース開発者」とか「オープンソースプログラマー」になってるじゃん？
Laravelの中では、例えば有料プロダクトに特化してるチームと、Laravel本体とかlaravel.comみたいなオープンソース周りを担当するチームって、はっきり分かれてるの？

Tony)
うん、チームはいくつかあって、「クラウドチーム」とか「Forgeチーム」とかがあるよ。それとは別に、最近「オープンソースチーム」もできたんだ。
ただ、めちゃくちゃ小さいチームで、今のところ僕とJoe、それにもう1人いるはずなんだけど……ちょっと待って、名前がパッと出てこない（笑）。
でも彼はたしかLaravelの社員第1号とか、それくらい初期からいる人だったと思う。後でちゃんと調べてみるね。
だから、オープンソース側のチームはかなりコンパクトだけど、クラウド、Forge、オープンソースって感じでちゃんと分かれてるよ。
あとは、マーケティングとか人事とか、普通の会社にあるような部門ももちろんあるね。

Matt)
たぶんMiorもオープンソース関連の仕事してると思うんだけど、Novaもやってるから、そっちのほうがメインかもしれないね。

Tony)
そうだ、それだ！Miorのこと考えてたのに、名前が思い出せなかった（笑）。ごめんね、Mior。

Matt)
Miorはかなり早い段階で採用されたよね。たしかMuhammadが最初の採用だったと思うけど、Miorもかなり初期からいる。
ただ、彼の本名を知ってる人は意外と少ないんだよね。ずっとネット上では「crynobone」って名前で活動してるから。
知らない人のために説明すると、彼は Laravel Testbench っていうパッケージを作ってるんだ。
これがあると、パッケージを開発する時にテストを簡単に実行できるようになる。Laravelアプリを本当にインストールしなくても、テスト環境をパッと立ち上げられる感じだね。
彼はもうずっとLaravelに関わってるし、Laravel本体だけじゃなくてNovaの開発やカスタマーサポートもやってるよ。
じゃあ、その小さなチームの3人って感じだね。

TonyがLaravelチームにジョインするまでの経緯

Matt)
さて、今度はTony自身の話を聞かせてほしいんだ。もし誰かが君のことをまったく知らなかったとして、過去のプロジェクトもフォローしてなかったとしたら、どうやってプログラミングに興味を持ったのか、どんなストーリーでLaravelにたどり着いたのか、ぜひ教えてほしい。
みんなそれぞれ違う道を歩んできてると思うんだけど、君の最初のLaravelとの出会いまでの話を聞かせてよ。

Tony)
もちろん！僕がプログラミングを始めたのは、ゲームを作りたかったからなんだ。たぶん同じ理由で始めた人も多いと思うけど、子供の頃にNintendoとかSuper Nintendoに夢中になって、「自分でもゲームを作りたい！」って思ったのが最初だった。
それでソフトウェアエンジニアリングの学位を取ることにして、大学ではC、C++、C#とか、Microsoft系の技術を中心に学んだんだ。
でもその途中でPHPを知って、「え、メモ帳にコード書いて保存するだけで動くの！？しかもすぐ結果が見れるじゃん！」って感動した（笑）。
C#とかASPだと、コンパイル時間がかかるし、重いIDEを起動するだけでも時間がかかる。それに比べてPHPは軽くて、すぐに動かせるのが気に入ったんだよね。

大学卒業後はサンディエゴに引っ越して、いくつか仕事をしながらフリーランスもやってた。
もちろんWordPressの案件もやったよ（笑）。
PHPを使いこなしたくて、もっと深く学ぼうと思った時にCodeIgniterに出会ったんだ。これが3～4年くらい僕のメインだったかな。

ちょうどその頃、Node.jsやRuby on Railsが注目され始めてて、僕もRailsを使い始めたんだよね。それで「このままRuby on Railsの開発者になるべきか、それともPHPを続けるべきか」ってめちゃくちゃ悩んだ。
そんな時に、Hacker NewsかRedditで「Laravel」っていうフレームワークの話を見つけたんだ。興味本位でクリックしてみたら、ちょうどLaravel 3の時代で、Eloquentの説明が書いてあって「ユーザー情報をデータベースから取得するのに User::first() って書くだけ！」みたいな話だった。
それを見て、「え、Railsっぽいじゃん！？」ってなって、一気にLaravelに引き込まれた。
それ以来、ずっとLaravelを使い続けてるし、Goとか他の技術も学びつつも、やっぱりPHPが僕のホームベースって感じだね。
今でもLaravelのカンファレンスに行くのが大好きだし、PHPの世界にいることが楽しいよ！

Matt)
なるほどね。
たぶん、多くの人が君の名前を最初に聞いたのって Dev Dojo を通じてじゃないかな？
Dev Dojoってどんなものなのか、ちょっと話してもらえる？

Tony)
うん、そうだね。
実は Dev Dojo のドメインを買ったのは、もう15年くらい前なんだ。当時、誰かと話してて「俺たちって開発者の忍者みたいじゃん？」みたいなことを言ったら、「じゃあ、俺たちのdojo（道場）ってことか！」ってなって、「あれ？ Dev Dojoってめっちゃいい名前じゃん？」って思ったんだよね（笑）。
それでドメインを調べたら、すでに誰かが持ってて、ダメ元で「売ってもらえませんか？」って連絡したら、「1000ドルでどう？」って言われたんだ。でもその時お金がなくて、「うーん…無理だな」って思ってたら、向こうから「じゃあ500ドルでどう？」って来て、さらに交渉して「300ドルならどう？」って言ったらOKしてくれた（笑）。
それで devdojo.com をゲットしたってわけ。

最初はただの僕の遊び場みたいな感じで、最初はブログとして始めたんだけど、途中でクライアントを2〜3人抱えるような小さな開発エージェンシーっぽくなったんだ。その後、動画コンテンツを追加し始めて、だんだん Laracasts っぽい感じになっていった。
今は Wayback Machine（過去のウェブサイトが見れるサービス）で見れると思うけど、当時の Dev Dojo はNetflixっぽいデザインで、きれいなサムネイル付きの動画が並んでたんだよね。
ただ、その頃には Laracasts がすでにめちゃくちゃ人気になってたから、別に競争しようとかじゃなかったけど、僕は RailsCasts の影響を受けて、「こんな感じで動画を作るのって楽しそうだな！」って思って始めたんだ。

それで Dev Dojo は動画学習プラットフォームっぽい形になったんだけど、正直そこまで大きくはならなかったね。
最盛期でも、月9ドルのサブスクユーザーが100人くらいだったかな。
でも、いろいろ試行錯誤するのは楽しかったし、そこからいくつかプロダクトも作った。
今では Tailwind CSS のページビルダー、Laravelのスターターキット、TALL Stack（Tailwind+Alpine+Laravel+Livewire）向けのテンプレート なんかを作ってるよ。

で、実は数年前に Dev Dojo にフルコミットすることにして、2年間くらい専業でやってたんだ。その間、いくつかクライアント仕事もしてたね。
そんな時、Taylor（Otwell, Laravelの創設者） からTwitterでDMが来たんだよ！「Laravelでポジション空いてるんだけど、興味ある？」って。

でも、ちょっと話を戻すと、実はその前にもLaravelのポジションに応募したことがあったんだよね。その時は「もう埋まっちゃったけど、また何かあったら連絡するよ」って言われてたんだけど、本当に連絡をくれたんだ。
で、オープンソースチームで Laravelのスターターキット を担当する仕事を提案されて、「え、マジで！？ これはやるしかない！」ってなった（笑）。
今は月曜から金曜まで、自分が趣味で週末にやってたことを仕事としてできてるって感じで、本当に最高だよ！

Matt)
いいね！
君がスターターキットを担当するって聞いたとき、「ああ、それはピッタリだな」って思ったよ。
だって、君が作ってきたツールって、アプリ開発の手間を減らすものばかりじゃん？
クリック＆ドラッグで簡単に使えるものとか、スターターキットとか、繰り返し作業を減らして、開発をスムーズにするものばかり。
だから、君がLaravelのスターターキットを担当するって聞いて、「いや、これはまさに適任でしょ！」って思ったんだよね。

新しいスターターキットの制作経緯

Matt)
で、Laravelにジョインして4ヶ月になるけど、最初のプロジェクトがスターターキットだったわけだよね。
これは、BreezeやJetstreamが導入されて以来、かなり大きな変化だったと思うんだけど、
このプロジェクトが始まったきっかけって何だったの？
Taylorが最初に出したビジョンってどんな感じだった？
「こういう風にやってくれ、3つ作って、それぞれ独立したリポジトリにしよう」みたいな感じだったのか、
それとも「こういう方向性でやりたいんだけど、あとは任せるよ」って感じだったのか、どうだった？

Tony)
うん、最初はTaylorがツイートで「新しいスターターキットは、それぞれ独立したリポジトリになる。React、Vue、Livewireの3種類を用意する」って構想を話してたんだ。
そのツイートには色々なフィードバックがついて、それを元に方向性が決まっていった感じだね。

僕がLaravelにジョインしたとき、Taylorがそのツイートを送ってきて、「これが今考えてるアイデアなんだけど、どう思う？」って聞いてくれたんだ。
それでTaylorと Joe Tannenbaumと一緒に話し合って、
「どういう形にすればより良くなるか」とか、「追加すべき機能は何か」っていうのを詰めていった。
例えば、「チーム機能を組み込むべきか」「2要素認証をどう扱うか」みたいな話もしてたね。

だから、「これを作って」って言われて、いきなり作り始めたわけじゃなくて、
かなりの時間をかけて、フィードバックをもらいながら、しっかり計画を立てた感じだったよ。
その中で、例えば「ShadCN（UIコンポーネントライブラリ）をVue版に入れるべきか？」とか、
「Livewire版はVoltを使うべきか？それともシンプルなLivewireコンポーネントのままがいいか？」とか、色々な議論があった。

Voltに関しては、Twitterでも「なんで普通のLivewireじゃなくてVoltなの？」って議論があったよね。
新しい技術って、最初はみんなちょっと警戒するものだから、その気持ちはすごく分かる。
でも、全部が完璧に正しい選択をできるわけじゃないし、新しいことに挑戦するのは大事だと思ってる。

Vueは前から結構やってたから、割とスムーズに取り組めたけど、Reactはこれをやる前に半年くらい触った程度であまり知識がなかったんだ。だから僕も非常に多くのものを学んだよ。
僕は全ての技術が好きなんだ、NodeであれLaravelであれね。
まぁでも、やっぱり Laravelが僕のホームベース だし、一番手が早いのはLaravelなんだよね。

結局のところ、「自分が一番効率的に開発できるものを使うのが正解」だと思ってる。
それがLaravelでもNodeでも、どんな技術でもいいんだけど、
大事なのは「楽しく開発できるかどうか」だよね！

Matt)
そうそう、これはすごく面白い話なんだけどさ。
よく「自分専用のスターターキットを持つべき」っていう意見があるじゃん？
例えば Michael Dyrynda も「自分用のスターターキットを作って、毎回新しいLaravelアプリを始めるときにすぐ使えるようにするべきだ」ってよく言ってるよね。
でも、実際のところ スターターキットを最新のLaravelのバージョンに維持し続けるのって大変 だと思うんだよ。
そのために 専用のツール を作ったりしてるの？ それとも今のところは 手作業で アップデートしてる感じ？

Tony)
今のところは 完全に手作業 でアップデートしてるよ。
基本的には 新しいLaravelのバージョンが出るたびに依存関係を更新 するっていう感じだね。

でも、それだけじゃなくて、他にも考えなきゃいけないことが結構ある んだよね。
例えば ShadCN（ShadCN Vue） も使ってるんだけど、これが まだTailwind CSS v4に対応してない んだ。
だから、Laravelだけじゃなくて、こういう 周りのオープンソースプロジェクトの進捗もチェック しないといけない。

実際、Tailwind v4がリリースされたのって めちゃくちゃ最近 じゃん？
だから、僕たちもリリースの 1〜2日前の夜中に必死にコードを書いて、「Tailwind v4入れられるか！？」「ShadCNの最新バージョン対応できるか！？」ってバタバタしてた（笑）。

でも、そのおかげでめちゃくちゃ面白い経験ができたんだよ。
ShadCNの作者にTwitterでメッセージ送ったら、「おお、今ここまでできてるよ！スターターキット送ってくれたらフィードバックするよ！」 って言ってくれてさ。
いやもう、そういう めちゃくちゃすごい人たちと気軽にやり取りできる って、本当にクールな世界だなって思ったよ。

Matt)
そうそう、それに ShadCNの開発者 って、今ではネットでめちゃくちゃ有名な人だけど、もともと Laravelの開発者だった って知ってた？

Tony)
えっ、マジで！？ それ知らなかったわ！

Matt)
そうなんだよ！つい最近のツイートで、「最初にプログラミングを始めたのはLaravelだった」って言ってたよ。

Tony)
うわ、それめっちゃいいね。

スターターキットへの反響と対応

Matt)
でさ、スターターキットを最初にリリースしたとき、React・Vue・Livewireの3つ を用意してたじゃん？
でも、その後すごい議論が起こったよね。
「2要素認証はどこ？」とか、「API向けのスターターキットが欲しい」とか、いろんな意見が飛び交ってた。
まぁ、最初から 完璧なものは作れない ってのは分かるけど、僕が気になってるのは、
今後追加される機能って もともと最初から予定してたもの なのか、それとも リリース後のフィードバックを元に方向性を決めてる のかってこと。
例えば 2要素認証 みたいなのは「最初からいつか入れるつもりだった」のか、
それとも「まずリリースして、ユーザーの声を聞きながら進めてる」って感じなの？

Tony)
そうだね、今やってるのは ユーザーのフィードバックをしっかり聞きつつ、でも同時にLaravelチームとして「何が最適か」も考える っていうバランスを取ることかな。

例えば、Taylorが Voltを使わないLivewire版のスターターキット をリリースしたのも、
「なんでVoltなんだ？」っていう意見がたくさん出たからだよね。
やっぱり、みんなの意見をちゃんと聞くことはすごく大事 だと思う。

でも、追加機能を考えるときには、単に「ユーザーの声を聞いて全部追加すればいい」ってわけじゃなくて、
どうやったらReact・Vue・Livewireの各スタックにうまく統合できるか っていうのを考えないといけない。

例えば、将来的に チーム機能・2要素認証・課金システム みたいな機能を追加したとする。
これを React・Vue・Livewireのそれぞれに個別に実装 していったら、
管理する側の負担がめちゃくちゃ大きくなるじゃん？

だから、1つの共通の仕組みを作って、どのスターターキットにも簡単に組み込めるようにする っていうのが理想なんだよね。
例えば、Laravel Spark みたいに、プラグ＆プレイで簡単に機能を追加できる仕組みを作れたら最高だなって思ってる。
「このルートを追加すればOK」とか、「イベントを発火させれば自動で動く」とか、そういう形にできれば、
全部のスターターキットに一括で変更を適用できる から、管理も楽になるしね。

とはいえ、まだ 具体的にどう実装するかは決まってない んだよ。
今週、Joe・Taylorと一緒に話し合って、どう進めるのがベストなのか ブレスト（ブレインストーミング） する予定。
だから、今後どうなるかは、まだこれから決まっていくって感じかな！

Matt)
そうそう、これを聞けてよかったよ。
たぶん多くの人が「これはもう解決済みの問題なんだから、なんでそれをわざわざ変えたの？」って思ってるんだよね。
でも実際は、新しいアーキテクチャになってるわけで、「前のほうが良かった！」って単純に言える話じゃないんだよね。

個人的に、僕は Jetstream の一番の批判者と言ってもいいくらいで（笑）、
何度もポッドキャストとかで「Breezeを使え！」って言い続けてきたんだよね。
で、今回の 新しいスターターキット の方向性は、かなりBreezeに近くなったと思う。
どのファイルがどこにあるのかが めちゃくちゃ明確 になったし、
全部アプリケーション内にあるから、「依存関係の奥深くに埋まってる」みたいなこともない。

ただ、新しいアーキテクチャになったことで、確かに 機能の維持管理は難しくなった よね。
例えば 「チーム機能がほしい！」 って言われても、
単に作るだけじゃなくて、React・Vue・Livewireの3つすべてで維持管理しなきゃいけない っていう問題が出てくる。
だから「やりたいけど、これは技術的にかなりのチャレンジだよね」って話になる。

それに、Laravelのチームがすごい人たちばかりだからって、
「なんでもできるでしょ？できないのは意地悪してるからでしょ？」 みたいに思われるのは違うんだよね（笑）。
実際、めちゃくちゃ難しいこともあるし、簡単に解決できるわけじゃない。

でも、こういう問題をどう解決していくのか、めちゃくちゃ楽しみだよ！
1〜2ヶ月後くらいに、また君を呼んで「どうやって解決したのか」って話を聞きたいな。
もしくは Joe・Taylorと一緒に 出てもらって、「どうやって問題をクリアしたのか」って話してもらうのも面白そう！

Tony)
ぜひぜひ！ それめっちゃ楽しそうだね！

それに、こういう話って Reddit とかでよく議論されるけど、
Reddit民の意見ってなかなか面白いんだよね（笑）。
顔も名前も出さずに、純粋に思ったことを自由に言える場だから、いろんな意見が飛び交うし。

でも、どんなものを作っても 絶対に賛否両論が出る のは避けられないよね。
Laravelが大きくなればなるほど、批判の声も増えるのは当然 だと思う。

たとえば、TaylorがForgeをリリースしたとき も、
Redditでは 「ほら見ろ、オープンソースを金儲けに使い始めたぞ！」 みたいなこと言われてたんだよ。
でもさ、「いや、ちょっと待てよ？」って思うわけ。
彼は 世界で最高のオープンソースフレームワークを作ったんだぞ？
それで ちょっとくらい収益化して、それをフルタイムで続けられるようにするのが何か問題なのか？ ってね（笑）。

結局のところ、「100%全員を満足させることなんて不可能」 なんだよね。
でも、それは 批判してる0.01%の声 であって、
残りの99.99%の人たちは、Laravelの進化を楽しんでくれてるし、僕自身もめちゃくちゃ楽しんでる！

Matt)
Matt:
うん、そのRedditの価値についての話、すごく共感するよ。

Laravelのコミュニティって、意図的に「フレンドリーでポジティブな空間」にしようとしてる じゃん？
これは めちゃくちゃ素晴らしいこと なんだけど、その 意外な副作用 もあるんだよね。

つまり、「みんなポジティブでいたいから、批判的な意見を言いづらくなる」っていうこと。
「雰囲気を壊したくない」とか「ネガティブなことを言うと嫌われそう」って思って、
本当は気になってることがあっても、あえて言わない みたいな空気が生まれるんだよね。

Twitterとか、健全な関係性の中では特にそういう傾向が強い。
だから、建設的なフィードバックが出にくくなるんだよね。

で、その反対に Reddit（特にLaravelやPHPのサブレディット） みたいな場所は、
今度は 「ネガティブすぎる方向に振り切ってる」 んだよね（笑）。
正直、僕は Reddit LaravelもReddit PHPもそんなに好きじゃない。
だって、あそこにいる人たちって 「無料のソフトウェアに対して匿名で文句を言う権利がある！」 みたいな態度の人も多いからさ（笑）。

でも、Redditの良いところは、「みんなが言いにくいことも遠慮なく言ってくれる」 って点なんだよね。
だから、Laravelの 「明るくポジティブな空間」 に、ちょっとだけRedditのスパイスを加える くらいがちょうどいいのかもね。
つまり、ポジティブさは維持しつつも、批判的な意見もちゃんと拾えるバランス を取るのが理想かなって思う。
そういう視点を持つのはすごく大事なことだと思うし、君がそういう考えを持ってるのは素晴らしいね！

Tony)
ありがとう！

でもね、オープンソースの概念自体が、この10〜15年で大きく変わった と思うんだよね。

昔は 「えっ、これ無料で使えるの！？ すごい！ ありがとう！」 っていうのが普通だった。
でも、今は 「無料で提供するのが当たり前」 になって、
「なんでこの機能ないの？」「これも欲しいんだけど？」みたいな要求がどんどん増えてる（笑）。

まあ、これは オープンソースが広く普及した結果 だから、ある意味で自然な流れなんだけどね。
とはいえ、無料のものに対して 「感謝」よりも「要求」が先に来る文化 には、ちょっと考えさせられる部分もあるよね。

Matt)
そうそう、「権利意識（Entitlement）」って本当にあるよね。

子育てしてると、これをめちゃくちゃ実感するんだよ（笑）。
子どもには 「できるだけいいものを与えたい」 って思うけど、
同時に 「何でももらえるのが当たり前」っていう甘えた態度にはなってほしくない って思うじゃん？
それって、まさに インターネットの世界 でも同じことが言えるんだよね。

Tony)
うん、100%同意！

親って、本当に「自己犠牲の仕事」だよね。
僕自身も、子どもの頃は 母親がやってくれてたことに全然感謝してなかった んだよ。

でも、大人になって初めて 「ああ、あれってめちゃくちゃ大変なことだったんだな…」 って気づいた。

スターターキットの未来

Matt)
うん、確かにそうだね。
じゃあ、Tightenからもらった質問をいくつか聞いていこうと思うんだけど、主に 「Laravelのスターターキットの未来」 に関する話だよ。

まず、Tightenのチームには APIスターターキットをめちゃくちゃ気に入ってる人 が何人かいて、
そのうちの一人が「しつこくてごめんだけど、APIスターターキットっていつリリースされるの！？」って聞いてるんだよね（笑）。
これは後で聞くとして、もう一つ気になってるのが、「コミュニティ製のスターターキット」 の話。

Tightenの Tony Messias が、どのリポジトリだったか忘れたけど、laravel installer にカスタムフラグを追加するPR を出したらしいんだよね。
例えば laravel new my-app --starter=my-custom-kit みたいな感じで、
Laravel公式のスターターキットじゃなくても、好きなスターターキットを選べるようにする機能 ってことだと思うんだけど、
Ed Grohl も 「コミュニティが作ったスターターキットをどこかでまとめて管理できないか？」 みたいなことを話してたみたい。

だから、今回聞きたいのは 2つ ！
A: APIスターターキットのリリース予定はあるのか？
それとも、次に開発してるものって何か他にある？
B: Laravel公式じゃない「コミュニティ製スターターキット」の扱いについて
• これは公式として サポートする予定 なのか？
• それとも「勝手に作るのはOKだけど、公式のインストールシステムには組み込まない」って感じなのか？

API スターターキット

Tony)
じゃあ、まず APIスターターキット から話そうか。

実はTwitterとかでも「APIスターターキットが欲しい！」って声がめっちゃ多くて、
僕もいろんなところでこの話を見かけてるんだよね。

でも、一つ気になってるのが、「スターターキットのメイン機能って何か？」 ってことなんだよ。
今のところ、どのスターターキットも 認証（Authentication）がメイン になってるじゃん？
ログイン・登録・パスワードリセット機能があって、そのあとダッシュボードやユーザー設定ページがある。
でも、実際に一番大事なのは 「認証の仕組み」 なんだよね。

で、Laravelには Fortify があるよね？
Fortify を使えば、APIベースの認証はすでにフル機能で提供されてるんだよね。
だから、もし 「APIスターターキットが欲しい」 って人がいたら、
React・Vue・Livewireのスターターキットから認証ルートを削除して、代わりにFortifyを使えばいいんじゃないか？ って思ってたんだよ。

でも、確かに「APIスターターキット欲しい！」って声が多いから、
ちゃんとした形でそれを提供する方法を考えたほうがいいかも しれないね。
たとえば、最初から 「認証がFortifyベースになってるAPIスターターキット」 を用意するとか？

Matt、君のほうでみんなが本当に求めてるAPIスターターキットってどんなものか何か分かる？

Matt)
なるほどね。
Titanの Niiko ってやつが、最初に API向けのスターターキット についてTaylorに聞いたみたいで、
今週のTitanのSlackで「こういうものが欲しい」って話してたんだよね。

彼の言ってたことをまとめると、
Breezeには「フロントエンドなしの純粋なAPI用Laravelプロジェクトを作れるオプション」があった んだよ。
APIモードでインストールすると、
• 認証用のエンドポイントをセットアップ（Fortifyを使う）
• 必要最低限のアプリのスキャフォールド（ベース構造）を作成
• 不要なものを全部削除（JavaScript、CSS、package.json、vite.config.js など）
が行われる感じ。

彼が実際にPRを作って見せてくれたんだけど、
結局 「APIスターターキット」っていうのは、完全に新しいコードを提供するというよりも、
Laravelの標準インストールを「API向けに設定する一連の手順」 みたいな感じなんだよね。

ここが今までのスターターキットとの大きな違いかもしれない。
以前のスターターキットって、
「必要なパッケージを追加・削除するコマンドの集まり」 みたいな感じだったけど、
今のスターターキットは 「アプリのテンプレート」 に近い作りになってる。

だから、「APIスターターキットを作るなら、Laravelのインストール時にFortifyを設定して、不要なファイルを削除する だけでも十分なんじゃないか？」って感じなんだよね。
もちろん、それを スターターキットとして作るのか、Laravel Installerのオプションとして用意するのか は分からないけど、
結局やることは「LaravelをAPI用にセットアップする作業の自動化」ってことになりそう。

Tony)
ああ、なるほど！めっちゃ助かる、その説明。

つまり、Laravel Installerでスターターキットを選ぶときに、
「APIモード」 を選択できるようにして、
• FortifyのAPIエンドポイントをセットアップ
• JavaScriptやその他の不要なものを削除
みたいな流れにすればいいってことか。

それなら Laravel Installerのオプションに追加する形で実装できそう だね。
これはTaylorやJoeと話してみる価値があるね。

今のところ 「いつできるか？」 っていうタイムラインはまだ分からない。
正直、ここで「数週間後にはできるかも！」なんて言っちゃったら、
自分で自分の首を絞めることになる（笑） から、今は何とも言えないけど。

でも、この話をもらったことで、「何を作るべきか」がかなり明確になったから、
TaylorやJoeと話し合うときに 具体的な方向性を持って相談できるよ！

ほんとにありがとう。とても参考になったよ。

Matt)
じゃあ、Nicoが作ったAPIスターターキットのPRを送るよ。
これで、君たちが話し合うときに 実際のdiffを見ながら議論できると思う。

カスタムスターターキット

Tony)
ああ、それは助かる。ありがとう！こうやって話しながら実際の作業も進められるのはいいね。

じゃあ、コミュニティ製のスターターキットについても少し話そうかな。
個人的には、Laravelをインストールするときに「コミュニティスターターキット」っていうオプションを追加するのはすごくいいアイデアだと思ってる。
たとえば、laravel new を実行するときに、スターターキットなし、React版、Vue版、Livewire版、そしてコミュニティスターターキット版みたいな選択肢を用意するとかね。
コミュニティスターターキットを選ぶと、API経由でデータを取得して、登録されているコミュニティ製のスターターキットを一覧表示する仕組みにできるかもしれない。
これは結構面白い仕組みになりそうだよね。

個人的には、Laravelの公式サイトで、公式のスターターキットに加えて、コミュニティ製のスターターキットも一覧で見られるようにするのも良さそうだと思ってる。
ただ、これをやるには、フルタイムで管理する人が必要になると思うんだよね。
なぜかというと、スターターキットを作った人が継続してメンテナンスしてくれるとは限らないし、アップデートされないスターターキットをずっと掲載し続けるのがいいのかどうかも悩ましいところだから。

あと、品質の管理も結構難しい問題だと思う。
例えば、作った人が「せっかく作ったのに、公式には載せてもらえなかった！」って感じる可能性もあるしね。でも、こういう仕組みをやるなら、Envatoみたいに、基準をしっかり設けて、一定の品質を満たしたものだけを掲載するのもアリかもしれない。
Laravelが「これは公式として掲載します！」って言う以上、一定の品質は担保しないとLaravelのブランドにも影響するからね。

とはいえ、個人的にはコミュニティスターターキットの仕組みがあったらすごく面白いと思ってるし、どんなスターターキットがあるのかチェックする役割を僕が担当するのも楽しそうだなと思ってる。
だから、もし「こんなスターターキット作ったよ！」っていうのがあったら、ぜひTwitterで僕に連絡してほしい。リポジトリのリンクをつけて送ってくれたら、僕がチェックするし、それがコミュニティスターターキットの仕組みを作るきっかけになるかもしれないからね。^[1]

Matt)
最高だね。
それに、ちょうど数日前にEd Grohlも「コミュニティで作ったスターターキットを一箇所にまとめる方法を探してる」って言ってたんだよね。
Tightenでも、以前Novaで同じような問題に直面したことがあったんだ。みんながNovaのパッケージを作るようになったけど、それをどうやって探せばいいのか、どれが信頼できるのか分からなかった。
だからnovapackages.comっていうサイトを作って、Nova向けのパッケージを一覧で見れるようにしたんだ。Laravelでやろうとしてることと似てるよね。

それに、Tightenではこのサイト用のAPIも作ってて、もしLaravelが必要なら使えるようにすることもできると思う。
もしLaravel側で「公式の承認を与えるのは難しい」という話になるなら、もう一つの方法として、コミュニティ主導でやるっていうのもアリかもしれないよね。
例えば、ユーザーがスターターキットを評価したり、怪しいものをフラグで報告できるようにするとか。そういう形なら、公式が全部を管理しなくても、ある程度の品質を保てるかもしれない。

Edともう少し話をしたら、また君にも連絡するよ。
でも、今の段階で一番現実的なのは、とりあえず スターターキットを作ってる開発者が君に直接連絡して、「こういうの作ったよ！」って見せてもらうことだと思う。
配布の仕組みをどうするかはまだ決まってないけど、とりあえずそうやって少しずつ形にしていくのがいいかもしれないね。

Tony)
うん、それがベストな方法だと思うな。とりあえず、コミュニティで作られたスターターキットを集めるためのページを作って、そこに「最新版にアップデートしないと削除される可能性があります」みたいな注意書きをつけるのはありかもしれないね。
例えば、Laravel 13、14とバージョンが上がっていったときに、アップデートされないスターターキットはリストから削除するっていうルールを作るとか。

考えなきゃいけないことはたくさんあるけど、こういうスターターキットのテンプレートページができて、みんなが自由に提出できる仕組みがあったらすごく面白いと思う。
僕自身、コミュニティで作られたスターターキットを試してみるのも楽しそうだしね。

スターターキット以外で取り組む予定のこと

Matt)
最高だね。本当にワクワクする話ばかりだった。いつもこんなに生産的なポッドキャストになるわけじゃないんだけど、今回はすごく実のある話ができたと思う。こういうの、めちゃくちゃ好きだな。

さて、そろそろ締めに入ろうと思うんだけど、最後に聞きたいことがある。
今日はスターターキットの話ばかりしてきたし、今のところ君のLaravelでの仕事の大部分はスターターキットに集中してると思う。
でも、それ以外に何か楽しみにしてることや、ワクワクしてるプロジェクトはある？
仕事に関係することでも、関係ないことでもいいから、今取り組んでることや今後の展望について聞かせてほしい。

Tony)
そうだね、今のところスターターキットが僕のメインの仕事なのは間違いない。でも、それ以外にもめちゃくちゃ楽しみにしてることがあるよ。特に Laravel Cloud の今後にはすごく期待してる。

実は、Cloudに関してもいくつかアイデアがあって、いずれ提案してみたいと思ってるんだけど、まだLaravelの開発の流れを掴んでる最中だから、もう少し時間が必要かな。
でも、将来的にCloudがどんな風に進化するかを想像するとすごくワクワクするんだ。
例えば、リポジトリがなくてもCloud上でスターターキットを選んで「デプロイ」って押すだけで、すぐにアプリがURL付きでデプロイされるようになったらすごく便利だと思わない？
もちろん、そのまま使うだけじゃなくて「このアプリをGitリポジトリと紐づけて、本格的に開発を進められるようにする」みたいな流れを作ることもできると思う。

それに、ここ数週間Cloudを触ってるんだけど、設定がめちゃくちゃ簡単なんだよね。本当に30秒でLaravelのアプリが立ち上がるのは、何度やっても驚きだよ。

あと、laravel.comのサイト もこれからどんどん進化していく予定なんだ。
最初に新しいデザインが公開されたとき、モバイルでの表示が崩れてるとか、一部の機能がちゃんと動かないとか、いろんなフィードバックがあった。
でも、デザインを担当している David と話してたら、彼が「これは最初のステップに過ぎない」って言っててね。
新しいLaravel 13や14が出たタイミングでまた一新するんじゃなくて、これからも継続的に改良していく予定なんだって。

よく「新しいウェブサイトが公開されたら、それで完成」って思われがちだけど、今回はそうじゃない。ずっと改善を続けていって、本当に誇れるサイトに仕上げていくつもりなんだ。
僕もそのプロジェクトに関われるのがすごく楽しみだし、これからどんな風に成長していくのかワクワクしてるよ。

Matt)
それはすごくいいね。そういえば、Jason…たしかJason B.S.だったと思うけど、彼もウェブサイトの構築に関わってたって言ってたんだよね。
チームの中でどんな人が関わってるのか気になってたんだけど、君もサイトの開発に関わってるんだね？

Tony)
うん、Jasonも手伝ってくれてたよ。
僕はスターターキットのページを担当したんだけど、たまにJasonが突然PRを送ってきて、細かい部分を修正してくれることがあったんだよね。
まったく予告なしに、気づいたら修正されてて「おお、すげぇ！」ってなった（笑）。
彼、本当に優秀で、たしかCloudのホームページも彼が手掛けたと思う。めちゃくちゃ才能のある人だよ。

Matt)
スターターキットのページ、すごくいい感じに仕上がってるよ。本当に素晴らしい仕事だったと思う。

Tony)
ありがとう！
でも、デザインを作ったのはDavidで、僕はそれを実装しただけなんだ。
Tailwind v4は本当にすごいよ。
スターターキットのページを見ると、3つのアプリが重なってるようなデザインになってるでしょ？
あれもTailwindの新しいスタイルを使ってるんだよね。

Tailwind v4を触ったことがあるか分からないけど、本当にシンプルにアニメーションを追加できるんだよ。
「最初は不透明度ゼロで、ページが読み込まれたら100にする」っていうのが、たった1行で書けちゃう。
例えば、starting:opacity-0 opacity-100 って書くだけで、ページをリロードするとスムーズにフェードインしてくれる。

今の開発環境って、すごく恵まれてるよね。
昔なんて、Photoshopでボタンを作って、角を丸くするだけでも一苦労だったのに…（笑）。

Matt)
そうだよね。昔だったら、不透明度のアニメーションをつけるのなんて、まったく別のレベルの話だったよね。本当に信じられないくらい簡単になった。いやー、感慨深いな。

さて、そろそろ締めようかと思うんだけど、今日話せなかったことで「これは話しておきたかった！」っていうことはある？

Laravelのこれから(VCの影響)

Tony)
いや、特にないかな。ただ、一つだけ言いたいのは、Laravelチームの一員になれたことが本当に光栄だ ってこと。いまだに信じられないよ。
10年以上も使い続けてきたこのフレームワークの開発に、今こうして関われていることが、本当に夢みたいなんだ。
しかも、めちゃくちゃエキサイティングな時期にね。

Laravelのチームにいる人たちは本当に優秀な人ばかりだし、今は VCによる支援 もあるから、これからLaravelの人気はますます加速していくと思う。
ただ単にチームの才能がすごいっていうだけじゃなくて、VCのバックアップがあることで、企業がLaravelを採用しやすくなるんだよね。

僕は以前、VC支援を受けている企業で働いていたことがあるんだけど、そういう会社では「この技術を使って開発しろ」っていう指定があることが多かった。
なぜかというと、そのVCが支援している他の企業との関係があるからなんだよね。たとえば、「Reactを使え」とか「Vercelでホスティングしろ」とか言われるのは、単に技術的な理由だけじゃなくて、VCの意向も絡んでることがある。

だから、今LaravelがVCの支援を受けたことで、逆に「いや、Laravelで開発しよう」っていう流れが生まれる可能性が高い。
以前だったら「ReactとVercelで作れ」って言われてたような案件が、これからは「Laravelでやるのがベストだよね」っていう風に変わっていくかもしれない。

それに、Taylorが「もしVCの支援を受けなかったら、それこそLaravelを裏切ることになる」と言ってたのも、すごく納得できる。
もし何もしなかったら、「Laravelはここまでの成長で終わり」っていう未来になってたかもしれない。
でも、今は違う。
VCの支援を受けて、もっと大きく、もっと良いものになっていく。
Laravelが進化し続けることで、これからWebアプリケーションを作るのが もっと楽しくなるって確信してるよ。
本当に、こんな素晴らしいチームの一員になれて最高だし、これからの未来が楽しみで仕方ないよ。

Matt)
もうそろそろ締めるところなんだけど、その話は本当に重要なポイントだと思うから、ちょっとだけ追加で言わせてほしい。

この1年で、何度もビジネス開発のミーティングに参加してきたんだけど、そのたびに同じような状況を見てきたんだよね。CTOも創業者も、みんな「Laravelを使いたい」って言ってるのに、どこかの誰かが「いや、うちはXYZを使わなきゃダメだ」って言い出す。
理由はいろいろあるけど、たとえば投資先の関係だったり、スタートアップ仲間が「これが唯一の正解だ」って言ってたりね。
その結果、Laravelが選ばれずにプロジェクトごと失われることもあるし、CTOやリードエンジニアが「本当はLaravelを使いたかったのに、使えないまま開発が進んでしまった」っていうケースもあるんだよね。

これまで僕は、Laravelがプライベートエクイティ（PE）の支援を受けたことで得られる最大の価値は、単純に「認知度が上がること」だと思ってたんだけど、実はそれだけじゃなかった。
この支援によって、単にLaravelを知る人が増えるだけじゃなくて、「Laravelを使ったほうがいい」って勧める人が増える可能性があるんだよね。
投資家やスタートアップのネットワークの中で、「他の会社がLaravelを使ってるから、うちも使うべきだ」っていう流れが生まれるかもしれない。これは本当に大きな影響を与える話だと思う。
いい視点をシェアしてくれてありがとう。

Outro

Matt)
さて、そろそろ終わりにしようと思うけど、今日は本当にありがとう。
スターターキットの開発、お疲れ様！
これからのアップデートもすごく楽しみにしてるし、Laravelでの他の仕事についても引き続き期待してるよ。
ぜひまた近いうちに、このポッドキャストに戻ってきてくれると嬉しいな。
次回はチーム機能やSaaS関連の話なんかもできたらいいね。

Tony)
それは最高だね！
僕もぜひまた呼んでほしいよ。本当に今日はありがとう。
実は僕、このポッドキャストの第一シーズン、TaylorとJeffrey Wayがやってた頃からの大ファンなんだ。だから、こうして実際に出演できたことが本当に光栄だよ。ありがとう！

Matt)
こちらこそ、ありがとう！
そしてリスナーのみんなも、聞いてくれてありがとう。また次回、お会いしましょう！

脚注

1. カスタムスターターキットは3/8にlaravel/installer v5.14.0でリリース済。 ↩︎