「私の愛したLaravel」―トークの裏側、シンプルへのこだわり

PHPerKaigi 2025に3年連続で登壇させて頂いている。

年	タイトル
2023	Laravelへの異常な愛情または私は如何にして心配するのを止めてEloquentを愛するようになったか
2024	Laravel OpenAPIによる “辛くない” スキーマ駆動開発
2025	私の愛したLaravel 〜レールを超えたその先へ〜

今回の題材は、アプリケーションを破綻から守るための「Laravelの拡張」だ。この題材や「私の愛したLaravel」というタイトルの理由、テーマ選定や完成までの紆余曲折を紹介したい。主にトークまたは資料をご覧になった方向けの補足記事。

映画や小説作品をオマージュする理由

「私の愛したLaravel」というタイトルは、小川洋子さんの小説「博士の愛した数式」が元になっている。「Laravelへの異常な愛情」は「博士の異常な愛情」が元ネタだ。

私は、映画や小説をオマージュしたトークタイトルを使うことが多い。これは、トークの引きを強めることを目的としているわけではない。最終的にはその効果も期待しているが、本来の目的は別のところにある。

本来の目的、それは、自分自身にトークのテーマを腹落ちさせることだ。

題材は「Laravelの拡張」だ。真っ当にやると複雑になりそうな実装も、少しの発想の転換 ―Laravelの拡張で問題を単純化できることがある。だがこれは、「魔改造」と紙一重でもある。無秩序に改造されたフレームワークは非常に厄介だ。控え目な少しの変更で問題を大胆に解決するような、繊細で美しい解法が望ましい。

「美しい解法」という言葉が頭に浮かんだ、数学を題材とした作品からインスピレーションを得るのが良いと考えた。そこで「博士の愛した数式」を選んだ。次のようなストーリーの物語だ:

不慮の交通事故で、天才数学者の博士は記憶がたった80分しかもたない。何を喋っていいか混乱した時、言葉の代わりに数字を持ち出す。それが、他人と話すために博士が編み出した方法だった。博士のもとで働くことになった家政婦の杏子と、10歳の息子。博士が教えてくれる数式の美しさ、キラキラと輝く世界。母子は、純粋に数学を愛する博士に魅せられ、次第に、数式の中に秘められた、美しい言葉の意味を知る―。

博士の愛した数式 | Prime Video

作中で博士が語る言葉より、「調和」という今回のテーマを発見できた。資料と口頭の両方で、何度もこの言葉を繰り返している。

資料作成中は常に映画をループ再生していた。行き詰まった時に聞こえてきた台詞がヒントになって先に進めたこともある。この方法は「Laravelへの異常な愛情」の時も役立った、詳しくは過去に書いた通りだ。

気に入ってるやり方だが欠点がある。あくまで自分自身の腹落ちを目的としているため、世に広く知られたメジャーな作品を選べるとは限らない。2作品とも知名度は決して低くないが、会場にいた方やこの記事を読んでいる方で知っている人は多くないかもしれない。だが気にしない。インスピレーションを得てトークや資料の完成度を高めることが目的だ。

過去のトークとの技術的な関係

トークとしては「Laravelへの異常な愛情」の続編と位置づけたが、技術的には昨年の「Laravel OpenAPIによる “辛くない” スキーマ駆動開発」を含む3つで連続している。

「Laravelへの異常な愛情」では、最初から最後までLaravelの話だけを扱った。

「Laravel OpenAPIによる〜」では、OpenAPIやその他スキーマ管理ツールとの統合を扱い、トークのリファレンス実装としてLaravel OpenAPI Validatorを作成し公開した。

「私の愛したLaravel」では、個別のテクニックやツールではなく、より広く一般化した形で、Laravelと「何か」とを統合する話題を扱った。

年	題材
2023	Laravel
2024	Laravel + 個別の課題解決
2025	Laravel + 一般的な「何か」

3つの話は地続きだ。「拡張」という難度の高い話題を耳にするとつい試したくなるのはエンジニアの性だが、それは個別の課題解決の延長線上であり、目的はあくまでアプリケーションをシンプルに保つことだ。これを忘れてはいけない。

トーク考案中の方針転換

資料作成中、困ったことに気づいた。結論、書いたコードの半分以上を捨て、資料の大部分を再構成した。

拡張を取り扱うには、ドキュメントに書かれていないフレームワークの内部構造を説明する必要がある。拡張それ自体のコード例も必要になる。一通り書き終え見積もった所、ここまででちょうど40分。

これは非常にまずい。拡張を安易に試された結果、その方の業務コードが「魔改造」になってしまうのは絶対に避けたい。「拡張」ではなく「拡張の結果コードはどうなるのか」を示さなければいけない。多くのコードを捨て、空いた時間を「Laravelへの異常な愛情」の再説明に充てるよう変更した。シンプルにLaravelだけを取り扱った「簡潔なコード」を紹介するトークだ。

苦渋の決断だったが、結果的に悪くなかったと感じている。

まずは「簡潔なコード」を示す。いかにもそれを崩しそうな要件を示す。どこを拡張すれば「簡潔なコード」を維持できるのか示す。

頂いた感想の中で最も多かったのが、「簡潔なコード」を維持できなくなった状態を指し「まさに同じ失敗をしたことがある」というものだった。これは「Laravelへの異常な愛情」を観た方から最も多く質問頂く点でもある。

コードを削った分だけ実例の具体度は落ちてしまったが、拡張を学ぶ目的はより強く共有できたと感じる。

あまりにも広い題材、そして準備不足

プロポーザルを通過した時点から嫌な予感がしていたが、この題材でトークをするのであれば、100分は必要だったかもしれない。準備時間も3ヶ月では足りなかった。

話しきれない内容は多くあった。DBドライバの拡張はそれだけで40分欲しい。コーディング中につい脱線し Application や Kernel などの差し替えを試みて失敗した話は「魔改造」の反面教師として悪くなかった。Eloquentの拡張は、今回の説明とはまた異なるパラダイムを持っている。削りに削ったが、それでも時間を少しオーバーした。

心残りは、紹介の中で一番気に入っていた最後の拡張例を駆け足でしか説明できなかった点だ。この例は実は何も拡張していない、にも関わらずユーザーランドに「簡潔なコード」を提供できている。何もしないという選択肢も含め「調和」を模索する好例と考えたのだが、おそらく伝えられなかった。そこで早速次の機会に申し込んだ。

直近のPHP勉強会でその箇所だけ切り出した説明をすることにした。Laravelに限らない一般的な話題として話すので、主催や参加者の皆様、どうかお許しとお付き合いをお願いします。きっと面白い話です。

次のステップ

拡張はあくまで手段、目的はアプリケーションをシンプルに保つこと。

それとは別で、1つ大きな利点がある。趣味のコーディングなどある程度失敗できる状況を前提に、どんな題材でも良いので是非ともチャレンジして欲しい。フレームワークの理解度が一気に上るはずだ。

いつどんな場合でも、博士が私たちに求めるのは正解だけではなかった。何も答えられずに黙りこくってしまうより、苦し紛れに突拍子もない間違いを犯した時の方が、むしろ喜んだ。

小川洋子 (2003), 新潮社
博士の愛した数式

ちょっとしたパッケージへのプルリクエストならすぐに送れるようになるはずだ。そこまで至らなくとも、問題に遭遇した時に自分たちのコードが原因なのか、フレームワークのバグなのか仕様なのか、この程度の区別はすぐつけられるようになる。

今回のトークやこの記事が、Laravelの理解を深めるきっかけになってくれると嬉しい。

「私の愛したLaravel」―トークの裏側、シンプルへのこだわり

映画や小説作品をオマージュする理由

過去のトークとの技術的な関係

トーク考案中の方針転換

あまりにも広い題材、そして準備不足

次のステップ

関連URL

トークに言及頂いたブログ記事

資料中の参考リンク