トーク

「ハイコンテキスト」「ローコンテキスト」「言語間距離」。
これらは、日本語や英語といった自然言語を語る際によく用いられる言葉です。
言語が持つ"性格"を表す概念でもあります。

では、私たちのPHPはどうでしょうか。
文法があり、慣習があり、文脈によって意味が補われる。
PHPもまた言語である以上、「言語としての性格」を持っています。

近年、生成AIの普及によって、エンジニアの言語環境はより複雑になりました。
日本語で考え、英語を交えてPHPを書き、複数のAIと同時対話する。
このように異なる性格を持つ言語の行き来が、いまや日常となっています。

しかし、この切り替えは人間の脳にとって、時に無視できない認知負荷となります。
大AI時代となった今「以前より集中できない」「脳が疲れる」と感じる人が増えているのも、
この言語の切り替えによる負荷が、気付かないうちに積み重なっていることが原因かもしれません。

本セッションでは、技術選定や言語選定の是非は扱いません。
PHPを言語学の視点から捉え直し、AI時代の「脳疲れ」はどこから来るのか、
そして日々の思考を少し楽にする対策についてお話しします。

本セッションの対象者

• 最近なんとなく疲れや集中力の途切れを感じている人
• PHPをいつもとは少し違う視点で見てみたい人

"ジョシュアツリーの法則"を知ってますか？
「名前を知ればそれを認識できるようになる」「名前を知らないと認識できない」といった現象のことです。

我々エンジニアの身の回りには様々な現象があり、中にはみんなが経験したことがあるものも多数存在します。
そんな「現象」や「事象」の中にはあまりにも名前が付けられ、事象の解消や共有が行われているものがあります。
名前を知ることは認識すること！
この発表を聴いてそんな""あるある""の名前を知り、事象を正しく認識して、次に生かしましょう！

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

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

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

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

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

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

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

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

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

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

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

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

決してテスト用のライブラリでもなく、メタプログラミング用のユーティリティでもなく、
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では、技術的な詳細はさておき、
フレームワークを理解するための概要(登場人物の紹介程度)を押さえつつ、
「実際にはどんな感じなのか」をデモ中心でお伝えします。

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

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

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

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

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

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

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

について紹介します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

フレームワーク同士の噛み合わせによって、カスタムしたい箇所がうまくカスタムできずモヤモヤしたことはありますでしょうか？

私は「例外時のAPI Platformからのレスポンスをカスタムしたいのに、Laravelの標準エラーハンドラに書いても効かない〜〜〜！」とAPI Platform for Laravelの例外処理に悩まされました。
これは、API Platformが内部で利用するSymfonyのコンポーネントが、Laravelの例外処理よりも手前でレスポンスを生成し、意図的に上書きしているためです。

そこでフレームワークのソースコードを確認して勝ち取った解決策を共有します。それは、複雑な設定変更ではなく、たった一つのサービスプロバイダへの追記によるものです。
ポイントはフレームワークのErrorHandlerクラスをカスタムクラスで上書きすることでした。

このLTでは、フレームワークの制御の意図的な優先問題を解決する実例とDI（依存性注入）がいかにフレームワークを裏側から制御する武器になるかをお話しします！

オンプレミスの本番環境の構築を行う際にも、やはり開発/テスト環境が欲しくなります。

Dockerを日常的に使用するエンジニアが多いですが、Hyper-Vを利用すると実機の環境をより正確に再現できます。
特にHyper-VはWindows Pro / Enterpriseの環境であれば、機能を有効化することで簡単に導入できるのでとても便利です。

Hyper-Vの機能を有効化すると「Hyper-Vマネージャー」というGUIツールで管理できるようになりますが、設定項目が多いのでチームで共有するためにPowerShellスクリプト（ps1ファイル）で記述してコードで管理できるのが望ましいです。

本LTでは、Hyper-Vの各コマンドを詳しく説明するのではなく、実際にps1ファイルで環境構築を自動化しようとしたときにハマったポイントと回避策を紹介します。

今回はこの2点に絞って話します。

・ps1ファイルをそのまま実行できない環境で、WSL2からPowerShellを呼び出してHyper-Vを操作した方法
・仮想スイッチ作成やVM作成など、管理者権限が必要な作業をPowerShellで記述するための工夫

これからHyper-V環境をコードで管理したい方が、同じ落とし穴にはまらないための知見を共有できればと思います。

近年、PHPには多くの意欲的な言語機能が追加され、ますますコーディングしやすくなっています。
筆者はLispをはじめ、「関数型」と分類されるプログラミング言語について関心を持って取り組んでいますが、それでもPHPと関数型言語には大きな隔たりがあります。

このトークでは、関数型的な観点からの近年のPHPの構文の変化と、それでも関数型言語と見なすには何が足りないのかについて騙ります。

合わせて読みたい： (読まなくていい)

• Lispは関数型言語(ではない) by うさみけんた | トーク | 関数型まつり2025 #fp_matsuri - fortee.jp

近年、AIを使ってテストを書くという流れが一般化しつつあり、私自身もAIにテストコードを補助的に生成させています。

しかし一方で、「AIにはあえて任せないテスト」が確実に存在します。
それは仕様そのものを表現するテストです。
AIは既存コードや表層の情報をもとにテストを書いてくれますが、「どうあるべきか」という意図やコンテキストの把握は人間がやる必要があり、仕様の補完や抜け漏れの指摘まで踏み込むことはできません。
TDDを行うときに「先にテストを書く」理由と同様に、最初に仕様を描く役割は人間側に残されていると感じています。

私はテストを「振る舞いの記述」であり、「仕様を共有するためのドキュメント」だと考えています。
したがって、他の開発者が見たときに、そのテストがどんな意図で書かれ、どのような状態を期待しているのかが読み取れる形を大切にしています。

このLTでは、AI時代における「AIに任せるテスト」と「手で書くべきテスト」の線引きを、実務の経験と失敗談を交えながら整理します。
AIに任せてショートカットした方が良い部分、一方で人が書くべき仕様の部分をPHPUnitを使った具体例とともに紹介します。

Feature Toggleは、ソフトウェア開発において特定の機能を有効または無効にできる手法です。

Feature Toggle はとても便利です。一部のユーザーだけに機能を公開したり、本番では機能を無効化しておくことでトランクベースの開発ができることによってコンフリクトを避けることができます。

一方で、Feature Toggle は便利ですが、if (FeatureToggle::enabled(...)) をあちこちに書き散らすと、後からトグルを消すのが辛くなりがちです。
「とりあえず if で分岐」から始めた結果、開発が終わった頃には自信を持って削除できない…という経験がある方も多いのではないでしょうか。

このトークでは、コードの可読性を保ちながら安全にトグルを削除するための設計方法を紹介します。

トーク概要（800文字以内・感謝ニュアンス版）

約3年ぶりにPHPへ「ただいま」しました。
復帰して最初に困ったのは文法ではなく、「今の現場の前提」が変わっていたことでした。
PHPのバージョン差に起因する互換性の勘どころ、フレームワークを選ぶときの判断軸、テストや静的解析をどこまで整備するのが標準なのか。
名前は聞いたことがあっても、根拠を持って決めるための材料が手元にない。ここが復帰直後のいちばん大きなギャップでした。

そんなときキャッチアップの根源になったのが、PHPコミュニティが積み上げてきたブログ記事や登壇資料でした。公式ドキュメントへつなぐ導線になっていて、単なる機能紹介ではなく「なぜそうするのか」「どこでハマるのか」「どう進めると安全か」という実務の知恵が、短時間で手に入る。
結果として、復帰直後に必要だった互換性・FW・品質ツールの未知を、一気に理解できる形に変えてくれました。

このLTは、その感謝を伝えにきました。
PHPに戻ってきた人間が、どんな知らなさに直面し、コミュニティの知見にどう救われたのかを共有します。

ある日ふと思いました。PHPで円を描きたいな……。
円という単純な形を画面に表示するだけの簡単なお題なのに、実際にやってみると驚くほど多様なアプローチが存在します。
今回は、その“いろいろ”をまとめて一気に紹介します。

普段バックエンドエンジニアとして向き合うのは、データベースと業務ロジックが中心。
それはそれで高度で面白いのですが、今回は少し頭を柔らかくして、PHPで円を描くというシンプルな遊びを一緒に楽しんでみましょう。