テストコードを書いたことがない人からすると、テストコードとは『コストをかけられる人が行う、高品質を目指すためのもの』という印象があるかもしれません。

しかしテストコードは全くもってバグを減らすためだけのものではなく、もっと手軽で日々の開発を楽に安全で効率的に進めるためのものでもあります。

「仕様がすごい変わるから付け足しのコードになるのは仕方ない」
「コードを変更するとバグが起きるリスクが高いし、コストもかかるので極力変更してはならない」
「できるだけコード追加で済むようにする」
「デッドコードなんじゃないかって？でも動かなくなったら嫌だしさ…」

――こうした“秘伝のタレ状態”のコードは、まさにテストコードがないことで生まれます。

本セッションでは、テストコードがないとチームやコードにどんな影響が出るのか、テストコードを導入したことで何が変わったのかを、実体験を交えて紹介します。
さらに、テスト文化のないチームでどのようにテストコードを広めていっているのかなどについても解説します。

テストコードを社内に広めたい方、チームでの導入に悩んでいる方、また既にテストを書いている方がその価値を改めて再確認する助けになれれば幸いです。

PHP-Parserを利用すると、PHPのコードを抽象構文木 (AST) に変換したり、逆にASTをソースコードとして出力したりすることができます。

ASTの一部を書き換えることもでき、たとえばRectorはこれを利用してソースコードの書き換えを行います。

この技術を利用すると、PHPコードをminifyすることも可能です。
minifyはソースコードの空白の除去や変数名の短縮などにより、ソースコード全体のサイズを圧縮することです。JavaScriptやHTML、CSSでは、ブラウザ↔サーバー間の転送量削減のためによく行われます。

WASMを使いブラウザ上でPHPを動かす事例も増えている昨今、PHPコードをminifyしながらASTの力を感じてみませんか？

話すこと

• ASTとは
• ASTを使ってPHPコードをminifyする方法
  • 同一のASTになる最小のコードの出力
  • 同じ意味・動作の異なるASTへの書き換え

想定観客

• 抽象構文木を知らない人
• ASTが何の役に立つか分からない人
• PHPをブラウザで動かしている人

自分の住む地域で技術系勉強会を開きたいと思ったことはありませんか？ そして「でも勉強会は続けないといけないし，ネタも集めないといけないし，レベルも維持しないといけないし，責任もあるし......」と，思ったその瞬間に継続コストが頭によぎり，「やっぱりやめとこ」と動き出さなかったこともありませんか？
　
勉強会は技術系コミュニティにおける基礎体力に影響します．参加者のレベルアップや仲間づくりなど，即座にわかる効果もありますが，これを皮切りに全国的な技術系カンファレンスの行脚先に名乗りを上げたり，地域の技術カンファレンスを開いたりすることにもつながっていきます．
　
そうしたある種の呪縛を解くために，私が見てきた範囲で，"関係する人たちが苦しくなってしまった勉強会" が手軽でなくなったと思われる要素をひとつずつ噛み締めていく会を行い，最後に最大級の手軽な勉強会の実践を会場のみなさんで行います．

抽象化能力を身につけるのに役立つ、いくつかの切り口を手に入れよう というトークです。
設計に不慣れな人も、手軽に「抽象化に思いを馳せる」ようになることを目指します。

「優れた設計には、優れた抽象化が欠かせない！」
そんな声を聞いたことはありませんか？
プログラミングにおける抽象化は、
PHPコミュニティでも、これまでに何度も探求され、発信されてきたテーマです(末尾に一例を挙げます)。

「うまい抽象化を身に着けたい・・」そのためには、理解と鍛錬が求められるものと考えます。
体術のように反復や試行錯誤が欠かせませんが、当てずっぽうにやる訳にも行きませんよね。
◯◯アーキテクチャやパターンランゲージと呼ばれるものはどうでしょう？
それらも強力なヒントになりますが、どうしても「実装寄りの話」に閉ざしたものになってしまいます。

より一般的な = クラス設計より手前の「抽象化」も重要です。
このトークでは、頭の中の道具箱にしまっておけるような、
「こういう観点で思考実験をしてみると、抽象化が捗るかもよ」という複数の切り口を提供します。

話すこと

• そもそも「抽象化」ってなんだっけ、それがあると何が良いの？のおさらい
• 「抽象を見つける」ために役立つ観点、試せること

抽象化についての発信があった例

• hidenorigotoさん(2019)
• 77webさん(2021)
• soudai1025さん(2025)
• shin1x1さん(2025)

MCPの登場により、LLMは様々なツールと接続できるようになりました。オープンソースに限らず、自分たちのサービスや社内ツールも手軽に統合できるようになり、LLMの活用の幅が広がっています。

今回は、PHPとPostgresでRAG（Retrieval-Augmented Generation）を実装した経験をもとに、方法と精度向上の工夫についてお話しします。まず、ベクトルとは何か、そしてなぜ意味的に近い情報を検索できるのかを解説します。その上で、文章をベクトル化して意味的に近い情報を検索する仕組みや、検索結果の精度を高める拡張クエリとリランキングについても具体的に紹介します。

WordPress Playground は、WordPress を丸ごと WebAssembly 化し、ブラウザ上で実行できるようにした仕組みです。
サーバーやデータベースを構築することなく、WordPress の一連の動作をブラウザ上でエミュレートできます。管理画面で投稿や設定を保存し、それがフロントエンドに反映される──こうした体験を、サーバー構築の手間なく再現できることが学習・検証・プラグイン開発のハードルを大きく下げました。

PHPer の中でも Laravel や Symfony を日常的に使っている方には、WordPress エコシステムに馴染みがない方も多いかもしれません。
本セッションでは、WordPress コミュニティがどのように WASM を実用して Playground を生み出し、開発者体験を再構築したのかを紹介します。PHP vs WASM という対立構造ではなく、PHP アプリケーションでありながら補助的に WASM を活用することで体験を拡張できる可能性について、一緒に考えてみましょう。

※ WASM の基礎知識を前提としていないため「WASM なんもわからん」という方でも大丈夫です

本セッションでは扱わない内容

• PHP アプリを WASM にコンパイルする方法論
• Laravel / Symfony など他フレームワークへの適用手順
• PHP と他言語（Rust / Go など）を比較した WASM の優位性や将来性
• 初心者向けの WASM 入門や、WASM の基礎的な仕組みの解説

Laravel には、非同期処理を手軽に扱えるジョブキューの仕組みが用意されています。私自身もこの仕組みを利用してメッセージ予約配信機能を実装しました。

本セッションでは、そこで直面した課題や悩みを出発点に、まずジョブキューの基盤となる メッセージキューの仕組み、選択できる キュードライバ、そして 同期処理と非同期処理それぞれのメリット・デメリット を整理し、どのような場面でジョブキューを導入すべきかを考えます。

さらに、Laravel が標準で提供する リトライ・タイムアウト・並列処理 などの機能を踏まえながら、非同期処理やバッチ処理で重要となる 冪等性・リトライ戦略・並列制御・タイムアウト設計 を掘り下げ、堅牢でスケーラブルなシステム設計のヒントを探っていきます。

近年、カンファレンスや書籍を通じて多様なソフトウェア設計の手法が広まり、私たちの選択肢はますます多くなっています。
しかし、リソースは有限です。すべてを全力で完璧に作り込むことは難しい場合もあります。
「どこに力を注ぐか」を見極めることも重要です。

事業の競争優位を支える核心領域には積極的に投資し、それ以外はあえて“手軽に”抑える。
判断を誤れば、逆に設計に振り回されて事業価値に結びつかないコストばかりが膨らんでしまう危険もあります。

ドメイン駆動設計の著者であるEric Evansはかつて、「最も才能がある人をコアドメインに割り当てること」と述べています。
そして現在では、メンバーの技術力やドメイン知識、内製・外注という判断軸に加え、"AI"という選択肢も広がっています。
これらの判断はどのように見極めればよいのでしょうか。

さらに近年では、コードや機能の「捨てやすさ」も注目されています。
手軽に「作る」だけでなく、手軽に「捨てる」ことも重要となってきました。

本セッションでは事業理解を基盤に設計・コーディングの「力の入れどころ」や「捨てやすさのデザイン」をどう考えるかをお話しします。
Kent Beckが提唱する"Optionality"などに触れながら、設計投資にメリハリをつける視点を紹介します。
また、私自身も過去に設計に投資しすぎてかえって無駄な複雑性を増やしてしまった失敗を経験してきました。
こうした自身の過去の失敗例も交え、理論と実践の両面から学びをお届けできればと思います。

事業価値を見据えつつ、どこに投資し、そしてどう捨てるか。
このセッションを通じて、その判断を明日から少し“手軽に”行えるようになるヒントを持ち帰っていただければ幸いです。

“もっと実りあるふりかえりをしたい”と思ったことはありませんか？
「ふりかえりって何？」「初めてチームにふりかえり文化を根付かせたい」という方から、「いつもなんとなくKPTをしているけど効果が見えにくい」「色んな手法を試したい」という方まで、
幅広い参加者に向けて、ふりかえりの基本から現場ですぐに使える手法までをわかりやすくお話しします。

しっかりと原則や基本的な考え方を押さえつつ、現場ですぐに使える「手軽に試せる実践知」を盛り込み、
明日から一歩チームをカイゼンできるヒントをお届けしたいと思います！

【セッション内容】

1. ふりかえりとは？ ─ その効果と意義を再整理
2. チームで実際にふりかえりを行う具体的ステップ
3. 「DPA」「Starfish」「象、死んだ魚、嘔吐」など様々なふりかえり手法の紹介
4. Tips：リモート実施での注意点やファシリテーションの工夫
5. 私がチームで普段実践しているふりかえりを具体的な事例として共有

【このセッションの価値】

• “なんとなく”実施していたふりかえりを見直すきっかけになる
• ふりかえりを効果的に進めるためのヒントや具体的な手順を持ち帰れる
• ふりかえり文化がないチームでも、始め方の指針が得られる
• 新しいふりかえり手法を知ることができる

チームで“ふりかえり”をちょっとアップデートしてみたい方、お話できるのを楽しみにしています！

概要

Web を支える重要なプロトコルのひとつ、HTTP。言語やライブラリ、フレームワークの下に隠蔽され、通信プロトコルを直接意識する機会は少ないと思います。そこで、PHP のソケット API を使って HTTP を解する小さなサーバを実装し、HTTP の理解を目指しましょう。

話すこと

• TCP/IP スタック
• HTTP の基本的なプロトコル
• HTTP を実装する
  • GET / POST メソッド
  • Cookie / Set-Cookie ヘッダ

実装を通して、初心者が抱きがちな次のような疑問を解消します。

• 「プロトコル」とは？
• GET と POST はどう違う？
• Cookie とセッションはどう違う？

対象

• Web サイトの通信がどのようにおこなわれているのか詳しく知りたい方

Setup PHP Actionは、テストに必要なPHP環境を手軽に設定できる、GitHub Actions用のアクションです。PHPの各バージョンに対応しているだけでなく、さまざまな拡張モジュールやツールを活用できます。さらに、マルチプラットフォームに対応しており、LinuxだけでなくWindowsやmacOS上でテストを実行させることも可能です。

本トークは、OSSに関心のある開発者やGitHub Actionsにおけるテストに興味のある方を主な対象としています。開発やテスト、OSSにコントリビュートする際に役立つ、Setup PHP Actionの使い方を紹介します。

最近のPHPではUnicodeを正しく扱え、使いやすいgrapheme関数の強化がなされています。
本トークでは、そのgrapheme関数の使い方と、これからPHP 8.5で採用された関数・機能をご紹介します。

Web APIの認証・認可の基盤技術として至るところで使われているOAuth 2.0ですが、
その難解さから「何度説明されてもやっぱりよく分からない・・・」という意見がよく聞かれます。

このトークでは、

• OAuth 2.0の同意画面を触ったことはある
• OAuth 2.0のフローはなんとなく知っている
• OAuth 2.0をアプリケーションに導入したこともある
• 一番わかりやすいOAuthの説明 も読んだ
• でも、OAuth 2.0とは何なのか、やっぱりよく分かっていない気がする・・・

という方に向けて、今度こそ絶対に腑に落ちる、本当に一番分かりやすい解説を試みます。

お話しする内容は以下のとおりです。
OAuth 2.0としばしば混同されるOpenID Connectについてもあわせて解説します。

• OAuth 2.0とは何なのか
• OAuth 2.0の仕組み（まあまあ詳しく）
• OpenID Connectとは何なのか

このトークを聞いて、「雰囲気でOAuthを使っている」状態から脱却しましょう！

Doctrineは、Symfonyフレームワークの標準の構成でも採用されているPHP製のORMです。

Laravel全盛の現代、Doctrineにはまったく馴染みがないという方も多いと思いますが、
いつSymfony案件にアサインされるかもしれません。備えあれば憂いなしです。
それに、普段と異なるパラダイムに触れることは学びの面でもとても有意義だと思います。

この機会にDoctrineを完全にマスターしておきましょう！

このトークでは、

• 「Active Record」と「Data Mapper」の違い
• Doctrineがデータを扱う仕組み（「Doctrineの世界」という感覚）
• エンティティマネージャー、Unit Of Work、リポジトリなどの要素概念

などについて30分で可能な限り詳しく、そして分かりやすく解説します。

「協働」とは、複数の主体が目標を共有し、共に力を合わせて活動することを指します。
単なる「分業」や「協力」ではなく、立場や役割が異なる人たちが一緒に価値をつくりあげていく営みです。

エンジニアリングはコードを書いて終わりではありません。
サービスを設計する人、営業やサポートを担う人、エンドユーザの声を聞く人、──様々な立場の人たちが関わって初めて、プロダクトは価値を発揮できます。
しかし現実には、部署や部門の壁に阻まれ、うまく連携できないことも少なくありません。

実際の現場では、こんなことが起こりがちです。

• お互いの事情を押し付け合ってしまう
• 言葉がすれ違い、不満や陰口に発展してしまう
• 結果として「協働」ではなく「対立」になってしまう

でも、本来エンジニアリングは「他部署とともに価値をつくる営み」であり、協働がうまくいくとチームもプロダクトもぐんと強くなります。
私はこの「協働」のあり方こそ、これからのエンジニアにとって大切なテーマだと感じています。

今回のトークでは、私自身が他部署と一緒にプロジェクトを進めるなかで学んだことをベースに、

• 部門の壁を越えていくためのマインドセット
• 協働をスムーズにするための具体的な働きかけ
• 「これはやってはいけない」失敗例
  をご紹介します。

また、PHPカンファレンス香川2025のテーマ「手軽さ」にちなみ、“美味しいうどんを手軽に作るプロセス”をメタファーにしながら語ります。
協働は大げさに構えるものではなく、ちょっとした工夫や自然体のやり取りから始められる。
まるで「手軽に作れるのに驚くほど美味しい一杯のうどん」のように。

このトークでは、少しでも他部署とのコミュニケーションに悩むエンジニアが減ることを願い、他部署と働いているエンジニアがもっと「手軽に」協働できる方法をお話しします。

このトークは

• AST(抽象構文木)はコンパイラにとって便利なものだが、それ以外にも便利に使える
• ASTって何だろう？を知って、その便利な活用例も知ろう

モチベーション

phperの皆さんは、アルファベットや数字に記号などなどをファイル上に並べていきますよね。
私達が直接的に生産するのは、ただの「文字の羅列」に過ぎません。
これを文法の枠組みに則って解釈することで、文や句と行った構造が手に入るのです。
例えば class Hoge{} と書かれていれば、「1つのクラスが定義されていて、そのクラスはHogeという名を持つ」といった具合です。

ASTの主な利用者はコンパイラでしょう。
人間が読み書きしやすい文字の羅列を、機械のための表現に変換する過程で現れます。

そして、「字句レベルではない、構造化されたレベルでコードを扱える」ことが、
コンパイラ以外にも色々な可能性をもたらします。
より抽象的な理解や操作が容易になり、色々な作業やコード品質の担保をお手軽なものにしてくれるのです。

そんなASTについて、「確かに面白いね！」と感じる人を増やしたいトークです

話すこと

• 基本的なASTの説明
• ASTを活用した便利ツールの解説(出来ること、使い方、仕組み)
  • rector/rector
  • ajthinking/archetype

対象(難易度)

• 「ASTって何だろう？」と感じる人や「聞いたことはあるけど、具体的には知らないな」という人
• 「ASTを利用したツールを使ったことはあるが、その内部にある仕組みまでは知らないな」という人

Symfonyは“フレームワークを作るためのフレームワーク”と呼ばれ、Laravelのコアにも採用されています。
そのため、初心者向けの導入説明や上級者向けの抽象概念を獲得するための解説などの知見を聞く機会が多くあります。

また、PHP 5.4で導入されたtrait(特性)も便利な仕組みである一方で、「知ってはいるが、どう活用していいか分からない」という人が多いのではないでしょうか。

本トークでは、Symfonyの拡張しやすい仕組みとtraitの相性に注目し、ストレージアクセスモデル、フォームバリデーション、ページ描画といった領域で、少ないコードで手軽に拡張・調整する実践例を紹介します。
また、trait導入によるインターフェース統一による不具合防止、Doctrineエンティティ、フォームバリデーションや描画の定義の一貫性や安全かつ手軽な変更を実現する方法についても解説します。
そして、これらの事例を足がかりに、traitパターンをアプリ全体に横展開することでチーム開発における安心感と長期運用に耐える拡張性を手軽に実現できることをお伝えします。

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

• Symfonyの設計思想に沿ったtraitの活用パターン
• モデルやフォームを少ないコードで手軽かつ安全に変化させる技法
• traitを「どんな場面で選ぶべきか」という実務的な判断基準

このトークの対象者

• Symfonyを日常的に利用している方、または興味を持っている方
• PHPでtraitを知ってはいるが、実務でどう活用すればよいか悩んでいる方
• Symfonyやtraitの活用を通じて、アプリケーション開発を効率化したい方

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

• Symfonyの基本的な使い方