配属されたPHPプロダクトは、次につくる機能が決まっていませんでした。

私が担当することになったプロダクトは、立ち上げ時に想定していた機能をつくりきった状態でした。
しかし、ビジネスチームのメンバは他のタスクに追われ、次の開発方向性をなかなか決められず、小さなバグ修正や軽微改善のタスクばかりが提案される危険がありました。
そのため、次の一手をビジネスチームと一緒に考えることになりました。しかし、今までの開発チームはビジネスサイドからの要求を実装することがメインの仕事であり、主体的に開発の方向性を考えられるようになるためには、開発フローやいくつか"仕掛け"が必要でした。

このトークでは、ビジネスチームに頼っていた開発チームを、主体的に動けるチームに変えるために行ったことについてお話しします。

「PHPってWebサーバー上で動くもの」——そんな常識をNativePHPは打ち破ります。
2025 年 4 月に正式リリースされた NativePHP for desktop について解説していきます。

Electron やTauri のようなクロスプラットフォームなデスクトップアプリが主流になる中、
私たちが普段使っている PHP でも実現できる時代が来ました。

NativePHP を使えば、PHP でデスクトップアプリが作れちゃうらしい！
そんな知らせを聞いて、手を動かさない PHPer はいない！
実際にデスクトップアプリを作成して、見えてきた魅力や気づき、課題について率直にお話しします。

Web の外へと飛び出した PHP の勇姿を、ぜひ見届けてください。
「PHP もまだまだやれる！」

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

この発表では、オニオンアーキテクチャによって仕様追加による改修が最小限に抑えられた事例について解説します。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

PHPに出会ってまもなく遭遇した奇妙なコード「$$」
まるで変数名が意思を持ち、少し不思議な動きを見せるその子は可変変数と呼ばれます。
本LTでは、可変変数について「変数名が踊り出す」とは一体どういうことなのか、PHP初心者の目線で簡単な例を通して、その基本的な仕組みを紐解きます。
便利な機能にも落とし穴はつきものです。可変変数を使うと、なぜコードが分かりにくくなってしまうのか、本当に使い所はないのか？について発表します！

対象者
・PHP初心者
・変数という概念は理解しているが、可変変数についてはまだ知らない方
・可変変数の使い所がわからない方

はじめに

PHPの最新版は8.4になり、かなり進化しました。7.0が出たのはすでに10年前。
巷ではモダンなフロントエンド技術が流行っており、PHPerは圧倒的な高齢化の一途を辿っています。
「うちの会社は割と若い人もいるよ！」と思ったそこのあなた。では一番コード書ける人、一番技術力ある人も同じく若い人たちですか？

10年前、第一線で活躍してた人が今もポジション変わらずの状態であればイエローサインです。
PHP界の高齢化を防ぎ、若手が育ちやすい“新陳代謝のある”文化をつくっていきましょう。

ちなみに私は過去COBOLのプログラマーを「おじいちゃんばっかりじゃん」と思っていた時期がありますがそんな自分を殴りたい。

話す内容

• PHPは素敵な言語
• 勉強会による間口を広げるご提案
  • 老害化の注意点
• 他言語とのコラボを狙う
  • 例えばSPAのフロントはJS、API側PHP、というご提案
• PHPの普及ではなくPHPで作られたものの普及を考えてみる
  • 言語の良さを説いても限界がある
  • 魅力的なPHP製品の良さを伝えて、メンテをする楽しさを伝えてみる。WordPressとかEC-CUBEとか

技術の話よりかはPHPerのコミュニケーションの話です。
意見も聞きたいので、みなさんにも意見を聞きながらセッションを進めて行きたいと思っています。
一緒に高齢化阻止の方法を考えましょう

こんな人は聞いてほしい

• PHPの良さを改めて知りたい人
• PHPの良さって何なんですか？と言われてアピりたいけど答えに詰まってしまう人
• 最近若い人減って来たなぁと嘆いてる人
• もっとPHPerを増やしたい人
• ↑のように思ってるのに若者にマウントを取ってしまう人

概要

時は2025年、AIエージェント元年と言われるこの世の中では「人よりもAIが仕事ができる」という噂が囁かれる事態となりました。
ですが、果たして本当にそうなのか。AIは人並みに仕事してくれるのか？我々のような老練のPHPerが立場を危うくするほど驚異的なものなのか？

本セッションでは、自律型AIエージェントプログラマー「Devin」について実際に使ってみた感触と、PJメンバーとしての有用性についてお話します。
今みなさんが気になってるホットなAIエージェントの話題をPHPer的な視点から掘り下げます。

トピックとしては以下です

• コードのクオリティーについて
• 仕様をどこまで理解してくれるのか
• Unit Testとかも書いてくれるの？
• リーダブルコードを考慮して書いてくれるのか
• PHPのVersionは考慮してくれるのか
• 結論、有用なのか否か

対象者

• PHPer
• AIに興味がある人
• AIに焦燥感を抱いてる人、大丈夫でしょうと高をくくってる人
• Devinについて情報収集してる人

得られるもの

• AIエージェントはどんな仕事をしてくれるのか
• AIエージェントへの指示（プロンプト）の効果的な与え方はどうすれば良いのか
• 自社で導入する時に評価できる・できないポイントがどこにあるか

私は今、受託開発の会社に勤めていますが、受託開発だと複数案件に関わることはあるあるだと思います。
ただ、参画したタイミングや状況により様々なポジションや開発言語で案件をかけもつことがあります。
時にはマネージャーとして管理を行い、時にはメンバーとして開発を行う。イレギュラーな事態は毎日発生し、考えていた進捗まで中々届かない。。
このLTはそんな中で自身を管理しつつ各案件をなるべく燃やさずに進めている方法をお話します。

対象者

• Laravelを使用している開発者（初級〜中級）
• コード品質向上に関心のあるPHPエンジニア
• 静的解析をこれから導入したいと考えているチーム

セッション概要

型エラーや未定義変数のアクセスなど、実行前にコードの問題を発見できる静的解析ツールは、モダンPHP開発の必須ツールとなっています。本LTでは、Laravel向け静的解析ツール「Larastan」の導入から実践的な活用方法までを5分間で簡潔に解説します。Eloquentモデルやファサードなど、Laravel特有の型安全性課題に対する解決策を中心に、明日から使える実践的なテクニックをお伝えします。

名前の似た機能の実装を集約して、複数のドメインと機能でテーブルとAPIを共有する。

この設計アイディアによって、弊社機能の立ち上げは部分的には加速しましたが、サービスの成長に伴い高いコストをもたらしました。
この設計アイディアを社内では「汎用テーブル・API」と呼んでいます。

本トークでは、「汎用テーブル・API」がどのようなコストをもたらしたか、ドメインと機能の境界に沿ってテーブルとAPIを分割するまでの道のりを具体例を交えてお話しします。

以下の内容をお話しします。

• 「汎用テーブル・API」とは何か、どのようなコストを発生させているか
• ドメインと機能の境界に沿って分割するまでの具体的な手順

対象者:

• バックエンドの技術負債に向き合っている方
• DBテーブルのデータ移行に興味のある方

DB負荷問題に直面した時、インデックス、クエリチューニング、キャッシュ… 私たちは反射的に技術的な解決策を探しがちです。
しかし、本LTでは「ちょっと待ってください！その負荷、本当に技術だけで解決すべき問題ですか？」と問いかけます。
私たちがアプリのタイムライン機能で経験した、深刻なDB負荷との戦い。
そこで見出したのは、技術的な複雑化に頼るのではなく、「仕様そのものを見直す」という、シンプルかつ強力な解決策でした。

本トークでは以下の内容をお話します

• なぜ私たちが技術的対策の前に「仕様変更」に踏み切ったのか
• その結果、いかにDB負荷を劇的に削減できたのか（嬉しいことにUXも向上しました！）
• 仕様変更という負荷対策のアプローチについて

対象者:

• DB負荷をはじめとするパフォーマンス問題に悩むWebアプリケーションエンジニア
• 要件定義や仕様策定の段階からパフォーマンスを意識したい方
• プロダクトの持続可能性とユーザー体験の両立を目指すプロダクトマネージャー

DB負荷対策の引き出しに、技術的アプローチと並ぶ選択肢として「仕様変更」を加えることの有効性を、具体的な事例と共にご紹介します。

いまやPHPの根幹を成すComposer

意外と「なんとなく」使ってる方もいらっしゃるのではないでしょうか？
そんな方々に、「Composerの仕組みもバッチリ知ってるよ！」となって帰って頂ける内容をお話します。

1. なぜComposerを使うのか？
   ・「車輪の再発明」は絶対やめよう
   ・ 成熟したPHPコミュニティ、あなたが作ろうとしている機能、大体あるんです
   ・ 複雑な依存関係を理解しよう

2. Composerはどのような仕組みで動いているのか？
   ・ packagistとComposerの関係について
   ・ composer.jsonとcomposer.lockの役割について
   ・ autoloadの仕組み、説明できますか？
   ・ ライブラリのバージョン、理解してますか？

3. Composerは遅いのか？
   ・ プロジェクトにおいて、Composerを使わず、手動requireした方が速いのか？否。
   ・ 大規模プロジェクトでのComposerの最適化テクニック

4. どんなプログラムをパッケージとして頒布するべきか？
   ・ もう、プロジェクト間のコピペはやめよう

ブラックボックス的な印象の強いComposer、これを機に、仲良しになりましょう！

Agenda

1. What is DDD x Clean Architecture?
2. What kind of systems is it suitable for?
3. How was the actual implementation in Laravel?
   • What steps were taken to introduce it?
   • What kind of structure was used for the implementation?
   • Good points and bad points

※この資料の内容で話します！日本語版に直すのも可能です。
https://speakerdeck.com/bumptakayuki/laravel-x-clean-architecture

あなたのPHPコードはif文の中にたくさんの条件を連ねて条件分岐していませんか？
可読性の下がりがちな条件分岐、実はもっと読みやすく・テストしやすくすることができるんです！
Specificationパターンを使ったリファクタの実例をライトニングに紹介します。

PHPに限らず、プログラムは繰り返しても劣化しない正確さと速さが持ち味です。人間は繰り返すと集中力が落ち、集中力が落ちると正確さと速さが劣化しがちですよね。
私は素早く開発することを突き詰めた結果、定型的なPHPコードは自分で書くよりPHPに書かせた方が早いと考えるに至り、さまざまなコード自動生成を日々試してきました。
2025年、AI時代に入って、世間のPHPerの皆さんもコード生成を始めていると思いますが、単に自然言語でプロンプトを投げては生成ガチャを引くだけになっていませんか？
私は、作業ログを読み込ませたりコンテクストの与え方を工夫するよりも、AIとPHPを組み合わせて利用することで「退屈な仕事」はPHPに任せてガチャの範囲を狭め、より効率的にコード生成を行えるのではないか、という仮説に基づいて実験をしています。その結果を報告します。

PostgreSQLにはRow Level Securityがありますが、PHPを使った開発プロジェクトではほぼ使われていないのではないでしょうか。
Row Level Securityを使ってLaravelでアプリケーションを開発するにあたって、私はEloquent ORMとDoctrine ORM両方でコードを書いてみて、開発者体験を比較検討してDoctrineを選択しました。どういう判断でDoctrineを選んだか、2年半に渡って実際に開発に使ってみてどうなったかを共有します。

• Row Level Securityとはどんなものか
• EloquentでRow Level Securityを扱う方法の解説
• DoctrineでRow Level Securityを扱う方法の解説
• Eloquent vs Doctrine そして結論

「HowじゃなくてWhyで考えよう！」なんてセリフを良く聞きますね。
その一方で、設計について聞くと「○○設計を踏まえていて〜」と返答をもらうことも、しばしば。

ローカル変数の命名1つをとっても、フレームワークやインフラストラクチャの選定にしたって、
一気通貫の「なぜ設計をするのか」「どんなものが必要なのか」の考え方があるはずです。

それが「トレードオフを見極め、織り込み、決定する」ことです。
これこそが「設計行為である」という立場からトークをします。

抽象的で、広いスコープに届くような話を、なるべく具体的で卑近な例を取り上げながら説明していきます。

話すこと

「Why」としての設計

• ソフトウェア開発の最終目的である「品質」 = ユーザーにとっての価値実現
• 求めるべき品質を可能な限り摩擦ゼロで実装する支えが「設計」

取り上げる話題の例

• 「テストしやすくする」時に、何を天秤にかけているのか
• 「YAGNIだ、だからやめよう」は何を捨てているのか・拾っているのか
• ベテランに聞いてみました！ "「設計的な判断をする」時に、何を考えていますか？"

ソフトウェア開発をやっていると、実に様々な「○○駆動」に出会います。
ドメイン駆動、ユースケース駆動、テスト駆動・・・

開発や設計の進め方だったり、考え方だったりについては、「駆動」以外にも似たような単語がありますね。
オブジェクト指向などの「指向」、ユーザー志向などの「志向」、人間中心デザインなどの「中心」、モバイルファーストなどの「ファースト」、etc。

その中にあってTDDやDDDなどは、どうして「駆動/ドリブン」なのか？を考えたことがありますか。
一歩留まって考えると、ただ「○○を最初にやること」ではないはずだ、と気付くはずです。
私は、この言葉を使う時、中核には「フィードバックを得やすくする」「あるべき姿の探索を推進する」ための仕掛けである！という主張が眠っているものと捉えています。

更に一歩踏み込んで、「なぜ、そうした仕掛けが必要なのか？」も考えてみましょう。
その答えは、「人間として、プログラミングを少しでも楽にするため」だと私は捉えています。

複雑で難しい問題を解く時、「できるところから始める」と進みやすくなります。
高度で曖昧な問題に取り組む時、「間違いに気づいて修正ができる」と正解に近づきやすくなります。
つまり、「認知負荷がキャパシティを超えないようにチャンクする」「適切なタイミングでフィードバックを得る」「軌道修正をする」を組み合わせることで、人間の問題解決能力が高まるのです。
「○○駆動」とは、正にこうした「人間が進むための杖」となるべきものでしょう。

このトークで話すこと

• 色々な「○○駆動」は、人間に楽をさせるための道具である
• どうやって楽をするか？に向き合うことが、プログラミングの能力に磨きをかける

このトークで話さないこと

• 特定の「○○駆動」についての解説や宣伝

一般的に「理系の専門職」と言われるプログラミングのお仕事について、
「実は国語力がとても大事だ！」という主張。
皆さんも、しばしば耳にした事があるのではないでしょうか？

多くは、「文章や会話の中から、要求を掴む」「表現すべきことを、構造化して記述する」といった点についての言及です。
なぜ、これらを「国語力」というのでしょうか？
あるいは、他にも要素があるのでしょうか？

例えば、「大学入試科目・現代文」の解き方をトレーニングすることで、職業プログラマーが学べる事とは──
もし、必要な能力が身につくのであれば、取り入れていきたいですよね。

そんなチャレンジをしてみましょう。

やること

• 「現代文(主に入試現代文)」の参考書で、どんなことが述べられているかを調べる
• 実業務と照らし合わせて、関連しそうなケイパビリティを紐解く

聴き手に提供すること

• 改めて「業務で求められる能力(のいち側面)」について分析し、言語化する
• 得意な人には自覚的な「強み」として、苦手な人には「鍛え方」「着目ポイント」として、国語力について考える機会にする

Composerで「パッケージを入れる」とは何なのか？について考えてみてください。

• 多くのパッケージにおいて、その他の様々なパッケージへの依存を持っています。
• 単純なパッケージ名だけでなく、各々が要求し許容するバージョン指定の範囲も、実に様々です。
• そして、その「その他の様々なパッケージ」もまた、その他の様々なパッケージへの依存を持っています。

・・・一体どうやって、こんなに複雑な仕事を達成しているのでしょう？
このトークでは、2つの観点から「どんな工夫をしているか」を解剖していきます。

提供する主な話題

1. Composerが複雑な「パッケージの組み合わせ」を解くための手続きとは？
   1. 「Pool」の最適化とは？
   2. SAT Solver、 2-Watched Literal Schemaといった概念についてざっくりと
2. メモリ節約のためのPHP的な工夫
   1. 各所で活躍するSPLデータ構造や実装に見られる構造面での工夫、おもむろに現れるgc_disable() 等

このトークで得られる体験

• 普段使っているツールが内部で「どんなエレガントな問題解決をしているか」に触れる
• PHPアプリケーションのいて大量・複雑なデータを扱う上での生きた例を垣間見る

対象者・扱うこと

• Composerの基本的な使い方を理解している方の方が望ましいです
• Composer全体の仕組みやパッケージ取得方法についての詳しい解説は行いません
  • ピンポイントで「パッケージとバージョンをどうやって決定しているのか」の話になります
  • ツールとしてのComopserの便利さ・使い方を紹介するトークではありません
• 数学・計算機科学的な踏み込んだ解説は範疇外です

ライブコーディングで、"Composerもどき”を作成します。

モチベーション

PHP Conference Japan 2024では、Composerの主要な機能を模倣的に作ってみるワークショップを実施しました。
その内容は、いくつかの機能を取り上げて、その内部の要素を掻い摘みながら実装していく流れでした。

そして今回は、発表者が与えられた時間の”LIVE”実装を披露します。
ワークショップという形式の都合上、端折った部分・お見せ出来なかった部分も含めて、全てお話します。

テーマ

Composerの仕組みについての簡単な解説(実況)を交えつつ、実際に動くものをゼロから書いてきます。
目の間で出来上がっていく様を見届けることで、普段とは違った角度からの理解の手助けになるでしょう。

※ 「Composerの機能」「導入や運用」について紹介することを目的としたセッションではありません。

ライブコーディングの内容

require コマンドの機能をベースにします

1. 任意のパッケージの指定を受け取るCLI
2. パッケージ情報の取得(※今回はPackagist限定)
3. composer.json相当のファイルの作成
4. 間接的に依存しているパッケージの情報の取得
5. 各パッケージの依存の解決(※今回はplatformやext系の情報は無視)
6. composer.lock相当のファイルの作成
7. パッケージ本体の取得
8. パッケージのvendorへの配置
9. autoloaderの作成