プロポーザル

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

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

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

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

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

「スタイルとは何か。野生とは何か」──元同僚が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の大きな魅力です。

array_merge() や implode() のような定番の関数がある一方で、
「えっ、こんな関数あるのぅ〜〜〜ぅん！？」と思ってしまうような、
ちょっとニッチで味濃いめな関数も存在します。

今回はそんな"気になる関数"を取り上げて、
背景から意外な使い方までざっくばらんに紹介していきたいと思います。

まだ内容は調整中ですが、5分で「へぇ〜」がひとつ増える
そんなトークを楽しくライトにお届けする予定です！

AIエージェントがコードを生成する時代、エンジニアに求められるスキルは根本から変わりつつあります。
単なるコーディング速度ではAIに太刀打ちできない今、必要なのは「AIに正確で効果的な指示を出す力」。そしてその力の本質は、設計論という“共通言語”にあります。SOLID原則、デザインパターン、クリーンアーキテクチャなどの知識は、AI時代における最強の武器となるでしょう。
本セッションでは注目の「スペック駆動開発」にも触れながら、設計力がどのようにAI協働を支えるのか、実例を交えて掘り下げます。
今こそ、設計を学びなおす絶好のタイミングです！

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

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

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

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

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

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

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

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

laravelの php artisan optimize
開発環境では思わぬエラーになるかも？

TypeScriptやRubyから、
PHPを触りはじめて1番戸惑ったコチラについて、事例も交えてお話出来ればと思います。

この辺りの理解を深める事で、
なんとなく治った謎のエラーから、
ちゃんと理解して解決できるようになりました！

こんな事を話します。

• 事例
  • こけるはずのテストが通ってしまった
  • laravelのAPP_KEY変更が反映されない
• php artisan optimize とは
• optimizeのクリア用コマンドについて
• どういう運用がベターか？
• なぜ本番環境では必要なのか

皆さんは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下げをするものではありません

LaravelとInertia.jsを使ったフルスタック開発では、バックエンドからフロントエンドへ渡すPropsやリクエストボディの型情報をTypeScriptで手動で定義する必要がありました。これにより、バックエンドとフロントエンドで型定義の不整合が起きやすかったり、データ構造の変更時に複数箇所の修正が必要などの課題がありました。
Laravel Wayfinderは、Laravelのコントローラーやフォームリクエストから自動的にTypeScript型定義を生成するパッケージです。バックエンドを変更すると自動的にフロントエンドの型情報も変更されるので、開発体験が大幅に向上します。

話すこと

• Inertia.js概要
• Laravel Wayfinderの導入方法と基本的な使い方
• Inertia.jsのPropsとフォームデータの型自動生成
• 実際のコード例とライブデモ

謎のIDや変数と複雑な仕様、夜中の手動更新、トラッキング漏れ──20年使われてきたユーザ流入基盤の運用は、もはや限界を迎えていました。「うちら辛くね？」この一言から始まったプロジェクトで学んだのは、システム改善の成功は「仲間づくり」にあるということ。

チーム・上司・運用・ビジネスを巻き込み、刷新プロジェクトを発足。安全性と保守性を備えた新基盤への移行をリーダーとしてやり遂げました。「ちょっと頑張る必要あるけど、めっちゃ使いやすくするから」という言葉を、どう信じてもらえる形にしたか。

本トークでは、フェージングが雪崩になった失敗、重い課題を別PJに切り出す判断、段階的リリースから一気リリースへの方針転換など、9ヶ月のリアルな軌跡を共有します。中堅エンジニアが直面する「与えられた仕事以外」をどう進めるか、「“やるべき仕事”は自分で作りだす」ための実践的なヒントをお話します

エラーが発生したとき、ログを追ったりデバッグを繰り返したりするのは大切な作業ですよね。でも、それだけだと「エラーが起きた後の対処」に留まってしまいます。もっと良い方法があるとしたら？

設計の段階から、エラーが「見つけやすい」仕組みや「そもそも起きにくい」コードの書き方を取り入れることで、システムの信頼性がグッと上がり、あとから困ることも減ります。

このセッションでは、例外の基本的な役割や考え方から始めて、PHPやJavaのように例外を持つ言語と、RustやGoのように例外を使わない言語のエラーハンドリングを比較。それぞれの特徴を活かした設計方法をお話します。難しい話だけでなく、「こうすれば実務で役立つ！」という具体例も紹介しますので、チームのディスカッションにもぜひ活用してください！

PHP 8.5で導入されるパイプ演算子（|>）、楽しみですね！

パイプ演算子を使うと、
strtoupper('hello')
と
'hello' |> strtoupper(...)
が同じ意味になります。

実は、例にあげた2つの式は、opcodeとしても同一です。

このトークでは、php-srcのソースコードを読み解きながら、パイプ演算子がどのように実装されているかを見ていきます。

具体的には以下の内容を扱います

• vldでのopcodeの比較
• opcodeのコンパイルに使われるzend_astとznode
• パイプ演算子を処理するzend_compile_pipe

PHPの新機能を通じてphp-srcに入門してみましょう

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

現代のPHPフレームワークでは、Dependency Injection(DI)が標準機能として組み込まれ、その有用性は広く認知されています。
しかし、既存の動いているアプリケーションへ適用するにはどうすれば良いでしょうか？

本トークでは、実運用されているレガシーアプリケーションや、Ray Di for Laravel など、複数のDI適用事例を基に、実践的な戦略を共有します。
フレームワークとユーザーコードの境界線、既存のライフサイクルに配慮した依存性注入の活用、マーカーパターンによるルートオブジェクトの識別など、既存アプリケーション特有の課題と、その解決策を具体的なコード例と共に紹介します。

本トークを通じて、既存アプリケーションにDIを導入する際に考慮すべきポイントを持ち帰っていただき、明日から実践できる知見を提供します。

皆さんは機能を作成する際に、何から始めますか。

私は情報設計に取り組むチームに所属しており、日々情報設計と向き合っています。
情報設計とは、Web に限らず情報の整理が必要なあらゆる場面で活用できる普遍的な設計の考え方で、受け手が望んだ情報を適切に与える方法を作ることです。

先日、私たちは概念オブジェクト（ユーザーがイメージする「写真」や「メール」のような対象物）を発見し、Slack ワークフローを作成するワークショップを主催しました。

ワークショップでは「なに が なに を どうする」という構文から概念オブジェクトを発見しました。発見された概念オブジェクトは開発者以外にも伝わる共通言語となりました。

本トークでは、ワークショップでおこなった誰にでも分かりやすい概念オブジェクトの発見の方法から、PHP のコードがどのように現れるかを考察しどのような恩恵が得られるのかをお話します。