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

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

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

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

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

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

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

について紹介します。

あなたのPHPコードはif文の中にたくさんの条件を連ねて条件分岐していませんか？
可読性の下がりがちな条件分岐、実はもっと読みやすく・テストしやすくすることができるんです！
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に入門してみましょう

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

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

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

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

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

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

世の中にはさまざまなプログラミング言語があり、それぞれさまざまな分類方法があります。

オブジェクト指向プログラミング、関数型プログラミングのようなプログラミングのスタイルは「パラダイム」と呼ばれ、言語ごとのプログラムの世界観となるものです。これらの言語やパラダイムは独自に発展するだけではなく、互いに影響を与え合いながら発展を続けてきました。PHPも例外ではなく、30年前の誕生時から同じ「PHP」と呼ばれていても、そのソースコードは似ても似つかないものに変化しています。

特に2000年代以降は「関数型」と呼ばれる概念がPHPをはじめ、さまざまな言語に浸透してきましたが、その概念を育んできた関数プログラミング言語と、PHPで実現できる関数型プログラミングは同等のものなのでしょうか。

本トークではプログラミング言語にまつわるさまざまなトピックを紹介し、PHPの作者はそこまで考えていなかったであろうPHPの正体を丸裸にしていきます。

• PHPの構文の基礎
• プログラミング意味論について
• 型システムについて

Quine とは、自分自身のソースコードと一致する文字列を出力するようなプログラムのことです。
PHP なら、

$ php a.php > output.txt

と実行したとき、output.txt と a.php が完全に一致するような a.php を「Quine」と呼びます。
一見すると不可能にすら思えますが、実のところほとんどの言語で簡単に書くことができます。

この記事では、基本的な Quine の書き方をいくつか説明した後、それを応用して更に面白い挙動をする Quine を書く方法について紹介します。

話すこと

• Quine とは
• Quine の作り方
• 応用 Quine
  • Quine アスキーアート
  • 変化する Quine

<?eval($s='printf("<?eval(\$s=%c%s%c);\n",39,$s,39);');

Observabilityにおけるアプリケーションのパフォーマンス監視において、APM（Application Performance Monitoring）は不可欠な存在です。
しかし、これらのツールが「内部でどのように動作しているか?」を理解している開発者は多くありません。

本セッションでは、OpenTelemetry PHP SDKを使用して、シンプルなAPMツールをゼロから自作します。
トレース、メトリクス、ログの3つのシグナルを収集・可視化する過程を通じて、APMの仕組みとOpenTelemetryの設計思想を深く理解することを目指します。商用のAPMツールを「なんとなく使っている」状態から、「仕組みを理解して使いこなす」状態へステップアップしていきましょう!

【セッションの対象者】
・APMを使っているが仕組みを理解したいエンジニア
・Observabilityに興味があるエンジニア

【このセッションで得られること】
APMが内部で何をしているか?の理解
OpenTelemetry SDKの活用方法について

本セッションでは、「大量のショップが同時刻にセール予約をすると開始遅延や未開始が発生する」という課題に対して、「計測→可視化→ボトルネック特定→個別改善→再計測」というループを元にパフォーマンスの改善をした実践を共有します。

まず New Relic のダッシュボードでCPU・レイテンシ・処理件数を可視化し、遅延要因を特定しました。打ち手は、SNS Publish のバルク化、Active Record での N+1 の一部処理の切り出し、重いセールグループを処理するプロセスごとの負荷の平準化などです。

この改善を実施したことにより、開発環境でおおむね 40% の速度改善に成功。2025年のブラックフライデーでも 10 万商品のセールをインシデントなく完了しました。

ユーザーが直面しているペインを解消するために、技術でプロダクトを泥臭く改善する大切さと華々しい成果だけではなく、根本解決のためにはまだやれることがあるという現場のリアルもお伝えします。

ISUCONをご存知ですか？「いい感じにスピードアップコンテスト」の略で、Webサービスの性能向上を競う技術イベントです。インフラ、アプリケーション、データベースと幅広いスキルが求められ、参加者からは「難しいけど楽しい」という声をよく聞きます。

私もISUCONに興味を持ちながらも、「自分にできるだろうか？」と二の足を踏んでいました。そこで思いついたのが「社内ISUCON」の開催です。本家に挑戦する前に、まずは社内で仲間を集め、一緒にスキルアップしようという作戦です。

本トークでは、社内ISUCONを企画・準備・運営した経験から得たノウハウをお伝えします。

【お話しする内容】
・なぜ社内ISUCONを開催しようと思ったのか
・問題の選定・環境構築のポイント
・参加者募集と当日運営で気をつけたこと
・開催してみて得られた学びと反省点
・次のステップ：本家ISUCONへの挑戦に向けて

このトークが、皆さんの職場でも社内ISUCONを開催するきっかけになれば嬉しいです。

※注意：本プロポーザル提出時点では、社内ISUCONは企画・準備段階です。登壇時には実施完了予定ですが、進捗状況により共有できる内容の範囲が変わる可能性があります。
現時点でスケジュール、取り組む課題までが決まっています。

本トークでは、経営学のノウハウをいくつか取り上げ、エンジニアの実務でどう活かせるか、具体的なシーンとともに紹介します。

私はCTOになったことをきっかけに、約1年前からMBA（経営学修士）プログラムで学んでいます。
現在はCTOを退任しましたが、今も続けています。
単純に「便利だ」と実感しているからです。

学んでみて気づいたのは、エンジニアリングと経営学のアプローチが似ているということでした。
問題を構造化し、制約の中で最適解を探し、仮説を立てて検証する。
フレームワークで思考を整理し、他者と共有可能にする。
違いは明確な答えがあるかないかです。
エンジニアにとって経営学は馴染みやすく、実務へ接続も難しくありません。

具体的な効果を挙げると、たとえば経営会議では、なぜ経営陣がそのような判断をするのか、その思考プロセスを理解できるようになりました。
また、メンバーとの1on1やメンバーが上程する際のフォローも理論を背景にして行えます。
よりエンジニアリングの文脈であれば、ドメイン駆動設計のサブドメイン等に対する解像度、技術的負債の返済優先度、イノベーションの進め方などのエンジニアリングの判断にもビジネス視点が自然と入るようになりました。
私個人の話でいえば、クリティカルシンキングやファシリテーション、ネゴシエーション等の知識は、レビュー、設計議論、ステークホルダーとの調整等、さまざまな場面に直結するスキルで、もっと早く知りたかったと感じています。

トークの中で紹介するノウハウは、MBAプログラムに通わずとも関連書物を紐解けば習得・活用できるものです。
エンジニアと経営学、その共通点から学びやすさを、そして活用法から相性のよさを感じていただき、皆様のキャリアを広げる新たな要素にしていただけることを目指します。

divだけあればフロントなんてちょちょいのちょいですが、意味のあるHTML書いてみませんか？

AIが発展してきている今、あなたのサイトで情報を得ているのは人間だけじゃなくなっています。
divだけで構築されたサイトはAIが正しく認識できない可能性もあります。

意味のあるHTML（セマンティックHTML）をおさらいして、AIにも人間にも優しいwebサイトを目指してみましょう！

2015年、PHPコミュニティは内戦状態でした。Scalar Type Declarations RFCは、賛成108票、反対48票という異常な投票数を記録し、厳密派と寛容派が激しく対立しました。なぜ最終的にstrict_typesは「ファイル単位のオプトイン」になったのでしょうか。

背景には、PHP 5.4で削除されたmagic_quotesの苦い教訓がありました。php.iniの設定次第で同じコードが環境によって異なる動作をし、SQLインジェクション脆弱性を生む原因となった経験から、PHPは環境依存の設定を避ける方向に舵を切りました。さらに、Composerエコシステムとの共存も不可欠でした。もしグローバル設定が可能だったら、vendorディレクトリ以下の数百のパッケージが想定外の動作モードを強制され、エコシステム全体が壊れる可能性がありました。

この設計は「漸進的型付け」という学術的アプローチに基づき、後方互換性、エコシステムの安定性、開発者の選択の自由を守りました。「全部ONにすべきか」という問いへの答えは、あなたのプロジェクトが決めることです。Whyを知るとHowの判断が変わります。