PHPカンファレンスには、今PHPを使っているひとも、今は使っていないけど、PHPが好きだから参加しているひともいると思います。

「PHPにずっと関わり続けている」「PHPを使っていたが、今は別の言語で開発をしている」「最近PHPで開発しはじめた」という方々へ、以下の内容をエンジニアのキャリアプラットフォームを運営している転職ドラフトならではの視点でお伝えしていきます。

・そもそもPHPは、キャリアにおいてモダン？スタンダード？レガシー？どのフェーズの言語なのか？
・転職ドラフトのデータから見えるPHPerのキャリアパスの傾向は？
・PHPを軸として、今後のキャリアを選択するうえでの考え方とは？

kubellでは日々100万人以上のユーザーが「Chatwork」にログインし、アプリケーションを利用しています。
このセッションでは、「Chatwork」の認証基盤をAuth0へ移行し、運用を行っている実際のプロセスを詳しく紹介します。
Auth0への移行方法とPHPでの実装における工夫について具体的に解説します。
また、ログデータを活用した異常検知やビジネス分析の手法についても触れ、データを活用したアプローチについても紹介します。

「なぜこの設計になったのか？」「複雑な判断の根拠を説明できない...」「チームの知恵が個人に閉じ込められている...」
チームでこんな課題を感じていませんか？複雑化するシステム開発において、特定の個人に依存した知識管理ではなく、チーム全体の「知」を育み、新たな知識を創造することが成功の鍵です。

個人に知識が集中すると、その人の離職で暗黙知が失われ、プロジェクトが停滞するリスクがあります。また、複雑で不確実性の高い開発では、個人判断では視野が限られ、想定外の事態へのリカバリーも困難です。個人の暗黙知をチーム全体の知恵に昇華させる仕組みが求められています。

本セッションでは以下をお伝えします：

1. SECIモデルとは？知識創造の4つのプロセス
2. モブワークがSECIモデルを加速させる仕組み
3. 各プロセスを促進するモブワークプラクティス
4. 知識創造するチームへの変革事例

SECIモデルの「共同化」「表出化」「連結化」「内面化」という知識創造の4プロセスを、モブワークは自然な形で促進します。暗黙知の共有から始まるこのサイクルは、モブワークで驚くほど加速します。

これにより「部族記憶」や共通文脈が生まれ、背景情報の共有だけでなく、チームの知的相互作用から新しいアイデアや知見が生まれる土壌が形成されます。個人では到達できない創造的飛躍が、多様な視点の交わりから実現できると登壇者は考えています。

PHP 8.4「プロパティフック」からオブジェクト指向設計を紐解きます。

プロパティフックとは、プロパティの読み書きに任意の処理を挟み込む機能です。従来の退屈なgetter/setterメソッドを使うことなく、より自然かつ柔軟な記述でプロパティの読み書きを実装できます。初めて使う際の学習コストも低く、手軽に導入できる点も魅力です。

一方、少し複雑な使い方や他の機能と組み合わせた使い方をしようとすると、型に関する制限や思わぬ仕様の違いに戸惑うことがあります。コンストラクタプロモーションとsetフックでの型の違い、readonlyとの併用不可、継承時の制限、これらは経験者でも混乱を招きがちです。

こうした仕様の背後には、オブジェクト指向設計の基本原則のひとつである「リスコフの置換原則（LSP）」が存在します。LSPは一見すると開発を窮屈にする制約のように感じるかもしれません。しかし、実はその制約が、アプリケーションの一貫性や信頼性を守るための重要な役割を果たしています。

本トークでは、プロパティフックの構文と振る舞いを整理しながら、なぜそのような制約が必要なのかを丁寧に紐解いていきます。また、LSPの考え方はオブジェクト指向の設計にとどまらず、より広い領域でも応用可能な「設計上のものの見方」であることにも触れていきます。

PHPの最新機能をきっかけに、日々の開発でも見落とされがちな設計原則の価値を改めて見直しましょう。

「ちょっとWAFのブロックを追加したい」「S3のバケットを作りたい」──そんなとき、SREにチケットを出して数日待ち、という体験をしたことはありませんか？私たちの現場でも、PHPアプリエンジニアがインフラに手を出しづらく、SREに依頼が集中していました。その結果、SREは日々の対応に追われ、改善や新しい挑戦に手を出す余裕がなくなっていきました。

このセッションでは、私たちアプリケーションエンジニアがインフラ構築の裁量を広げることでどう現場を変えたかを紹介します。Terraformを使ったIaCのテンプレート化、GitHub Actionsを活用した安全なCI/CDパイプラインの構築、パススルーやWAF設定といったよくある変更の“自分でできる化”など、PHPエンジニアが安心してインフラに関われるようにした具体的な工夫をお話しします。

もともと私自身がPHPerからSREに仕事を広げたことから何に困り、どう整えてきたか。開発体験を良くするためにSREとアプリケーションエンジニアが整えるべき“やってよい設計”のヒントを、実際の試行錯誤や失敗談も交えてお届けします。

本トークでは、弁護士ドットコム株式会社でより良いプロダクトの開発を目指して、 情報設計というキーワードを中心に約 5 年ほど取り組んできたことについてご紹介します。

具体的には、Application-Level Profile Semantics(ALPS) というアプリケーションの操作や語彙を記述するテキストフォーマットを活用した、情報を中心としたチーム開発の事例やAI開発ツールの活用事例についてお話します。
また、組織・プロダクトを跨いだメンバーで取り組んでいる、社内ワークショップ活動を通じた啓蒙活動についてもお話します。

いまやPHPの根幹を成すComposer

意外と「なんとなく」使ってる方もいらっしゃるのではないでしょうか？
そんな方々に、「Composerの仕組みもバッチリ知ってるよ！」となって帰って頂ける内容をお話します。

1. なぜComposerを使うのか？
   ・「車輪の再発明」は絶対やめよう
   ・ 成熟したPHPコミュニティ、あなたが作ろうとしている機能、大体あるんです
   ・ 複雑な依存関係を理解しよう

2. Composerはどのような仕組みで動いているのか？
   ・ packagistとComposerの関係について
   ・ composer.jsonとcomposer.lockの役割について
   ・ autoloadの仕組み、説明できますか？
   ・ ライブラリのバージョン、理解してますか？

3. Composerは遅いのか？
   ・ プロジェクトにおいて、Composerを使わず、手動requireした方が速いのか？否。
   ・ 大規模プロジェクトでのComposerの最適化テクニック

4. どんなプログラムをパッケージとして頒布するべきか？
   ・ もう、プロジェクト間のコピペはやめよう

ブラックボックス的な印象の強いComposer、これを機に、仲良しになりましょう！

プログラミング技術はこの長い歴史の中、Webではいろんな業種のナレッジが共有をされてきました。その中の一つに「共通化」を行い、「車輪の再開発をやめる」や「認知負荷を下げる」といったこと目的で取り組みするのをいたるところで聞きます。

ただし、「共通化」をすることで数年後に見るも無残な姿となり、逆にプロダクトの成長を抑制してしまったり、認知負荷を上げてしまうことがよくあります。

今回筆者が考える、プログラミングで考えるべき「共通化」の考えを中心に、過去経験したアンチパターンを元に話ができればと思います。

対象の聴講者は下記となります。

・プログラミング初心者
・悪い「共通化」がいたるところで見えるけど、どう伝えようか悩んでいる人
・失敗談を聞きたい人

本トークでは、チームの協働によって生み出されたイベントストーミング図を実際の動作するコードへと変換する手法を紹介します。

イベントストーミングとは、ドメインイベントを中心に据えたワークショップ形式のモデリング手法で、付箋やポストイットを使って、ビジネスプロセスの流れを視覚的に表現していくものです。
ドメイン駆動設計の原則に基づいたシステム開発を実現する上で、開発者とドメインエキスパートの協働を支える効果的な手法として注目されています。

これまで、イベントストーミングのワークショップを行うことで、ビジネスプロセスの理解を深め、チーム間の認識を統一するといったことは成功させてきました。
しかしながら、その成果物を具体的なソフトウェア実装へ昇華させる段階でつまづくことがあります。

そこで、このトークではイベントストーミングで可視化された知識の宝庫を、どのように実装へ導くのかということをテーマに、具体的なアプローチを解説します。
ビジネスドメインの本質を損なうことなく、いかにモデルをコードに落とし込むか、そのプロセスと実践的なテクニックを共有していきます。
また想定コードは先進的なアーキテクチャでなく、一般的な Web サービスを想定としたコードとします。

理論と実装の間に存在するギャップを埋め、モデル図をコードへ落とし込む方法論を学びたい開発者、設計者、プロジェクトリーダーにとって価値ある内容となっています。

◆お話しすること
・イベントストーミング図からPHPコードへの変換手法
・イベントストーミング図を構成する要素の簡単な説明
・ドメインモデルのコード表現
◆話さないこと
・イベントストーミングワークショップの具体的な進め方
・ファシリテーション手法

概要

時は2025年、AIエージェント元年と言われるこの世の中では「人よりもAIが仕事ができる」という噂が囁かれる事態となりました。
ですが、果たして本当にそうなのか。AIは人並みに仕事してくれるのか？我々のような老練のPHPerが立場を危うくするほど驚異的なものなのか？

本セッションでは、自律型AIエージェントプログラマー「Devin」について実際に使ってみた感触と、PJメンバーとしての有用性についてお話します。
今みなさんが気になってるホットなAIエージェントの話題をPHPer的な視点から掘り下げます。

トピックとしては以下です

• コードのクオリティーについて
• 仕様をどこまで理解してくれるのか
• Unit Testとかも書いてくれるの？
• リーダブルコードを考慮して書いてくれるのか
• PHPのVersionは考慮してくれるのか
• 結論、有用なのか否か

対象者

• PHPer
• AIに興味がある人
• AIに焦燥感を抱いてる人、大丈夫でしょうと高をくくってる人
• Devinについて情報収集してる人

得られるもの

• AIエージェントはどんな仕事をしてくれるのか
• AIエージェントへの指示（プロンプト）の効果的な与え方はどうすれば良いのか
• 自社で導入する時に評価できる・できないポイントがどこにあるか

私が担当しているメール共有サービスのメールディーラーではE2Eテストを導入することで、一定以上の品質を担保することに成功しました。

E2Eテストを導入したことの効果やテストコードの実装やテストケースの作成で工夫しているポイントなど、
メールディーラーのテクニカルリーダである私が可能な限り具体的に事例をもって説明いたします。

メールディーラーは2001年にローンチしましたが、フレームワークを導入しておらず、
DBアクセスとHTMLの生成をひとつのプログラムで行っています。

内部構造のアーキテクチャもさることながら、プログラム構造の陳腐化がリリースを行うごとに進みました。
いわゆる「スパゲッティコード」が散在し、それらがサービスの品質にまで影響するようになりました。

具体的には、ある共通関数が別の共通関数を呼び出し、
それが繰り返されることでプログラムが複雑にネスト化しています。

その結果、コード全体の把握が難しくなり、修正前に十分な影響調査ができない状況が生まれました。
このような状況下で、思ってもみない機能に不具合が混入し、
新機能のリリース直後に改修していないはずの機能で「画面が表示できなくなる」といった致命的な障害が発生しました。

そこで対策としてE2Eテストの導入と自動化を行いました。

通常の開発と並行して約3ヶ月という期間で273画面に対してテストコードを実装し、
導入後は「画面が表示できなくなる」といった致命的な不具合の発生を防止することができました。

限られた期間とリソースでどのようにして、当初の目標通りの成果を出すことができたか？をご説明いたします。
本セッションを通じてE2Eテストの導入や品質担保の参考になれば幸いです。

このセッションでは、LaravelとInertia.jsを組み合わせたモダンなフルスタック開発について紹介します。
Inertia.jsは、ReactやVueなどのモダンなフロントエンド技術のメリットを活かしながら、サーバーサイドアプリケーションのシンプルさを維持するためのツールです。これにより、複雑なAPIやクライアント側の状態管理なしで、モダンでインタラクティブなウェブアプリケーションを構築できます。
ReactやVue、TypeScriptと組み合わせて使用する方法や、Inertia 2.0で導入された新機能（Prefetch, Deferred Props, Infinite Scrollingなど）、UIコンポーネントライブラリのshadcn/uiの活用法、ライブバリデーションを実現するPrecognitionについても説明します。
また、Laravel Wayfinderを用いて、Laravel側のRouteをフロントエンドからTypeScriptの型としてシームレスに呼び出す方法についても紹介します。

Clean Architectureを使えば変更に強いソフトウェアが作れる、アプリケーションの寿命を時代の進歩に合わせて更新し、ビジネスに価値を届け続ける
そんな理想を夢見て、Clean Architecture を導入した、または導入したいと考える方は多いのではないでしょうか

ユースケース層まで丁寧に分離したつもりでも、実際には DB 依存が思わぬ場所に残り、「この設計は本当に変更に耐えられるのか」と不安になる瞬間があります
Clean Architecture は理想的だと言われますが、いざ大きな変更が発生したときに本当に価値を発揮するのか、設計原則の“手応え”を確かめたいと思ったことはありませんか

本セッションではその疑問を検証するために、Laravel のアプリケーションを設計ごと Symfony へ移行するプロセスを可視化します
対象とするのは 2 種類のユースケース：①ドメイン層が純粋に保たれているロジック、②Eloquent 依存が進んだロジック、それぞれの移行過程を比較し、前者では構成と DI の置換だけで動作し、後者では Repository 抽象の導入など、追加のリファクタが必要になることを示します
その過程を示し比較することで設計が継承できる / できない境界線を感覚ではなく、コードで理解します

Clean Architecture がなぜ必要か、そのためにどれだけの実装コストがかかるのか、そして構造を超えて設計を継承する方法を一緒に学びましょう

• お話すること
  • Clean Architectureが変更に強いか設計ごと移行して検証
  • ドメイン層の純度による移行の難しさとリファクタの観点を紹介
• 想定聴講者
  • Clean ArchitectureやDDDに関心がある方
  • 設計を再利用・継承したい方

Composerで「パッケージを入れる」とは何なのか？について考えてみてください。

• 多くのパッケージにおいて、その他の様々なパッケージへの依存を持っています。
• 単純なパッケージ名だけでなく、各々が要求し許容するバージョン指定の範囲も、実に様々です。
• そして、その「その他の様々なパッケージ」もまた、その他の様々なパッケージへの依存を持っています。

・・・一体どうやって、こんなに複雑な仕事を達成しているのでしょう？
このトークでは、2つの観点から「どんな工夫をしているか」を解剖していきます。

提供する主な話題

1. Composerが複雑な「パッケージの組み合わせ」を解くための手続きとは？
   1. 「Pool」の最適化とは？
   2. SAT Solver、 2-Watched Literal Schemaといった概念についてざっくりと
2. メモリ節約のためのPHP的な工夫
   1. 各所で活躍するSPLデータ構造や実装に見られる構造面での工夫、おもむろに現れるgc_disable() 等

このトークで得られる体験

• 普段使っているツールが内部で「どんなエレガントな問題解決をしているか」に触れる
• PHPアプリケーションのいて大量・複雑なデータを扱う上での生きた例を垣間見る

対象者・扱うこと

• Composerの基本的な使い方を理解している方の方が望ましいです
• Composer全体の仕組みやパッケージ取得方法についての詳しい解説は行いません
  • ピンポイントで「パッケージとバージョンをどうやって決定しているのか」の話になります
  • ツールとしてのComopserの便利さ・使い方を紹介するトークではありません
• 数学・計算機科学的な踏み込んだ解説は範疇外です

昨今のWebアプリ開発において、Webブラウザは切っても切れない存在です。
このWebブラウザには、HTMLとCSSからテキストや画像を描画する「レンダリングエンジン」が含まれています。

これがどのような仕組みで動いているのか、その裏側についてはご存知でしょうか?

このトークでは、超ミニマムな簡易レンダリングエンジンをPHPで実装することで、レンダリングエンジンの大まかな仕組みの理解を目指します。
また今回のトークで用いた、サンプルコードを他言語で再実装する勉強法も合わせてご紹介します。

このトークを聞き、レンダリングエンジンの裏側を垣間見ることで、Webアプリ開発におけるブラウザからの新たな視点を獲得できるでしょう。

対象の方

Webブラウザの仕組みに興味がある方
PHPでなにか書きたいけど作りたいものがない方

PHP コードの正当性は、テストや静的解析によって保証するのが一般的です。

しかし実際には「このメソッド呼び出しが正しいことは、どのテストで保証されていたっけ？」と確認を要する場面や、静的解析ではカバーしきれないコード構造も現実には多く、必ずしも安心とは限りません。

このセッションでは、コード自身が自分のやろうとしていることの正当性をその場で保証する "Self-Validating Code" というアプローチを紹介します。

テストや静的解析を補完し「この処理は確かに正しい」とコードの内側で完結して確認できる仕組みが、開発体験をどう変えるかに注目してみましょう。

Laravel アプリケーションに導入した具体例をもとに「正当性の保証がコードの外部に散らばっている」煩雑さをどう減らせるか、それが Fail Fast や防御的プログラミングとどう違うのかも整理してお話しします。

書いたその場で、正しさを信じられる。そんなコードを書くためのヒントをお届けするセッションです。

「オブジェクト設計スタイルガイド」は、オブジェクト指向のパワーを引き出し、クリーンなコードを書きたいPHPerにとって必読の書籍です。本セッションでは本書の内容を紹介しつつ、チーム全員の目線が揃うアプリケーション設計やクラス設計に役立つ考え方を紹介します。

本セッションで紹介すること
・Service、EntityとValue Object、DTOの使い分け
・クエリメソッド・コマンドメソッド・モディファイアメソッドの違い
・インターフェースの作成基準

本セッションを通して理解できること
・MVCフレームワークから疎結合なアプリケーションとは何か
・サービス層とドメイン層という言葉が意味すること

本セッションに参加された方が現場に持ち帰って実践できること
・クリーンなコードを書くこと
・レビュー時にコードの良し悪しを言語化できること
・AIが出力するコードを採用するか判断できること

PostgreSQLにはRow Level Securityがありますが、PHPを使った開発プロジェクトではほぼ使われていないのではないでしょうか。
Row Level Securityを使ってLaravelでアプリケーションを開発するにあたって、私はEloquent ORMとDoctrine ORM両方でコードを書いてみて、開発者体験を比較検討してDoctrineを選択しました。どういう判断でDoctrineを選んだか、2年半に渡って実際に開発に使ってみてどうなったかを共有します。

• Row Level Securityとはどんなものか
• EloquentでRow Level Securityを扱う方法の解説
• DoctrineでRow Level Securityを扱う方法の解説
• Eloquent vs Doctrine そして結論

Hypervel is a Laravel-style PHP framework with native coroutine support for ultra-high performance. It ports many core packages from Laravel while maintaining familiar usage patterns, making it instantly accessible to Laravel developers.

This framework combines the elegant and expressive development experience of Laravel with the powerful performance benefits of coroutine-based programming. If you're a Laravel developer, you'll feel right at home with this framework, requiring minimal learning curve.

In this talk, I will introduce the key features of Hypervel, demonstrate its practical applications, and explain how it significantly outperforms Laravel Octane in high-concurrency scenarios.

Note: I will provide AI-powered realtime translation in this talk.
注: この講演ではAIを活用したリアルタイム翻訳を提供します。

Webプログラミングに欠かせない「正規表現」。でも、なんとなく 「怖い」「よくわからない」 と思っていませんか？
本セッションでは、業務で出そうな易しめの問題から、書いたら地雷なアンチパターン問題まで、全5問のクイズ形式で楽しく学びます！

動機:

1. 正規表現のシンプルな仕組みを伝えたい
2. 「魔法の道具」ではないことを実感してほしい
   • 通常の言語と「同様に」、関心を詰めこめば、それだけメンテナンスが厳しくなる
3. 複雑な正規表現を避けるための現実的な方法を紹介したい
   • 過去の発表で紹介した内容 (https://zenn.dev/shundeveloper/articles/e6405c323c555a) やライブラリなど

対象者:

1. 正規表現が「なんとなく怖い」プログラマー -> 楽しく学びを提供します！
2. 正規表現が大好きなツワモノ -> 目指せ全問正解!!

参照：

• https://zenn.dev/shundeveloper/articles/e6405c323c555a
• https://zenn.dev/shundeveloper/articles/8f74aa69ed9702
• https://zenn.dev/shundeveloper/articles/b5cc85b4d1e7eb