今年も PHPerKaigi に参加させていただきました。
毎年費用を負担してくれる会社に感謝しつつ、「今すぐ」「次期プロジェクトに」何かしら＋になるものを持ち帰れるよう臨みました。

PhperKaigi2025 の Vlog も PHPerKaigi2024 Vlog のようにアップしてもらえるかもしれないので、そちらも後で更新します！

追記: PHPerKaigi2025 Vlog もアップされましたー！

PHPによる"非"構造化プログラミング入門 -本当に熱いスパゲティコードを求めて-

非構造化プログラミングを通し、構造化・非構造化の違いをとても鮮明に体感することができました。
中でも「人間が考えなくてはならない領域が変化していく」という言葉が特に胸に刺さりました。

AIと構造化の新たな意味

昨今AIの成長が凄まじく、今まで「人が考えるべき」とされていた設計や制御の領域も、徐々にAIやツールに委ねられる時代になっています。

そうした中で、プログラミングにおける「構造化」という考え方が、単にコードを読みやすくするためだけではなく、
人間が理解しやすいように知識や処理を整理し直す行為であることに改めて気づかされました。

人間の認知限界と構造化の知恵

構造化は、人間の脳という有限なリソースを最大限に活かすための知恵であり、だからこそ重要なのだと感じます。
逆に言えば、非構造化はそれをあえて破壊することで、どこまで「人間が耐えられるか」を体感させるメタ的な実験でもあったのかもしれません😂

スパゲティコードの洗礼

「goto」を多用したスパゲティコードの実演はユニークかつ強烈で、「構造化されている」ありがたみを痛感しました。
学生の頃にCを触っていた時を最後にgotoは使っていませんでしたが、composerでも利用されているという事実も衝撃的でした。

感想

非構造化プログラミングを実体験することで、構造化の真の価値が明確になりました。
技術の進化と共に、私たちプログラマーが担う役割も変わり続けていくのでしょう。
しかし、「人間にとって理解しやすい」という原則は、どんな時代でも大切なのだと再認識させられました。

実演！CSVダウンロードパフォーマンス改善

Laravel でよくある CSV 出力処理ですが、大量データを扱う際にはパフォーマンス面やメモリ使用量など、さまざまな課題が生じます。
今回のセッションでは特に「N+1問題」と「メモリ使用量の削減」について、具体的な対策方法が紹介されました。
日頃取り組んでいる対策が方針として正しいと思える、良い機会になりました。

セッションの主なポイント

Eloquent とクエリビルダの使い分け
大量データや複雑なクエリを扱う際は、場合によって Eloquent よりもクエリビルダを使った方が良い場合があります。
N+1問題の対策
多くの関連テーブルを繰り返し取得するようなコードは、パフォーマンスを著しく低下させます。N+1問題を検出・解消する仕組みや、コードの最適化が重要です。
メモリ使用量の最適化
不要なデータを読み込まない・不要になったデータを随時開放するなど、メモリを意識した処理が求められます。
ジェネレータの活用
生成処理を分割しながら実行できるため、メモリ消費を抑えつつスケーラブルにデータを扱えるメリットがあります。

感想

日頃から N+1問題の影響は痛感していたため、ローカル環境で AppServiceProvider::boot に N+1検出の仕組みを仕込む方法は、改めて効果的だと感じました。
また、メモリ使用量の計測は予想以上に見落としがちな要素です。推測ではなく実測によって継続的に確認し、不要なメモリ消費を防ぎたいと思いました。

PHPStan七転八倒

PHPStanはうさみさん過去のセッションとカンファレンスでいただいたアドバイスの下導入しました。
今では手元やCIで回していますが、まだまだ使いきれていないという印象です。

感想

OSSであるため、皆様積極的にPRを出していこうというお話でしたが、私はまだまだそのレベルになく...！
もっと使いこなせるようになりたいですね。

小話にあった \PHPStan\dumpType() は配列型（Array Shape など）をドキュメントコメントに注釈するときのヒントにできますので使っていきましょう！

私の愛したLaravel 〜レールを越えたその先へ〜

Laravelが破綻するパターンがとてもわかりやすく解説されていました。

感想

他の設計パターンを中途半端に混ぜると、Eloquentと両立できず複雑化する
対応範囲外の外部サービスや独自要件を無理に組み込むと、フレームワークの強みが活かせなくなる。
未記載=非対応

これらがブッ刺さりましたね...。

また、拡張に関しても非常にわかりやすく解説されていました！

拡張についてはこれからも業務内で多々遭遇するかと思いますので、
フレームワーク(Laravel)の設計をよく理解し、
破綻させないように細心の注意を払って設計したいと思いました。

大規模ふるさと納税サイトをPHP8化した時の苦労話

「ふるさとチョイス」のPHP8化の貴重なお話でした。

感想

事前作業を徹底して行うことが改めて大事だなと考えさせられました。

- ライブラリの徹底調査
    - 依存関係が原因でプロジェクトが止まらないように
    - Packagistを参照しPHP8に対応していないライブラリがないか
- APC->APCuへの移行
- PHPStanの導入
- PHP_CS_Fixer
    - mergeの衝突を減らす

IDE, エディタ, ルールの違いで衝突したり差分が出たりはよく見かけます。
チーム内でPHPStan, PHP-CS-Fixer は徹底していきたいですね。

-> ドキュメント化チームを横断したコミュニケーションは本当に大事

こちらも非常に大切だと感じています、.md 1枚でも良いのでテンプレート化したものを埋めていきたいですね。

リリースに関してはカナリアリリース -> 一括切り替えへシフトした理由が「なるほどなあ」と思いました。
QAもとても参考になり、とても有意義なセッションでした。

「うわっ…うちのテスト、遅すぎ…？」 PHPUnit高速化テクニック

テストコード、まだ書かれていないプロジェクトがあったり、ガチガチなプロジェクトがあったりしますが、
PHPUnitの高速化のお話でした。

感想

環境によって走らせるものを変えていたこと
差分変更とその影響範囲のテストのみに絞ること

これらが非常に参考になりました！
特に後者は全く頭になく「影響範囲がわからないから全件通せ」かと勘違いしておりました。

CI側で差分とその影響範囲のみに絞ってテストできていけたら良いですね、
github actions 側の調整を頑張りたいと思います(まずは手元から！)

PHPから考えるクレジットカードにおける3Dセキュア決済

3Dセキュア2.0とは何なのか詳しく解説していただいたセッションでした。

感想

実際の決済時の流れ、どのタイミングで認証が入るのか(入らないのか)、
サブスクリプションの場合はどうなのか、非常にわかりやすかったです。

Stripeの使いやすさも際立っていたかと思います。
Stripeでは決済の流れをあまり意識しないで実装できる、他のサービスでは、決済の流れを理解した上でドキュメントを読む。
肝に銘じておきます。

ソフトウェア開発におけるインターフェイスという考え方

インターフェイス設計は「契約」そのもの

契約は安易に変更できない
- 一度公開したメソッドやAPIのシグネチャを変えづらいのと同じで、インターフェイスは利用者にとって“約束事”
- 名前や返却値まで含めて、もし変更するとしたら、破壊的変更を伴わないよう工夫が必要になる
契約は不明瞭であってはならない
- “どの引数に何を入れればよいのか” “どう動作するのか” などが曖昧なままだと、利用者が誤った使い方をしてしまう可能性が高くなる
- 仕様を明確にしつつ、ドキュメントやテスト、エラーメッセージなどで利用者をフォローすることが大切
実装の詳細は隠しておく
- 内部実装を安易に晒すと、利用者が想定外の箇所に依存してしまい、契約を保てなくなるリスクがある
- “ここは呼び出せる、ここは呼び出せない” をはっきりさせるのがインターフェイス設計の基本

感想

開発者バイアスを取り除く一つの方法として自分自身が利用者として触れてみる（ドッグフーディング）ことを大切にしていきたいと思いました。
また最近では、AIを使った検証も挙げられています、AIに実際にAPIを叩かせたりコードを組んでもらうことで、人間の“思い込み”とは異なるパターンを見出すことができるかもしれません。インターフェイスがしっかりしていれば、AIにとっても使いやすい設計になっているはずです。

インターフェイスを意識しておくと、開発プロセス全体が引き締まり、「使いやすい」かつ「わかりやすい」コードに近づいていくと感じます。
テストもエラーメッセージもスキーマも、すべては契約をより明確に、より強固にするためのインターフェイス。
私自身、今後のプロジェクトでも積極的に「インターフェイスという考え方」を取り入れ、自分やチームの“使いやすさ”を追求していきたいと思います。

非エンジニアにも伝えるメールセキュリティ

DKIM、DMARC、SPF
Google様のおかげで各社対応に追われましたね。

感想

おさらいができ、かつ非エンジニアに説明もできるようになる素晴らしいセッションでした。
なんとなくわかっていた部分が明瞭となり非常に良かったです。
ありがとうございました。

ルーキーズLT

会場の盛り上げも会場のノリもとても楽しいものでした

「PHPシンタックスコレクション〜ペチコレ〜」厨二病が好きそうな小難しいシンタックス編

null結合演算子も良いですがなんと言ってもエルビス演算子ですね！
とても面白いLTでした、完走して全て聴きたかったですね。

リファクタリングでもPHPStan！？ Rectorと組み合わせてかっこいいリファクタリングしようぜ！

PHPStanを使いこなされていましたね、、、より良い使い方を模索していきたいと思います。
(手始めに配列型の自動化)

英語文法から学ぶ、クリーンな設計の秘訣

とてもわかりやすかったです！
save()は衝突しちゃいそうで実際には使わないかもしれませんが、
意味合い的には一発でSVOで分かるのはありがたいですね。

バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法

Cursorの力を感じました、フロントエンドは今後AIの力を借りながら正誤の判断が正しくできるようにスキルアップしていきたいですね。

社内コードゴルフ大会を開催したら最高に楽しかった！！

弊社でも取り入れたいなと思いました！
が、うちのメンバーには反対されました笑
ノウハウが頭に入ってないのでそこからかなあと思いますが、
いつかゴルフしたいですね！笑

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

マイクロサービスの代替として注目を集めるモジュラーモノリスのお話でした。
モジュール単位でのチーム開発は(苦労は抜きにして)楽しそうだなと感じました。

感想

トランザクション管理に Unit of Work を導入
- モジュラーモノリスの開発で意外と重要なのが、操作をひとまとまりとして扱う UnitOfWork の考え
- 各モジュールが自分の責任範囲でデータを操作し、最後にまとめてトランザクションコミット（GO）する仕組みにすることで、整合性を保ちつつモジュール単位の変更もスムーズに行える

考え方として非常に大切ですね肝に銘じておきます。
今着手している案件の中でも切り分けたいのがいくつかありますね。。。
なんとか余力を作って試していきたいものです。

OpenTelemetryを活用したObservability入門

Observability（可観測性）, OpenTelemetry の話でした

感想

社に戻ってすぐに導入したいと思えました！
まずは手元にあるLaravelでコンテナを立ててやっていく作戦でいきます！

php-fpm がリクエスト処理する仕組みを追う

php-fpm は普段から使っていますが、詳しく中の処理がどのように動いているのかまで追ったことはなかったため、非常に勉強になるセッションでした。

感想

実際に中の仕組みがどうなっているのか、知っているのと知らないのとでは取れる選択や思考が変わってくると思います。php-fpmに限らず、あらゆるものに対して探究の視点を捨てずに学んでいこうと思いました。

全体の感想

お祭り感があって参加していてとても面白かったです！

フィードバック時間が設けられていたこと
スタンプ押しながら全ブース回るように動線設計されていたこと

非常に良いなあと感じました！
黄色のTシャツをいただいたのは非常に嬉しかったですね！笑
また次回も参加したいです！