Laravel Podcast - 2025年5月
Maru2025/05/12
Laravel Podcast Season7 Episode 6 - 前編
Matt Stauffer(Tighten CEO) x Joe Dixon(Laravel Engineering Team Lead)
Intro
Matt)
やあみんな、Laravel Podcast シーズン7へようこそ。ホストのMatt Staufferです。TightenのCEOをやってます。このシーズンでは、毎回Laravelチームのメンバーをゲストに迎えてお送りします。
今日はLaravelのエンジニアリングチームリード、Joe Dixonと話します。
Joe、ちょっと自己紹介と、最近Laravelでどんなことをやってるか教えてもらえる？
Joe)
やあ、Matt、呼んでくれてありがとう！
僕の名前はJoe Dixonで、Laravel Cloudのエンジニアリングチームリードをやってるよ。
Laravelでの日々の仕事は、まあ…ずっと変化し続けてるって感じかな。特にここ1年くらいは、かなり波乱万丈だったと思う。
というのも、Laravel Cloudの開発を始めたのが2024年3月で、まだ1年ちょっと前なんだけど、当初はめちゃくちゃ小さなチームだったんだ。
最初は僕とNuno、それから早い段階でチームに加わったChris Fidao、そして当時はMohamedもCloudに取り組んでた。
だから最初の頃は、僕もがっつりコード書いてたし、プロジェクトの進む方向を決めるために、いろいろ手を動かしてた。
で、それから1年ちょっと経った今、さっきこの収録の前にちょっと人数を数えてたんだけど、今はチームがだいたい18人近くまで増えてる。今は14人だけど、もうすぐ18人になる予定なんだ。
つまり、最初はめちゃ小さなチームで、超スピードでLaravel Cloudを世に出すぞって頑張ってたのが、今じゃチームもかなり大きくなって…。
で、それにともなって僕の役割も大きく変わってきたって感じだね。
Matt)
それめちゃくちゃ聞きたいこといっぱいあるんだけど、毎回最初から話を聞くようにしてるから、ちょっと時間を巻き戻してもいい？
Joe)
ごめん、ちょっと先走っちゃったね。
Laravel入社前について
Matt)
いやいや、むしろそういう話が聞きたかったんだけど、順番に掘っていきたくてさ。
Laravelでフルタイムで働く前って、何をしてたの？ それからどういう経緯でLaravelに入ったのか、聞かせてほしいんだ。
みんなそれぞれ全然違う経路で来てるし、Joeの場合はどうだったのか気になるんだよね。
Joe)
そうだね、どこまで遡って話せばいいか迷うけど、そこそこ前から話すね。
僕、大学に行ったのってちょっと遅めで、たしか21歳くらいからだったと思う。
その頃ってまだ自分が何をしたいのかよく分かってなかったんだよね。
で、たまたまめちゃくちゃウマが合う講師がいて、その人がPHPを教えてたんだ。
その後、大学を卒業して、何の仕事をするかまだハッキリ決まってなかったんだけど、
その講師がある会社を紹介してくれて、そこで「KTP（Knowledge Transfer Partnership）」っていうプログラムに参加することになったんだ。
これはイギリス特有の仕組みなんだけど、大学・企業・卒業生の3者で連携する形のプロジェクトで、
僕が通ってた大学とも提携してて、まさに僕はピッタリその枠にハマったんだ。
で、そこにフレッシュな状態で入って、僕の役割はその会社のウェブ系の仕組みを全部リビルドすることだった。
当時使ってた技術は ExpressionEngine[1] だったんだけど…Matt、ExpressionEngine使ってたことある？
Matt)
うん、それがきっかけで僕もCI（Code Igniter）やコーディングを始めたんだよね。
Joe)
おお、そっか。
僕は当時 ExpressionEngine 関連のカンファレンスにめちゃくちゃ参加してて、
というのもそのKTPには研修費用の予算もついてて、
それを使ってとにかく知識を吸収しまくってたんだ。
で、あるカンファレンスで聞いたトークがきっかけだったんだけど、
たしか Joel Bradbury っていう人が話してて、Twitterでも一度感謝を伝えたことがあるんだけど、
僕にとってはかなり大きな存在なんだよね。
彼のトークって、ExpressionEngine自体がテーマじゃなくて、たしか「WordPressをバックエンドにしてその上にLaravelをのせて動かしてみた」みたいな「フランケンシュタインアプリ」の話だったんだ。
で、それが僕が初めて「Laravel」って言葉を聞いた瞬間だった。
そのときから彼はLaravelの良さをめちゃくちゃ熱く語ってて、
僕もそのカンファレンスから戻って、試してみたらすぐにハマったんだよね。
Matt)
いい話だなぁ。
Joe)
何年だったかは忘れちゃったけど、たぶんLaravel 4.1か4.2の頃だったと思う。
で、その後、会社に戻って、「やっぱExpressionEngineって、うちの要件には合ってないっすね…」って説得して、Laravelに全部リプレイスしたんだ。経験としてはまだ浅かったけど、なんとかやりきった。
結果的にすごくいい経験になって、その会社にはさらに数年残ったあと、スタートアップで働くチャンスがあって、
3人チームのうちの1人として参加したんだ。
そのスタートアップには6年間いて、その間ずっとLaravelがメインの技術スタックだった。
Matt)
めちゃクールだね。
Joe)
そんな感じでLaravelとの関わりがどんどん深まっていったんだけど、
その後、Jessのインタビューでも言ってたけど、彼女と同じように、Taylorのツイートに反応したんだ。
ただ、JessやTimほどの気合いの入った応募内容[2]ではなかったけどね（笑）
Matt)
他にあんな感じの人はいたのかな？（笑）
Joe)
いや、いないと思う。かなりクリエイティブだよね（笑）
僕はというと、Taylorとは当時一切話したことなかったんだけど、
応募のときにちょっとでも目立てるようにしたくて、奥さんとも相談してさ、
メールの件名を「Here be dragons（ここにドラゴンあり）」にしたんだ。
ちょっとしたジョークのつもりだったんだけど、それが効いたかは分からない（笑）
正直、自分が採用されるなんて思ってなくて、ダメ元で挑戦した感じ。
「せっかくチャンスがあるなら、投げてみよう」って気持ちだったんだよね。
で、Taylorと何度かやりとりしてるうちに、話が進んで…
気づけばLaravelで働いて、もうすぐ3年になる。
今でもほんと夢みたいな気持ちでさ、
「これ本当に現実？」って毎日ちょっとつねって確かめてるよ（笑）
Matt)
ほんとすごいよね、そして面白いのが、JoeとかJessとかと話してると、
僕の中では「いや絶対この人たち受かるでしょ！」って思ってたんだよね。
たまにTaylorが「この人どう思う？」って僕に聞いてくることもあったけど、
たいていの場合は彼自身でもう判断できてたみたいで、
彼ってそういう能力の見極めがめちゃくちゃうまいんだよね。
で、そのあと誰かが採用されたって聞いたら、「そりゃそうだろ！」って思うんだけど、
当の本人たちは「いや〜、受かるか不安だった」とか言うんだよね（笑）
「僕に聞いてくれたら『絶対受かるよ！』って言ったのに！」って思う（笑）
とにかく、本当に実力で勝ち取ったポジションだよ。
Laravel入社後の業務
Matt)
で、Laravelに入った最初の頃は、どんなことをやってたの？
Joe)
僕は最初からVaporにがっつり関わってたよ。
Nunoと一緒に、ほぼ2人でVaporの開発をやってたんだ。
そのままずっと、Laravel Cloudプロジェクトが始まるまではVaporに専念してて、
期間でいうと2年近くかな。
正直、Vaporは前職での僕にとって“銀の弾丸”みたいな存在だった。
っていうのも、うちの会社はDevOps担当を雇う余裕がなくて、
サーバーまわりのことは全部僕一人でどうにかしなきゃいけなかったんだ。
だから、Vaporはもうまさに「これだよ！」って感じで、
うちの状況にピッタリだったんだよね。
もうね、問題っていう問題をことごとく解決してくれたんだよ。
それまでは週末も「サーバー落ちてないかな…」ってヒヤヒヤしてたけど、
Vaporにしてからは、そういう心配は一切しなくてよくなった。
ほんと僕たちにとっては完璧だったよ。
Matt)
それ、めちゃくちゃいい話だよ。
今のエピソードだけでも、JoeがLaravel Cloudでどれだけ力を発揮できたかってのが伝わってくる。
だって、まさにそれがCloudのコンセプトそのものだからさ。
「なるほどね、そりゃうまくいくわ」って感じだよ。
Joe)
うん、まさに「自分の痒いところに手が届く」ってやつだったよね。
それがまた原動力になってた感じ。
あと、たしか入社して1年くらい経ったころかな、
Taylorが「Laravel用のWebSocketパッケージを作りたい」って言ってたんだよね。
で、うちのチームではやりたいプロジェクトがあると、社内でピッチ（提案）する文化があって、
僕も「それやりたい！」って思って、提案を出したんだ。
それが後に Laravel Reverbになったんだよね。
だからReverbについても、僕がほぼメインでやってたって言っていいかな。
Laravel Reverbについて
Matt)
ちょうどそのこと聞こうと思ってたんだ。
Reverbって全体の中でどんな位置づけだったの？って。
あとはReverbを知らない人がいるかもしれないから、簡単に「Reverbって何なの？」っていう説明もお願いしていい？
今まであったものととどう違って、どう似てるのかも含めて、サクッと教えてくれると助かる。
Joe)
うん、簡単に言うと、ReverbはLaravelアプリにリアルタイム通信機能を追加できる仕組みなんだ。
普通だったら、何か変化があったときにその情報を取得するには、
HTTPリクエストを何度もサーバーに送って、レスポンスを受け取るっていう「往復の待ち時間」が必要になるよね。
たとえば、画面にニュースのテを出して、リアルタイムで更新したいときとか。
そういう場合、1つの手段として「ショートポーリング（短時間ごとにサーバーに問い合わせる）」を使うってのもある。
でも、これはサーバーとの通信を何度も繰り返さないといけないし、効率が悪かったりもする。
一方で、ReverbはWebSocketの実装なんだ。
WebSocketを使うと、サーバーとクライアント間で1回の接続を確立すれば、そのあとはその接続を通じてリアルタイムに情報を送受信できる。
つまり、HTTPのハンドシェイクを毎回する必要がないんだよね。
だから、ページ上の更新がすごく素早くて、即時的に見えるようになる。
もちろん、WebSocketがすべてのケースに最適ってわけじゃないけど、
リアルタイム性が求められるようなケースにはぴったりなんだ。
実際、Laravelの主要なサービス――たとえば Forge、Vapor、Envoyer、Cloudではアプリのデプロイを実行したときの進行状況の表示なんかが、全部Reverbを使ったWebSocket経由で画面に反映されてるんだ。
NightwatchがReverbを使っているかはちょっとわからないけど、間違いなく同様の仕組みでリアルタイム反映に取り組んでいると思うよ。
Matt)
すごいなあ、本当にクールだよ。
僕が本を書いてたような頃って、WebSocket系の機能ってたいていサードパーティーのサービスに頼ってたんだよね。
で、あるときTerry Labrador[3]がたしかNode製のLaravel WebSocket Server みたいなラッパーを作ってくれたのを覚えてるんだ。
それを見たとき、「え、これって自前でWebSocketサーバー立てられるってこと？」ってマジで衝撃だった。
それはPHPで書かれてたわけじゃないし、Laravel製のプロダクトってわけではないけど、「自分でやれる」ってことを見せてもらえたのが、めちゃくちゃインパクト大きくてさ。
だからReverbの話を聞いたときは、正直“黒魔術”か何かかと思ったよ（笑）
「え、それ本当にできるの？」って感じ。
Reverbにはほんと感謝してて、使いやすいからってだけじゃなくて、「今までPHPでは出来ないと思っていたことが実際にはできるんだ」っていうことを見せてくれた初めてのものだから。
それでね、Tightenのチームから質問が来ててさ、
「JoeってReverbを作る前からReactPHPとか非同期系の仕組みに詳しかったの？ それとも仕事の中で覚えた感じ？」って。
Joe)
うん、僕のWebSocketの経験って、PusherのAPIキーを設定ファイルに書くだけだった（笑）
それで「魔法のように動いた！」っていう、それだけ。
だからね、もうAaron Francis になりきるつもりで、
Webの仕様を全部紙に印刷して、最初から最後まで読んだんだよ。
いやほんと、勉強になるけど同時にめちゃ退屈だった（笑）
ReactPHPにはそれまで全然触れたことなかったんだけど、Beyond Codeチームが出してるLaravel WebSocketsっていう別のコミュニティ製パッケージがあって、そこからめちゃくちゃ学ばせてもらったよ。
ReactPHPのドキュメントも読み込んで、結果的には思ってたより早くカタチになったんだよね。
ただ、やっぱり非同期のPHPを書くって、頭の切り替えが必要なんだよね。
普通のPHPとはぜんぜん感覚が違うけど、すごく楽しかったよ！
Matt)
ああ、Beyond Codeの話を出してくれてよかった。
Terryの話をしてるときに、それも言おうと思ってたんだ。
Terryのやつが僕が初めて見たWebSocketラッパーだったんだけど、
たしかにBeyond Codeも、間違いなく最初期の取り組みの一つだったね。
さて、じゃあそろそろ次の話に進もうか。
Cloudの話に入る前に何か他に話したいことってある？
というのも、CloudってJoeが関わってきた中でも最新のことであって、キャリア全体で見ると、他にもいろいろやってきたでしょ？
Laravel Vaporについて
Matt)
…あ、そうだ、Cloudの前にVaporの話を少しだけしようか。
というのも、Cloudは今めちゃくちゃ新しくてワクワクするプロジェクトだけど、Vaporを使ってる人たちって、マジでVaporを愛してるんだよね。
同じように、Forge使ってる人もForgeをめちゃくちゃ好きだと思うんだけど。
で、JoeがVaporに関わってた頃って最初の立ち上げ時からいたの？ それとも、すでに製品として動いてる段階から参加したの？
Joe)
うん、もうすでに動いてた段階だったね。僕が Laravelに入ったのは2022年で、Vapor自体はたしか2019年の Laracon US でローンチされたんだよね。
だから僕が入ったときには、3年経った成熟したプロダクトだったって感じかな。
Matt)
なるほどね、もう成熟してたんだね。じゃあ、Vaporでの開発を通じて新しく学んだことって何かあった？
というのもプロダクトとして成熟しているということが、全員が知っている技術スタックであるということを意味しないと思うんだ。
Joe)
僕は前の仕事でもVaporを使ってたから、Vaporが何かってこと、どう動くのか、どういう課題を解決してくれるのかっていうのは、すでにわかってたんだよね。
それがあったから、Laravelに入ったときもちょっと有利だったというか、AWSの裏側で何が起きてるのかっていうのもある程度把握できてたし。
それと、これたぶんみんなも想像つくと思うんだけど、Laravelに入ってコードベースを読んだときの快適さって、ほんとにすごかった。
もう即座に作業を始められるくらい読みやすいコードで、何か特別な“慣れ”とか“準備期間”とかも必要なくて、「これぞLaravelアプリケーションだな」って感じだった。
だから、開発を始めるまでの立ち上がりは本当にスムーズだったね。
で、学んだことについては詳しく覚えてるわけじゃないんだけど、それまで使ったことのなかったデザインパターンとかがいくつかあって、すごく興味深かったんだよね。
で、その一部はたぶんCloudにも活かされてると思う。
というのも、Nunoと僕は両方のプロジェクトに関わっていて、Cloudの土台作りにおいてもVaporの経験がそのままつながってる部分があるから。
あとは、Vaporっていろんな設定オプションがめちゃくちゃ豊富なんだけど、僕が前の仕事で使ってたのって、その中のかなり限定的な一部だけだったんだ。
だから、Laravelチームに入って、実際にユーザーからのサポート対応をする中で、「えっ、そんな使い方してるの？」っていうケースもあって、そこから「じゃあこれ何やってるんだ？」って調べたり、理解したりしていった感じ。（笑）
だから最初はちょっと試行錯誤しながらやってた部分もあったけど、チームのメンバーが本当に素晴らしくて、特にNunoがそばにいてくれて、最初のころにすごく丁寧に助けてくれたのがめちゃくちゃ心強かった。
AWS APIについて
Matt)
いや〜それはすごいな。
僕はAWSのAPIに触れるたびに「崖から飛び降りたい」って思ってたくらいなんだけど（笑）
VaporでのAWS周りの実装って、もう十分に確立されてた感じ？
それともやっぱりAWSのドキュメントを紙に印刷して全部読むような状態だった？（笑）
Joe)
世界中のプリンター用紙を全部集めても、AWSのドキュメントは印刷しきれないと思う（笑）
Matt)
うん、そうだね（笑）
Joe)
Vaporの中のAWSまわりの仕組みは、たしかにかなりしっかり整ってたとは思うよ。
でも、AWSって常に何かしらの変化球を投げてくるんだよね（笑）
たとえば今でも覚えてるんだけど、VaporってRDS（リレーショナルデータベース）を簡単にプロビジョニングできる機能があるんだよね。
で、そのRDSには証明書（certificate）でのハンドシェイク処理があって、あるとき、その証明書が期限切れになるっていう問題が起きたんだよ。
気づいたらお客さんたちに「あなたの証明書が使えなくなります」ってメールが届き始めてて、「やばい、これどうにかしないと！」ってなってさ。
しかも、サービスを止めずに（ダウンタイムを起こさずに）どうやって更新するかがめちゃくちゃ難しくて、AWSのドキュメントを深く深く掘り下げて、あちこちに散らばったブログ記事とか技術情報とかを全部かき集めて、やっとのことで対応したって感じだったね。
あれはほんとに大変だったよ。
Matt)
僕も似たような対応をやらなきゃいけなかったことがあったから想像がつくよ。
昔、「あ、Valetの証明書って最初は2年で期限切れになるようになってて、今まさに2年経ったユーザーが出てきたぞ…どうする？」みたいなことがあったんだ。
でもそれって個々の開発者のローカルマシンでの話だったし、開発用のマシンだから、ちょっとダウンタイムがあったり、コマンドを一つ実行すれば済むような話で、まあ大したことではなかった。
でも、君たち（Laravelチーム）がやってることって、全然レベルが違うと思うんだよね。
面白いのは、君たちは開発者向けのツールを作ってるんだけど、それがまたその開発者たちが運用する高い稼働時間が期待されるサービスに使われているんだよね。
その期待値って、たとえば僕らがエンドユーザー向けのアプリを開発するときと同じくらい高い。
普通、開発者向けのツールって「オープンソースだし、多少問題あっても理解してもらえるだろう」みたいな雰囲気あるけど、君たちの場合は顧客になるからそうはいかないと思うんだ。
「SSHで入ってこのコマンド実行してね」みたいにさ。
Joe)
うん、ほんとそう。
あのときは「どうやってその問題を解決するか」だけじゃなくて、「どうやってそれをお客さんに伝えるか」っていう部分も含めて、ちゃんと考える必要があったんだよね。
十分な余裕をもってアナウンスして、お客さんのほうでいきなり「え、何これ？」ってならないようにしないといけない。
最終的には、たぶんわりとうまくやれたんじゃないかなって思ってるけどね。
あと、もうひとつ覚えてる具体的なトラブルがあって、「デプロイしたあとに、古いキャッシュされたアセットが出てくる」っていう奇妙なバグ報告が来てたんだよね。
というのも、Vaporでは裏でCloudFrontを使って静的アセットを配信してるんだけど、
そのキャッシュがすごく断続的に、気まぐれに変な挙動をすることがあったんだ。
で、そういうのって本当に原因を突き止めるのが難しくてさ。
僕はもう「これは自分でなんとかするしかない！」と思って、
またしてもAWSのドキュメントにどっぷり潜っていったわけ。
そしたら、すごくマイナーな設定項目を見つけて、それを変えたらその問題がきれいに解消されたんだよね。あれはかなり気持ちよかったよ。
ドキュメント・ソースコードを読むことの重要性
Matt)
なるほどねえ！
Joe)
「ドキュメントを読め」って言う人たち、ウソ言ってないからね。
ほんとに、ドキュメント読むってのはスーパーパワーなんだよ。
Matt)
うん、僕にとってそれってすごく興味深くて。
最初ブログを続けるために、Laravelのソースコードとかドキュメントを全部読んでたんだ。
それから本を書くときには、「Laravelのすべてを読んだぞ」って思ってたんだけど、
いざ本を書き終えたときに、「あれ、僕ってコードベースの3分の1くらいしか知らなかったじゃん」って気づいてね。
それで、そこからは複数バージョンに渡って、すべてのコードを1行ずつ読んだんだよ。
そうして初めて、「ああ、僕は“ドキュメント読む人”とか“ソースコード読む人”だって思ってたけど、全然だったな」って思った。
Laravelのドキュメントは何回も全部通して読んだけど、ソースコードを読むことのインパクトは全然違ったんだ。
で、今はCEOっていう立場になって、全体の細部にまで手を突っ込む時間がなくなってしまってて、
知ってる範囲については今でも自信あるけど、新しいものが出てくると、それについては「まあまあ分かる」って程度で、すごく得意って感じではないんだよね。
ありがたいことに、Tightenにはそのへんをちゃんとわかってる人たちがたくさんいるからいいんだけど、でもほんとに面白いのが自分はLaravelのエキスパートだって思ってたし、何百、何千というコードベースに関わってきたけど、新しいものに関しては、ドキュメントもソースも読んでなければ、普通に何もわからないってこと。
まあ、似たようなツールを使った経験があれば、多少は助けになるけど、
でもどの新しいものも、それぞれ別の“獣”なんだよね。
で、また話を戻すけど、AWSって本当に“次元が違う獣”なんだよ（笑）
だからね、今の君が、少なくとも2つのプロジェクト、もっとたくさんになるかもだけど、AWSを日常的に使ってるって聞いて、「いや〜それは…うらやましくないな」って思ってる（笑）
じゃあその流れで、Cloudの話に移ろうか。
Mattのエイプリルフールジョークについて
Joe)
その前にちょっとだけいい？
今、君が自分の本の話を出したでしょ？
言いたいんだけど、エイプリルフールのジョーク[4]に僕、完全に引っかかったんだよね（笑）
Matt)
うわっ、マジで！？（笑）
Joe)
「え、Matt何やってんの？」って本気で思ったもん（笑）
Matt)
いやー（笑）知らない人のために言うと、僕がエイプリルフールにジョーク投稿したんだよね。
で、それって実は僕のアイデアじゃなくて、TightenのJohn Bonacursyって人がいて、
たしか9月か10月くらいに「Matt、君がエイプリルフール好きじゃないのは知ってるけど、こんなアイデア思いついたんだ」って言ってきたんだ。
それは、「Mattが自分の本をオーディオブック化したって発表して、
そのサンプル音声が『コロン、スペース、PHP、スペース、カンマ、スペース、ファンクション』ってただ読むだけってやつ（笑）」
で、僕も「これはやらなきゃダメだな」ってなって、TightenのSlackにリマインダー入れておいたんだよ。
で、実際に公開したんだけど、僕がエイプリルフール好きじゃない理由がよくわかったんだよね。
それは、「信じた」って言ってくれた人たちに、めちゃくちゃ申し訳ない気持ちになったから。
中には、「本当に楽しみにしてたんです！」って言ってくれた人もいて、もう「僕って最低の人間だな…」って思ったよ（笑）
だから、ごめんね。でも、笑ってくれてるなら、それは嬉しいよ。
Joe)
大丈夫（笑）最後にはちゃんと笑えたから（笑）
Laravel Cloudの立ち上げ
Matt)
よし、よし。じゃあ、Cloudの話をしようか。
VaporからCloudへの移行って、どういう感じだった？そのプロセスって、どんなだったかな？
Cloudに取り組み始めたとき、チームに配属された最初の日に出されたmarching orders（任務指示）って、どんな内容だった？
それと、最初からリードとして配属されたの？
それとも最初はチームの一開発者で、チームの規模が大きくなる中でリードに移ったって感じ？
Joe)
最初は、ちょっとしたスカンクワークス（非公式・実験的な少人数チーム）を立ち上げたんだよね。
PoCしてみようっていう目的で、そういう形から始まった。
VaporからCloudへの移行は、ある意味でチャレンジングだったよ。というのも、考え方そのものがちょっと切り替わる必要があったから。
その頃僕はもうVaporの開発そのものは積極的にはやってなくて、主にお客様のサポート側にまわっていて、バグ修正や、サポート対応、質問への回答とかがメインだった。
そこから、まったく新しいプロジェクトに頭を切り替えるのは最初けっこう大変だった。
でも、新しいサポートスタッフが何人か入ってくれて、そういったサポート業務の一部を引き継いでもらえたから、早く進んだかな。
で、さっきも言ったけど、最初のメンバーはChris Fidao、僕、Nunoの3人で、プロジェクトを大きく3つの主要コンポーネントに分けるっていう判断をしたんだ。実際、その構成は今でもほぼそのまま維持されてるよ。
1つ目は、Chrisが主に担当したんだけど、お客さんのコンピュート環境（＝アプリの実行環境）をどう動かすかって部分。つまり、お客さんのワークロードをどこで、どうやって動かすかってこと。
ChrisとTelegramで何度かやり取りして、最初は「Lambdaを使おう」って話になってたんだ。
つまり、Vaporでの経験をスケールさせて再利用しようとしてたわけだね。
でも、いろいろ理由があって、「それはベストな方法じゃないな」ってなって、結局、Kubernetesをベースにする方向に切り替えた。それが今でも使われてる方向性だよ。
2つ目は、Webアプリ側。
つまり、お客さんがUIにログインして、アプリケーションを構築したり設定したりデプロイしたりするためのものだね。
ただ、この部分は最初の頃はなかなか前に進めなくて、というのも、データモデルすらまだはっきりしてなかったからなんだ。
だから、「とりあえず必要になるのは“ユーザー”だよね」「“チーム”という単位も必要そうだよね」
みたいな、わかりやすいところから取りかかるようにした。
でも正直に言うと、その段階でも間違ってた部分もあったんだけどね（笑）
3つ目は、ビルドサービス。
UIから「デプロイ」ボタンを押したら、Docker環境でアプリケーションをビルドして実行する仕組みを作る必要があったんだよね。
僕ら3人でパートを分担する中で、Chrisはコンピュート環境、NunoはWebアプリ側、で、なぜか僕がビルドサーバーの担当になった（笑）
その分野については全然知識なかったんだけど、
でも、僕としてはそういう「未知のことに飛び込む系のプロジェクト」が好きだから、とにかく飛び込んで、やりながら覚えたって感じ。
今ではもうそのコードベースに触ることはあまりないけど、当時僕が書いたコードの多くが今でも残ってるって話を聞いてて、ちょっと嬉しいんだよね。
Matt)
それは素晴らしいね。いい話だよ、ほんとに。
Joe)
うん、そのアプローチでかなりのところまで進めることができたんだよね。
そこから、その周りに少しずつチームを拡張していくようになったんだ。
それで、Mohamedがアプリケーションチームに加わったんだよね。
で、今でもそうなんだけど、チームはざっくり2つに分かれてるんだ。
もちろん、1つのチームユニットとして動いてはいるんだけど、専門領域という意味では、2つの分野に分かれてて、
1つは、アプリチーム（App team）。
これはフルスタックのウェブ開発者たち、つまりLaravelの開発者たちが中心。
もう1つは、インフラチーム（Infrastructure team）。
これは僕たちにとっては新しい領域で、Cloudの開発に取りかかるまでうちには存在していなかった職種なんだよね。
それで少しずつ人数を増やしていって、JustinとFlorianが加わった。
さらにDavid Hillも迎え入れて、彼はデザインの責任者として入ってくれて、かなりCloudに積極的に関わって、Laracon USでCloudを発表するまでの準備をリードしてくれたんだ。
それから、Jason Biggsも加わってくれた。うちはバックエンドエンジニアのチームとしてはすごく良いメンバーが揃ってたんだけど、フロントエンド側が少し弱かったんだよね。
…もしこのプロジェクト初期メンバーで誰か名前を漏らしてたらごめんだけど、
だいたいそのあたりのメンバーで、Cloudのプロトタイプ（Proof of Concept）を作り上げて、Laraconで発表できる状態まで持っていったって感じだね。
Cloudチームメンバーの役割分担
Matt)
うん、面白いのはさ、こうやって違う専門分野があるとはいえ、JustinとFlorianってどっちもフルスタックのLaravel開発者なんだよね。
たまたま彼らは、オペレーション寄りのフルスタック開発者ってだけで、君たちバックエンド寄りの人たちも、実際はフロントエンドもすごくできるんだよ。でも専門としてはバックエンドが中心っていう感じで。
だから、僕はすごく感心してるんだ。
というのも、多くの会社って完全に独立したチームを作って、お互いが何をやってるか知らない状態がベストだって思ってるところが多いけど、僕はそれが原因で対立が起きてるのを何度も見てきたんだよね。
だから僕のアドバイスとしてはそういうふうに完全に分断するのは避けたほうがいいってことなんだけど、君たちはまさにうまいやり方を見つけてるなって思ったんだよね。
つまり「全員が全部の作業をできる」けど、「その中で一番効率のいい配置」を選んでるって感じで。
で、今こうして話してて気づいたんだけど、それってうちのTightenでも最終的にそうなってるんだよね。
つまり、「こっちの人はこの領域にちょっとだけ詳しい」とか、「この分野にもう少し興味がある」とか、
そういう違いを元に担当を分けてるだけなんだ。もちろん、両方できる人ばっかりなんだけどね。
だからフルスタックで全部できるLaravel開発者たちが、それでも自然に役割分担して、チームとして機能してるって話を聞くのはすごく面白いよ。
Joe)
うん、正直すごく楽しいよ。
これまで自分がやってきたのとは全然違う種類のチャレンジだけど、でもそれがまた良いんだよね。
それにさっき話したインフラ担当の人たち、ほんと全員すごい人たちなんだ。
インフラのスキルがめちゃくちゃ高いだけじゃなくて、Webアプリのコードベースにも飛び込んで作業できるんだよね。
実際Pull Requestを出してくれることもあるんだよ。僕らを待たずに自分でやっちゃうっていうね。（笑）
Laravel Cloudのビルドの仕組み
Matt)
うん、それは完全に納得できるね。
で、君は最初ビルドの部分を作ってたんだよね。
Cloudでは各デプロイごとにDockerイメージをビルドしてるってこと？
実は、Cloudがそのへんをどう処理してるのか完全には理解できてなくて。ビルドに使ってるツールって何なんだろう？
Joe)
じゃあその「デプロイ」ボタンを押したときに裏側で何が起きてるのか、ちょっと説明するね。
まずWebアプリ側から、UIで「デプロイ」ボタンをクリックすると、裏でキューにジョブを1個追加するんだ。使ってるのはSQS（AWSのキューサービス）ね。それで、うちの内部ツール群があって、それがKubernetesのオーケストレーションのために作られてる。
で、最初にやることは、そのツールがキューからジョブを取り出して、次にお客さんのリポジトリをクローンする。ここでは「buildkit」っていうツールを使ってるよ。
そしたら、そのクローンしたコードの正しいディレクトリに移動して、UI上で設定されたビルドコマンドを実行するわけ。それでそのプロセスでDockerイメージが作られて、それをDockerのレジストリに保存するんだ。
で、そのあと「このプロジェクトのビルド終わったよ」っていう通知用に、もう1個ジョブをキューに載せる。
なんでそうしてるかっていうと、ビルドとデプロイの工程を将来的には分けたいかもって思ってるから。でも今のところは、ビルドが無事に終わったって通知を受け取ったら、すぐに「じゃあデプロイしていいよ」っていうジョブをまたキューに載せる仕組みになってる。
そしてまた同じ内部ツールがそのジョブをキューから取り出して、今度はさっき作ったDockerイメージをECR（AWSのイメージレジストリ）から取ってくる。
それからお客さんが設定した「アプリのコンピュート環境の構成」を元に、Kubernetes用のカスタムリソースを作って、それをKubernetesのAPIに適用する。そうすると、お客さんが希望する構成でアプリケーションのワークロードが立ち上がる、っていう感じだね。
Matt)
それはマジで魔法みたいだね。
僕はよくKubernetesの悪口言うんだよ。というのも、Kubernetesを使ってる人の98%くらいは、別に本当はそれ必要ないだろって思ってて。
Kubernetes自体は本当にすごいツールだと思ってるんだけど、98%の人には必要ない。
だからこそ、「いや、こういう人たちこそがKubernetesを使うべき人たちなんだよ」っていうのが見られるのは面白いんだよね。
この仕組みを学ぶのもすごく楽しいし、君らがどうやってセットアップしてるのかを知るのも本当にクールだなって思う。
開発者からリーダーへの移行
Matt)
で、話を変えるけどさ、
「毎日コード書いてる」みたいな状態から、「あ、今はもうチームをまとめたり、期待値の調整をしたり、メンバー管理とか、そういうのがメインだな」って感じるようになったのって、どういうタイミングだったの？
いきなりそうなったの？それとも少しずつ移行していった感じ？
Joe)
うん、たぶんJessのインタビューと似たような感じで、ある時期にそうなったと思う。
JessがNightwatchプロジェクトのチームリードになって、JamesがCore Servicesのリードになった。
Core Servicesっていうのは、ForgeとかVaporとか、あのあたりのプロダクト群のことを僕たちは呼んでるんだけど。
で、そのときに僕もCloudプロジェクトのチームリードになったんだ。正確にいつかは覚えてないけど、たぶんCloudが公式発表されてから数ヶ月経ってからだったと思う。
それでもコードには関わってたよ。今も一応書いてる。ただ、だんだんとコードに触れる時間は減ってきてるね。
Laraconまでは結構がっつりコード書いてた。やりたいことが山ほどあったから。
正直なところ、その時点ではまだチームとしてはかなりスリムな体制だった。実際、2月にCloudをローンチするまではずっと少人数でやってたからね。
でもその少人数体制がむしろ良くて、めちゃくちゃ速く動けたんだ。Cloudをゼロから1にするまでの、ちょうど1年弱くらいの期間を通してね。
だからチームを本格的に拡大し始めたのは、わりと最近、去年の終わり頃からだったと思う。
当然だけど、チームが大きくなっていくと、いろいろ変わってくる。採用に時間もかかるし、
採用だけじゃなくてオンボーディングもあるし、チームの形をどうすべきかっていう検討も必要だしね。
その間にワークフローも少しずつ変えたりしてたから、けっこう調整ごとがたくさんあったんだよ。
その流れで、自然とコードから離れていくことになったって感じかな。
でも、今でも開発は好きだし、構成やアーキテクチャの把握はしっかり続けてる。
最初の頃、僕とNunoが中心になって決めた設計とかも、今でもちゃんと活きてるしね。
もちろん、新しいパターンを導入しなきゃいけない場面もあるけど、Vaporと同じで、Cloudのコードベースって「すぐ立ち上げられる、わかりやすい」ものになってると思ってる。
だからまあ、ちゃんと良い仕事ができたんじゃないかなって思ってるよ。
30:00 まで翻訳。続きは後編で