トーク

みなさんはnikic/PHP-Parserをご存知でしょうか？
様々なライブラリの裏側で使われているPHP-Parserですが、実は皆さんにとっても身近な存在かもしれません

このトークではPHP-ParserやASTの概要について軽くお話しするとともに、
PHP-Parserを利用してASTの差分を取り、同じプログラムであることを保証することで軽微なリファクタリングを気軽に行う方法を紹介します

「レガシーな環境だし、テストもないからLinterをかけたいけどかけられない」
そんなお悩みを持っている方の一助になれば幸いです

「設計ドキュメントは必要か？」
この議論は開発現場でたびたび持ち上がります！

ドキュメントが少ないことでスピードが出るチームもあれば、丁寧な設計が結果的に開発効率を高めるチームもあります。
複数の開発チームを経験する中、『チームトポロジー』を読んで「ドキュメントの最適なあり方は、チームの特性に依存する」という気づきを得ました。

本トークでは、以下の観点から「チームごとに適したドキュメント管理の考え方」について具体的にお話しします。

・ドキュメントの必要性とは
・チーム特性に応じたドキュメント管理
・実際のチームで実践しているドキュメント管理方法

設計やチーム運営に関わるエンジニアにとって、明日からの開発をより良くするヒントを持ち帰っていただける内容を目指します。

「スタイルとは何か。野生とは何か」──元同僚がXでつぶやいたとき、探索的テストにまつわる曖昧さに、改めて目を向けるきっかけになりました。
Cem Kanerが「スタイル」と呼んだこのアプローチは、仕様の曖昧さに対して、観察・仮説・検証を繰り返す“ふるまい”です。それは、私自身の思考のクセに根ざしつつ、チームの存在によってアプローチとしての気づきが促されてきました。

本セッションでは、探索的テストを「スタイル」として捉えることで見えてきた、属人性・再現性・品質との向き合い方を語ります。QAの実践における“野生”──型にはまらない問いとふるまいが、どんな価値を生んできたのか。その軌跡を共有します。

「やべっ！テスト落ちた！！一旦Rerun！！！」
──みなさん、これ、やっていませんか？（特大ブーメラン）

通ればラッキー、通らなければ…まああとで考えるか、というアクションに陥りがちです。
このような"たまに落ちる"Flaky Testを放っておくと、じわじわとテスト全体の信頼性を失っていきます。

私自身、何度も同じ轍を踏んできましたが「そもそもそのようなテストを書かないようにする」勘所を掴んできました。
このトークでは、Flaky testになりそうな臭いのするテストの勘所、そして、そもそも生まないためのテストの書き方について話します。

話すこと
・Flaky Testになりやすいパターン（キーワード: 不定な並び順, 非決定的な現在時刻, 日付が変わると落ちる, ...）
・Flaky Testにしないための書き方
・Flaky Testをそもそも生まないために

Amazon RDS Blue/Green Deploymentは本番DBのクローンを作成し、更新後にスイッチすることで安全かつ高速にリリースを行う仕組みです。
ダウンタイムめちゃ少なく移行できる！！というのが旨みで時間のかかるDBアップデートもユーザーに負担をかけることなく終わらせることができます。

これを完遂させるまでにはいくつかの悩み・ハマりポイントがありました。
そのため実録として、どのように運用したか実際に作った手順書も大公開します。
不安の多いDB バージョンアップをハードルなく進めるための指針となる話をします。

話すこと
・Blue/Green Deploymentとは
・実録〜前もって確認すること・手順書・リアルな所要時間〜
・Blue/Green Deployment を選ぶ場面、選ばない場面
・やってみてわかったDBバージョンアップの勘所

何かを志そうと思った時

「どうせ無理」
「そんなのできる訳がない」

と言われたり

「私にはどうせ無理か…」

と諦めてしまったりすることがあるかと思います。

システムエンジニアとして働く中でそんな”どうせ無理”に抗い、今では好きなことを仕事にすることができています。
どう抗い、どう好きなことを仕事にしてきたのかをご紹介します。
誰かが少しでも自分らしく生きるためのヒントになれば幸いです。

バグはゼロにできません。だからこそ、起こさないための仕組みと、起こったときの対応力の両方が重要です。
本セッションでは、QAがエンジニアと協働しながら、PR環境の自動生成やFeature Flagsによる安全な開発プロセスなど、予防的な仕組みにどう関与しているかを紹介します。
さらに、Slackでの即応体制やレトロスペクティブへの関与など、インシデント対応におけるQAの役割と、品質文化の育て方についても共有します。
「防ぐ」と「向き合う」両軸を支える仕組みと文化を、実践例を交えてお話しします。

PHPでwebシステムを開発をしていると、必ずと言っていいほど日付に関わる処理を実装します。

「契約開始日から1ヶ月後の契約だけこんな処理を。。。」
「この条件は注文された日から30日間だけ有効で。。。」
「受注日より前の注文だけ取得して。。。」

新人エンジニアの頃、何気なく渡されたタスクで、何気なく実装した日付に関する処理でエラーを連発してしまいました。

• DateTimeImmutableを使わないとどうなるのか？
• DateTime->modify('1 month')が1ヶ月後にならない
• 1ヶ月後って何日後？

簡単そうなタスクに見えて落とし穴がいっぱいの日付について話します。

Laravel開発でphp artisan serveを叩きビルトインサーバを起動するお馴染みの光景。
しかし、公式ドキュメントには「本番環境で使うな」の一文が。
なぜビルトインサーバーは手軽さと引き換えに、本番環境で採用できないのでしょうか。
また、本番環境でデファクトスタンダードとなっている「Webサーバー + PHP-FPM」という構成は、どのようにそれを解決するのでしょうか。

以下についてお話しします。

• ビルトインサーバーが本番環境で推奨されない理由
• WebサーバーとPHP-FPMの基本的な仕組み

皆さんはPHPに機能追加してみたくなりませんか？
私はPHP 8.4から機能追加をPHP本体にやってきていて、様々な関数を世に送り込んできました。

• mb_trim、mb_rtrim、mb_ltrim関数
• mb_ucfirst、mb_lcfirst関数
• grapheme_str_split関数

PHP 8.5では以下の関数が追加予定です

• grapheme_levenshtein
• grapheme*関数にロケールを追加する(8月8日現在では投票中です)
  https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive

みなさんも、RFCで提案してみるのはどうでしょうか？そのコツなどやり取りをお伝えできればと思います。

元々PHPerだった私は、2025/03に転職をし、Gopherとなりました。
まだまだGoの知見は少ないですが、そんな中で感じるPHPの良さについて話します。

当然ながらGoの良さはたくさんあり、パフォーマンス、静的型付け言語、シンプル、ゴルーチンによる並列処理 etc...
しかしながらPHPも進化を重ね、非常に優れた言語となっています。
高速かつ安定したPHPの実行を可能にするPHP-FPM、膨大なライブラリとコミュニティの知見、Laravelのような至れり尽くせりなフレームワーク etc..

Goと比較しつつ、PHPの良さを語ります。
※Go下げをするものではありません

6年間運用したPHP製テレビCM分析管理画面で、ストレージとデータ構造の限界から大規模刷新を決断。この機会に、アプリケーション全層の型安全性も確立する統合的リアーキテクチャを実行した事例を紹介します。
きっかけはストレージのスケーラビリティ問題でしたが、管理画面特有の複雑なビジネスロジックにおいて、各層での型の曖昧さが顕在化していました。インフラ刷新と同期させることでリスクを最小化しつつ、gRPC-Connect+静的型付け言語への完全リアーキテクチャを実現しました。
本トークでは、インフラ起点で全体を巻き込む意思決定プロセス、リアーキテクチャの設計と実行、各層での型問題の具体的な解決例、DIを活用したテスタビリティ向上について、実コードとともに解説します。管理画面システムの統合的リアーキテクチャの実践知をお届けします。
話すこと: 実践的な移行プロセス、型とDIによる品質向上の具体例

テレビCMを軸にマーケティング分析プラットフォームを開発する株式会社テレシーで、Laravel Novaは6年間、私たちの事業成長を支え続けてくれました。管理画面の爆速開発を実現し、今の事業スピードを可能にしてくれたのはNovaのおかげです。なぜNovaを選んだのか、どのように事業にインパクトを与えたのか、そしてなぜ今、別れを決意したのか。
本トークでは、Laravel Novaの強みと適用領域、運用で見えてきた限界点、そして「卒業」のタイミングの見極め方を、実際のコードと共にお話しします。さらに、次の技術への移行で採用した仕様書駆動開発のアプローチもご紹介。
Laravel Novaは適材適所で本当に輝く技術です。これから導入を検討している方には最適な活用シーンを、すでに運用中の方には「卒業」のタイミングを見極めるヒントをお届けします。6年間の感謝を込めてお話させて頂きます。

「どこで何が起きているのか分からない」──複雑な処理が詰め込まれたコードを前に、そう感じたことはありませんか？

本セッションでは、そんな不透明なロジックを “出来事” を軸に整理し直す、イベント駆動アーキテクチャへの段階的な移行プロセスを紹介します。
「〇〇が起きた」というドメインイベントを導入し、処理を手続き型から宣言的なスタイルへと転換することで、コードの見通しや責務を明確にしていきます。

まずは同期イベントによる責務分離から始め、そこから非同期イベント処理へと進化させる3ステップを、PHPコードの実例とともに解説します。
さらに、非同期化に伴って生じる整合性の落とし穴についても、Transactional Outbox などの実装パターンを交えて紹介。

“出来事”を中心にコードを組み立てることで得られる、読みやすさと保守性を兼ね備えたアーキテクチャ設計のヒントをお届けします。

PHP では try-catch による例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか？
過剰なエラーハンドリングや、catch したけれど何もしていない“握りつぶし”が積み重なると、責任の所在が曖昧になり、コードの見通しや保守性にも悪影響を及ぼします。

こうした課題へのヒントとして、Rust などの言語で採用されている Result 型の考え方を、PHP に応用するアプローチがあります。
Result 型は、失敗を型として明示的に扱い、成功も失敗も返り値で表現する設計手法です。

本セッションでは、さらに一歩進んで、処理の流れを線路のように“合成”する「Railway Oriented Programming」の考え方を取り入れ、複雑な分岐処理をシンプルに記述する実践的な方法を紹介します！

php-srcを知りたいときの教材として、てきめんさんの「var_dumpを写経する - php-srcを学ぶぞ -」は分かりやすいです。

https://techbookfest.org/product/5746408227340288?productVariantID=6343868242984960

このトークでは、実際に本に倣って進めていくところで詰まったポイントとその解消方法や、php8で写経をしてみるために必要な準備を解説します。

実際にextensionを含めてビルドして動くところまで到達することを目標にします。

ソフトウェア開発の現場では、短いサイクルで継続的に学習する仕組みとしてスクラムが広く採用されています。
しかし、直近で担当した納期必達のPJでは、コミュニケーションコストを削減するためにスクラムイベントをすべて取りやめる決断を下しました。
このPJは無事に納期を守り、大成功で終わりましたが、後続の追加開発プロジェクトでは、スクラムイベントの廃止により課題共有の不足や、チームの一体感の低下などの問題を経験をしました。
そこで、課題を発見するたびにスクラムイベントを一つずつ再導入した結果、チーム連携が向上し、課題解決も円滑に進むようになりました。
本セッションでは、スクラムイベントの廃止によって発生した具体的な問題と、それらをスクラムイベントがどのように解消していったかをご紹介します。
日頃当たり前のように行っているスクラムイベントが持つ価値を改めて実感してもらえるようなトークをします

新卒でエンジニアとして働き始めてから、タスクの取りかかり方や進め方で度々つまづきました。
知識やスキルといった技術面だけでなく、「どこから手をつければ効率的か」「わからないことをどう相談すればいいのか」といった小さな判断に迷い、手が止まってしまう場面も多くありました。

このセッションでは、そんな“タスク詰まり”を感じたときに私が実践してきた、

・タスクの進め方を整理するちょっとした工夫
・周囲とスムーズに相談・連携するための意識の持ち方

など、日々の業務の中で培ったTipsをお話しします。

これからエンジニアとして経験を積んでいく若手・新人の方はもちろん、
後輩を支える立場の方々にも、現場の小さなつまずきに気づくきっかけやヒントを持ち帰っていただけたら嬉しいです。

PHPでRustリスペクトのResult型をなるべく使いやすい形で実装するならこうなりそうを話すセッションです。
PHPで制御が複雑になりがちなtry-catchのエラーハンドリングを解消したい人に向けて、Result型を使ったエラーハンドリングを話します。

話す予定

• Result型の説明
• （PHPStanを前提に実装するので）PHPStanの簡単な説明
• PHPで実装したコードの説明
• Aの実装だと使いずらいのでBの実装に変更変えると良さそう
  • @templateを使ったジェネリクスだと複数のエラーを返せない
  • 型のnarrowing
  • 関数を補完してくれないパターン（IDEでの関数補完を効かせる工夫）

想定読者

• Result型を使ったことがない人

※ Rustの知識が必要ないセッションにします

コードの自動修正を行うツール、Rector。提供される修正ルールは700超！
大量で多様なルールに対応する裏には、高い拡張性を実現する「良い設計」があります

中核的なコンセプトの1つは、対象コードを抽象構文木として扱うことです。 そして、各ルールはVisitorパターンで適用されます
──ツリーに対してVisitor。美しく王道的なアプローチの魅力を、一緒に覗いてみましょう

• 目的
  • 普及しているOSSという実践的な例から、Visitorの概要と効果について学ぶ
• 対象
  • これからデザパタやVisitorパターンを身に付けたい
  • Rectorやカスタマイズに興味がある
• 話すこと
  • Rectorの概要
  • ルールを自作して基礎を掴む
  • Visitorパターンの概要、使われ方