数ある Symfony コンポーネントの中で、私が一番好きなのが ExpressionLanguage です。
私が関わる PHP のプロジェクトでは ExpressionLanguage を多く使っています。

とても便利で使い勝手の良い ExpressionLanguage ですが、情報が少なく、活用事例はほぼ皆無です。

みなさんにもっと ExpressionLanguage を活用してほしい！ということで、使い方や勘どころを活用事例を交えて紹介します。

本格的な DSL (Domain Specific Language: ドメイン特化言語) システムを作るのはかなり大変です。
でも、簡易の DSL システムであれば、ExpressionLanguage と YAML で簡単に構築できます。

DSL システムを構築することで今まで見えなかったものが見えてきます。

本トークでは、障害対応が特定のメンバーに集中していた状態を見直し、チームで対応できる体制を構築するために取り組んだ内容を紹介します。

私たちは、レガシーな PHP アプリケーションを日々運用しています。
その中で、障害対応が属人化し、特定の人に負担が偏ることが課題となっていました。

この課題に対して以下のような取り組みを行いました。

• 障害対応の予行練習
• 障害振り返り会の実施
• PagerDuty を用いたローテーション制の導入

これらの取り組みにより、障害対応の対応手順やナレッジがチーム内に共有され、属人化から脱却しつつあります。
似たような課題を抱える方にとって、何かしらのヒントになれば嬉しく思います。

PHPのsocket拡張を利用するとsocketプログラミングができ、通信プロトコルもPHPで実装できます。
さらに、RAW socketという機能を使うとOSが管理しているTCP/IPプロトコルもPHPで実装可能です。

今回のセッションでは、

• PHPのsocketプログラミングの基本
• HTTPの実装
• TCP/IPの実装
  の話を通して、はまりポイントやプロトコル実装の楽しさを共有したいと思います。

プロトコルは仕様が決まっていて、その仕様を見てひたすら実装し、最終的にはサーバやクライアントと通信できるようになります。この通信できた時の喜びは非常に大きく、かつ大変勉強になります。通信できるまでの過程も含めて楽しさが伝えられたらと思います。

「テックリード」という響き、とてもかっこいいですよね！
そんなかっこいいテックリードが何をするのか知っていますか？

私は合議制による意思決定の遅さというチーム課題の解決と自身の成長を期してテックリードになりました。
しかし、待っていたのは「テックリードとして何をすべきか」が不明瞭な状況と、役割を見出すための深い葛藤でした。
本セッションでは、そんな暗中模索の時期から、どのように自身の役割を定義し、周囲の信頼を得て「自他共に認めるテックリード」になるに至ったか、そのプロセスと乗り越えた壁について、実体験に基づき、そのリアルな姿と乗り越えるヒントお伝えします。

テックリードを目指している方、テックリードという役割に悩んでいる方へ
皆さんの「テックリード」の解像度が少しでも上がれば幸いです。

PHPは時刻を文字列から取得する仕組みとして、日付/時刻パーサーを提供しています。
このパーサーが受け付ける表現の幅広さは凄まじく、その特性を利用することによって、開発者の意図をより正確にコードへ反映することが出来ます。

本トークでは、PHPの日付/時刻パーサーが受け付ける表現にはどういったものがあるのかを紹介します。
またそれを詳しく知ることによって、コードの表現はどう変わるのか、どう分かりやすくなるのかをお話させていただきます。

お話すること
・PHPの日付/時刻パーサーが受け付ける表現の種類
・高い表現力を利用した場合における、日時操作のコード(DateTimeImmutableクラス, date_parse(), etc...)
・実務でパーサーの高い表現力を利用したコードを書く際に注意すべきこと

注意事項
・日付/時刻パーサーの内部的な実装については基本的に触れません

普段当たり前のように使っている “Git”、その仕組みを理解していますか？
本セッションでは、Git の内部構造を理解するために「PHP で Git の再現」に挑戦した取り組みを紹介します。
実際に再現してわかった、Gitのデータ構造や差分管理の仕組み、そして再現を通じて学べた本質的な気付きについてお話しします。

トーク内容（予定）

• なぜ Git を再現するのか
• なぜ PHP で再現するのか
• どうやって Git を再現したのか
• Git を再現するために必要なもの
• Git の中身はどうなっているのか
• 差分はどのように管理されているのか
• データはどのように保存されているのか

普段なんとなくGitを使っている方も、このセッションを通じて仕組みへの理解を深めてみませんか？

私のチームが運用するPHPサービスは、全てがEC2で動作し、オートスケーリングにも対応していないレガシーな構成です。
さらに、Laravel・Zend Framework・Yiiという3種類のフレームワークが共存し、構成は複雑を極めています。
TerraformによるIaC導入を進めた私は、社内勉強会中に操作を誤り、本番環境を壊してしまい、サービスが一時停止する事態に。
このトークでは、構成管理が属人化したPHP環境にIaCを導入する中での失敗と学び、環境差異や大量のバッチ処理など泥臭い現場で起きた苦労、そして再発防止に向けた取り組みを共有します。
理想と現実のギャップに悩むPHPerの、生々しい挑戦の記録です。

Laravel 11/12に移行して「Handlerクラスがなくなった！どう構成すべき？」と悩んだ方も多いはず。
例外処理の責任の境界が曖昧になっていませんか？
本セッションでは、例外設計・分類・キャッチの責任を明確にし、保守しやすく壊れにくいLaravelアプリケーションの作り方を紹介します。

扱う具体例:
例外をどこでthrowし、どこでキャッチするかを整理する方法
Laravel 11でExceptionHandler相当をサービスごとに定義し、モジュール単位で対応
例外が増えてきたときの管理方法
CIで異常系テストを実行し、例外が正しく処理されているかを確認する仕組み

このセッションで得られること:
各層でのエラー処理の役割を整理し、例外を分類する方法
Laravel 11/12のエラーハンドリング設計のポイント
「例外が増えても怖くない」CI/CDとテストで品質を保つ方法

「例外＝\Exception、返すのはいつも500…」そんな状態に悩んだことはありませんか？
Laravel 11/12では、ExceptionServiceProviderによってエラーハンドリングの構成が見直され、独自例外による明確な設計がより重要になっています。
本セッションでは、独自例外をドメインルールを表す手段として活用し、保守性と読みやすさを高める設計のコツを紹介します。

扱う具体例
PermissionDeniedExceptionのようなドメインルールを表す例外の設計方法
Laravel 11以降のExceptionServiceProviderの活用法

セッションで得られること
業務ドメインを意識した例外設計による責務の明確化
「なんでも 500」から脱却し、想定外と想定内を分けた異常系設計
Laravel 11/12 での例外処理構成の考え方と実装の勘所

デシジョンテーブル（決定表）といえばテスト設計の手法として知られていますが、PHPでの実装パターンとしても非常に強力です！
複雑な条件分岐をif文の入れ子で書くと保守性が低下しますが、決定表を使えば条件と結果の組み合わせを表形式で美しく整理できます。

登壇者は実際の業務で、条件の組み合わせが数千パターンにも及ぶ大規模な決定表を実装してきました。
この経験から得たノウハウと実践的なテクニックをご紹介します。

• 複雑な条件をわかりやすく可読性を上げる
• 決定表の定義誤りを防ぐ
• 時系列で変化する決定表の表現方法
• 決定表の評価のバグを検知する
• 決定表をアプリケーションだけでなく、テストでも活用する

明日のプロジェクトですぐに活用できる実装パターンをお伝えします。
難解なビジネスロジックをクリアに表現できるPHPのデシジョンテーブル実装に、ぜひチャレンジしてみましょう！

もぅﾏﾁﾞ無理…PHP の array 関数、多すぎぃ〜😵‍💫
array_map とか array_filter とか、似た名前ばっかでﾏﾁﾞで呪文かと思ったし🌀
「どれ使えば正解なん？」「ﾃｶ違いなに？」「ぇ、もう全部 foreach でよくね？（白目）」ってなって、
ｶﾞﾁで心折れた🥀

でもね、業務でﾌﾞﾁ当たりすぎて、
泣きながら調べて、試して、失敗して、やっとちょっとずつわかってきたの🫶

このトークでわ、その時の「array 関数メンタル崩壊事件簿」をゆるっと共有しながら、
それぞれの関数の違いや、こう使えばよくね？って話をしてくよん🌈💡

array 関数で病みかけたギャル（ぅちらギャルだよね？）、全員集合〜💖💖

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

この発表では、オニオンアーキテクチャによって仕様追加による改修が最小限に抑えられた事例について解説します。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

PHP8.4のリリースをきっかけに、日本語ドキュメントの翻訳に参加してみようと思ったのが始まりでした。

ですが、最初の壁となったのは翻訳用の環境構築でした。
自分も悩んでしまった環境構築。その敷居を少しでも下げたいという思いから、誰でも簡単に始められる翻訳支援ツールを作りました。

短いコマンドで動き、初めての方でも迷わず使えるよう工夫したことで、実際に参加者も増え、小さな翻訳の輪が広がりました。
なかには初めてOSSへの貢献をされた方もおられたようです。
この取り組みの背景やツールに込めた思い、そして“壁を取り除く”ことで生まれた変化についてお話しします。

「カンファレンススタッフは敷居が高そう...」「どんなことをするのか分からない...」「私でもできるのだろうか...」
そのような不安を感じていませんか？

私は2025年「カンファレンススタッフをやってみよう！」と行動し始め、これまで5回ほど当日スタッフとしてカンファレンスに携わりました。
このLTでは主に当日スタッフとしてやったこと、実際に当日スタッフをやってみた感想についてお伝えします。

話すこと
・カンファレンススタッフとは
・「スタッフをやってみよう！」と思ったきっかけ
・当日スタッフとしてやったこと
・スタッフとしてカンファレンスに携わった感想

このLTを通して「カンファレンススタッフをやってみよう！」と思ってくれる方を増やし、ひいては関西コミュニティの持続可能な運営体制の構築に寄与することを目指します。

PHPだけでフロントエンド（JavaScript）まで結合したe2eテストを書けるsymfony/pantherのハンズオンです。
symfony/pantherは通常はcypressやplaywrightなどJavaScript/TypeScriptのスタックを使って書かねばならないe2eテストをPHPのみで書くことができるライブラリです。
PHPのAPIとReactのフロントエンドというよくある構成のSPAに対してsymfony/pantherを使ってe2eテストをステップ・バイ・ステップで実装しながら、symfony/pantherに親しんでみましょう。
テストデータの用意などPHPで書けることの柔軟性と利点を体感してもらうとともに、e2eでテストすべき観点や注意点についても解説します。

「とりあえず動くPHP」から一歩進みたい初学者へ向けて、PHP 8の文法と型の表現力を通じて、読みやすく・壊れにくいコードの設計を学ぶセッションです。

match 式や readonly プロパティ、union types、named arguments などの機能が、静的解析ツール（PHPStan, Psalm）と組み合わせてどのように活きるのかを具体的なコード例で解説します。

「型を書くだけで、こんなにミスに気づけるのか」「PHPでも設計って考えられるんだ」と実感できる内容を目指します。

文法の表面的な知識だけでなく、現場でコードを書く上で意識したい“意図を型で伝える”視点を手に入れましょう。

皆さん、こんにちは！私は普段テスター/QAとして活動しており、PHPのプロフェッショナルではありません。
そんなテスターの私は、PHPをコア技術とする企業に参画したことを機に、PHP開発者の方々やPHPコミュニティの皆様と交流する機会を得て、大きな刺激を受けています。

今回のLTでは、テスターである私がPHPコミュニティに参加し、そこで感じた熱い想いを共有させてください。
具体的には、以下の3点についてお話したいと考えています。

• 開発のための"テスト"と品質保証のためのテストという二面性
• テスターとプログラマーが協力し合うことで生まれる、新たな価値創造
• PHPコミュニティの温かさと、そこから得られる学び

このLTを通して、テスターとプログラマーが互いに協力し、刺激し合いながら、より良いソフトウェア開発を追求できる未来を皆さんと一緒に描きたいと思います。

PHPを使用して「サーバーサイド・ブロックチェーン」という新たな概念にチャレンジします。

従来、ブロックチェーンはクライアントサイドで署名したデータを、スマートコントラクトがデプロイされたP2Pネットワークに通知する構成が主流であり、サーバーサイドでの活用事例は多くありませんでした。

この構成は、1対1の当事者間においては高いセキュリティを実現できる一方で、複数関係者の同時関与や段階的な意思決定が求められる実業務の場面においては、柔軟なワークフローの設計や、合意形成の自動化に課題が残っていました。

本トークではSymbolブロックチェーンを活用し、サーバーサイドに部分署名を組み込むことで、既存のWebシステム上に、安全かつ自然に統合する手法を紹介します。

これにより、業務システムに求められる実用性と、ブロックチェーンの信頼性を両立する、新たな実装モデルの可能性を提示します。

概要

PHPの実行環境は、アプリケーションのパフォーマンスやスケーラビリティに大きく影響します。
本セッションでは、Laravelで作成したCRUDアプリを用いて、次の環境のパフォーマンスを比較します。

対象の比較環境

• mod_php + Apache
• Nginx + php-fpm
• Swoole
• FrankenPHP

各実行環境の特徴と、ユースケースごとの適性を実測データに基づいて比較・考察して、結果を共有し、
実行環境を選定するさいの実践的な知見を持ち帰っていただくこと目標にしています。

対象者

• PHP開発者
• パフォーマンス最適化に関心のあるアプリケーションエンジニア

話さないこと

• パフォーマンスチューニングにおける個別パラメーターの詳細説明
• 実行環境の構築手順・設定方法

僕はよく思うんです。

自分が書いたコードで満足することってないなあって。
過去の自分に忸怩たる思いを抱きつつ、今日出せる最高のコードを書き続ける。

しかしだな、テストコードだけはサラッと書きたい。
何ならAIにだって書かせられる。

メンテしやすいテストコードについて。今出せるすべてをここに置きたい。

• テストコードの設計方法
• テストデータの取り扱いについて