Laravel Podcast - 2025年4月
Maru2025/04/29
Laravel Podcast Season7 Episode 5 - 前編
Matt Stauffer(Tighten CEO) x Taylor Otwell(Laravel CEO)
Intro
Matt)
Laravel Podcast シーズン7に戻ってきてくれてありがとう！ホストのMatt Staufferです。TightenのCEOをやってて、今シーズンは毎回Laravelチームの誰かをゲストに迎えています。
そして今日は、Taylor Otwellと話すよ。
もう彼こそLaravelそのものって感じだよね。Laravel = Taylorって言っても過言じゃない。
ところで、今の肩書きってCEOで合ってる？正式にはなんて呼んでるの？
Taylor)
うん、それが正式な肩書きだよ。
Taylorが今行っていること
Matt)
じゃあ、創設者でありCEOってことで、まさにOG（元祖）だよね。
毎回ゲストに「自己紹介して、Laravelでどんなことしてるか教えてくれる？」って聞いてるんだけど、
今回はちょっと面白い感じになりそうだね。でも実際、今のTaylorがLaravelでやってることって昔とは違うわけで、そういう意味ではちゃんと聞く価値あると思うんだよね。
というわけで、Taylor、簡単に自己紹介して、最近Laravelでどんなことしてるか教えてもらえる？
Taylor)
うん、もちろん。どうも、Taylor Otwellです。Laravelの創設者であり、CEOをやってるよ。
Laravelを作り始めたのは2010年で、最初のバージョンを公開したのは2011年。
それからずっとLaravelを見守りながらやってきたんだけど、本当にいろんなことをやってきたんだ。
最初の…そうだね、13年近くは、実質的に僕が「会社の顔」って感じで、
僕と数人のプログラマーで「こういうのLaravel開発者に必要だよね」って思ったものを、手探りでどんどん作っていったんだ。
いわば自分たちの「これ欲しい！」っていう気持ちに従って。
で、正直に言うと、今でもやってることはあまり変わってないんだよね。ただスケールが大きくなっただけ。
今はだいたい60人くらいのチームになってて、CEOとしての立場ではあるけど、
今でもGitHubで毎日Pull Requestの確認してるし、質問にもいろいろ答えてる。
「今後Laravelをどうしていくか」「コミュニティにとって何が一番いいのか」っていう方向性について、できるだけガイドしたりしてる感じかな。
Laravel Cloud - ローンチを振り返って
Matt)
Matt：
最高だね！
前のシーズンでも、たびたび出演してもらってたけど、最近はTaylorもすごく忙しいから、今シーズンはこういう形で話すことにしたんだよね。
でもやっぱり、定期的に近況を聞いたり、今の視点を共有してもらいたいなって思ってるんだ。
で、今日の最初のテーマは「Laravel Cloud」。
この話題はけっこう前にも話して、一旦Nightwatchの話に移ったけど、やっぱりTaylor自身の視点でCloudのローンチがどうだったかをちゃんと聞きたいなと思ってて。
うまくいったこと、うまくいかなかったこと、ForgeとかEnvoyerのリリースと比べて違った点とか、そのへんを教えてくれる？
そのあとで、Cloudのこれからの話もちょっとしたいな。
Taylor)
うん、全体としてはすごくうまくいったと思ってるよ。いろんな意味でね。
まず、ちゃんと動いた！っていうのは良かったね。
ローンチしてすぐにユーザーが使い始めてくれて、システムが落ちることもなく、技術的な大きなトラブルもなかった。これはめちゃくちゃ良かったと思ってる。
あと、想像してたよりずっと早く、たくさんのユーザーが使い始めてくれたんだよね。
これまでリリースしてきたどのプロダクトよりも、成長スピードが速い。
ちょっと意外だったのは、たとえばVercelとかNetlifyがNext.jsのホスティングを始めた頃って、
Next.js自体が新しいフレームワークだったから、みんなが自前でホスティングしてるわけじゃなかったんだよね。
でもPHPって、もう30年近く自分たちでホスティングして運用してきた歴史があるわけで、
だから僕は、Laravel Cloudに移行するのはすごくゆっくりで、
「まあ時間かけてじわじわ広まっていくだろうな〜」って思ってた。
アプリがすでに動いてるなら、いきなりLaravel Cloudに乗り換える意味ってあんまりないし、ビジネス的にもメリットがないかなって。
だから、Cloudは「時間かけて育てていくプロダクト」だと思ってたし、
最終的にはうまくいくとしても、まずは機能を充実させてユーザーに移行を促していこうって考えてたんだ。
でも実際は、リリース直後からめちゃくちゃ多くの人が使ってくれて、びっくりした。
一方で、いくつか対応・考えていることはCloudは人々が慣れてきたForgeのようなモデルではないっていうことなんだよね。僕の中ではCloudの一番のライバルってForgeだと思っているんだ。悪い意味じゃなくてね。
Laravelアプリを運用する上で、2つの選択肢があるって感じで素晴らしいことだと思うんだけど、Cloudで今苦労してる点としては、「教育」的な部分なんだよね。
たとえば、1GBメモリのアプリなのに、500GBのキャッシュをつけてて、月200ドルとかかかってるケースがあるんだけど、
それってユーザーが料金の仕組みとか最適な構成をよく分かってないから起きてることなんだよね。
だから今、アプリのタイプ別に「おすすめ構成＋月額の見積もり」ができる料金シミュレーターを作ってて、来週にはリリースできるように進めてるところ。
たとえば「小規模アプリ」「SaaSスタートアップ」「ECサイト」みたいにタイプを選んでもらって、
「これぐらいの構成が良さそうで、フルで使った場合はこのくらいの料金になりますよ」って教えてあげる仕組みにしたいんだ。
あとは、UI上でも料金の内訳とかをもっと見やすくしようとしてて、
Forgeの「サーバー単位で払えば終わり」っていうモデルとは違うからこその工夫が必要なんだよね。
でも、全体としてはすごく良いスタートが切れたと思う。
最近もCloud上で「環境の複製」ができるようにしたり、新しい機能もどんどん出してるし、将来的には「プレビュー環境」みたいなものも導入していく予定で、これからの展開には僕自身すごくワクワクしてるよ。
Laravel Cloud - 料金
Matt)
それを聞けてよかったよ。事前にこの話をするって決めてたわけじゃないんだけど、
僕がLaravel Cloudに関して耳にした不満って、基本的には「料金がわかりづらい」ってことなんだよね。
で、それが「思ったより請求が高かった」っていうパターンもあれば、
「ForgeからCloudに移行する意味がよくわからない」っていうパターンもある。
実際、最近も2つのケースがあって、
1つ目は、ある友人が「予想より高い請求が来た」って言うから、いっしょに明細を確認してみたんだ。
そしたら、めちゃくちゃ重い処理をするWorkerがいて、それが1分おきとか5分おきにDBアクセスしてたんだよね。
そりゃあ請求高くなるよっていう（笑）。
Cloudの料金って「使った分だけ」だから、こういう特殊なユースケースだと高くつくのも当然なんだよね。
でも、普通の人の使い方ならもっと安く済むはずなんだ。
2つ目のケースは、別の友人なんだけど、
「海外（特にアメリカ以外）のスタートアップ開発者とよく仕事してるけど、そういう人たちってみんな共有ホスティングから脱出して、
5ドルのDigitalOceanのドロップレットで20個アプリ動かしてたりするんだよね」って言ってた。
だから「アプリ1個ごとにそれ以上のコストがかかる」っていう時点で、ForgeもCloudも検討外になっちゃうんだって。
僕自身、Cloudに一番興味があるのって、実は自分のためじゃなくて、クライアントのためなんだ。
もちろんCloudってもっと広いターゲットを見てると思うけど、
僕らのクライアントの多くは、ForgeとDigitalOceanで環境を作ったまま、
そこから何していいかわからなくて、変更が必要なときに僕たちに連絡してくるんだよね。
でもCloudなら、多少高くてもフルマネージドで運用してくれるよね。
今までHerokuとか他にもLaravel向けのマネージドサービスって試してきたけど、「これだ！」って思える体験はなかったんだよね。
だから今後クライアントがCloudに移行できることを期待しているよ。
今後料金の透明性がもっと上がるのはすごく嬉しいし、Cloudが「誰向け」で「誰向けじゃないのか」、
どんなプロジェクトにCloudが向いてて、どんなのには向かないのか、そういう話もできるようになるといいよね。
もちろんその中に料金の話も含まれてくると思うけど。
Taylor)
うん、それめっちゃよく分かる。
Cloudをできるだけ多くのプロダクトやアプリにとって「最高の選択肢」にしたいって思ってるし、
僕たち自身もまだ、「CloudとForge、どっちがどんなユーザーやケースに向いてるのか」っていうのを探ってる途中なんだよね。
たぶん、まだはっきり答えが出てない部分もあるんだけど、どちらにしても、CloudもForgeもどっちも素晴らしい体験にしたいと思ってる。
最終的には、「どうやって自分のアプリを運用したいか？」って話になると思うんだ。
たとえば、完全にマネージドでお任せしたいのか、それともSSHで入って自分で細かく触りたいのか、とかね。
どっちを選んでも「使ってよかった」って思ってもらえるように、僕たちは引き続き改善を進めていくつもりだよ。
Matt)
そうそう、それで思ったんだけど、結局のところ「そのアプリが収益を生んでるかどうか」ってのも大きいよね。
もしアプリがちゃんとお金を生んでるなら、「5ドルのサーバー」と「25ドルのCloud」の差なんてあんまり気にならない。
むしろ、その差額を気にせずに、アプリに集中できるようになるんだ。
だからたとえば、「ずっと動いてないと困るけど、お金を生んでないサイドプロジェクト」みたいなケースだと、
Cloudの存在意義を説明するのがちょっと難しくなるかもね。
でも、たとえ少しでも利益が出てるビジネスだったら、Cloudの方がずっと魅力的になると思う。
Taylor)
うん、ほんとその通り。
僕たちも今、そういうサイドプロジェクト向けにCloudをもうちょっと使いやすくするために、ちょっとずつ改善してるところなんだ。
たとえば、Cloudで新しく環境を作ったときに、
これまでは「ハイバネーション（自動停止）」っていう機能をデフォルトでオンにしてなかったんだけど、
「サンドボックスアカウント」では、これからデフォルトでオンにしようかなって考えてる。
実際、結構な数の人がCloudで趣味プロジェクトとか立ち上げてくれてるんだけど、
「ハイバネーションすると思ってたのに、されてなくて料金が思ったよりかかっちゃった」っていう声があったんだよね。
要するに、「オンにしてなかったから動きっぱなしになっちゃってた」っていうケース。
だから今週中にはそれを改善して、デフォルトでハイバネーションが有効になるようにしようとしてるよ。
こういう風に、コミュニティからの声を聞きながら、少しずつ改良していこうと思ってるんだ。
Matt)
それはいいね、素晴らしい。
Laravel Cloud - MySQLへの正式対応
Matt)
で、Cloudに関してもうひとつ話したかったのが、「MySQLの正式対応」についてなんだよね。
今のところCloudではPostgreSQLが標準で使えるようになってて、MySQLはまだベータ扱い。
僕が話した人たちの中には、既存アプリをCloudに移行したいっていう人もいて、
そのときに「PostgreSQLからMySQLに移行ってどうやるの？」って聞かれるんだけど、
僕としては「いや、そこまでして移行しなくていいから、MySQLの正式対応を待った方がいいよ」って言ってるんだ。
そのあたり、Taylorから詳しく教えてもらえる？
Taylor)
うん、そうだね。今言ってくれた通り、CloudではすでにPostgreSQLが正式リリースされてて、
MySQLはまだベータ版として提供してる状態なんだ。
で、MySQLがずっとベータ扱いになってる大きな理由のひとつが、「バックアップとリストアの仕組み」がまだ完全じゃなかったってことなんだ。
でも、これから1〜2週間以内にリリース予定なのが、MySQLの自動スナップショット機能と、
そのスナップショットから新しいMySQLクラスターにリストアする機能なんだよね。
さらに少し先になるけど、そんなに遠くないタイミングで、
PostgreSQLと同じように「ポイント・イン・タイム・リストア（特定の時刻に戻せる機能）」もMySQLに追加される予定だよ。
たとえば「〇分〇秒の状態に戻す」みたいな細かい単位でリストアできるようにするつもり。
この「バックアップ／リストアの整備」が、MySQLをベータから正式リリースにできなかった一番の理由だったんだ。
だから、そのスナップショット機能が整って、バックアップ周りがしっかりしてきたら、
いよいよ「GA」に切り替えるつもりだよ。
バックアップもリストアなしに「正式版」と呼びだくなかったんだ。
Matt)
でもさ、誤解しないでほしいのは、「MySQLそのものがベータ版」ってわけじゃないんだよね。
つまり、「外部のMySQLを使ってる人がCloudにデータベースが必要だから使いたい」っていうような普通のケースなら、問題なく使えるんだよね？
Cloud側がまだベータって言ってるのは、あくまでCloud標準の…というか、Cloudとして提供する一連の仕組みがまだ整ってないって意味で。
Taylor)
そうそう、その通り。
たとえば、TablePlusみたいなツールを使って、自分でバックアップを取ることもできるし、
そういう意味では「まったくできない」ってわけじゃないんだ。
ちゃんとやろうと思えば、自分でエクスポートしてバックアップすることもできる。
ただ、CloudのUIや仕組みとして、そういうバックアップ／リストアを標準機能としてまだ提供してないっていうだけなんだよね。
Matt)
あとすごく感じたのが、もちろん今まで出してきたLaravelのプロダクトってどれもクオリティ高いんだけど、Cloudにかけてる意気込みというか、自己要求のレベルが明らかに今までより数段上がってるよね。
その理由はいろいろあると思うんだ。
会社の規模が大きくなってきたこともあるだろうし、Laravel自体の立ち位置とか、今の時代的な流れもあると思う。
でもやっぱり大きいのは、今ってLaravelに対する注目度がこれまで以上に高くなってるってことだと思うんだよね。
たとえば昔だったら、最初に機能を出して、あとからバックアップ＆リストア機能を追加しても、
「ふーん、そういう流れか」って感じで誰も気にしなかったと思う。
でも今だと、「えっ、それ業界標準の機能入ってないの？どうなってんの？」みたいに見られがちなんだよね。
そういうプレッシャーを、今はLaravelチーム全体が感じてるんじゃないかなって。
Taylor)
うん、間違いなくその通りだよ。
Laravel Forgeの今後
Matt)
じゃあちょっとだけForgeの話もしよう。
そのあとでNightwatchの話に移りたいんだけど、さっきも言ってた通り、Taylorは「Forgeも引き続き重要だ」って話してたよね。
実際Cloudが出たとき、「いや、自分はCloud使わない。ずっとForgeで行く」って言ってる人もたくさんいて、
僕自身も「一生Forge使い続けるつもりだし、Cloudも併用するよ」って感じなんだ。
で、Forgeについても引き続き投資していくって話してたけど、
最近「Forgeの新しい展開があるらしい」っていう情報もちょこちょこ出てきてるよね。
今話せる範囲でいいから、Forgeの今後について教えてもらえる？
Taylor)
もちろん。僕自身もForgeの大ファンだし、やっぱりForgeはすごく特別な存在なんだよね。
Laravelで初めて作った商用プロダクトでもあるし、それがあったからフルタイムでLaravelの開発に専念できるようになった。
今、Forgeではこれまで以上に大きな、しかも野心的なアップデートを進めてるところで、少なくとも過去5〜6年では最大級の開発になると思う。もしかしたら、今までで一番大きいかもしれない。
正直なところ、Forgeが素晴らしいプロダクトである証明って、すでに50万台以上のサーバーを管理してて、何万ものユーザーが使ってくれてるっていう事実そのものなんだよね。
これだけ使われてるってことは、みんなに求められてるってことだし、ちゃんと価値があるってこと。
だから、「もうForgeはやめて、これからはCloud一本です」なんて判断をするのは、バカげてるというか、無責任すぎると思ってる。
なので、Forge向けにも超ワクワクするような新しいプロジェクトを進めてるよ。
ちょっと前にXで「Forgeに興味ある人はLaracon USに来てね！新情報あるよ」って投稿した[^1]んだけど、
あれは本当で、Laraconではたくさんの新しいForge関連の発表がある予定。
みんなが予想してたことの中にも、いくつかは正しかったんだけど、
誰も予想してなかったようなこともあって、いい意味で驚いてもらえると思う。
で、多分みんなが気にしてるポイントの一つとして、「ForgeとEnvoyerの機能を統合してほしい」っていう声があると思うんだけど、
そこはまさに僕らも重点的に取り組んでるところ。ゼロダウンタイムデプロイとか、監視機能とか、そういった部分を含めて、Forge側のデプロイ体験をEnvoyerレベルに引き上げるっていうのが一つの柱になってる。
ただ、それだけじゃなくて、まだ誰にもバレてない秘密の新機能もいろいろあって、
これはきっと楽しんでもらえると思ってる。
僕としては、ForgeもCloudもどっちを選んでも満足できるようにして、「どっちを選んでもLaravel開発に最適な環境だよね」って言ってもらえるようにしたいんだ。
で、Laracon USが終わる頃には、ようやくそのビジョンが形になってきたって言える状態になると思う。
だから、Forgeファンにとっては今年の夏はめちゃくちゃ楽しみな時期になると思うし、
これから出てくるアップデートは、Forge史上最大級のものになるよ。
Matt)
それを優先事項として大事にしてくれてるのは、本当に嬉しいよ。
多くの人がよく言うのが、「資金が入ると、結局ユーザーが望んでるものは後回しにされて、企業側の都合が優先されるんじゃないか」っていうことなんだよね。
だから、Cloudが出てきたときに
「えっ、じゃあForgeは無くなるんじゃないの？」って心配する人がいたのも、すごくよく分かるんだ。
でも今日の話を聞いて、「ちゃんとForgeも必要とされてるし、開発も続けていくんだよ」ってTaylorが言ってくれたこと、そしてそれを「口だけじゃなくて、本当に行動でも示してる」っていうのが分かって、安心する人がいると思う。
CloudでもForgeでも、選んだ側が「損した」と感じないようにしてくれてるっていうのは、ほんと素晴らしいことだと思うよ。
Laravel Nightwatchについて
Matt)
さて、Nightwatchの話もしようと思ってるんだけど、
この前Jessと一緒にNightwatchのエピソードをやって、あの時は「Nightwatchが何か」というよりも、
どうやって生まれたかとか、開発の裏話を掘り下げて話したんだよね。
だから、Taylorとして特別に何か話すことがなくても全然大丈夫なんだけど、
まずは「何か言いたいことある？」って聞きたいし、
それと同時に、Nightwatchを日常的に触る機会ってある？ たとえばサーバーにインストールしてみたり、実際に使ってみたり、フィードバック出したりとか。
もちろん、開発のリードはJessだけど、NightwatchもLaravelの一部で、Taylorにとっては“自分の子”みたいなものでしょ？
だから、今TaylorがNightwatchにどれくらい関わってるか、どんなふうに見てるかを聞きたいな。
Taylor)
うん、そうだね。実際、僕がNightwatchと一番リアルに関わってるのは、ForgeにNightwatchを導入してる実運用環境なんだよね。
Jessも話してたかもしれないけど、Forgeではもう数ヶ月前から本番環境でNightwatchを使ってて、ずっと稼働してる。
だから、僕はログインして、実際のForgeのデータをNightwatch上で見ることができる。
で、それが僕にとっては“完成されたNightwatch”って感じがするんだよね。もう本当に動いてるし、ダミーデータとかじゃなくて全部リアル。
それに、NightwatchのUIが本当に美しくてさ。
今までLaravelのプロジェクトで、ちゃんとしたログ監視を入れたことって正直なかったんだけど、
どうせややこしくて醜くなるでしょって思ってたから。
でもNightwatchは、composer.jsonにNightwatchのエージェント追加して、プロセスちょっと回すだけ。
もうそれだけで動くし、見た目も綺麗で、検索もできて、すごく使いやすい。
特に僕が「これはすごい」と思ったのが、あるユーザーがアプリに対して送ったリクエストを見て、
そのリクエストに対して書き込まれたログがその場で全部見られるってところ。
これって、たとえばAWSのCloudWatchダッシュボードでやろうと思ったら、
めちゃくちゃ時間かかるし、UIもゴチャゴチャしちゃうじゃん？
でもNightwatchならすぐに確認できる。ほんと感動モノだよ。
Nightwatchって、元々は「Pulse Pro」って仮の名前で構想してたアイデアだったんだよね。
Accelから資金調達するかどうかっていう話の時に、Cloudの構想はもちろんあったんだけど、
このPulse Pro（＝Nightwatch）も、「やりたいことリスト」の上位に入ってて。
で、もともとはForgeを運用してる中で、「あ〜これ、もっとすぐに問題特定できたらな〜」っていう
地味だけど積み重なるストレスから生まれたんだよね。
たとえば、「誰が大量にジョブ投げてて、キューが詰まってるのか」とか、そういうのを5秒で分かるようにしたい！っていう。
で、気づいたらその不満がプロダクトになってた。
それをLaravelコミュニティにも提供できるようになるって、めちゃくちゃ嬉しいよ。
Cloudのローンチと違って、Nightwatchのローンチで特にワクワクしてるのは、
Cloudはアプリ全体を移行しないと使えないから、初日に本番投入する人ってあまりいなかったんだけど、
Nightwatchは「composerで入れるだけ」だから、どんなにアクセス数が多いアプリでも、
リリース初日から本番環境に導入できるんだよね。
スケーラビリティも問題ないし、移行作業も不要。
ほんとにQueue Worker立ち上げるのと同じくらいの感覚で導入できる。
だから、Nightwatchのローンチはかなり“バナナ級”（crazyな意味）になると思ってるし、
ほんとに楽しい1日になると思うよ。
ローンチは……ああヤバい、
今、危うくNightwatchのリリース日をバラしかけた（笑）
気をつけないとね。
今日、「来月ローンチする予定」っていうところまでは発表したんだけど、
具体的な日付までは言ってないんだよね。
もし数日ずらす必要が出てきたときのために、一応そこはまだ伏せてあるんだ。
Matt)
笑
いや〜ほんと想像できないよ。Cloudもすごく大きなプロジェクトだし、やってることも多いけど、
Cloudの場合って、各ユーザーが送ってくるリクエストは基本的に1アプリ分だけじゃない？
でもNightwatchは違って、うちもサインアップしてすぐ、何千件ものリクエストをNightwatchに送信し始めたからね。
1分あたりだったか正確な数は覚えてないけど、とにかくかなりの量だった。
しかも、あれって一番大きなプロジェクトじゃなくて、テスト目的で軽いのを載せただけなんだよね。
でも、うちのクライアントの中には1日に何百万アクセスあるようなアプリを持ってる人もいて、
そういう人たちがリリース初日にいきなりNightwatchを導入したら…
もうサーバーの負荷、桁違いになるよね。
何億とか何兆っていうリクエストが一気に飛んでくる…
運用チーム的には、すごい一日になるんじゃない？
Taylor)
うん、実際、NightwatchをForgeに導入して最初の30日間で、
データベースクエリだけで30億件くらい収集したよ。
Matt)
えっ……本当? Forgeだけで!?
Taylor)
うん、Forge単体で追跡したDBクエリだけで30億件。
Matt)
うわ……。
Taylor)
しかもそれってクエリだけなんだよね。
リクエストや例外（例外ログ）は含まれてない。
で、もちろん全部を100％収集する必要はなくて、
データをサンプリング（間引き）する設定もできるようにしてるんだ。
たとえばアプリが何十億リクエストも受けてるようなケースなら、
0.1％だけを収集するっていう設定でも全然OK。
それでも、どのクエリが遅いか、どのルートがボトルネックかはちゃんと分かるようになってる。
だから、負荷を抑えながらも必要な洞察は得られるっていう感じ。
Matt)
いや〜ほんとすごいよ。
僕も最近やっとNightwatchのベータアクセスをもらって、実際にアプリに導入してちょっと触ってみたんだ。
以前、本を書いたり『Forge』についてブログを書いたりしてたときに、Papertrail（ログサービス）を使ったことがあって、
他にも何個かログ系サービスを試したんだけど、やっぱり「必要な情報をログから見つけ出すのってめちゃくちゃ大変」なんだよね。
もちろん、ローカルシステムで確認するよりはマシなんだけど、
「今この瞬間、自分が知りたい情報」にピンポイントでたどり着くのって、本当に難しい。
しかもNightwatchって、ログだけじゃなくて、リクエスト情報とかユーザー情報とか、もっと広い視点のデータも一緒に見れるでしょ？
「最近ログインした40人のユーザー」とかがバーッと出てきて、それぞれ「このユーザーはこのページでエラー出してる」とか、「この人は300番台のエラーを3回、400番台のエラーを1回出してる」とか、そういうのが一目で見えるんだよ？
で、さらに「500番台エラーが多発してるルートはここですよ」とかも分かって、もう凄すぎるって思った（笑）
Taylor)
あと個人的にすごく良いなって思ってるのが、Nightwatchで見れるP95（95パーセンタイル）値なんだ。
パフォーマンス的に「外れ値」っぽく見える処理時間を示す指標なんだけど、実はアプリにとって一番重要なユーザーだったりするんだよ。
たとえばForgeを例にすると、仮に1,000台のサーバーを管理してるユーザーがいたら、それってうちにとっては超重要な顧客なわけでしょ？
でも、その人のダッシュボードがめっちゃ重くても、P95に入ってるからって「たまに重いユーザーがいるだけだね〜」って流しちゃう可能性がある。
でも実際には、その“外れ値”が売上的には超大事な存在だったりする。
だからこそ、そういうデータをちゃんと見える形にしてくれるNightwatchは、めちゃくちゃ価値があると思ってるよ。
Matt)
うん、僕が言いたかったのは、これは本当に魔法みたいに感じるってことで、
ただの「セールストーク的な意味」ではなくてね。
というのも、僕らってログ、トラッキング、分析、デバッグの領域でずっと取り組んできたけど、
今までこんなものを手に入れられたことは一度もなかった。
正直、最初に思ってたのは、
「Laravelブランドのエラーマネジメントプラットフォーム」が出てくるのかなってこと。
まあ、「エラーマネジメントはエラーマネジメントだよね」って感じで。
で、そのあとにAPM（アプリケーションパフォーマンス監視）も来るのかなって思ってた。
それはそれで嬉しい。良いAPMプラットフォームって確かにあるけど、見つけにくいし、営業色が強すぎるものが多いし。
でも、今回のNightwatchでは、ログの統合、他の機能との連携、全体の構成が
想像以上のものになっていて、「こんなのができるなんて、想像すらしてなかった」って感じなんだ。
今こうしてそれを見て、「ああ、これはすごい」って感じるけど、
そもそもこんなものが作れるなんて、思いもしなかったよ。
Taylor)
うん、まさにその通り。
実はNightwatchを作り始めたときって、エラー監視とか例外トラッキングをメインにするつもりじゃなかったんだ。
それはあくまで結果的に取り込まれた要素のひとつで、
最初から「エラートラッキングプラットフォームを作ろう！」っていう話ではなかった。
もっと全体的な視点（holistic）から入っていたんだよね。
Matt)
うん、それで納得がいったよ。
たしか最初にLaracon AustraliaでJessと話したとき、
彼女が「Nightwatchには3つの要素がある」って言ってたんだけど、
そのときは、「ああ、3つの機能があるんだな」っていうくらいの理解しかなかったんだ。
でも実際に触ってみて、やっと分かったんだよね。
“Holistic（全体的な統合性）” こそがNightwatchの魔法だったんだって。
「3つの機能がそれぞれ単体で優れている」っていうのも素晴らしいことだけど、
それよりも、その3つが揃って初めて得られる“構造化された情報”が、
今までのどんな単体ツールでも得られなかったような深い洞察を与えてくれる、ってことに気づいた。
Taylor)
そうだね。
Laracon US 2025 - 準備
Matt)
それはすごくクールだね。
さて、最後に聞きたい大きな話題なんだけど、Laraconについてだよ。
Laraconへの期待が、明らかにもう高まってきてるよね。
新しい公式サイトも、たしか今日リリースされたばかりだと思うし、
うちもスポンサーだから、スポンサー向けの連絡が来始めてる。
それから、「Mostly Technical」ポッドキャストを聴いたら、
前日にはプレパーティーの企画もあるらしくて、他にもいろんなイベントが動いてるみたいだよね。
で、毎回聞いちゃうんだけど、
やっぱりTaylorの視点からLaraconってどう見えてるのかが気になるんだ。
今まで独りでの開催もやってきたし、
IanやJessと一緒にLaraconを運営してきたこともあるし、
去年はチームとしてイベントを回す動きが本格化してきたタイミングだったと思う。
で、今年はどう？
どれくらい自分が関わっていて、どんな感じの経験になってる？
Taylor)
今年はね、けっこう意識的に“距離を取る”ようにしてるんだよね。
理由は、これを聞いてチームのみんなが僕に怒らないといいんだけど（笑）、
僕が一から十まで指示しなくても、チームがどう動くのか見てみたかったっていうのがあるんだ。
というのも、たとえば2016、17、18、19年あたりのLaraconは、
イベント運営会社なんて一切使わずに、ほぼ僕とあと1〜2人で全部やってたんだよ。
本当に、手探りでなんとか回してた。
ここ数年はイベント会社を使うようになったけど、
それでもやることは山ほどあるし、自分で決めなきゃいけないことも多かった。
だから今年は、会場とか開催地とかについては意見したけど、
それ以外は極力チームに任せるようにしてる。
会場に関しても、最終的には「予算と日程の空き状況」で決まることが多いし、そこはもうどうしようもない部分もあるからね。
あともう1つ僕が関わったのは、スピーカーの選定。
これは、どんなトピックがいいかとか、バランスの取り方とか、僕ならではの知見があるから、
そこはちゃんとフィードバックしたよ。
でもそれ以外は本当に関わってなくて、たとえば先週なんて、うちのチームでLaraconを担当してるHankに「ステージってどんな感じ？」って聞いて、それでいい感じだねって言ったり。
あと「ケータリングどうなってる？」って聞いたりとか。
でも、あえてマイクロマネジメントしないようにしてる。
それって、Laravel全体で取り組んでる、もっと大きな方針の一部でもあって。
つまり、「僕が全部を細かく見なくてもLaravelがちゃんと動くようにしたい」っていう。
というのも、これまでは本当にずっと僕がほぼすべての意思決定をしてたんだよね。
でも、いずれは僕も「ログイン」せずにバケーションに出かけられるようにしたいんだ。
まだその段階までは来てないけど、
だいぶ近づいてきたなっていう感覚はあるよ。
Matt)
それは素晴らしいね。
Taylor)
僕としても、他のメンバーにも楽しんでほしいし、成長してほしいんだ。
やっぱり働くなら、「自分も貢献できてる」「実際に起きることに影響を与えられてる」って感じられる方がいいでしょ？
ただ単に「上の人の指示を実行するだけ」みたいな感じじゃなくて、
創造的な意見を出せる余地がある環境が良いと思う。
だから、イベント運営もみんなに楽しんでもらいたいんだ。
だって実際、イベントを企画して形にしていくのってすごく楽しいし、
何ヶ月も前から構想してきたものが、目の前で現実のものになるわけだからね。
ソフトウェアの仕事では、そういう“物理的な成果”ってあまり経験できないから、
こういうイベントって、ちょっと特別なんだよ。
だからきっと、今回のLaraconも楽しくなると思うよ。
Matt)
それはいいね。
僕はいつもあなたのチームの様子を見るのがすごく楽しいんだよ。
彼らがイベントに関われるときって、本当にワクワクしてて、テンションがめちゃくちゃ上がってるのが伝わってくる。
うちはスポンサーだから早めに現地入りできるんだけど、
その時点ではまだ倉庫みたいな会場に誰かが椅子を並べ始めてるくらいで、ほぼ空っぽなんだよね。
で、Laravelチームの人たちがそこに来てて、Tシャツ着てて、すっごく嬉しそうにしてる。
「ここにいられること」「手伝えること」「この一員であること」に本当に興奮してるのが伝わってくる。
特に初めて参加するメンバーにとっては、
「自分がチームLaravelの一員として、名札とかTシャツを着て現場にいる」っていうのがめちゃくちゃ特別な体験になるんだろうね。
だから、Taylorがそうやってみんなに機会と余白を与えてるっていうのは本当に素晴らしいことだと思うよ。
それに、会社を所有して、それを成長させていく上でのチャレンジのひとつって、
「どこまで自分が手を離すか」「どこを手放さないか」っていう判断だよね。
「自分の名前や、自分の大事な“子供（＝Laravel）”にふさわしいクオリティ」を保ちつつ、
少しずつ他の人に任せていくバランスを取るっていう。
誰かに任せてみて、「あ、よくやったね」って言える時もあれば、「うーん、次はもうちょっと構造を決めてからお願いしようかな」ってなる時もある。
そういうのがまさにリーダーシップスキルで、Taylorは明らかにそれを実践してるし、伸ばしてるんだと思う。
Taylor)
うん、トライしてみてるよ。（笑）
〜後編に続く〜
Maru2025/04/29
Laravel Podcast Season7 Episode 5 - 後編
Matt Stauffer(Tighten CEO) x Taylor Otwell(Laravel CEO)
Laracon US 2025 - 会場
Matt)
うん、君のチームのメンバーたちともけっこう話してるけど、Taylor、君は本当にいい仕事をしてると思うよ。
それで、今年のLaraconはデンバー開催だけど、現地の雰囲気ってどんな感じなのか、君自身の印象が知りたい。僕も一応は調べたんだけど、Taylorの感覚としてはどう？
Taylor)
うーん、そうだね。会場自体は去年とちょっと似てるんだけど、去年より広いんだ。
今回はいわゆる「ベンダーホール（出展者用スペース）」が別で用意されてる。
知っての通り、ここ数年の悩みのひとつが、スポンサーとトークセッションが同じスペースにあって、
騒音の問題が起きてたことなんだ。
もちろん、みんながスポンサーと話したがるのは良いことなんだけどね（笑）
とはいえ、今回はそれを解決するために、スポンサー専用のスペースを別に設けたってわけ。
それから、全体的にアクティビティがすごく増えてる。
たとえば君も言ってたけど、前日から何かがある予定だし、屋上イベント（ルーフトップイベント）の噂も聞いてる。
スポンサー各社もいろいろやるみたいで、これまでみたいに「日中にカンファレンスがあって、初日にアフターパーティー1回だけ」みたいな構成じゃなくて、もっといろんなことがある年になりそうなんだ。
全体的にもっと賑やかになると思うし、楽しみな雰囲気になると思うよ。
聞いた話では、ゴルフがあるとか、さっき言った屋上での何かがあるとか、そういうのもいろいろ聞いてるし、きっとすごく楽しい時間になると思うよ。
Matt)
それは本当にクールだね。
で、スポンサーとしての立場から言うと、
会場から少し離れた場所にスポンサーエリアがあるっていうのは、
一部ではちょっとネガティブに捉えられることもあるかもしれないけど、
僕はその変更、すごく嬉しいと思ってる。
前は、話しかけたい人がいても「今はダメ」って感じで気を遣わなきゃいけなかったし、
来てくれた人にも「ごめん、あと1時間後にまた来てね」って言わなきゃいけないことがあった。
だから今回、スポンサーがメイン会場から少し離れるっていうのは、
人によっては文句言うかもしれないけど、僕はむしろ大賛成。
これでスポンサーエリアは思いっきり盛り上げられるし、
参加者も「後ろの席だからトークが聞き取りにくい」ってことがなくなると思う。
ほんとにいい判断だったと思うよ。すごく楽しみ。
Laracon US 2025 - トークについて
Matt)
さて、今年のLaraconについて他に聞きたかったことなんだけど…
トークの選定について、今発表されてる人たちは、すでに全員決まってるの？
それとも、まだ選考中の段階なの？
Taylor)
いくつかまだ最終決定してないトークがあると思うんだけど、ほとんどはすでに選ばれてる。
で、面白い企画もいくつか進んでるから、楽しみにしててほしい。
たとえば去年の基調講演（キーノート）でもやったように、チームのメンバーをステージに上げて、発表の一部を任せたんだけど、今年もそれに近い感じになると思う。
たとえば、Cloudのアップデート、Nightwatchのアップデート、Forgeの大規模アップデートとか、
そういうのを発表する場面があるだろうし、それ以外の企画もかなりワクワクするものがある。
たとえば今回は、僕、Adam Wathan（Tailwind）、Evan You（Vue.js / Vite）、Jeffrey Way（Laracasts）
この4人でパネルディスカッションもやる予定だよ。
かなりクールな時間になると思う。
Matt)
えっ！Jeffreyも来るの!?
それは最高だね！
Taylor)
Jeffreyの登壇については、まだ公には発表してないんだ。
というのも、先週Telegramで彼にメッセージ送ったばかりでさ。
彼がLaraconに来ること自体は知ってたんだけど、トークの準備ってすごく大変だから、
彼が「いや、今回は話したくないんだ」って言っても全然責められないと思ってて。
でも今回は、「カジュアルなQ&Aセッション」をやる予定だから、彼に「プレゼンじゃないし、そんなに準備もいらないよ。質問は1週間前くらいに送るから、それでちょっと考えておいてくれれば大丈夫。
登壇者は僕とAdamとEvanなんだけど、もし参加してくれたら最高だなと思って連絡したんだ」ってメッセージ送ったら、彼もOKしてくれたんだよ。
だから今回のことはまだ公表してないんだけど、Jeffreyが数年ぶりにLaraconのステージに上がるってことで、みんなにも楽しんでもらえると思うよ。
PHP、CSS、JavaScript、それから教育的な観点の代表達だね。
Matt)
うん、Jeffreyって本当に素晴らしいスピーカーなんだよね。
しかも面白いのが、彼ってめちゃくちゃ内向的なんだ。
内向的な人って、動画では話せるけどステージに上がると緊張してしまうことがあるじゃない？
でもJeffreyは違って、ステージに上がってもカメラの前と同じくらい上手く話せるんだよね。
ただ、これはみんなに知っておいてほしいんだけど、ステージから降りたJeffreyは、そのまま人とわいわいやる感じじゃないからね（笑）
別にそれでいいし、内向的であることはまったく問題ない。
僕自身、Jeffreyからはたくさんのことを学んだんだ。たとえば、「人と関わる中でも自分を大事にする方法」とか。
彼はこう言ってたよ。
「燃え尽きたときは、もうだめなんだよ。だからホテルに戻るんだ。」
これはカンファレンスでもそうだし、彼の人生全体がそういう姿勢なんだよね。
たしか彼が言ってたのは、「心の底から “YES!!” と思えないことには、NOと言う。」
つまり「Hell yes! じゃないなら、それはNoだ。」ってこと。
そうやって、自分の平穏を守るようにしてるんだよ。僕も「それでいいじゃん、それが君らしさだよ」って思った。
だって僕たちみんな、彼のこと大好きなんだからさ。
Taylor)
うん、よくわかる。
僕も自分の本質としては内向的だと思ってる。
最近は少しずつ外向的にもなってきたし、前より肩の力も抜けてきたとは思うけど、
やっぱり内向的な部分はあるよね。
カンファレンスって、すごくエネルギーをもらえる一方で、めちゃくちゃ疲れることもある。
特に内向的な人にはね。
でも…やっぱり楽しみだね。
Laraconに参加する意義
Matt)
最近、ある見込み客と話したんだ。
彼は「君たちの活動をずっと追ってきたよ。Tightenの初期から、Laravelのバージョン3の頃からずっとだよ」と言ってて、でも、これまで一度もカンファレンスに参加したことがないって言ってたんだよね。
で、僕は改めて気づいたんだ。
「カンファレンスに参加する価値」にまだ気づけていない人もいるんだって。
だからちょっとみんなに伝えたいんだ。
僕はLaraconからお金をもらってるわけじゃないし、出資してるわけでもない。
でも、あの数年間物理的なカンファレンスがなくなったとき、僕自身も、他の人たちも、Taylorに「どうかまた現地開催してほしい！」って頼んだんだ。
本当に、なんとしてでも開催してほしかった。だって、カンファレンスには本当に価値があるから。
もちろん、カンファレンスの中心は「トーク（講演）」だし、登壇者の方には申し訳ないけど
確かにトークは素晴らしい。でもカンファレンスの本質はそこじゃない。
よく「トークはYouTubeで見ればいいから現地には行かなくていい」っていう人がいるけど、
トークはあくまで「人が集まる理由」「名目」であって、本当に価値があるのは “現地で人と会うこと” なんだ。
登壇者に話しかけたり、隣の席に座った人と話したり、一緒にご飯を食べたり、フーズボール（テーブルサッカー）したり、スポンサーの人たちと顔を合わせたり、そういう交流こそが、現地に行く価値。
実際、ブースに来てくれた開発者の中には、「Twitterで名前だけ知ってる人」だったのが、実際に会って話すと、一気に“つながりの深さ”が変わる。
Taylor)
うん、Laraconは本当にエネルギーをもらえる場所なんだ。僕たちLaravelのチームにとってもね。
開発者の話を聞いたり、何にワクワクしてるかを知ったり、一緒に交流するだけでも本当に刺激になる。
君の言う通り、トークは「みんなが集まる理由」みたいなもので、
実際は、みんなで何日か一緒に過ごして、ネットワークを広げたり、お互いに学び合ったり、作ってるものについて盛り上がったりする、そんなイベントなんだよ。
僕たちが主催してるとはいえ、Laraconって本当に良くできた技術系カンファレンスだと思ってる。
クオリティも高いし、場所もいいし、雰囲気もすごくポジティブ。
しかも、Laravelチームのメンバーもみんな普通に参加者と混ざってるんだよ。
他の技術カンファレンスに行くと、「会いたかった有名人」がステージにだけ出てきて、講演が終わったらすぐ帰っちゃうってこともよくある。
僕も昔、憧れてたプログラマに会いたくて行ったのに、ステージにだけ出て、あとはどこにもいなかった…って経験があるんだ。
でもLaraconや、あとRailsのイベントなんかは違って、DHH（Railsの生みの親）もロビーに普通にいるし、
Laraconでも、たとえばNunoやJames Brooks（Forgeチーム）、僕自身も含めて、みんな会場に普通にいて、ランチも一緒に食べてる。
だから、Laravelチームのメンバーと直接会って話せる、すごく良い機会なんだよね。
Matt)
最近あまりポッドキャストを聴いてないんだけど、今朝、木を植えてたときに久しぶりにポッドキャストを聴いて、それでまた「Mostly Technical」の話ばっかり引用してるんだけど（笑）
その中で、React Miamiについて話してて、あれはすごく「ハイプでエネルギッシュでパーティーっぽい」雰囲気のイベントだって言ってた。
それに対して、Laraconは“チル（落ち着いてる）”だと。
でも、Laraconの“チルさ”って面白いんだよね。
「ハイテンションな人じゃなくても楽しめる」って意味でチルなんだけど、かといって、「何も起きてない」「退屈」ってわけじゃない。
常に楽しいことがどこかで起きてるし、
そこが僕がLaraconをすごく好きな理由のひとつなんだよね。
エネルギーにあふれてて、ワクワクするイベントでありながら、同時に誰でもアクセスしやすい・入り込みやすいイベントでもある。
他のイベントだと、主催者がめちゃくちゃ元気すぎて、「うわ、自分には無理かも…」って思うこともあるけど、Laraconは、人それぞれの“エネルギーレベル”や“社交性のスタイル”に合わせて楽しめるところが本当にいい。
Taylor)
確かにそうだね。
Outro
Matt)
じゃあ、僕からの質問はこれで全部なんだけど、
LaravelやLaracon、あるいはTaylor自身のことで何か話しておきたいことある？
それとも、今日はだいたい全部カバーできた感じかな？
Taylor)
うん、だいたいカバーできたと思うよ。
でもやっぱり、まだCloudを触ってない人には、ぜひ使ってみてほしいし、あともちろん、来月リリース予定のNightwatchにも注目しててほしい。
Nightwatchの良いところは、Cloudじゃなくても使えるってこと。Forgeでも、自宅サーバーでも、PHPさえ動けばどこでも使えるから、そこはすごくクールだと思ってる。
それから、Laraconのチケットをまだ持ってない人は、ぜひ検討してみてほしい。
Cloud、Nightwatch、Forgeの新しい機能もいろいろ見られるし、
僕たちと2日間一緒に過ごして、楽しい時間を過ごせるはずだからね。
Matt)
最高だね。
本当に、以前より忙しいだろうに、こうして時間を取ってくれてありがとう！
Taylor)
うん、こちらこそ呼んでくれてありがとう。
Matt)
では、リスナーのみなさん、また次回お会いしましょう！
Maru2025/04/17
Laravel Podcast Season7 Episode 4 - 前編
Matt Stauffer(Tighten CEO) x Jess Archer(Laravel Nightwatch／APACチーム エンジニアリングチームリード)
Intro
Matt)
よし、Laravel Podcast シーズン7へようこそ！ホストの僕、Matt Staufferです。TightenのCEOをやってます。
今シーズンでは、毎回Laravelチームのメンバーをゲストに迎える予定で、
今日は僕の昔からの親友、Jess Archerと話すよ。
LaravelのAPACチーム（アジア太平洋地域）のエンジニアリングチームリードだよ。
あれ…今の紹介あってたかな？まあいいや。
Jess、紹介あってたかどうかはさておき、自己紹介とLaravelで何してるか教えてもらえる？
Jess)
うん、こんにちは〜！今の紹介バッチリだったよ！
私はJess Archer、オーストラリアのブリスベン出身で、Nightwatch／APACチームのエンジニアリングリードをしてるよ。
APACってのはアジア・パシフィックね。
で、Laravelで今何してるかっていうと、Nightwatchの開発をしてるんだけど…
あれ、それ以外の質問なんだっけ？（笑）
Matt)
全然OK、それで十分だよ。Nightwatchを作ってるってことだよね。他の話は僕が補足するし。
ていうかさ、Jessの名前を言うとき、ついオーストラリア訛りで言っちゃいそうになるんだよね。
「ジェス・アーチャー」じゃなくて「ジェス・アチャ！」って感じで（笑）
でもそれって人のアクセントをからかうのはよくないから言わないけど、
僕の頭の中では英語の発音じゃなくて、完全にオーストラリアアクセントでJessの名前が再生されるんだよ（笑）
Jess)
それめっちゃ好き（笑）
JessがLaravelに入社した経緯
Matt)
じゃあ、みんなに聞いてる質問だけど、Laravelに入った経緯を教えてほしいな。
入社前はどんなことしてた？そもそもLaravelで働くってどうやって現実になったの？
「Laravelで働くとか想像してなかったのに、気付いたら初出社してた」までのストーリーが聞きたい。
Jess)
もちろん！
たまにTaylorがTwitterで求人出してるのは見かけてて、
「へえ〜Laravelで働ける人もいるんだなぁ、でも自分は無理だろうなぁ」って思ってたから、
応募しようなんて全然考えてなかったんだよね。
でも、Laravel自体はたぶん8年か9年くらいずっと使ってて、
Laraconで登壇したり、コミュニティに参加したり、Podcast出たりって感じで結構関わってて。
Taylorとも一度Laraconで会ったことがあって、ちょっと気まずく「こんにちは〜」って言ってちょっと話したくらい（笑）
あとLaravel本体にもPR送ったりしてたかな。
そんなときに、TaylorがまたTwitterで求人出してて、「よし、やってみるか」って思ったの。
当時は医療系のソフトウェア会社で働いてて、友達のTim McDonaldと一緒に開発してたんだけど、
ふたりで「Laravelで一緒に働けたら最高じゃない？」って話してて。
たしかTaylorが言ってたか、私たちが感じ取っただけか忘れたけど、
私たちのタイムゾーン（オーストラリア）がちょっと問題になるかもって思ったのよ。
だからふたりで「一緒に応募したらタイムゾーン問題も緩和できるし、しかも一緒に働けるし最高じゃん！」ってなって、ちょっと変わった応募方法を思いついたの。
その方法っていうのが、「Taylor宛のチャット形式のスクリプト」を書いて、
まるでTimと私が会話してるみたいな体裁で、Taylorをその会話に”参加させる”っていうやつ（笑）
たとえば「ねぇTim、Laravelが採用募集してるの見た？」って私が言って、Timが「見たよ〜」って返して、その流れでお互いのスキルを褒め合いながら、
「あなたはForgeにピッタリ！」「Jessこそ最高のスキルを持ってるよ！」みたいな（笑）
で、「ふたり一緒に働けば孤立しないし、タイムゾーンの問題も解決できるよね〜」っていうのも会話の中でアピールして、その長〜いチャット風スクリプトを夜中に一気に書いて、Taylorが寝てる間に送信したんだよね。
朝起きたTaylorがメッセージを読めるように（笑）
で、送信ボタンを「えいやっ」って押したら、
Taylorの返信が「😁（ニコニコ絵文字）」と「で、君たちのメールアドレス教えて」だった（笑）
そこからやり取りが始まって、Timと私はLaravelで一緒に働くことになったんだよね。
Matt)
いやほんと最高だよ、それ。
実はMuhammadにも言ったんだけど、君たちにもまったく同じことを思ってて、
Taylorが君たちの応募を見てるときに、僕は「お願いだからこの人たち雇って！」って本気で言ってたんだ。
Muhammadのときは「もし君が彼を採用しないなら、僕が採るからね」ってTaylorに言ったくらいで、
君たちのときも「ふたりとも採用したいんだけど、タイムゾーンだけがネックなんだよなあ……」ってめっちゃ悩んでた。
でもふたり一緒にっていうアイデアがほんとに素晴らしくて、
もう「お願いだから！」って思ってた。
それにしても、君たちふたりは、それぞれが単体でも僕の人生で出会った中で最高に優秀な人たちで、
めちゃくちゃクリエイティブで、イノベーティブで、素晴らしくて、親切で、
Laravelコミュニティでもトップクラスの人たちなのに、
それがタッグを組んでるって……もう反則だよね（笑）
こんな才能と能力のかたまりがセットで来るなんて、誰かの元にドンって届いたら、そりゃズルいよって思うくらい。
だから、あのアイデアを実行してくれて本当にありがとう。
君たちのおかげで、僕らみんながどれだけ恩恵を受けたか計り知れないよ。
Jess)
ありがとう、今でもたまに朝起きて「えっ、私Laravelで働いてるんだよね……？」って思うことあるよ。
いまだに現実味がない感じで、ちょっと変な気分（笑）
Laravelに入社して最初に取り組んだこと
Matt)
いいね〜。でも、ほんとにJessはLaravelチームにぴったりだよ。
で、みんなに聞いてるんだけど、初出勤の日って、たしかまだNightwatchには関わってなかったよね？
最初の仕事って実際なにしてたの？
Jess)
うん、Taylorとは入社前から「どんなことをやるか」って話をちょっとしてたんだよね。
で、彼は私がオープンソース領域で、いわゆるR&Dとかスカンクワーク（実験的な開発）っぽいことをやるのがいいんじゃないかって思ってくれてて。
で、最初に取りかかった正式なプロジェクトは、Laravel用の Viteプラグインの開発だったの。
LaravelでViteを使えるようにするやつね。
PHPのプロジェクトっていうよりは、もっと深くVite側に入り込んだやつだった。
まあ、Laravelの中でそれをつなげるためのPHPコンポーネントもあるけど、中心は「WebpackをViteに置き換える」ってところ。
Viteって当時からめちゃくちゃ速くて、良さげな機能もいっぱいあって、
「Laravel Mixみたいに快適な開発体験をViteでも提供できないかな？」って考えながらやってた。
でも、Mixみたいな「ラッパー方式」にしちゃうと、Vite本来の機能が使いにくくなるよねって話になって、
じゃあシンプルに「Viteそのものを直接使えるようにしつつ、Laravel向けに便利なプラグインを作ろう」って方向に決まったんだ。
OSS開発からNightWatchというプロダクト開発への変化
Matt)
すごくいいね。で、ちょっと聞きたかったんだけど——
知らない人のために言っておくと、僕この前Twitter（というかBluesky）で「Jessに聞きたいことある？」って質問募集したんだよね。
その中に「Laravel PromptsからNightwatchにどう移っていったの？」って質問があったんだ。
で、僕自身、その経緯をちゃんと知らないんだけど、
PromptsってJessの正式な担当だったのかどうかもわかってなくて（笑）
でもまあ、最初はオープンソースっぽい活動してて、それからプロダクトの開発に移ったわけでしょ？
その変化って、「えっ、毎日やること全然違うじゃん！」みたいなカルチャーショックあった？
それとも自然な流れでスッと切り替えられた感じ？
Jess)
うーん、それはけっこう大きな変化だったかな。
それまでは完全にオープンソース寄りのことばっかやってて、しかもTimと一緒にやることが多かったのね。
ViteプラグインもTimが手伝ってくれたし、Laravel Pulseもふたりで一緒に作ったし。
でもPromptsは、私が一人で作った数少ないプロジェクトで、しかもそれは「私自身のアイデア」がベースになってたものだったの。
他のやつはだいたい「Taylorからこのアイデアどうかな？ちょっと試してみてよ」って言われて始まる感じなんだけど、Promptsだけは「これ、どうしても自分で解決したい！」って思って作ったんだよね。
Matt)
いやほんと、Promptsにはめっちゃ感謝してる。あのツール、大好きなんだよ。マジで最高。
Jess)
うん、Promptsは今でもすごく誇りに思ってるし、めちゃくちゃ気に入ってるよ。
で、それから「プロダクト寄り」の仕事にシフトしたわけだけど、もともと前職とかはそういう領域の仕事が多かったから、そんなに変な感じはなかったかな。
とはいえ、大きな変化ではあったよ。
でも私たちの働き方って、基本はずっと変わらないのよね。
今でもずっと「開発者体験」を考えて、開発者向けのツールを作ってるわけだし。
目指してるところは同じなんだよね。
たぶん、プロダクト開発ではもうちょっと細かいところまで手をかけたり、ちゃんと磨き上げる（polish）ことに時間をかけられるっていうのはあるかも。
もちろん、オープンソースでもいつも全力でやってたけど、プロダクトの方が「さらに時間をかけて仕上げる余裕」があるというか。
あと、プロダクトの場合は最初から完成度高いものを出さなきゃいけないっていうプレッシャーがあるよね。
オープンソースだと、ある程度良い感じの状態で出して、あとはコミュニティがフィードバックくれたり、一緒に方向性を決めてくれる感じだけど、プロダクトだと最初から「ちゃんとした、方向性がはっきりしたもの」を出す必要があるなって感じる。
Matt)
それに、有料プロダクトだとさ、誰かがコントリビュートしてくれるなんて期待もできないわけだよね。
だってコードは公開されてないし、修正とかするのも全部自分たちになる。
たとえユーザーがめちゃくちゃ好意的な人だったとしても、
「毎月お金払ってるんだから、ちゃんとしてて当然でしょ？」っていう感覚はあると思うんだよね。
無料で提供してるものだったら、「ありがとう！ちょっと改善のPR送るね！」ってなるけど、
有料だと「ちゃんと完成されたものを提供してよ」って期待値が全然違ってくる。
だから、リリースまでにかかるコストやハードルも全然違うよね。
Jess)
うん、ほんとに全然違う関係性だよね。
Laravel NightWatchとは
Matt)
で、さっきから何回か「Nightwatch」って名前を出してるけど、
Podcastを聴いてる人の中にはまだ知らない人もいるかもしれないから、最初にちゃんと説明しよう。
Nightwatchって何？それから、リリースに向けたスケジュールとか、今どのくらい開発が進んでるのか、その辺も教えてもらえる？
Jess)
もちろん！
Nightwatchは、ざっくり言うと3つの機能が合体したサービスって感じで、
例外トラッキング（バグ検知）、パフォーマンスモニタリング（速度やボトルネックの可視化）、ログ収集
この3つを全部ひとまとめにして提供してるのがNightwatchなの。
で、それぞれがすごく関連性の高い情報だから、全部セットで扱えるのはすごく便利なんだよね。
LaravelプロジェクトにNightwatchをインストールすると、アプリケーションのテレメトリデータ（ログやパフォーマンス情報、エラーなど）がNightwatchのサービス側に送られて、その情報をダッシュボードで見られるようになるっていう仕組み。
たとえば発生してるエラー、パフォーマンスの問題（遅いルート、遅いクエリ、遅いジョブ）、アプリ内で出力されたログが全部まとめて可視化できるの。
しかも、それらが完全にリンクされてるから、まずは「全体のリクエスト一覧」があって、グラフ上で「お、この辺エラー多いな」ってところにズームインできて、そのエラーを起こしてるルートを特定して、
さらにその中の1件のリクエスト単位まで掘り下げて見られるの。
で、その中に出力されたログも同じページ上に表示されて、別のシステムから探してこなくても、その場で全部確認できるんだよね。
Laravel APAC（アジア太平洋）チームについて
Matt)
僕たち、前にLaracon AustraliaのPodcast回でもNightwatchについて話したんだよね。
そのときは基本的な概要とか、「こういうところが面白い！」みたいな話をしたんだけど、
もしまだそれを聴いてない人がいたら、ショーノートにリンク貼っておく[1]のでぜひチェックしてね。
それから、Jessは最近デモもやってたよね？たしかLaracon Indiaだったかな？
どこかでNightwatchの紹介をしてたと思うんだけど、最近いろんなところでNightwatchについて話してくれてるよね。
というわけで、それらのリンクもまとめてショーノートに載せておくよ。[2]
で、今日はNightwatchの「中身」よりも、Nightwatchを作る側の体験について、
つまり「開発者としてどう感じてるか」って視点で話を聞きたいなと思ってるんだけど、
その前にちょっとだけ、今シーズンのテーマに絡めた質問があってね。
今シーズンは「Laravelチームをもっと知ろう！」って趣旨だから、
JessがリードしてるAPAC（アジア太平洋）チーム、今のNightwatchチームでもあると思うんだけど、
そのチームについてちょっと紹介してもらえる？
JessとTim以外には誰がいるのかとか、
将来的にNightwatch以外のプロジェクトにも関わる予定があるのか、とかそのへんも含めて、
チームのざっくり紹介をお願い！
Jess)
もちろん！今、チームメンバーは全部で7人いるよ。
ちょっとずつ人数も増えてきてて、Laravel全体で見たら、私たちがこのチームを始める前は会社全体で10人くらいしかいなかったんだよ。
それが今は、この1チームだけで7人だから、なかなかの規模になってきたよね。
で、メンバーを紹介するとプロダクトマネージャーとしてPhillip Hartin、デザイナーとしてJeremy、インフラ担当としてJames Carpenter、開発者としてRyutaとTim、そして最近新しく入ってくれたSabrinaも開発者として参加してくれてるよ。
たぶんこれで全員…だと思うけど、間違って誰か抜けてたらごめんね（笑）
Matt)
あれ、Phillipもチームに入ってたんだっけ？
Jess)
うん、一番最初に名前出したよ（笑）
Matt)
あー聞き逃してた、ごめんPhillip（笑）
てか、今あらためて思ったんだけど、「チームの全員の名前挙げて」って聞くのって、意外とプレッシャーかけちゃうよね（笑）
僕だって、Tightenの全メンバー挙げてって言われたら、たぶんもう辞めてる人の名前とか出しちゃうと思うし……ちょっと意地悪だったかも、ごめん。
でも、ほんとにすごいなって思うのは、最初はJessとTimっていう印象だったけど、
いま挙げてくれたメンバーって、単に何人かの開発者がいるってだけじゃなくて、
バックエンド・フロントエンド・デザイン・プロジェクト管理・プロダクト管理まで、
ちゃんと役割がそろった「本当のチーム」なんだよね。
その形でチームを作れたっていうのがほんとすごいなって思ってて。
で、ちょっと気になったんだけど、Jess自身は採用プロセスにどれくらい関わってるの？
それとも、「この人どうかな〜？」ってTaylorに提案するくらいで、あとはTaylorが決めて、Jessは「やったー来たー！」ってなる感じ？
Jess)
うーん、最初はね、まだTimと私のふたりだけだった頃は、
3人目として加わった Ryuta Hamasaki の採用には、私はちょっとだけ関わったって感じだったの。
そのときは、面接だけは私もやらせてもらったけど、
ジョブディスクリプション（募集要項）を作ったりとか、最初のプロセスには関わってなかったの。
たしかAndreが先に面接してて、「この人も会ってみてよ」って言われた流れだったと思う。
で、実際に会ってみたらすごく良くて、すぐに「この人いい！」ってなったの。
その後くらいに私がチームリードに昇進して、そこからは本格的に採用に関わるようになったかな。
最初の面接をやったり、ポジションの説明文を考えたり、そういうのにも関わるようになった。
面白いのが、最近採用したメンバーって、以前から一緒に働いたことがあって、もう信頼関係ができてる人たちが多くて、「ちょっと声かけてみようかな？」って感じで入ってくれた人が多いの。
やっぱり、一緒に仕事してて相性がいいってわかってると、
「ねえ、興味ある？」って自然に声かけやすいし、それってすごく嬉しいことだよね。
リーダーという役割について
Matt)
でさ、リーダーとしての役割ってどう？
Jessがコーディングできるのはもちろん知ってるけど、
コードのリードだけじゃなくて、人々を管理する立場ってどんな感じ？
Jess)
うん、正直けっこう面白いよ。ただ、もともとはずっと避けてた役割なんだよね。
昔から、なぜか周りの人に「マネジメント向いてると思う」って言われ続けてて、
「いやいや、私はコード書きたいだけなんだよ〜！」って思ってたから、ずっと断り続けてたの。
でも、Laravelでその役割をやるってなったときは、「もしマネジメント的な仕事やるなら、Laravelのチームだったら楽しめるかもしれない」って自然に思えたんだよね。
しかも、私のチームはみんな本当に超優秀で、すごく自主的に動ける人たちばっかりだから、私ががっつり指示出すって感じじゃなくて、チーム全体で協力して動いてる感じ。
私は一応「リード」って肩書きはあるけど、実際はみんなで一緒にチームを引っ張ってるって思ってるよ。
だから、いまでもコーディングの時間はたくさんあるし、あと、メンバーと1on1で話す時間もすごく楽しいんだよね。
定期的にちゃんと話せる時間があるのは、ほんとにいいなって思ってる。
他の会社のやり方とはちょっと違うかもしれないけど、Laravelって、チームごとに好きなスタイルで働けるんだよね。だから、うちのチームもずっと自分たちのやり方を貫いてて、楽しく協力しながらやってるって感じ。
あと、ソフトウェアの設計もすごく楽しくて、開発者向けのツールを作ってるから、自分たち自身が「どういうのがクールか」って判断できるんだよ。
前に医療業界で働いてたときは、「これどう作ればいいの？」って他の人に聞かないといけなかったけど、今は自分が開発者だから、「これが最高でしょ！」って自信を持って決められるのが本当にいいんだよね。
Matt)
それめっちゃいいね。
最悪の場合でも「ねぇ、これってどう思う？」って友達に聞けるもんね（笑）
それってほんとに最高なことだと思う。
Nightwatchを機能させるために、Laravel本体に変更が必要だったか？
Matt)
じゃあ次は、インターネットから集まった質問に移ろうか。
特に順番はないけど、まぁちょっとだけ僕の興味で並べ替えたりはしてる（笑）
で、最初の質問はこれ：
Nightwatchを動かすために、Laravel本体に何件くらいPRを出す必要があった？そもそも必要だったの？
Jess)
Nightwatchを「動作させる」ために必要だったPRで言えば、ほぼ間違いなくゼロだったと思う。
というのも、Laravel 10以上をサポート対象にするって最初から決めてて、だからLaravel 10がすでに持ってる機能でなんとかしようって考えてたの。
もちろん将来的には、Laravel 10向けにも変更をbackportさせたり、PRを出すこともあるかもしれないけどね。
Nightwatchは、Laravel内で発火するイベントを監視してデータを拾う仕組みなんだけど、Laravelって、かなり前から優秀なイベントがたくさんあるんだよ。
Laravel Pulseもそのイベントをベースにして作ったし、「使いたいイベント」は最初から把握できてたから、
わざわざ新しい仕組みを追加する必要もあんまりなかった。
とはいえ、一部のイベントには改良を加えたし、古いバージョンにはない新しいイベントも追加したりしてるから、必要があればそれをbackport（過去バージョンに対応）することもあると思う。
でも、仮にその新しいイベントが無かったとしても、代替手段はちゃんと用意してあるから、致命的な問題になることはないね。
Nightwatchを作る上で一番大変だった問題
Matt)
おっけー、めっちゃ面白いね。
じゃあ次の質問いくよ。
Nightwatchを作る上で一番大変だった問題は何？
あと、それをどうやって解決していったのか、プロセスも教えてほしい。
Jess)
うん、間違いなく一番大変だったのは、とにかく膨大なデータ量を扱うことだね。
ギガバイト、テラバイト、ペタバイト、
データベースに何十億行ものレコードが入ってるみたいな世界で、
これはもう文句なしで最大のチャレンジだった。
解決のためには、とにかく実験と調査の繰り返しだったよ。
Timと一緒に論文とかもめちゃくちゃ読んで、データの集計方法、特に事前集計（pre-aggregation）とか
ローリング集計（rolling aggregation）について調べまくった。
新しいデータを加えるたびに、全体を再計算せずに集計結果を更新できる方法があればよくて、
平均とか最小値・最大値なら簡単なんだけど、
P95（95パーセンタイル）みたいな分位数の計算はめちゃくちゃ難しいんだよね。
Matt)
ああ、なるほど、そこは確かに難しそうだ。
Jess)
で、Laravel Pulseで得た知見も活かしつつ、他に使えそうなツールや技術を探していく中で出会ったのが、
OLAPデータベース（オンライン分析処理：Online Analytical Processing）っていうジャンル。
それまで聞いたこともなかったんだけど、調べていくうちに「OLTP（トランザクション処理向けのデータベース、MySQLやPostgreSQLのことね）」との違いがわかってきて、「最初からこれを知ってたら、もっと早く調べられたのに〜！」って思った（笑）
OLTPっていうのは私たちが普段よく使ってるデータベースで、処理の正確さとかリアルタイム性に強いんだけど、大量データの集計処理にはあまり向いてなくて、
一方のOLAPは分析処理に特化してる分、トランザクション処理にはちょっと弱い。
だから両方を完璧にこなすってのは難しくて、どっちかに振り切る必要があるんだよね。
で、いろんなOLAP系のDBを試して、めちゃくちゃな量のデータを流し込んで、PoC（概念実証）を何回もやったって感じ。
Matt)
うんうん、それにJessはその解決方法の一部について、登壇して話してたよね。そのトークもショーノートにリンク貼っておくよ。[3]
たしか去年のLaracon USだったよね？
Jess)
そうそう、あれはまだNightwatchを正式に発表する前の段階だったんだけど、舞台裏的な話をしたトークだったんだよね。
もうそのときはClickHouse（データベース）に完全に夢中でさ、頭の中はそればっかり（笑）
登壇内容考えてたときも「今これ以外に話したいことない！」ってなってて、
世界中の人にこのデータベースのすごさを伝えたい！って思ってたから、あのトークになったって感じ。
Nightwatchの負荷テストをどう行っているのか
Matt)
いいね！そのトークはほんとに素晴らしかったし、Nightwatchの「キーパーツをどう解決したか」っていう旅として最高だったよ。
ショーノートにリンク貼っておくから、まだ聴いたことない人はぜひチェックしてね。
で、今Jessが言ってくれた話の中に、ちょうど他の質問と関連する内容があってね。
それが、「設計やアーキテクチャの検証のために、どうやって負荷テスト（ロードテスト）をしてるのか？」っていう質問なんだ。
Jess)
それはいい質問だね、、
Nightwatchって、データがデータベースに届くまでに、いくつかの処理ステップ（システム）を通るようになってたから、まずはそれぞれのコンポーネントを個別にテストする必要があったの。
たとえばデータベースについては、大量のリアルな見た目のランダムデータを作るスクリプトを自分で書いたの。
このとき重要だったのは、単純に「完全にランダムな値」を使わないこと。
例えば「1〜1000の間で適当にリクエスト時間を生成する」みたいにすると、データの分布が現実的じゃなくなるんだよね。
実際のアプリケーションでは、リクエストの時間って偏りがあるから、それをできる限りリアルに再現する必要があったの。
しかも、P95（95パーセンタイル）とかの集計アルゴリズムって、データの分布がどうなってるかによって、得意・不得意があるから、そういう部分も意識してデータを作ってた。
で、その上で大量のデータをデータベースに流し込んで、どこまで処理できるかをテストするというのが一番大きな検証だったと思う。
あと、データの取り込み自体は「まぁいけるだろう」ってある程度の自信はあったけど、
いろんなAWSのサービスを試したの。Kinesis Streamsとか。最終的にはAWSのKafkaを使うことにしたよ。Kafka単体でも負荷テストしたね。
そのときも、なるべく現実に近いペイロード（データの中身）を使って、
「このインスタンスサイズなら、うちのデータをどれくらい処理できるか」ってのを計測してた。
こういったテストを行ったんだけど、最終的に一番大事だったテストは実運用でのテストだったと思う。
具体的には、NightwatchをLaravel Forgeに実際に入れて動かしてみたんだよね。
Forgeって、めちゃくちゃデータベース処理が多くて、たしか1ヶ月で35億件以上のクエリ記録があるの。
つまり、とんでもない量のリクエストが飛び交ってる。
そのForgeにNightwatchを導入したら、今まで選んできた構成やリソースがどう動くかが一気に見えたんだよね。結論としては、「思ったよりちゃんと動いた！」って感じだった。
でも、正直Forgeのデータ量は想定より全然多かったし、「Forgeってこんなにやってたの！？」って、こっちが学ばされる場面も多かった。
Nightwatchを通して初めてわかったことも多くて、思ってた以上に複雑で重たい処理をしてるってことに気づいた。
で、そのせいでパフォーマンスの問題に直面したこともあって、そのたびに新しい集計戦略を考えたり、改善したりしていったの。
負荷テストについてはこんな感じで進めていたかな。
Nightwatch でKafkaをどう使っているのか
Matt)
それもすごいね。
で、実はそれも別の質問とかぶってて、何人かから聞かれてたんだけど、「Kafkaをどう使ってるのか？」っていう話、もうちょっと詳しく聞きたいんだ。
正直、僕はKafkaについてはちょっとしか知らなくて……「Apacheのストリーミング関連の技術だよね？」って程度。Nightwatchみたいなツールで、Kafkaがどういう役割を果たしてるのか、ざっくりでいいから教えてくれる？
Jess)
もちろん！
ていうか、私もNightwatchを作るまではKafkaのこと全然知らなかったよ。
だからあなただけじゃないから安心して（笑）
Matt)
ああ、それ聞いてちょっと安心した（笑）ありがとう。
Jess)
Kafkaってざっくり言うと、データのストリーミングサービスみたいなもので、Producer（プロデューサー）って呼ばれる側が、Kafkaに「メッセージ」をどんどん送って、それをConsumer（コンシューマー）が読み取るっていうものなの。
つまり、「メッセージバス」的な役割を果たしてて、送ったり受け取ったりするための中継地点みたいな感じなの。
ユースケースとしては、イベントを配信して、複数のConsumerが同じイベントを受け取るようなマイクロサービス構成とかでよく使われるよ。
でも、Nightwatchの場合は、ProducerとConsumerが1対1で、Kafkaを通ってからDBに行くだけなんだけど、色々なメリットがあるの。
たとえばもしデータベースのスキーマ変更をする必要があるとき、「ポーズ」ボタンを押して、データの受信を一時停止すると、Kafkaにはどんどんデータが溜まっていって、DBのメンテや変更が終わって「再開」ボタンを押すだけで、Kafkaに溜めてたデータを一気に処理できるの。
だから、一種のQueueみたいに使うことができて、パイプを一時的に分解して、あとからまた繋ぎ直すみたいな運用ができるの。
Matt)
それはすばらしいね。
Jess)
うん、すごく便利なんだよね。
Kafkaにはトピックっていう概念があって、それぞれのメッセージは別々のトピックに送られるの。
で、私たちが収集してるいろんな種類のメトリクスごとに、それぞれ違うトピックに入れてる。
そのトピックが、それぞれデータベース内の別々のテーブルに対応してるんだよね。
それに、Kafkaはデータの挿入にも役立ってて、データベースって、バルクインサートした方がいいじゃない？1行ずつ個別に insert するんじゃなくて、ある程度まとまったチャンク単位で insert してあげた方がいい。
Kafkaのストリームに全部のデータを流しておくことで、例えば5秒分のデータを一度に読み込んで insert できるようになるの。
そのときに、1回の insert で何百万行ものデータになることもあるし、データベースはそういう一括 insert のほうをずっと好むんだよね、1行ずつ処理するよりも。
Matt)
それって、普段僕たちが扱ってるようなデータベースの考え方とは真逆だよね。
普通だったら、「大量の処理をキューにためるのはやめよう、そうするとシステム全体が詰まっちゃうから」って思うじゃない？
でも今回は、「いや、むしろそれが正しいやり方なんだよ」っていう。
本当に、いつものLaravelアプリとはだいぶ違う世界だよね。
Jess)
ほんとに、そう。
~26:15まで。後編に続く
-
該当のPodcastリンク: https://share.transistor.fm/s/d1f7cc5b 。日本語訳はこちら ↩︎
-
Laracon EU 2025でのNightWatchデモ: https://www.youtube.com/watch?v=0j6z_oq4cZU ↩︎
-
Laracon US 2024でのJess Archer氏のOLAP DBについてのトーク: https://www.youtube.com/watch?v=_jjvaFWWKqg ↩︎
Maru2025/04/17
Laravel Podcast Season7 Episode 4 - 後編
Matt Stauffer(Tighten CEO) x Jess Archer(Laravel Nightwatch／APACチーム エンジニアリングチームリード)
前編の続き。26:15〜
スケーラビリティをどう担保するか
Matt)
すごく面白いね。さて、次の質問なんだけど……
ちょっとこの質問の前提がそもそも正しいのかどうか、Jessの意見も聞いてみたいなと思ってる。
質問の内容は「事実上スケールに上限がないようなシステムを、どう設計するか？」っていうものなんだ。
で、さっきの話でもあったけど、NightwatchをForgeに導入してみたら、想定よりもデータ量が多かったって話があったよね。
実際、今は全ユーザーを抱えているわけじゃなくて、まだ限られた段階だと思うけど、最終的にはもっとたくさんの顧客が使うようになるはずでしょ？
それを踏まえて聞きたいのは最初から「完璧にスケーラブルなものを作ろう」と意識して設計してたのか？
それとも、「とりあえずめちゃくちゃ強力なインフラを用意して、限界が見えてきたらその都度パワーアップさせていく」っていう方針だったのか？
つまりどれくらいが「自動でスケールする仕組み」で、どれくらいが「最初からオーバースペックで用意してある構成」なのか？ってことなんだ
Jess)
面白い質問だね。
やっぱりスケーラビリティの部分が一番怖いんだよね。
というのも、Nightwatchがどれくらい人気になるのかは分かってないし、それぞれのユーザーのアプリがどれだけ大きいのかっていうのも予測がつかない。
もし登録してくれる人たちのアプリがみんな小さめだったら、それは全然OKなんだけど、もしみんな想定以上に巨大なアプリを持ってたら、それはまた別の話になる。
だから、設計上すごく大きなポイントだったのは「あるユーザーの負荷が、他のユーザーに影響を与えないようにする」ってこと。
いわゆる「ノイジー・ネイバー問題（うるさい隣人問題）」ってやつね。
だからデータベースの構造も、ユーザーが自分のデータをクエリする際に、他のユーザーのデータに一切干渉しないような設計にしてる。
つまり、「他の誰かが大量に負荷をかけていても、小規模なユーザーのパフォーマンスには一切影響が出ない」っていう仕組み。
Kafkaに関しても、どうスケールするか、レプリカやインスタンスをどう増やすかっていうのは把握できていて、スケーリング戦略もきちんと用意してある。
それに、構成的にすごく良いのは、特定の顧客ごとに専用インスタンスを用意できるってこと。
たとえば、あるお客さんに対しては「このDBを使おう」って、ダッシュボード側で接続先を動的に切り替えることができるの。
だからいわゆる、水平スケーリング（横に広げる）、垂直スケーリング（性能を上げる）
の両方に対応できる設計になってる。
あとは、ちゃんとモニタリングツールも入れてあるから、
どのタイミングでスケールが必要になりそうか、事前に察知できる仕組みもあるよ。
今はNightwatchは「アーリーアクセス」段階で、少しずつお客さんが増えてきてるけど、それも含めて自分たちの想定が合っていたかどうかを検証する機会になってる。
今までのテストって、いわばラボ環境でのシミュレーションだったから、実際のアプリの使われ方と全然違うケースも多くてね。
たとえばForgeは面白くて、グラフを見てると、毎時ちょうどにでっかいスパイクが来るんだよね。
それって、バックアップジョブが全部一斉に走るタイミングなの。
他にも15分ごとにちっちゃいスパイクが必ず発生するんだけど、それも正確に15分刻みで発生するから、アプリ特有の使用パターンがあるってわかる。
でも他のアプリでは、また違った使い方のクセがあるはずだよね。
Matt)
面白いね。
きっと今後、深夜2時にスパイクが起きるみたいなケースも出てくるんだろうね。
「みんな寝てるから今のうちに重い処理やっちゃおう！」みたいな。
Jess)
そうそう、しかもタイムゾーンもバラバラだしね。
ある顧客の営業時間が、別の顧客にとっては真夜中だったりするから。
Nightwatchのアプリケーション構成
Matt)
いや〜面白いね。
これは元々の質問にはなかったんだけど、ちょっと気になってて。
データの取り込み（ingest）とダッシュボードって、完全に別々のアプリケーションなの？
それとも、今のところ全部が一つの巨大なアプリにまとまってる感じ？
Jess)
えっと、基本的には大きく分けて2つ、というか実際には3つのコードリポジトリがあって、全体を構成してるよ。
1つ目は、Laravelアプリにインストールするパッケージ。
これはオープンソースで、すでに公開済みだから、誰でも見られる状態になってる。
2つ目は、データ取り込み（ingest）のインフラ構成。
これは主に AWS のサービス群を使っていて、インフラコードが中心。
3つ目が、ダッシュボードのアプリケーション。
これは、データにクエリを投げたりするメインのUIアプリだね。
Matt)
これは面白いね。
普段の僕は、「アプリを複数に分けなくていいよ」「データベースを用途ごとに分ける必要なんてないよ」ってよく言ってるんだよ。
「そんな複雑なアーキテクチャは実際には要らないよ」ってアドバイスしてる立場でさ。
でも、今君の話を聞いてて思ったのは、「いや、これは確かに必要だわ」っていうこと。
「誰にも必要ない」わけじゃなくて、こういうユースケースみたいに必要になる場面もちゃんとあるんだよね。
問題は、それを聞いた人たちが、「じゃあ自分のアプリ、たとえば『犬のためのCRUDアプリ』にも同じ構成を使おう！」って真似しちゃうことなんだ。
いやいや、そのアプリには絶対そんな複雑さ要らないから！って（笑）
でも、Nightwatchにはちゃんと意味があるからOKなんだよね。
Jess)
ほんとそれ、100％同意だよ。
私たちも、めちゃくちゃ慎重に判断してると思う。
Nightwatchでは、今のところ「2つの別アプリ」にしてるけど、世の中にはこの問題を10個以上のサービスに分けて解決しようとする人もいると思う。
でも私たちは、できるだけシンプルに保つことを大前提にしてた。
ちなみに、データベースは2つ使ってるんだけど、私自身これまでのキャリアで「2つ必要だな」って思ったのはこれが初めてかも。
1つは、トランザクション向けのデータベースで、これは今でも必要だし、そこには引き続き PostgreSQL を使ってる。
Postgres は、本当に優れたDBで、「特定の1件を素早く検索する」とかにはめちゃくちゃ強い。
でも、何十億行ものデータに対して集計処理をかけるってなると、さすがに向いてないんだよね。
モニタリングによるクライアントアプリケーションへの影響を防ぐために行なっていること
Matt)
なるほど、集計処理についてはってことだね。
じゃあ、次の質問にいこうか。
すでに触れた内容かもしれないけど、念のため聞いておくよ。
もしまだ話してないことがあれば教えてね。
「モニタリングコードによってクライアントアプリケーションが遅くなるのを防ぐために、どんな技術が使われていますか？」
……あ、最初これ Nightwatch 自体のパフォーマンスの話かと思ってたんだけど、
たぶんこれ、僕らが Nightwatch をアプリに入れたときの話だよね。
Jess)
うん、そうだね。
Matt)
じゃあ、どうなってるのか教えてほしいんだけど、
Nightwatch をインストールしたときに、自分のアプリのパフォーマンスが落ちたりしないようにするには、どういう仕組みになってるの？
Jess)
うん、まず最初にはっきり言っておきたいのは、
どんなオブザーバビリティツールでも、多少なりともパフォーマンスへの影響はあるってこと。
つまり、何かを観測したり計測したりする以上、完全にノーインパクトっていうのは物理的に不可能なのね。
でも、私たちが行った負荷テストの結果では、
その影響は基本的に目に見えて分かるようなレベルではなかった。
Nightwatch を Forge に入れたときも、「パフォーマンスに大きなスパイクが出た」みたいなことは全くなかった。
で、私たちはそこにすごく意図的に・慎重に取り組んでいて、たとえばデータ収集のコードでは、Laravel の便利な機能（Collectionとか）を使っていないんだよね。
Matt)
ああ、それってちょっとだけ余計な負荷がかかるからでしょ？
Jess)
そう、ほんのちょっとだけどね。
たとえば、Collection を使うと、 余分なオブジェクトがメモリに載ったり、ループ処理が少しだけ非効率になったりするの。
でもその代わり、コードは読みやすくなるし、ほとんどのアプリケーションでは全然問題ない。
むしろ、そのトレードオフは正解だと思う。
ただ、Nightwatch においては影響を最小限にしたかったから、
あえてもっと低レベルな実装を選んだ。
もう一つの大きな工夫として、ローカルエージェントを使っているっていうのがある。
アプリの各リクエスト処理の中で発生するメトリクスは、外部サーバーに直接送るのではなく、ローカルで動いているエージェントに送る仕組みなの。リクエストの最後に外部通信するんじゃなくてね。
この処理ってローカルで完結するから、すごく速い。
たとえば、レスポンスを返した後の terminating フェーズでデータを外部に送る場合、たしかにユーザー側ではもうレスポンスを受け取ってるから、体感では遅く感じないかもしれない。
でも、その処理が終わるまでそのリクエストを処理してたプロセスはまだ解放されないんだよね。
つまり、次のリクエストを受け取れるまでの時間に影響する。
だから、できるだけその処理を早く終わらせたかった。
で、そのローカルエージェントが受け取ったデータは、一定量ごとにまとめて送るようになっていて、
たしか10秒ごとか、もしくは6MB分のデータが溜まった時点で、最終的に Ingest インフラ側（取り込みシステム）に送信されるの。
Matt)
なるほどね、、そのエージェントってどこで、何で動いてるの？
Jess)
うん、エージェントは PHP で動いてるよ。
最初は正直、「これって Rust とか Go みたいな言語で書かなきゃダメかな？」って思ってたの。
でも、「まずは PHP で試してみよう」ってことで、軽くプロトタイプを作ってみたんだよね。
Tim がエージェントの大部分を作ってくれて、初期の PoC（概念実証）もやってくれたんだけど、
それがね、すごく良い感じだったの。予想以上に。
メモリ使用量も少ないし、制御もしやすくて、メモリの使用状況をちゃんと監視してても、ちゃんと自動的に解放されるのが分かった。
だから、「じゃあもうこれでいいじゃん」ってなって、「わざわざ Rust や Go に書き直す必要は今のところないね」って。
まあ、将来的に書き直すかもしれないけど、今のところは PHP で全然問題なしって感じだよ。
使ってるのは ReactPHP で、非同期イベントループを持った処理モデルになってる。
つまり、エージェント自体は 小さな Web サーバーのように振る舞うんだよね。
アプリのいろんなプロセスから送られてくるデータを受け取る必要があるから、それにすばやく応答して、データをバッチにまとめて、Ingestシステムに送信する。
しかも、送信中も新しいデータを受け取り続けられないといけない。
で、それ全部、PHP でちゃんとできちゃってるから、「じゃあもうこれでいいじゃん」ってなった、ってわけ。
Matt)
それはすごいね。でもそれって、アプリケーションをホストできる環境に制限が出たりしない？
それとも、最近のモダンな環境なら、そのエージェントも普通に動かせる感じ？
Jess)
そうだね、だってこれは PHP 製だし、Laravel も PHP 製でしょ？
つまり、Laravel が動くところならどこでもこのエージェントも動くってわけ。
それがまた、大きなメリットのひとつでもあるんだよね。
たとえば、もし私たちが PHP じゃないものを監視するツールを PHP で書いてたら、
「サーバーに PHP をインストールしてね」ってお願いしないといけないわけだけど、
今回のケースでは、もうすでに PHP がインストールされてるのが前提だから、そういう心配はないの。
Seederを作る上で便利なテクニック・パターン
Matt)
いや〜それ最高だね。すごく面白い。
えっと、時間的にこのあとの質問も全部いけそうだね。
その前に、プロセス関連の質問に入る前に、もうひとつだけ。
君が以前のトークでも話してたけど、Nightwatch をテストするために作った Seeder の話があったでしょ？
それについても少し触れてたし、実際このエピソードでも軽く話してくれたけど。
ちょうど僕たち（Tighten）でも最近 Seeder に関する大きなブログ記事を出した[1]ばかりで、
僕自身も、クライアントに対して「本番DBのダンプがないとアプリの正確なテストができない」って考えを変えてもらうのが好きなんだよね。
そうじゃなくて、「ちゃんと Seeder 作れば本番に近い形でテストできるよ」って伝えてるんだ。
ただ、多くの人が Seeder っていうと「Lorem Ipsum ばっかりのランダムデータ」って思ってるんだよね。
そこで聞きたいのは、リアルなデータを生成する Seeder を作るうえで、何か便利なテクニック・ツール・パターンがあった？
それとも毎回「とりあえず作ってみて、分布がそれっぽくなるまで地道に調整」って感じだった？
Jess)
「簡単だった」って言えるものはないね（笑）
正直、うちの Seeder のコードはけっこう汚いと思う。
宣言的（declarative）って感じでもないし、あちこちでガチャガチャいろんな処理をしててね。
でも、中には確率ベースのロジックがけっこう組み込まれてて、「どのリクエストを投げるか？」を決めるために、いろんなルートを登録して、それぞれに発生確率の重みづけをしてるの。
たとえば「このルートは 10% の確率で選ばれる」、「あのルートは 30%」とかね。
で、「どのユーザーがリクエストを投げるか？」もランダムに決めてるんだけど、
ちゃんと勤務時間（business hours）みたいな概念を持たせてるの。
Matt)
うわ、それめちゃくちゃかっこいいじゃん！
Jess)
でしょ？（笑）
だから、ユーザーをランダムに選ぶときも、その時間が「勤務時間内」のユーザーしか選ばれないようになってる。
これはけっこう大事で、Nightwatch では特定のユーザープロファイルをクリックすると、そのユーザーのリクエストのグラフが表示されるんだよね。
そのときに「24時間ずっと均等にリクエストしてる」ってのはリアルじゃない。
勤務時間だけ動いて、夜間は静かになるっていう方が、よっぽど自然。
それから、「時々失敗するリクエスト」も入れてて、たとえば「5%の確率で 500 エラーになる」みたいなランダムなレスポンスエラーの挿入もしてる。
それ以外にも、処理時間のシミュレーションもちゃんとしてるんだよ。Nightwatch ではタイムラインで個別のリクエストをズームインして、どの DB クエリがどれだけ時間かかったか（マイクロ秒単位）まで見られるから、そのために「どれくらい時間がかかるか」をランダムで設定してる。
でもただの完全ランダムじゃなくて、たとえば「だいたい1秒くらい。でも±100msくらいのばらつきがある」って感じで、ランダムだけど一貫性のある範囲に収めてる。
Matt)
なるほど、制約付きのランダムってことだね。最高だわ。
Jess)
そうそう、だから「スロークエリ一覧」みたいなページを見ても、全部がちょっとずつ遅いとかじゃなくて、常に速いクエリ、常に遅いクエリ、たまに遅くなるクエリみたいな、ばらつきのあるデータがちゃんと再現できてるの。
あと特定の時間帯だけ「外部APIがダウンしていることにする」っていう設定もあるよ。
だからその時間帯にそのエンドポイントへリクエストすると、ちゃんとエラーが返ってくるようになってて、グラフ上ではその時間帯だけ赤くなるんだ。
グラフが全体的に平均的に赤いんじゃなくて、あるエリアだけエラーが集中しているように見えるから、
「ズームインして調査する価値のあるデータ」っていうのが見えてくる。
さらに、デモで見せるときにすぐ意味が分かるようなシナリオも考えてあって、たとえば私たちが選んだのは「航空券予約アプリ」っていうドメインだった。
このドメインだと、航空券、フライト、航空会社とかいろんなリレーションがあってちょうどいい複雑さがあるし、でも誰でもイメージしやすいんだよね。
たとえば「このフライトはオーバーブッキングされてた」ときはオーバーブッキング例外が発生するとかもあるし。
Matt)
うん、それならすぐに理解できるよ。
Jess)
でしょ？
「この便だけキャッシュが10分効いてる」時は、10分間はキャッシュヒット、その後はキャッシュミスでスロークエリみたいなシナリオをすべて Seeder に組み込んでるの。
だから想像通りそのコード、まあまあカオスだけど（笑）、
それぞれに「名前付きシナリオ」をつけておいて、たとえば「たまに遅くなる slow ルート」とか、呼び出し側でも分かりやすくなるようにしてるんだよ。
Matt)
いや〜、本当に面白いね。
僕も今までかなり複雑な Seeder を書いてきたことがあると思ってたけど、これはもう次元が違うレベルだよ。聞いててめちゃくちゃ楽しい。
さっき君が言ってた「現実に起こりうるシナリオをちゃんと再現したかった」っていう話、
それって本当に大事だと思ってて。
前に話したときにも言ったけど、僕が Nightwatch の中で一番好きな部分のひとつは、「SaaS を開いたときに、ユーザーが何を知りたいのか」にめちゃくちゃ気を配っているってところなんだよ。
たいていの人が忘れがちなんだけど、SaaS を作るときって、「ただデータを見せるだけじゃ足りない」んだよね。
多くのユーザーは、アプリを開いた瞬間に「何かを知りたいんだけど、何を見ればいいのか分かってない」状態だったりする。
だからこそ、Nightwatch がやってるみたいに「今、ここを見てください！」って導いてくれる UI は本当に価値がある。
で、そういうことができるようになったのも、君たちがちゃんとしたデータを自分たちで得られるようになったからだよね。
……これ言ってよかったかわからないけど、実は今朝、僕たちのチームでも 早期アクセス をもらって、Nightwatch を実際の本番SaaS に入れて試してみたんだ。
で、クリックしながらいろいろ見てたら、もう「すげぇ…！」ってなってさ。
たとえば ユーザーページを開くと、過去24時間のリクエストのうち、何件が200番台、300番台、400番台、500番台だったかが一目で分かる。
これってほんとすごいよ。
たとえば「このユーザー、めっちゃエラーに当たってるな」ってわかったら、「多分今すごくフラストレーションたまってるんだろうな」ってすぐ気づけるし、場合によっては連絡をとる判断材料にもなる。
あるいは、全体のリクエストを見る中で「この API エンドポイント、402 エラーめっちゃ出てない？ 何これ？」って気づけたり。
チームがちゃんとセットアップできてるか確認するために、ただざっと UI をクリックして見てただけなのに、ユーザーの使い方・コードベース・アプリの構造について、今まで気づかなかったことが見えてきた。
つまり、「本当に気にすべきことの発見性（discoverability）」をめちゃくちゃ重視して作られてるってのが伝わってきたよ。
で、それができた背景には、あの Seeder の設計があるんだよね。
もちろん、君たちは最初から「そういうものを作る必要がある」って分かってたからそうしたんだけど、
僕としては、今回の話を通して「リアルで複雑で、現実的な Seeder を作ることで、普通では得られないリアリティのある気づきを得られるんだ」って、他の開発者にもぜひ伝えたいと思ったよ。
Jess)
ほんとに、その通りだと思う。
でもね、Seeder でやる場合の問題点のひとつは、「どんなことをソフトウェアから知りたいかを、あらかじめ自分で考えないといけない」ってところなの。
つまり、何が知りたいかを先に決めて、それに対応したシナリオを用意して、Seeder を書く必要がある。
でも、本物のデータがあると、まだ知らないシナリオが自然に出てくるんだよね。
「これ、何が起きてるのか分からない」っていう場面に遭遇したりして、全然違う視点でデータを見ることになる。
でも、Seeder によって教えられるのは、「自分がそれを教えてって言ったこと」だけだから、それを見せられても「うん、まあそうだよね」ってなる（笑）
だから、Seeder は Seeder でめちゃくちゃ役立ったけど、実際に Forge を Nightwatch で監視できるようになったときは、本当にいろんな情報が得られた。
そこから、「今見えてるこの情報、面白いけど、もう少しだけここも見たいな」ってなって、必要な情報を追加していくきっかけにもなったんだ。
つまり、Seeder で作ったたくさんのシナリオと、実際のリアルデータから得られる発見と、両方を組み合わせていくっていう感じ。
私たちは自分たちの Nightwatch を、Nightwatch で常に監視してるから、日々「使いながら改善する」サイクルが続いてる。
ただ、そこにはちょっとしたジレンマもあって……
たとえば、「今はツールとして Nightwatch を使って、ある問題を解決しようとしてる」最中に、「おっ、この UI なんか変じゃない？」って気づいちゃって、「あれ？ いまそれ直しにいく？ それとも今やってるタスクを先に終わらせる？」みたいに、自分の役割がごっちゃになるときもあるんだよね（笑）
プロジェクトのスコープ設計・計画について
Matt)
うん、それ最高だね。さて、今ちょうど44分。
「45分で終わる」って言ってたから、最後にもう1つだけ質問させて。
他にも質問くれた人たち、ごめんなさい。全部は取り上げられなかったけど、最後に紹介したいのは僕の友人 Kenny Meyers の質問。
3つ構成の質問なんだけど
1. プロジェクトのスコープ設計や計画をどうやって進めてる？
2. その中で、作業をどう分割して進めているか？
3. そして最後に……「僕、あなたの親友になってもいい？」
……これは Kenny が面白いからってのもあるけど（笑）、
でも同時に、君のことを素晴らしい人だと思ってるのが僕だけじゃないっていうのも伝えたくて。
「質問できる場面で、あえて “親友になりたい” って書きたくなるくらい」君のことを尊敬してる人が他にもいるっていうのが、このコメントからもすごく伝わると思う。
で、話を戻すと、Jess はリードとしてチームを率いているわけだけど、Laravel の他のメンバーと同じように、「それぞれのチームがそれぞれのやり方で動いてる」って話がよく出てくるよね。
厳密なプロセスがあるわけじゃなくて、チームごとに自由に動いてるって。
ただ、それでも今や君のチームは、ただ君と Tim が何かハックしてるだけじゃない、十分大きな規模のチームになってる。
そこで聞きたいのは「Nightwatch 全体を作るぞ」ってなったとき、どこから始めて、どうやって分割して、どう計画して進めたの？」
たとえば週単位のサイクルで動いてるの？とか。開発プロセスってどんな感じ？
Jess)
うん、プロセスはね、プロダクトの成熟とともにすごく変わってきたよ。
最初の段階では、ほんとにただ手探りでハックしてる感じだった。
プロトタイプを作ってみて、面白そうな方向に進んでみて、「これワクワクする！じゃあこっち行ってみよう！」っていう、ほんとに発見フェーズって感じ。
で、いろいろ試して「どこが難しいのか」「何が可能なのか」を学んだあとで、ようやく「じゃあこのプロダクト、どうやって作っていこうか」って形が見えてきた。
デザイナーを早い段階で入れたのはすごく助けになったよ。Jeremy をチームに迎えたんだけど、彼はほんとに素晴らしいデザイナーで、単なるビジュアルデザインだけじゃなくて、プロダクトデザインの視点も持ってる。
しかもフロントエンド開発もできるから、「この複雑なデザインも自分で実装できちゃう」みたいな存在で、すごく話しやすくて、「こんな体験を実現したいんだよね」って伝えると、彼が「じゃあこういうUXにしよう」って考えてくれる。
最初のうちは、チケットとかタスク管理とかはほとんどしてなかった。
とにかくオーガニックで自由な進め方。でも、チームが大きくなって、プロジェクトも「いよいよ本格的にやっていこう」って段階になって、そこから Linear を導入したんだよね。
最初は正直、「プロジェクト管理ツールってどうやって使えばいいの…？」って感じで（笑）
とりあえず何パターンか試して、「あーでもないこーでもない」ってやって、タスク突っ込んで放置しちゃったりもした。
でも、その後でプロダクトマネージャーが入ってくれて、しかも彼も開発者でもあるんだよね。
うちのチーム、職種問わず全員がコーディングするの（笑）
彼が入ってからは、カオスに秩序を持ち込んでくれた感じ。
たとえばアプリケーションをどう分割するか、他のチームが何をやってるかをどう連携するか、レポーティングの粒度をどう揃えるかみたいな管理的な視点もありつつ、チームのやりたいスタイルは崩さない、ってバランスが取れてきた。
今は、3週間のサイクルで進めてるよ。
サイクルの前にちょっとだけ「リファイン」の時間をとって、バックログにあるタスクを見ながら「今回はどれをやるか」を決める。
そういう意味ではプロセスもだいぶ整ってきたけど、それでもやっぱり、今のサイクルに入ってないことでも拾いにいったりするんだよね。
私たちは、本来の意味でのアジャイルでありたいと思ってるから。
たとえば、「今こっちのタスクがすごく気になって仕方ないんだよね」ってことがあって、そういうときは「うん、なんとか理由つけてやっちゃおう」ってなることもあるんだ。（笑）
Matt)
なるほどね。でさ、Linear の中に「ここまできたらリリースできる」っていうラインみたいなものってあったりする？つまり、Definition of Done(完了の定義) 的なものってどこかにあるの？
Jess)
うーん、厳密に言うと、そういうのは特にないかな。
ただ、いくつかのデッドラインは設けてて、「このタイミングまでにこのレベルに仕上がったら、それで出す」って感じ。
ずーっと永遠に磨き続けるのではなくて、ある時点で「もうこれ以上はやらない」って線を引く必要があったの。
そこで「この機能たちはリリースに含める」って決めて、それらを Laravel の標準にふさわしい品質まで磨き上げるっていう方針にした。
で、それ以外の機能については、とりあえず feature flag（機能フラグ）で非表示にしておいて、リリース後にちゃんと仕上げてから追加していく、っていう戦略を取ってる。
まずはちゃんと動くものを出してから、あとで仕上げていくっていうアプローチのほうが、私たちにとっては合ってるんだよね。
Outro
Matt)
じゃあ、さっきも言ったけど、これほんと何時間でも話してられるね。
でも時間的にそろそろ終わらなきゃいけないから、最後にひとつだけ。
このトピックの中で、他に話しておきたかったこととか、今頭の中にあること、心の中にあること、なんでも大丈夫なんだけど、今日の締めくくりとして何か伝えておきたいことはある？
Jess)
うーん、特に思いつかないかな……あっ！
Kenny の「親友になってくれる？」って質問に答え忘れてた（笑）
とりあえず、まずは「友達」から始めてみようよ。で、あとは流れにまかせていこう（笑）
Matt)
すっごくいい返しだったよ、ほんとに（笑）
Jess)
うん、そうだね、特に他に話しておきたいことは思いつかないかな。
とにかく今、このプロジェクトにすごくワクワクしてるの。
チームのみんなが作り上げたものを、すごく誇りに思ってるし、これをもっともっと多くの人に触ってもらえるのが、ほんとに楽しみで。
さっきも言ったけど、自分たちのアプリに Nightwatch を入れて使ってみるだけでも、「今まで知らなかった発見がある」っていうのがめちゃくちゃ面白いんだよね。
だからこそ、他の人たちにもその体験をしてもらうのがすごく楽しみなんだ。
Matt)
これは自慢とかじゃなくて、ほんとに本音なんだけどね、
昨日までの僕だったら、「ここまでワクワクするプロダクトって最近他にあったかな？」って思うくらいだったんだよ。
Cloud もすごく良いとは思うけど、僕はそのターゲットど真ん中ってわけじゃないから、そこまで刺さる感じではなかったんだよね。
でも Nightwatch は、初めて聞いたときから「これは絶対触りたい！」ってずっと思ってた
今日はまだ 3分くらいしか触れてないけど、その3分だけでも「期待してた通りだった」って言えるぐらい、すごかった。
これ、誇張抜きで本当に、何年も運用してるアプリについて、たった数分でこんなに多くのことを学べるなんて信じられない。
だから僕も、君とまったく同じ気持ちだよ。
他の人たちがどう感じるのか、どう使っていくのかを早く見てみたい。
そして僕自身も、もっともっと使っていきたいと思ってる。
いつもながら、ここまで作ってくれてありがとう。
Nightwatch に限らず、これまでやってきてくれたすべてのことに感謝してるよ。
そして今日、ちょっとでもこうして一緒に話せて本当に嬉しかった。
Jess)
ありがとう、Matt。そう言ってもらえて本当にうれしいよ。
そして呼んでくれてありがとう！
Matt)
こちらこそ、いつだって君と話せるのは最高だよ。
そして、聞いてくれていたみなさんも本当にありがとうございました！
また次回お会いしましょう！