「やる気が出ない。でも何かしなきゃ。」
そんな焦りに飲み込まれていた自分が、少しだけラクになれた経験をお話しします。

仕事での責務が増えてアウトプットが止まり、アウトプットするネタも浮かばず、周りがどんどんアウトプットしているのに自分だけが取り残されているように感じて、焦っていた時期がありました。
そこで私は、無理に動かず“できる範囲だけ続ける”ことを選びました。

このセッションでは、私が試してきた工夫や気づき、そして“やる気がない前提でどう設計するか”についてお話します。
やる気が出ないことにモヤモヤしている方、立ち止まっている自分に不安を感じている方へ、エンジニアとして長く続けていくための“ペースのつくり方”の一例として、少しでもヒントになれば嬉しいです。

開発体験以外のAI活用ってどんなものがあるんだろう？

サービスや事業にも非常に強力な要素にもなるドメインイベントを活用することで、
様々なシーンでAI活用を推進することができます。
例えばAIを活用したデータ分析をはじめとしてマッチングやレコメンデーション、
AIエージェント開発やエージェンティックRAGの実践など、
これまでとは少しだけ違った形でたくさんの価値を生み出すことができます。

今回はそんなドメインイベントとAIが利用しやすい様々なコンテキスト表現方法と、それらを実現するためのシステムアーキテクチャに触れます。

これからのアプリケーションについてのヒントをお届けするとともに、
みなさんのサービスなどに実装するAI関連技術についてもお話しします。

コードレビューでは、人格攻撃をしてはならないとされています。
それは裏返せば、書かれたコードをレビューするときに
それを書いた人のことをどうしても考えてしまう、ということでもあります。
自分が攻撃（非難）されたように感じてしまうのも、同じこと。
自分が書いたコードは、あたかも自分の一部であるかのように感じる気持ちがあるのです。

しかし現在、生成AIがコードを書くようになってきています。
人間が書いているところを補完してくれたり、
自律的にコードを書いてPull Requestの作成までしてくれます。
では、そのコードはあなたが書いたものだと言えますか？あるいは、思えますか？

このトークでは、コードと私たちの距離について考察します。
（心理的な）オーナーシップの話だけでなく、責任の分界点についても見ていきます。
生成AIの導入で変わりつつある距離感について、一緒に考えてみませんか。

PHP は2015年以来、毎年11〜12月頃にバージョンアップが行われており、11月20日には待望の PHP 8.5 がリリース予定です。

かつてはゆるふわ言語の代表格として知られた PHP ですが、7.0 以降は型周りの表現力が大幅に強化された他、Readonly Property/Class の導入など、堅牢で読みやすく、壊れにくいコードを書くための強化が行われてきました。

そして PHP 8.5 では Haskell や Elixir など「関数型言語」にあるような「パイプ演算子」が導入されます。PHP にパイプ演算子……隔世の感がありますね。

本トークでは PHP 8.5 で導入される新機能の内、個人的に注目しているパイプ演算子と NoDiscard アトリビュートを中心に、どのようなメリットをもたらすのかを具体的なコードと用例を用いて解説します。

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

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

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

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

本セッションでは、高負荷な処理を非同期処理として実装したいという実務的な動機を起点に、PHPの実体とその制御に取り組んだ経験を紹介します。
子プロセスの生成・監視・タイムアウト制御などを組み合わせたシンプルなバッチ処理管理システムを自作する中でプロセス制御について学ぶことはできましたが、しかし同時に「プロセスとはそもそも何か？」という疑問にも直面しました。
プロセス制御のコードは書けても、プロセスの実体や仕組みについては深く理解しているとは言えませんでした。
そこで、プロセスとは何か、どのようにOS上で扱われ、PHPからはどう見えているのか、そういった違う視点にも踏み込んで、プロセスについて深く掘り下げることにしました。
非同期処理やPHPでのプロセス制御に関心がある方、また普段は見えにくい「プロセスの中身」を学びたい方に向けたセッションです。

概要

LaravelにはOctaneというLaravelアプリケーションを高速化するための拡張ライブラリが存在しており、
従来のPHP-FPMより大幅な性能向上を実現します。
本セッションではFrankenPHPのZTS（Zend Thread Safety）環境でのワーカープロセス管理、
octane:startコマンドの内部動作、Octane Tables/Cacheの実装制約などを紹介していきます。
またOctane導入前後でどれくらいのパフォーマンスの差が出てくるのかを検証します。

話すこと

• ZTS環境でのワーカー管理とOctaneの連携実装
• octane:frankenphpコマンドの内部動作
• Octane Tables/CacheのFrankenPHP環境での実装と制約
• Octaneの有無でのパフォーマンス差異

概要

従来のPHP環境でリアルタイム通知を実装する場合、Node.js等を組み合わせた複雑なインフラ構成は悩みの種でした。
FrankenPHPではこの課題を解決するためにMercureが内蔵されており、PHPスタック内でシンプルかつ高速なリアルタイム通信を実現しています。
本セッションでは、実際に動作するアプリケーションの動作デモを交えながら、以下の技術的なポイントを紹介します。

話すこと

• 従来構成での実現の難しさを再確認する
• FrankenPHPがリアルタイム通信を実現する流れの紹介
• WebSocketとServer-Sent Events(SSE) の技術概要と差異
• FrankenPHPを使ったリアルタイムWebアプリケーションの具体的な実装方法と実演

話さないこと

• Mercureの技術詳細

フレームワークを作るためのフレームワークと言われ、実際にLaravelでもコアとして利用されているSymfony。
そのため、初心者向けの導入説明や上級者向けの抽象概念獲得のための解説などの知見を聞く機会が多くあります。

一方で、実用としてのSymfonyの知見を聞く機会があまりありません。
同様にPHP5.4で導入されたtrait（特性）の実用としての知見を聞く機会もあまりありません。

そこで、この登壇ではSymfony6.3および7.2において本番実証済みのtrait（特性）活用例をお話します。

このトークで得られる知見

• Symfonyの特性に沿った特性(trait)の活用事例
• traitの使いどころ
• 省力かつ安定し安全な機能改編の実例

このトークで扱わない内容

• Symfonyの使い方

注意事項

• サンプルコードの公開は間に合いません。悪しからず。

国内外であまり知られていないAstroのContainer API。主にコンポーネントテストのために使われますが、実はバックエンドフレームワークとの組み合わせも可能にするAPIです。
本発表では、Astro Container APIの紹介、バックエンドフレームワーク組み込みのための使い方、APIを使うときの落とし穴について語りたいと思います。HonoやLaravelなどを利用し、実例を紹介しながら発表します。
「Astroを使ってるけどバックエンドを追加したい！」　「既存のバックエンド知識を活かしながらモダンなUI開発をしたい！」　という方に向けたトークです。

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

技術的負債の、「利率」にあたる部分はチームメンバーの増加によって見かけ上増える

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

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

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

※内容の正確さには注意を払いますが、私は会計学の専門家ではありません。

API仕様書を管理するWebアプリケーション開発において、「スキーマと実装の乖離」は頭の痛い問題です。

以前、apidocでAPI仕様書を管理していましたが、各種問題がありました。
特にドキュメントの品質管理が個人に依存しがちで、実装との乖離が発生していました。

単なるツール移行では根本解決にならないと判断し、人ベースの品質管理からの脱却を目指しました。
開発プロセスから見直し、それを実現するアーキテクチャを検討した結果、swagger-phpをベースとした独自ライブラリを開発することになりました。
結果として、構造的な問題を解決し、スキーマ駆動開発にも対応できました。OpenAPIエコシステムの恩恵も得られて高品質且つ、開発者体験の向上にも繋がりました。

今回の登壇では、ライブラリ開発の経緯に加えて「eg-r2」の具体的な使い方を紹介し、OSS化の狙いについてもご説明します。

どのようなビジネス、プロダクトであろうと運用していくのに必要なのが管理画面
ただ、管理画面を作っているとこういう課題に出会ったことはないですか？

• 調査依頼が来てもどこを見ればいいかわからない
• おかしなデータが入ったことに気づけない、ログを追うのが大変
• 調査依頼からバグを再現するのが難しい

これらを1つ1つ向き合って解決し、プロダクトとビジネスの成長をさせるための管理画面の作り方を話します

話すこと

• 管理画面におけるログやデータの残し方
• 管理画面におけるアプリケーションの設計

話さないこと

• アプリケーション設計における具体的なコードの説明
• 画面のUI

PHPのmbstringのRFCを投げていても、最近ではなかなかAcceptされにくくなってきました。
それでは、代わりに何が来るのかというと、Unicodeを扱う関数であるgrapheme関数で、それを作っています。

皆さん、これからやってくるであろうUnicode大時代に向けてキャッチアップしませんか？

テストコード、書いていますか？

今日において、自動ユニットテストを整備することが開発生産性の向上に寄与することはもはや疑う余地がありません。また AI の活用により、テストコードを書くコストは従来に比べて大幅に減っています。

しかし「テストコードの書き方や導入方法がわからない」「テストコードがあるだけで満足してしまい十分にその効果を発揮されていない」「テストコードが負債化し開発の足枷になっている」などの課題に直面している方も多いのではないでしょうか。

AI がコードを書く時代になっても……いや、むしろ AI がコードを書く時代だからこそ「価値のある」ユニットテストについて一緒に考えてみませんか？

お話しすること

• AI 時代における自動ユニットテストの価値とは
• 価値のあるテストコードを書くための基本的な考え方
• よくあるアンチパターンと処方箋・テクニック

AIを利用したコーディングによって生産性が高まっていることは間違いありません。
0→1の生産性が高まった反面、設計不備による低品質なコードやテーブルも量産されてしまいます。

だからこそ、今こそデータモデルのあるべき姿を考え、その形にデータベースもリファクタリングしていくことが必要です。
そこで今回は下記の項目についてご紹介します。

• データベースのリファクタリングの手法
• データベースリファクタリングに必要な準備
• 大きく捉えて小さく設計する

広島人のためのブログコミュニティサービス「広島ブログ」を、気づけば20年運用してきました。
https://www.hiroshima-blog.com/

たった2人の小さなチームで開発から運営までを担い、広島に根ざしたウェブのコミュニティを作り続けています。
その間、本当にいろんなことがありました。

• ユーザー同士のつながりから、新しいウェブサービスやプロジェクトが誕生
• 広島市民球場を借り切ってのオフ会を開催
• 距離の近さゆえに起きるトラブルも

「人の顔が見えるインターネット」には、今も昔も特別な力があると感じています。

• 地域特化であることは「制限」ではなく「価値」
• 小規模開発だからこそできる、スピードと柔軟性
• 長く続けることが、信頼になる

地元と向き合い続けて見えた、小規模ウェブサービス運営の面白さと難しさをお伝えします。

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

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

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

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

ADRとは略称で、 Architecture Decision Records の頭文字をとったものです。直訳すると アーキテクチャ決定の記録 というところでしょうか。
その名の通り、構築計画中のソフトウェアアーキテクチャの重要な側面に関してチームが取った選択について説明する文書のことを指します。

このセッションでは自身がテックリードとして所属するチームにADRを導入する→してみてどうだったか？までを一貫してお話します。具体的には以下の通りです。

• (改めて)ADRとは何か
• なぜADRが必要だったのか
• 導入までにやったこと
• 導入までに困ったこと
• 実際の運用フロー
• 導入により得られた効果