プロポーザル

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

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

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

「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パターンが嬉しい場面」を見届けてみたい人

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

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

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

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

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

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

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

について紹介します。

あなたのPHPコードはif文の中にたくさんの条件を連ねて条件分岐していませんか？コメントを書いておかないと何の条件分岐かわからなくなっていませんか？
可読性の下がりがちな条件分岐、実はもっと読みやすく・テストしやすくすることができるんです！
Specificationパターンを使うことで、条件分岐に人間可読な名前をつけることができます。名前をつけるだけで、人間は物事を認識しやすくなりますし、覚えやすくなります。
まず名付けの大切さを日常生活や簡単なPHPコードの事例から解説し、その後にSpecificationパターンを使った実装・リファクタの実例をサンプルコードを共有しながら紹介します。

__get() 経由で読み取り可能な protected プロパティに対し、外部から empty() を使用した際、値が存在するにも関わらず true (空) が返ってくる現象に遭遇しました。

「直接アクセスでは値が取れるのに、なぜ empty() は空と判定するのか？」

調査の結果、原因は empty() 関数の内部仕様にありました。
empty() はアクセス不能プロパティに対し、いきなり get() で値を取りに行くのではなく、まず isset() で存在確認を行います。
ここで __isset() が未定義だと、問答無用で「存在しない＝空」と判断されていたのです。

本LTでは、この意外なハマりポイントの解説と、get() を使うなら必ず isset() も実装すべきという「お作法」について、実例を交えて共有します。

※PHP7.4のお話です。
8.1以降なら public readonly でプロパティを定義すれば __get() とか使わなくて良いはずですが、実際には8.1まで上げられていないプロジェクトもあると思うので…。

PHP8.0からFiberという機能が追加されました。

基本的にPHPは同期処理を扱いますが、Fiberという機能を使うことで非同期処理的なことを扱うことができます。
そんなFiberについて、皆さんと共有できればと思います。

皆さんDatabaseのIndexはよく業務でも利用していると思います。
ただ、そのIndex、前任者やAI Agentが付けているからとあまり考えずに設定していたりしていませんか？

本トークではMySQLおよびPostgreSQLに絞って、インデックスの付き方やよくあるIndexの間違いなどを皆さんと共有できればと思います。

本トークで話す内容
・採用されているIndexについて
・インデックスの種類について
・よくあるインデックスの間違い

本トークの対象者
・Databaseのインデックスを雰囲気で触れている方や知らない人

一般にフレームワークは「便利なツール」として捉えられますが、設計者の視点では、フレームワークの本質は「設計原則にしたがった制約（Constraint）」です。

本セッションでは、登壇者が設計・実装してきた複数のフレームワーク（AOP, DI, REST, 独自ドメイン基盤など）を題材に、これらを「アプリケーション制約」としてどのように機能するか、その効能を考察します。

具体的には以下の3つの視点から「制約」を紐解きます。

依存と関心の制約（DI/AOP）： コードの構造を縛ることで、変更耐性とテスト容易性をどう担保するか。

Web標準の制約（HTTP/REST）： アーキテクチャを標準に準拠させることで、キャッシュやスケーラビリティをどう「自動的」に獲得するか。

ドメインの制約（Temporal Model）： ドメインを静的なデータではなく「時間的変化」として制約することで、AI生成時代におけるモデルの整合性をどう保証するか。

特に、AIによるコード生成が当たり前になる時代において、「何（How）をAIに任せ、何（What）を人間が厳格に定義すべきか」の境界線は、この「制約の設計」にあります。

情報設計（ALPS）から実装へと段階的に制約を与えていく手法を例に、自律的なソフトウェアを構築するための指針を提示します。結論はシンプルです。

「どうでもいいことは流行に従い、重大なことは標準に従い、ドメインのことは自らドメインフレームワークを設計し実装する」

ソフトウェア工学70年の歴史で、我々は三つの主要パラダイムを経験しました。命令型（How）は手順を、オブジェクト指向（Who）は主体を、関数型（What）は計算内容を問いました。本講演では第四のパラダイム「存在論的プログラミング（Whether）」を提唱します。

従来のプログラミングはDOING（何をするか）に着目します：

$user->validate();
$user->save();
$user->notify();

対して本手法はBEING（何であるか）に着目します：

$rawData = new UserInput($_POST);
$validatedUser = new ValidatedUser($rawData);
$savedUser = new SavedUser($validatedUser);

動作を指示するのではなく、オブジェクトが「どう変容するか」を表現するのです。

『時間と存在は分割できない』——アインシュタインが時空の不可分性を説いたように、我々は「時間とドメインの不可分性」を基礎とします。メソッドを持たず、コンストラクタのみを持つそのオブジェクトは、内在（イマナンス）と超越（トランセンデンス）の出会いにより、時間の中で変態（メタモルフォーシス）し、時間的存在として自立します。

「さっぱり、何のことか分からない」と感じましたか？ しかし、その違和感はかつて60年代のアセンブラ利用者が初めてOOPに触れた時の衝撃と同じで、これが単なる方法論ではなくパラダイムシフトである証拠かもしれません。

70年間、我々は「より良い命令」を追求してきました。しかしAIが「命令（How）」を無限生成する今、人間が書くべきものは手順書ではなく「存在（BEING）の定義」です。

私たちは大きな時代の節目にいます。これまで半世紀以上にわたって続いてきたコーディングのあり方が、大きく変わろうとしています。AIによる開発支援は急速に高度化していますが、そのポテンシャルを最大限に引き出すための開発ワークフローやアーキテクチャには、まだ大きな進化の余地が残されています。 AIエージェントが本質的に力を発揮できる、開発ワークフローそのものの再設計が必要です。

本セッションでは、登壇者が開発してきた app-state-diagram（ALPS）, xdebug-mcp, SemanticLogger の3つのソフトウェアを通じて、AIエージェントと本質的に協働するための設計・実装手法「Semantic Build for Agents」を紹介します。

app-state-diagram（ALPS）はアプリケーションの語彙・構造・状態遷移をプロトコル非依存で定義し、設計時の意味を外部化します。xdebug-mcpは実行トレースやプロファイルといった実行時の事実をAIが直接扱える形で提供します。SemanticLoggerは intent→event→result を JSON Schema とリンクで表現し、なぜその結果になったのかを機械可読に証明します。

これらに共通するのは、人間向け説明ではなく スキーマ・ID・URIによって意味を運搬する設計思想です。本セッションでは、仕様・実装・実行結果をセマンティクスで接続するアーキテクチャと、その実践から得られた知見を共有します。

CIのテストに時間がかかって困る…
時間がかかっていそうなテストの修正や、XDebug無効化などの対策は試したが思ったように短くならない

そんな経験はないでしょうか？

闇雲にテストを修正するのはもう終わりです！

PHPUnitのフック機能を使って、個別のテストにかかっている時間を計測し、それに基づいた改善でテスト時間を約30パーセント削減した事例をお話します。

テストも「推測するな、計測せよ」で改善しましょう

プロダクト開発をしていて、他社のシステムを参考に作ることはないでしょうか？

そんな時、特許権について調べられているでしょうか？（特許権以外にも、実用新案権、意匠権、商標権、著作権などの権利もあります）

他社の特許権を侵害すると、自社製品の販売差し止めや損害賠償請求に発展する場合もあります。

一方で、特許は「発明の保護及び利用を図ることにより、発明を奨励し、もつて産業の発達に寄与することを目的とする」制度でもあります。

ビジネス・プロダクトを守りつつ、公開されている知識をプロダクト作りに活かすために、特許調査について知ってみませんか？

PHP 8.5で導入されたパイプ演算子（|>）、もう使っているでしょうか？

パイプ演算子を使うと、
strtoupper('hello')
と
'hello' |> strtoupper(...)
が同じ意味になります。

実は、例にあげた2つの式は、opcodeとしても同一です。

このトークでは、php-srcのソースコードを読み解きながら、パイプ演算子がどのように実装されているかを見ていきます。

具体的には以下の内容を扱います

• vldでのopcodeの比較
• opcodeのコンパイルに使われるzend_astとznode
• パイプ演算子を処理するzend_compile_pipe

PHPの新機能を通じてphp-srcに入門してみましょう

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

技術的負債の、「利率」にあたる部分は開発規模の増加によって見かけ上増える

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

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

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

会計の知識をインストールして、技術的負債というワードに輪郭を与えましょう。