チームに途中参加し、初見のアプリケーションを前にして「これ、どこから読めばいいんだろう」と立ち止まった経験はありませんか？

私は、技術サポートという仕事柄、すでに稼働している PHP アプリケーションに関わる機会があります。
中には長い歴史を持ち、コード量も多く、当時の設計意図がドキュメントとして残されていないケースもあります。

現場に入ると、こうしたアプリケーションをキャッチアップしていくのですが、
その様子を見ているメンバーの方から「どのようにキャッチアップすれば良いですか？」という質問を受けることがしばしばあります。

重要なポイントを一つ挙げるなら、すべてを理解するのではなく、必要となる箇所を効率よく把握することです。

本セッションでは、特に日々既存のアプリケーションのキャッチアップに課題を感じている若手の方に向けて、
私自身が実際に意識している考え方や、見るポイント、活用している手段などを具体的にご紹介します。

チームで既存アプリケーションの知識をシェアする方法を模索されている方にも言語化のヒントとして持ち帰っていただけると嬉しいです。

PHP アプリケーション開発において、Xdebug + IDE によるデバッグ実行を利用している方も多いでしょう。

ブレイクポイントを設定して、そこでアプリケーション実行を停止し、変数の内容を見ながらステップ実行で処理を追いかけていく作業はアプリケーションを理解する上で大いに役立つものです。

一方、便利そうな機能だと認識していても設定につまづいて敬遠している方もいるかもしれません。
デバッグ設定では、PHP(Xdebug) と IDE 双方の設定が必要であり、さらに昨今では PHP(Xdebug) は Docker コンテナで実行しているケースも多いので設定に難しさを感じる場面もあるかもしれません。

デバッグ実行は、Xdebug と IDE の間で行われる通信によって成り立っています。
この通信がどのように行われているか、またそれぞれの役割を知ることで設定のどこでつまづいているかを理解しやすくなります。

なにより、日頃便利に使っている機能がどのような仕組みで実現されているかを知ることは楽しいものです！

本セッションでは、Xdebug の内部動作や IDE との通信に焦点を当てて、どのような仕組みでデバッグ実行が実現しているかを見てみましょう。

PHPはZend VMの上で動いており、すべてのPHPプログラムはそのopcodeに変換され実行されます。
本発表では、そのopcodeを眺めてみて、他の言語処理系との違いについてご紹介します。
発表者はいくつか仮想マシンを作ったことがあり、とくにRubyの仮想マシンについてちょっと詳しいので、そういった観点でご紹介できればと思います。
参加者の皆様には、他の言語処理系との比較を通じて、Zend VMの独自性や利点を理解していただければと思います。

クラウドインフラコストを成果報酬型で削減してきたDELTAが新たにPHP/Rubyを第一弾としてバージョンアップの代行を始めました。
コンセプトとしては生成AIを活用して、半自動的にVersionUpができる状態を目指していますが、サービス黎明期の今は1プロジェクトずつ、手作業で泥臭く調査や検証、実行を重ねています。
今回は数あるプロジェクトの中でも、CakePHPの2系を最新バージョンまでアップデートする道のりについて語ります

取り上げる内容

• バージョンアップにおける生成AIの利用方法
• テストのカバレッジが低いアプリケーションのバージョンアップ方法
• (特に)Cake2からCake3へのバージョンアップ時の変更点の多さ
• Cakeのドキュメントのあいまいさと突破した方法
• AIを使って効率化（PRの高速化）を果たしてもレビューで詰まってしまい、プロジェクト自体のアウトカム生産性が高まらない際に実施した方法
• お客さんへ新しいバージョンのお作法やメソッドの変更などの共有

想定

• PHPで構成されたアプリケーションを開発しているエンジニア
• バージョンアップに向き合っている / まだ機会に遭遇していないが、具体実例から準備すべきこと・事前検討すべきことに興味関心がある方

OSS コントリビュートに憧れつつも、「何から始めればいいのか分からない」「英語やお作法が不安」と感じ、なかなか一歩を踏み出せずにいました。
そんな中、「AI とともにならコントリビュートできるのでは？」という考えが思い浮かび、実際にやってみた結果、見事コントリビュートを果たしました！

本トークでは、「AIを相棒に3日間でOSSにコントリビュートする」という挑戦についてお話しします。
AIを活用することで、心理的・技術的なハードルがどのように下がったのかを具体的に共有します。

OSS に貢献してみたいけれど踏み出せていない方の、最初の一歩を後押しする LT です。

レビューでつい「なんでこうしたの？」などと質問して、責める意図はないものの空気が気まずくなった経験はありませんか？
このLTでは、心理学をもとにした質問の技術を活用し、レビューを詰問ではなく「対話」に変えるためのヒントをお届けします。

「意図を引き出す」「気づきをもたらす」といった観点から、よくあるNG質問の言い換え例や、相手が話しやすくなる質問の工夫を紹介します。

• 話すこと
  • 相手を詰めずに意図を引き出す質問の例
  • NGな質問表現の言い換え例
• 話さないこと
  • レビューすべき観点そのもの

レビューの空気を気にする方に届いてほしい内容です。
少し変えるだけで大きく変わる質問の仕方を一緒に見てみませんか？？

Infrastructure as Code（IaC）とは、インフラ構築をコードや設定ファイルで定義し、再現性や自動化を実現するプラクティスです。IaC によって運用コストの削減やヒューマンエラーの防止といったメリットを得られる一方、導入初期の教育コストや特定メンバーへの依存といった課題も指摘されています。

私たちの組織では、2023年9月に既存サービスの稼働環境を見直した際に、AWS CloudFormation を用いて IaC を導入しました。導入からおよそ2年が経った現在も保守運用しています。

本セッションでは、はじめに IaC に関しての一般的な考え方やメリット・デメリットを解説します。続いて、私たちのチームでの導入に際しての実践内容や切り替えてからの運用の経過について共有します。最後に、IaC を導入してからのチームでの工夫や出てきた課題について紹介します。

IaC 導入での課題を感じられている方だけでなく、IaC 未導入の方や馴染みのない方にも、私たちの実体験から得た知見がヒントとなれば幸いです。

LaravelのQueueは便利ですが、Queueワーカーが裏でどのように動いているのかを知らない人も多いと思います。

ワーカーが内部で何をしているかが分かると、詰まり・遅延・失敗の原因に当たりを付けやすくなり、運用やデバッグがしやすくなります。

このトークでは、ライブコーディングを中心に、LaravelのQueueワーカーをゼロから（ただし必要最小限に簡素化して）実装しながら、php artisan queue:work が実際に何をしているのかを順番に解説します。

「Queueは使っているけれど中身はよく分からない」という人が、処理の流れを自分の言葉で説明でき、トラブル時に切り分けの視点を持てるようになることがゴールです。

近年、量子コンピュータの実用化に向けた開発が急速に進展しています。
その一方で、量子コンピュータの進化はRSAや楕円曲線暗号といった公開鍵暗号技術の危殆化を意味します。

これに対抗する技術が「耐量子計算機暗号（Post-Quantum Cryptography: PQC）」です。

2024年8月、NIST（米国国立標準技術研究所）は長年の選定プロジェクトを経て、PQCの最初の標準規格（FIPS 203, 204, 205）を正式に発表しました。日本国内でも政府機関が2035年への移行目標を掲げるなど、PQCは実装・運用のフェーズへと大きくシフトしています。

本セッションでは、PQCの基礎知識から、その中心技術である「格子暗号」の仕組みや特徴にフォーカスして解説します。 さらに、AWS、Google Cloud、Azureといった主要クラウドベンダーの対応状況や、PHPエコシステムにおけるPQCの対応状況についても取り上げます。

今すぐにコードを書き換える必要はないですが、PQCは近い将来には当たり前となる技術です。このトークをきっかけに興味を持ってもらえれば幸いです。

【トークのアジェンダ】
・PQCの現状
　　・量子コンピュータの脅威（ショアのアルゴリズム）とHNDL攻撃（Harvest Now, Decrypt Later）のリスク
　　・NIST標準化（FIPS 203, 204, 205）について
・PQC（とくに格子暗号）の特徴について
　　・主要なPQCの紹介（格子暗号、同種写像暗号、符号ベース暗号、多変数多項式暗号、暗号学的ハッシュ関数）
　　・格子暗号の簡単な仕組みや特徴
・各クラウドベンダーやPHPでの対応状況
　　・AWS、Microsoft Azure、Google Cloud の状況
　　・PHP での検討状況

基本的な情報

私たちのプロジェクトでは、Lumen FrameworkとCodeception / Specifyを採用していましたが
Codeception / Specify の更新が終了してしまいました。
移行先は pestphp を検討していましたが、１万を超えるテストケースを具体的にどうやって移行するのかが課題になっていました。

これらに、この１年でどう立ち向かったのか、どのように方針転換をしたのかをお話しします。

お品書き / 得られること

• codeception / specify についての簡単な説明
• 終わりの始まり：テスト用フレームワークの EOL
• Pest への移行
• Rector による置換の試みとその問題点
• 技術の進歩 Agent Skills という光
• まとめ

概要

Laravel Octaneは、Laravelアプリケーションを更に高速化させるためのパッケージです。
SwooleやRoadRunnerに加え、Caddy WebサーバーやFrankenPHPもサポートされ、モダンな構成が容易に導入できるようになりました。
しかし、単に「導入すれば速くなる」という理解だけでは、メモリリークやステート汚染といった、便利さの裏に隠されている落とし穴にハマってしまうかもしれません。
本セッションでは、特にLaravel OctaneのFrankenPHPドライバにフォーカスし、
octane:frankenphp コマンドが実行されたその裏側で何が起きているのか、ソースコードレベルで内部実装を紐解いていきます。

話すこと

1. ZTS（Zend Thread Safety）とワーカープロセス
   GoルーチンとPHPスレッドの連携
2. Bootstrapとリクエストのライフサイクル
   アプリの起動とリクエストごとのクリーンアップ処理
3. Octane Cache / Tables の実装と制約
   スレッド間共有メモリの仕組み
4. Octane導入によるパフォーマンス検証
   導入前後でのベンチマーク比較

できるエンジニアは高額の報酬をもらって当たり前、と思っていませんか。
エンジニアは能力の差が大きいので、報酬の幅も大きいと言われています。
ところで、「能力」とは何でしょうか。技術力？本当にそれだけでしょうか。

本トークでは、一般的に受け入れられている能力主義の考え方を批判的に見直し、
概論にとどまらず、現在エンジニアが置かれている状況を整理していきます。
その上で、エンジニアとそのチームにとってより好ましい考え方、ふるまい方を探求します。

気が付けばいつの間にか「能力」にとらわれすぎていませんか。
新たな視点を提供することで、すこしでも解きほぐすお手伝いができたらうれしいです。

「i18n」や「k8s」など、長い英単語を数字で省略する語をヌメロニム（数略語）と言います。

PHP の標準関数でも当たり前の様に使われているヌメロニム。Web 開発者であれば毎日のようにどこかで目にするこれらの言葉ですが、いつの間にか自分の知らないヌメロニムが当たり前のように使われていたり、その意味を理解したつもりが雰囲気だけで使っている……そんなことはありませんか？

この LT では我々PHP開発者の身の回りに溢れるヌメロニムをクイズ形式で出題しつつ、その意味をちょっとだけ深掘りしていきます。

あなたも今日からヌメロニムマスター！

あなたの担当するプロジェクト、変更が難しい「モンスター」になっていませんか？

機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、オブジェクト指向設計の基礎であるSOLID原則への理解不足や誤解にあるかもしれません。

SOLID原則はソフトウェア開発において高品質で保守性の高いコードを書くための重要なガイドラインですが、やたら難しい言葉が並んでいるせいで理解が難しかったり、誤解が広まってしまっている面があります。

本トークでは、SOLID 原則に含まれる下記の5つの原則について、アンチパターンやPHP での実践的な例を交えながら解説し、その活用方法や得られるメリットについてお話しします。

• 単一責任の原則
• 開放閉鎖の原則
• リスコフの置換原則
• インターフェース分離の原則
• 依存性逆転の原則

このトークを聞けば、難しかったSOLID原則が「いつでも使える便利な武器」へと変わり、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

こんな人に向けて話します

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則、聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていない人
• SOLID 原則、理解しているけどどこまでやればいいのか悩んでいる人

deptrac、便利ですよね。
設定ファイルを書いて実行するだけで、アーキテクチャのルール違反を検出してくれる。神ツール。

内部では、一体どんなことが起きているのでしょうか？
考えてみると、私はdeptracのことを何も分かっていなかった──
依存関係をどう収集しているのか。グラフとしてどう表現しているのか。ルールチェックはどうやって…？
「こういう情報を集めて、上手く使っているんだろうな」と想像してみても、実装方法まではピンと来ません。

そして思ったのです。
自分で読んで作って、動かしてみよう！
そうすれば納得感が増すに違いありません。

今の時代、知らないコードを読むのにAIの力を借りないなんて、 嘘 ですよね！
少し前なら「読み解くハードルが高いぞ…」と感じていたものも、挑戦しやすくなりました。
今回は、その力を存分に借りながら、
「どういう技術要素が詰まっているのか」「どういう流れで処理していくのか」をひも解いて、
「deptracもどき」を動かすところまで進めます。

やること

• ステップバイステップで「コードリーディングと小さなコードの実装」を進める
  • 「中身を読む〜動かしてみる」までを、40分で追体験できるように
• deptracの基本的な機能（＝「依存先の解決」と「ルールチェック」）の実装

お届けすること

• 「実際にこんな感じでコードリーディングを進める」という雰囲気
• deptracの内部実装についての知識
• 自分にもできそうだな！という気配

対象者

• コーディング用AIを使いながら、複雑なコードを読むことにチャレンジしてみたい方
• 「雑に作って学ぶ」方式の勉強法が好き、または興味のある方

とあるカンファレンスの廊下で、こんな会話が聞こえてきました。
「その◯◯ライブラリは、コンストラクタを通さないでインスタンス化しているんですよ」

決してテスト用のライブラリでもなく、メタプログラミング用のユーティリティでもなく、
Doctrine ORMの話です。
Entityとして定義したクラスを用いて、DBから取得したデータを元にオブジェクトを作る時、コンストラクタを通さないのです。

私自身、過去にその挙動を知らずにハマってしまった事もありました。
しかし、よくよく考えてみると、
「EntityはORMから独立して存在できるようにする」世界観と、
「DBのカラムとPHPオブジェクトのプロパティのマッピングは、Attiribute等の情報で管理する」作法によって、
Doctrineは「コンストラクタを、ユーザーが自由にできる土地として解放する」という強力なパワーを授けているようにも感じます。

「どんな場面で、こんな設計思想が”アリ”になるのだろうか」を考えてみると、面白いのではないでしょうか。

このLTでは、
「そもそも、どんな技術で”コンストラクタを使わないインスタンス化”を実現しているのか」
「その方法が、何をもたらすのか」
について、考えを共有します。

「新しいクラスやメソッドが定義されたから、旧い方は廃止していきます！」
そんな時に、”Deprecated"を示しますよね。

PHPを使っていく上で、いくつかの方法があります。
「どうやって廃止したいか」によって、その良し悪しが変わるでしょう。
そう考えると、使える武器を整理して増やしておくのは、役に立つかも知れません。

このLTで、複数の”Deprecated"(&& ちょっと違うけど「禁止」をする)の術を紹介します

1. PHPDocの @deprecated tag
2. trigger_error / E_USER_DEPRECATED
3. \Deprecated アトリビュート
4. phpstan-deprecation-rules
5. class_alias と1〜2を組み合わせて新クラスへの移行を促すやつ
6. PHPUnitで --fail-on-deprecation を使う
7. disable_functions

PHP-TUIというフレームワークがありまして、
まだ "currently a work-in-progress" と書かれている通り開発途上ではありますが、
実にワクワクします。

最近ではClaude Codeも普及したり、「TUIアプリ」に触れている時間が増えたな〜という方も多いのではないでしょうか？
「コマンドライン」ベースではなく、ターミナル上に“画面UI”を作って、カーソルで操作したりするようなアプリです。
PHP-TUIは、そんな感じのやつを作るのを助けてくれます ───しかも、PHPで書ける！！！

遊んでみたくなりますよね？
PHPといえばComposerということで、「Composerを使うためのフロントエンド」なんていかがでしょうか。
「パッケージの一覧」メニューがあり、説明やインストール状況を簡単に確認できる。
Composerコマンドより直感的で、IDE等を起動するよりも手軽な、そんなTUIアプリを想像してください。

このLTでは、技術的な詳細はさておき、
フレームワークを理解するための概要(登場人物の紹介程度)を押さえつつ、
「実際にはどんな感じなのか」をデモ中心でお伝えします。

Rector、いい感じで強力なPHPのリファクタリングツールです。
「好きなルールで、めちゃくちゃコードを書き換えられる！！」という経験は、味わうと夢のような心地がします。

素晴らしいのは、「単なる置換では出来ない」もしくは「人知を超えた正規表現でも難しそう」な一括自動修正を、
十分に人間が理解可能なルール記述で サクサクと実現してくれることでしょう。

なぜ、そんな事が可能なのでしょうか？その裏にあるのは、テクノロジーです。
コードを「木構造(AST)」として解釈して、様々な「ルール」を適用していくことで、
置換対象の検出と置換の実行を進めます。

そこで役立つのが Visitorパターン です。
「木」という複雑な繋がりを渡り歩き、1つ1つの「地点」で外から与えられたロジックを適用していきます。
こうした作りが、「適用対象の構造自体や、渡り歩き方の実装には全く手を加えず、ただルールを付け外しできる」という拡張性をもたらします。

このトークでは、
「Rectorって凄いな、面白いな！」というワクワクと、
「ドンピシャでデザインパターンがハマると、こんなに気持ち良いのだな！」というドキドキをお届けします。

話すこと

• ごくごく簡単に「ASTってなんだ」
• Rectorの使い方、できること
• Visitorパターンの概要
• 上記を踏まえた「なぜRectorでVisitorパターンなのか」

想定対象

• Rectorってなんだろう？を知りたい人
• 「Visitorパターンが嬉しい場面」を見届けてみたい人

あなた自身やチームメンバーは、スーパーマンのように頼られる「ヒーロー」になっていませんか？

ここでいうヒーローとは、相談すれば即座に経験に裏打ちされた的確な答えが返ってきて、実装を頼めばすぐに動くものを出してくれ、トラブル時には主導的に解決してくれる、とても頼りになる存在です。
チームメンバーにとってヒーローは心強く、ヒーロー自身も周囲から認められ、頼られることで、気持ちよく働きがいを感じているでしょう。

しかし一方で、その振る舞いが、経験や学びをチームに蓄積させず、他者の成長機会を奪ってしまってはいないでしょうか。

人は「早く終わらせたい」という合理的な理由から、知っていそうな人、つまりヒーローに仕事を集めてしまいます。
その結果、チームとしての経験はヒーロー個人に集中し、ヒーローは指数関数的に成長していく一方で、他のメンバーは十分な経験を得られず、成長が阻害されていきます。

さらに、ヒーローはますます忙しくなり、周囲のマインドも「助けてもらって申し訳ない」から、やがて「いつもみたいに助けてくれるよね」へと変化していきます。
その過程で、自ら考えて学ぼうとする意欲は少しずつ失われていきます。
最終的に待っているのは、チームとしての衰弱です。

本トークでは、持続的なチームを構築するために「ヒーローをやめ、リーダーシップを始める」ための具体的なアプローチとして、

• チームのマインドをどのように変えていくか
• ヒーロー個人の知を、どのようにチームの知へ移転していくか
• その変化を進めるうえでのマネジメント層へのアプローチ

について紹介します。