トーク

「普通の」PHPプログラミングに、飽き飽きしていませんか？

どうせ適当にフレームワークを選ぶか、使い捨ての小規模コードなら生で書けばいいやと思いませんか？

本トークでは「継続ベース」という、現在ではメジャーではない考え方についてPhpで再現し考察します。

「詳細の決定を遅らせつつ実装を早くする」一見矛盾しているように思えます。

外部APIの選定で悩んで手が止まる、DB設計が決まらず実装が進まない。こんな経験はありませんか？
APIやDBなどは「詳細」と呼ばれるものです。詳細の決定は大事ですが、まずは動くものを作ることが重要です。
動くものを作りフィードバックを得ることで、詳細の決定をより良いものにすることができます。

当セッションでは、「詳細」の決定を待たずに、PHPの柔軟性を活かして実装を進める手法を考えます。
インターフェースで境界を作り、ダミー実装から始めて、詳細を決定していきます。

詳細の決定を後回しにすることは、とりあえず動くものは作ったものの手戻りがある、まるで三歩進んで二歩下がる感覚を持つかもしれませんが、実際には一歩ずつ前進しているのです。
完璧主義から脱却し、仕様未確定でも手を動かせる実装パターンを身につけましょう。

Web サイトの 78% を支えるといわれる PHP ですが、最近の世情はどうも機械学習全盛の時代なようで、PHP でこのナウい技術へ触れるための方法はあまり選択肢がありません。最近主流の盛り上がっている技術、と、Web の主流と言える言語、の間に大きなギャップがあるわけです。

このトークではこのギャップを埋めるべく krakjoe (Joe Watkins) さんが最近に開発したライブラリ、PHP-ORT を紹介します。
https://krakjoe.github.io/ort/
どのような環境で、どのような速度で、どのような処理が可能なのか、そして既存のソリューションとの差異について、駆け足で解説していきます。

GitHubには多くの便利な機能があると知りつつも、 「結局どれを使えばいいのか分からない」 「CI/CDやAI活用をどう始めればいいか迷っている」 と感じている方は多いのではないでしょうか。
開発のスピードと品質を高めるActions、Codespaces、Copilotなどの機能は、単体で使うだけでなく、DevOpsの実践やチーム開発の改善にもつながります。

本セッションでは、GitHubを使っている・これから活用したい開発者を対象に、私が実践しているGitHubの活用方法を15分で紹介します。（全部言えるかもしれないし言えないかもしれません）
10月にはGitHubの年次カンファレンスである「GitHub Universe」に参加予定ですので、カンファレンスの様子も交えてお話しする予定です。

Azure Virtual Desktop(以下AVD)はMicrosoftが提供しているDaaSです。
DaaSですので、デスクトップを使用することが多いのですが、
デスクトップだけでなく特定のWebページを配信することも可能です。

AVDにおけるWebページ配信の方法についてご紹介します。

コードレビューでは、人格攻撃をしてはならないとされています。
それは裏返せば、書かれたコードをレビューするときに
それを書いた人のことをどうしても考えてしまう、ということでもあります。
自分が攻撃（非難）されたように感じてしまうのも、同じこと。
自分が書いたコードは、あたかも自分の一部であるかのように感じる気持ちがあるのです。

しかし現在、生成AIがコードを書くようになってきています。
人間が書いているところを補完してくれたり、
自律的にコードを書いてPull Requestの作成までしてくれます。
では、そのコードはあなたが書いたものだと言えますか？あるいは、思えますか？

このトークでは、コードと私たちの距離について考察します。
（心理的な）オーナーシップの話だけでなく、責任の分界点についても見ていきます。
生成AIの導入で変わりつつある距離感について、一緒に考えてみませんか。

「AIが相棒なら、1人で全工程実装したプロダクトを作れる……！！」

そう思った瞬間、ゼロからの個人開発に挑戦することにしました！
技術選定は、大好きなPHP、初めて使うInertia.js、そしていつかちゃんと学びたかったAWSインフラ構築。

このトークでは、私がなぜ個人開発を選んだのか、仕様策定から設計・実装・テスト・デプロイまで、開発フローの各段階でAIをどう活用したのか、AIと一緒に試行錯誤して挑戦する個人開発ストーリーをお届けします！
また、短期間で動くサービスに仕上げるための工夫や、個人開発で成長するために必要な考え方についてもお話します！

聞きに来てくれた皆さんには、「AIという相棒がいるからこそできる、新しい技術の学び方」を持ち帰っていただきたいです！

補足

カンファレンス参加をもっと楽しくするアプリを作りました！当日みんなで使いたいです！

PHPカンファレンス福岡は10周年、そのカンファレンスのコアになっているPHPが30年の歴史で世界の79.2%のWebサイトを支える理由はなんでしょうか？

歴史：1994年Rasmus Lerdorfの「Personal Home Page Tools」、Zendエンジン誕生まで歴史から設計思想を知り、
現在：PHP8のJITコンパイラ、Laravel・Symfonyエコシステムなど、2025年における実践的価値を理解し、
未来：なぜ650万人の開発者がPHPを選び続けるのか？「Why PHP？」の未来への展望を知る

歴史的必然性から現代の実用性、未来の可能性まで、PHPカンファレンス福岡10周年の今、PHPの真の価値を再評価しましょう

• 対象者:
  • PHP採用検討中の技術者・意思決定者
  • 他言語からの移行検討者
  • PHPの将来性に疑問を持つエンジニア

このトークでは、ある仮説を提案します。

技術的負債の、「利率」にあたる部分はチームメンバーの増加によって見かけ上増える

プロダクトの開発で機能とソースコードが変更されると貸借対照表の借方に新機能によって得られる価値(正味現在価値)が入り、貸方に技術的負債が入ると捉えられます。この、貸方に入る技術的負債が通常の負債とは異なる性質を持つと言うのが、この仮説の骨子です。

トークでは、貸借対照表や正味現在価値などの用語についても解説を加えます。

この仮説を通して、各チームで
・技術的負債の解消をするかどうか
・いつ技術的負債を解消するか
・カスタマイズをすべきかどうか
・カスタマイズをする場合はリファクタリングを計画するか
などについて議論を深めるきっかけにしていただくことを目指します。

※内容の正確さには注意を払いますが、私は会計学の専門家ではありません。

2012年頃から開発が始まったシステムを現在リプレースしています。

開発開始当時は社内に知見がない中で苦労をして価値を出してきたことは素晴らしいことだと思います。しかし、10数年たった現在さまざまな問題があることも事実です。

転職を機に現在このシステムを、基幹システムのリプレースに合わせてリプレースをしています。DevOpsが国内で話題に上がる様になって10数年経過した現在ではDevSecOpsのような、セキュリティを開発フェーズから意識する考え方も普及してきています。

このセッションでは、私が10数年DevOps/CI/CDを継続して進めてきた経験を活かし、0から構築している環境の考え方や実践している内容を共有したいと思います。

PHPカンファレンス福岡10周年おめでとうございます。
この10年で、私はアラサーからアラフォーに進化しました。

本トークでは、技術や仕事との付き合い方の変化についてお話しします。

最新技術は面白いです。でも1年後には違う技術で盛り上がってるんだろうなと思うこともあります。
若い頃は最新技術に夢中でしたが、今は新しさよりも、自分が熱を持てるものを重視するようになりました。

一方で変わらないのは、誰かの役に立ちたいという気持ちです。
気づけばマネジメントされる側から、する側になりました。
チームが楽しく働ける環境を作れると、嬉しいですし、やりがいもあります。

今回は「アツいトーク」がテーマということで、気恥ずかしさもありますが、私のパッションをお伝えしたいと思います。
同じ時代を技術者として過ごしてきた方や若い世代の方に、N=1のサンプルとして共感・参考にしていただけると嬉しいです。

当時、「効率よく生きることこそ、正義」というマインドを持っていました。
「楽をして生きること」が正しいと考えていました。
しかし、時代の流れと共に「何物でもない」ことへの焦りを感じていました。

そんな私が
好きな技術に出会い
コミュニティイベントへ参加し
ブログや登壇などアウトプットをするようになり
今や好きなことを仕事にできています。

実体験を元に今に至るまでの過程をご紹介したいと思います。
好きなことを仕事にするための何かヒントになれば幸いです。

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

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

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

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

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

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

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

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

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

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

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

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

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

WebAssembly（Wasm）はブラウザ上で動かすだけでなく、複数の言語環境で動くユニバーサルバイナリとしても流行しつつあります。
もちろんPHPの中でもWasmを動かしたいところですが、PHPでWasmを動かすことはまだ敷居が高いようです。Wasmを動かす場合、基本的にはC製のWasmランタイムをPHP拡張としてネイティブコンパイルする必要があり、動かそうとして失敗した報告も多いです。
果たして、一体どうすればもっと簡単にPHPでWasmを動かせるのか…。
今回、筆者は考えました。自分にはWasmのVM自作経験がある。では、PHPでWasmのVMを自作し、その上で動かしてみるのはどうか？そうすれば、C言語不要でWasmの力を享受できるはず！
ということでこの発表は、PHPでWasmのVM（のPoC）を作り、動かしてみる…その無謀な挑戦の記録です。

皆さん、バイナリやバイトコードはお好きですか？
さて、Java、Python、Lua、Ruby他、モダンな言語は言語VMという機構を備えています。さらに、WebAssemblyのような、特定の言語に依存しないVMもあります。
そしてご多分に洩れずPHPにもVMがあります。とはいえ、PHPプログラマが直接VMのバイトコードを書くわけもなく、「OPcacheが使うなんか高速にするやつ」というふんわりした理解の方も多いのではないかと思います。

このトークではPHPのZend VMを通して、VMとはそもそも何か、なぜ必要か、VM実装の基本についてお話しします。以下のトピックの予定です。

・VMに関する基礎知識
　・レジスタマシンとスタックマシン
　・バイトコードの基本
・言語におけるVMの意義とメリット
・PHPのZend VMに触れてみよう
・Zend VM互換のVMを自作してみた（？）

皆さんのコードは捨てやすい設計になっていますでしょうか？
現在私がリードを勤めているチームでは派生元となったチームの思想を引き継ぎ、「捨てやすい設計」を意識して開発を行なっています

でも捨てやすいって一体どういうことなんでしょうか？

このトークでは実際の開発現場で我々が日々取り組んでいることをお話しするとともに、
失敗したことによって再認識した「捨てやすさ」について実例やコード例を元に紹介します

このトークを聞いて「10分以内に機能を消せる状態」を一緒に目指していきましょう！