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

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

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

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にだって書かせられる。

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

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

• 自動テストの改修コストが高くリリース速度が落ちてる
• xUnitでどこまで書けばよいのか判らない
• E2Eで回してるけど本当に確認したいのは単純なI/Oだけなんだけど

これらのお悩みを纏めて解決する、よくばりテスト技法として「階層化自動テスト」戦略についてお話します。

本トークは「品質とは何か？」を前提に進みます。
より理解を深めたい方は、PHPカンファレンス関西2024での登壇「『"品質"が高いコード』って何？」をご覧ください。
https://fortee.jp/phpcon-kansai2024/proposal/a60c9e18-bc61-4f60-80d0-0a0ea7a205c4

このトークで得られる知見

• 品質管理の一環としての統合的なテスト戦略
• 「テストをどこに書けばよいのか」問題への指針

このトークで扱わない内容

• ツールの使い方や実装ノウハウ

本トークはPHPのメタプログラミング技術を活用し、本来の言語設計が提供する制約を超えた操作がどのように可能となるか、またその結果生じるリスクと課題についてをお話します。

PHPにはリフレクションAPIを使用したアクセスやeval()による動的なコード実行など強力な機能が提供されています。
これらの技術はいわゆるメタプログラミング技術に内包されるもので、特定状況下では非常に有用ですが、同時に深刻なリスクが伴うものです。
ちょっとしたいたずら心がどのような災厄を招くのか。
本トークではメタプログラミングの威力をあらためて確認し、その適正な使用範囲とベストプラクティスについてお話いたします。

陰キャの陰キャによる陰キャのためのPHPカンファレンスの楽しみ方を紹介します。

話すこと
・陰キャエンジニアのための、PHPカンファレンスを楽しむための心構え
・カンファレンス会場での効果的なぼっち行動
・疲れないための休憩戦略
・懇親会でぼっち飯にならない方法