プロポーザル

アプリケーション開発において重要な非同期処理。
昨今ではLLMを利用した機能開発の需要も高まってきており、
特にレスポンスに長時間を要する推論モデルを利用する場合などにもやはり非同期処理が必要となってくる場合があります。

本セッションでは、Laravelのジョブキューを用いた非同期処理について、
適切に運用するために重要なキューワーカーの台数・ジョブの優先度・タイムアウト・リトライといった設定、重複実行の防止方法や考え方などを初学者向けに分かりやすく紹介します。

アプリケーション開発において重要な非同期処理。
昨今ではLLMを利用した機能開発の需要も高まってきており、
特にレスポンスに長時間を要する推論モデルを利用する場合などにもやはり非同期処理が必要となってくる場合があります。

本セッションでは、Laravelのジョブキューを用いた非同期処理について、
適切に運用するために重要なキューワーカーの台数・ジョブの優先度・タイムアウト・リトライといった設定、重複実行の防止方法や考え方などを初学者向けに分かりやすく紹介します。

現在、私は1年間に及ぶデザインリニューアルプロジェクトのチームリーダーをしています（登壇時はリリース済み予定です）。ほぼ全ての画面を書き換えますので、画面数は100を超え、関係するプロジェクトは5 Project 以上、部署の数も IR やブランドチーム、CS など影響範囲は広範に及びます。

このような状況の中で、タスクを整理し、関係部署と調整をしたうえで、チームメンバーが開発に集中できる環境を作る重要性が身に染みました。

1年に及ぶプロジェクトに携わることはなかなかありません。 このプロジェクトを経験することで学んだ、難易度の高いプロジェクトであってもうまくいくチーム運営のエッセンスを凝縮した形で皆様にお伝えできればと思います。

Webアプリケーションは繁盛するとどんどん機能が追加されていきます。Laravelを代表とするWebアプリケーションフレームワーク(WAF)は、機能が少ない間は開発スピードも早く、比較的理解も用意なプログラムが書けますが、年を重ねるごとに複雑化していきます。

このように肥大化したWebアプリケーションのことを巨大泥団子(Big Ball of Mud)と呼びます。運用・保守性が下がることは、誰も望んでいないにもかかわらず、なぜこのような複雑なWebアプリケーションが
生まれるのでしょうか？

本トークで話す内容

• 巨大泥団子が生まれる技術的、社会的経緯
• 実際の改善策、改善例

複雑さという概念をご存知でしょうか？プログラムは放置しておくと、際限なく複雑になっていきます。この複雑さは、プログラムそのものから発生するものはもちろん、インフラやミドルウェアなどのアーキテクチャー設計、さらにはチーム体制や組織設計から発生するものまで、多種多様な発生源から現れます。本トークでは、プログラムにどのようにして複雑さが入り込むのかをマクロな視点、ミクロな視点の両方から解説します。複雑さが入り込む要因について、解像度を上げることで、今後の開発において複雑さの混入を防ぐ予防的な措置が取れるようになりましょう。

技術書が多すぎると思っていませんか？名著とよばれる古い書籍もたくさんありますし、新しい書籍も次々と出版されます。あれも読みたい！これも読みたい！そうして、書籍を手に入れるのは良いのですが、問題は読む時間の捻出です。可処分時間には限りがあります。ゲームもやりたいし、家事もある、どうしても技術書を読む時間を多く捻出できない。結果として、積読ばかりが増えていきます。

本LTでは、限られた時間を使って技術書を読む方法を紹介します。積読に怯えず、たくさんの本を読むことができるようになるでしょう。

本トークで話す内容

• ”読む”とはどういうことか？
• 技術書を消化する具体的手法

本トークで話さない内容

• 速読

私は今まで行われた「PHPカンファレンス福岡」のすべての回で登壇をしています。このカンファレンスとともに技術者として、また一人の人間として大きく成長し、自分のキャリアを作り上げてきました。本LTでは、エンジニアにとってカンファレンスというものがどういう存在なのか？そして、カンファレンスを通じて、どのように成長するのか。実体験を通して紹介します。

カンファレンスというイベントはさまざまな側面で人間を成長させてくれます。技術的な側面だけではないカンファレンスの魅力や素晴らしさをお伝えします。

昨今のPHP開発では保守性と拡張性を確保するためオブジェクト指向設計が重要と言われています。
しかし私は、オブジェクト指向を採用していない組織からオブジェクト指向を採用している組織へ転職した際、その必然性を実感できずに戸惑っていました。
本LTでは、オブジェクト指向という言葉は知ってる。用語もわかる。使い方もわかる。でもなんでそれが必要とされているのか分からなかった状態からオブジェクト指向の必要性を理解できるようになるためにやったこと、経験したことを共有します。
本や勉強でオブジェクト指向聞いたことあるけどイマイチ腑に落ちない。効果がよくわからない。そんな方の役に立てると嬉しいです。

「ふりかえり会で決めたTryは達成した。でも、なぜかチームは苦しいまま……」
「合意した要件・仕様を作り切った。それでも、プロダクトは思うように伸びない……」
「設定した個人目標をクリアした。なのに、評価が上がらない……」

こうした状況は、なぜ起きるのでしょうか？
実は、その背景には、「そもそも何を問題と捉えるか」という出発点のズレがあります。
どれほど見事な解決策でも、問題設定自体がズレていれば得られる価値は低くなります。
問題設定の質が、成果の上限を左右してしまうのです。

本セッションでは、"時間的変化"と"視座操作"という2つのアプローチを使って、問題設定の質を高める手法を紹介します。

現在HTTP Cacheに関するRFCは7234...ではありません。2022年に改訂され、RFC9111 HTTP CachingとしてInternet Standardになっています。
本発表ではRFC9111、特に共有キャッシュについて見ていきます。
プロキシサーバのアップストリームに位置するWebアプリケーションとしてどうすればキャッシュをしてくれるのか、もしくは拒否できるのか。理解すれば、実装にはよりますが少なくともRFCに沿った議論ができるようになります。
発表者はRFC9111に沿ったキャッシュミドルウェアを実装しています。
https://github.com/2manymws/rc
この実装経験に基づいた紹介をします。
（なお、2025年8月現在rfc9111で検索して出てくるのは我々のリポジトリを含めて5つ）

この機会に「RFC9111完全に理解した」になりましょう！

「いつかはカンファレンスで発表したい」そんな風に思っている方も多いのではないでしょうか。
私は今でこそ年に何度も発表をしていますが、勉強会デビューは30代後半のことでした。そして、初めてカンファレンスで発表したのは10年前、第1回のPHPカンファレンス福岡 2015でのことでした。
このトークでは2013年の勉強会デビューからどの様にしてカンファレンスで発表する様になったのか、勉強会やカンファレンスの楽しみ方、そしてそれから10年、カンファレンスでの発表が人生に与えた最高の影響についてお話します。
このトークを聞いた方がカンファレンスを一緒に楽しめる「仲間」になることを祈っています。

近年、PHP系カンファレンスが大流行していて、今後もその流れは続きそうです。
このトークでは過去に16回のカンファレンス主催をしてきた私が、これからカンファレンス主催したい方の最初の一歩に役立つであろう内容をお話します。

• カンファレンスをつくるのに必要な4種類の参加者
• 会場の探し方と選び方
• カンファレンス開催にかかるお金
• 管理する必要があるものとそのためのツール
• ノベルティや会場装飾の作り方
• カンファレンス準備カレンダー - いつ頃、何をするか

カンファレンス主催したい方だけでなく、スタッフとしてカンファレンスを作ってみたい方、カンファレンスがどうやって作られているかが気になる方にもお楽しみ頂けると思います。
このトークがカンファレンス主催したい方の助けになり、PHPカンファレンス福岡の復活や、福岡での新たなカンファレンス誕生の助けになることを祈っています。

E2Eテストの重要性は理解していても、実行時間の長さがボトルネックになっていませんか？

Playwrightはユーザー体験をテストするE2Eテストツールです。
PHPのテストでよく使われるバックエンド検証のユニットテストツールPHPUnitでは検証が困難な領域をカバーできます。

Playwrightは実際のブラウザを動かすため、ユーザーがWebサイトを操作するのと近い状況でテストを実行できます。
しかし、ユニットテストと比較すると実行時間が長くなる傾向があります。
テストケース数が増加すると、CI/CDのボトルネックとなり、開発者のテスト実行頻度低下の要因となります。

本セッションでは、Playwrightのテスト実行時間を大幅に短縮するための実践的なテクニックをご紹介します。

現代のコンピュータはハードウェアから私たちプログラマが書くプログラムの動作までの間が多くのレイヤーに分けられて動作しています。
レイヤーは自分より下を抽象化し、下のレイヤーを詳しく理解しなくても多くの場合プログラマはプログラムを書けます。
一方、プログラムが期待した様に動作しない時には下のレイヤーの動作の理解が問題の解決の助けになることもあります。

このトークでは私たちが愛するPHPをスタート地点にして、「VMって何？」「 PHPやJavaとC言語の根本的な違い」など、コンピュータプログラムがどの様に動作するのかを解説します。

コンピュータのレイヤー構造を理解すると、いままでは見えていなかった角度からプログラミングを楽しめるようになります。
このトークを通じて、低レイヤーが好きになったり、いろいろなレイヤーで面白いことをしたりする方が増えることを期待しています！

私が初めて参加した技術カンファレンス、それが2015年、第1回PHPカンファレンス福岡でした。
初めて体験した技術カンファレンスはとても刺激的で楽しく、すっかり虜になってしまいました。
当時iOS関連開発にも関わっていた私はiOS関連開発にもこうしたイベントが欲しくなり、無いなら作るとiOSDC Japan を立ち上げました。
あれから10年、私の人生は大きく変わりました。ここ数年はカンファレンスを2つ主催し、各地のPHPカンファレンスへの遠征参加を楽しんでいます。
そのきっかけをくれたPHPカンファレンス福岡への感謝の気持ちを伝えるとともに、PHPカンファレンス福岡が今回いったんの最終回を迎えることでカンファレンスロスになりそうなみなさんに、各地で開催されているPHPカンファレンスの楽しみ方をお伝えします！

社会人1年目の自分は弱小エンジニアだったので、色々な勉強会に参加して、そこで会った人に誘われてカンファレンスに行ったのが全ての始まりでした。登壇者や他社の取り組みに触れることで、「自分もこうなりたい」と思う反面、一般的な潮流とのギャップを痛感する機会になりました。その後、カンファレンススタッフにも挑戦して、視野が大きく広がりました。結果的に、転職や技術的成長にもつながり、社内イベント登壇などの機会を得るようになりました。本セッションでは、私がどのように技術コミュニティと関わり、そこから得た経験が自分自身にどのような変化をもたらしたかを共有します。まだ経験の浅い方や、エンジニアとしての視野を広げたい方の参考になれば幸いです。

OJTプロジェクトでOpenAI APIをcurlで呼び出していたのですが、プロンプトやAPIクライアントの管理が煩雑になりました。

そんな時社内にてAWS Strands Agentsの話を聞き、LaravelにもAIを効率的に実装する方法があるはずだと調査したところ、LarAgentというフレームワークを見つけました。

LarAgentを使うことで、AIエージェントの定義と呼び出し部分を簡単に分離でき、実装ロジックが単純になりました。
また、artisanコマンドでエージェント生成ができ、#[Tool]属性を活用することで、エージェントのFunction Tools定義が簡単になり、従来のJSONによるAPI呼び出しから解放され、認知負荷を大幅削減できました。

LarAgentを使うことで、新卒の私でも簡単にAIエージェントをつくことができました！その体験を皆さんに共有します！

生成AIの登場で、エンジニアの学び方と働き方は大きく変わりました。
私は普段バックエンドを担当していますが、とあるプロジェクトでフロントエンド領域への挑戦が必要になりました
最初は「何がわからないのかすらわからない」状態でしたが、PRレビュー補助やコード理解のガイドとして生成AIを活用することで、実装と学習のサイクルを加速させられました。
その結果、当初目標の倍以上のフロントエンドに関わる改善を出せるまでに成長ができました。

この発表では実際に、バックエンドエンジニアが生成AIを活用して、フロントエンド領域へ挑戦した実体験を発表します。

「愚者は経験に学び、賢者は歴史に学ぶ」はドイツ帝国宰相ビスマルクの言葉として有名です。しかし、ソフトウェア界隈では、「とりあえずやってみよう」を標語に経験から学ぶことが奨励されています。 またスクラムもその理念の一つとして、経験主義を掲げています。 経験から学ぶことは本当に悪いことなのでしょうか。

本セッションではネットの記事や書籍、スライドや発表から学ぶことと、自分で経験することから学んだことを区別する考え方を紹介します。 そして経験主義の語源や哲学史上の意義を紹介し、誤解されがちな経験主義の本当の位置づけを見直します。

ChatGPTやClaude Codeなどの生成AIツールの登場によりコードの自動生成や設計補助を一瞬でこなせるようになり、開発のスピードはかつてないほど上がりました。
しかし、システムの価値を決める設計の心臓部である中核の業務領域のモデリングや設計判断は、いまだ人間の理解と経験が不可欠と考えています。
本セッションでは、『はじめてのドメイン駆動設計』で紹介されている「中核の業務領域」に焦点をあてドメインモデリングを行う方法、それ以外の領域で生成AIを活用する事例を発表します。

• 設計を取り組むべき「中核の業務領域」について
• ドメインモデリングを活かした具体的な実装例
• 「中核の業務領域以外」でAIツールを効果的に使うポイントについて

このセッションを通じて、AI時代でも揺るがない設計の軸と、生成AIを使った開発を上手く共存する方法を持ち帰っていただければ幸いです。