まれにある深夜メンテは遠足気分(?)で楽しかったりしますが、頻繁にあると生活リズムを崩してしまいますし「もし未知のトラブルに遭遇して長時間サービスをダウンさせてしまったら・・・」などの心配も尽きません。

本トークではメンテナンスを日中にやるための交渉術や実現するためのテクニックについてご紹介します。

想定観客

• 深夜メンテをしたくない、部下・同僚にさせたくない人

お話しすること

• 深夜メンテをしない合意形成
  • 希望を伝え続ける、起きたトラブルをダシに使う、お金の話をする
• 日中にメンテをするための考え方とテクニック
  • 影響範囲とリスクを明らかにする、障害を避けるべき時間を明らかにする、ダウンタイムを許容する、ロールバックに備える、後方互換性を確保する

AIをプロダクトに組み込んだとき、従来なかった壁にぶつかりました。実行する度に結果が揺れる非決定論的な出力に対して、どうテストすればよいのか。完全一致を求める従来のアサーションは使えず、人の目での検証には時間がかかり、バリエーションが増えるたびにデグレチェックが困難になるという問題です。

このトークでは、スプレッドシートへの出力が期待通りかどうかを検証するというケーススタディを取り上げます。一方はAIが出力するシート、もう一方は期待値（正解）を示すシートです。出力が予測できないためプログラマティックに検証できません。一方で、AIに検証を丸投げすると精度に不安があります。AIとプログラムの強みを組み合わせることで比較精度の安定と、不一致セルのハイライトのような検証利便性の向上も実現しました。

ケーススタディを通じて、LLMと向き合う際の発想について整理することも目指します。

クラウドインフラコストを成果報酬型で削減してきたDELTAが新たにPHP/Rubyを第一弾としてバージョンアップの代行を始めました。
コンセプトとしては生成AIを活用して、半自動的にVersionUpができる状態を目指していますが、サービス黎明期の今は1プロジェクトずつ、手作業で泥臭く調査や検証、実行を重ねています。
今回は数あるプロジェクトの中でも、CakePHPの2系を最新バージョンまでアップデートする道のりについて語ります

取り上げる内容

• バージョンアップにおける生成AIの利用方法
• テストのカバレッジが低いアプリケーションのバージョンアップ方法
• (特に)Cake2からCake3へのバージョンアップ時の変更点の多さ
• Cakeのドキュメントのあいまいさと突破した方法
• AIを使って効率化（PRの高速化）を果たしてもレビューで詰まってしまい、プロジェクト自体のアウトカム生産性が高まらない際に実施した方法
• お客さんへ新しいバージョンのお作法やメソッドの変更などの共有

想定

• PHPで構成されたアプリケーションを開発しているエンジニア
• バージョンアップに向き合っている / まだ機会に遭遇していないが、具体実例から準備すべきこと・事前検討すべきことに興味関心がある方

Infrastructure as Code（IaC）とは、インフラ構築をコードや設定ファイルで定義し、再現性や自動化を実現するプラクティスです。IaC によって運用コストの削減やヒューマンエラーの防止といったメリットを得られる一方、導入初期の教育コストや特定メンバーへの依存といった課題も指摘されています。

私たちの組織では、2023年9月に既存サービスの稼働環境を見直した際に、AWS CloudFormation を用いて IaC を導入しました。導入からおよそ2年が経った現在も保守運用しています。

本セッションでは、はじめに IaC に関しての一般的な考え方やメリット・デメリットを解説します。続いて、私たちのチームでの導入に際しての実践内容や切り替えてからの運用の経過について共有します。最後に、IaC を導入してからのチームでの工夫や出てきた課題について紹介します。

IaC 導入での課題を感じられている方だけでなく、IaC 未導入の方や馴染みのない方にも、私たちの実体験から得た知見がヒントとなれば幸いです。

LaravelのQueueは便利ですが、Queueワーカーが裏でどのように動いているのかを知らない人も多いと思います。

ワーカーが内部で何をしているかが分かると、詰まり・遅延・失敗の原因に当たりを付けやすくなり、運用やデバッグがしやすくなります。

このトークでは、ライブコーディングを中心に、LaravelのQueueワーカーをゼロから（ただし必要最小限に簡素化して）実装しながら、php artisan queue:work が実際に何をしているのかを順番に解説します。

「Queueは使っているけれど中身はよく分からない」という人が、処理の流れを自分の言葉で説明でき、トラブル時に切り分けの視点を持てるようになることがゴールです。

基本的な情報

私たちのプロジェクトでは、Lumen FrameworkとCodeception / Specifyを採用していましたが
Codeception / Specify の更新が終了してしまいました。
移行先は pestphp を検討していましたが、１万を超えるテストケースを具体的にどうやって移行するのかが課題になっていました。

これらに、この１年でどう立ち向かったのか、どのように方針転換をしたのかをお話しします。

お品書き / 得られること

• codeception / specify についての簡単な説明
• 終わりの始まり：テスト用フレームワークの EOL
• Pest への移行
• Rector による置換の試みとその問題点
• 技術の進歩 Agent Skills という光
• まとめ

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

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

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

Rector、いい感じで強力なPHPのリファクタリングツールです。
「好きなルールで、めちゃくちゃコードを書き換えられる！！」という経験は、味わうと夢のような心地がします。

素晴らしいのは、「単なる置換では出来ない」もしくは「人知を超えた正規表現でも難しそう」な一括自動修正を、
十分に人間が理解可能なルール記述で サクサクと実現してくれることでしょう。

なぜ、そんな事が可能なのでしょうか？その裏にあるのは、テクノロジーです。
コードを「木構造(AST)」として解釈して、様々な「ルール」を適用していくことで、
置換対象の検出と置換の実行を進めます。

そこで役立つのが Visitorパターン です。
「木」という複雑な繋がりを渡り歩き、1つ1つの「地点」で外から与えられたロジックを適用していきます。
こうした作りが、「適用対象の構造自体や、渡り歩き方の実装には全く手を加えず、ただルールを付け外しできる」という拡張性をもたらします。

このトークでは、
「Rectorって凄いな、面白いな！」というワクワクと、
「ドンピシャでデザインパターンがハマると、こんなに気持ち良いのだな！」というドキドキをお届けします。

話すこと

• ごくごく簡単に「ASTってなんだ」
• Rectorの使い方、できること
• Visitorパターンの概要
• 上記を踏まえた「なぜRectorでVisitorパターンなのか」

想定対象

• Rectorってなんだろう？を知りたい人
• 「Visitorパターンが嬉しい場面」を見届けてみたい人

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

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

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

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

私たちは大きな時代の節目にいます。これまで半世紀以上にわたって続いてきたコーディングのあり方が、大きく変わろうとしています。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によって意味を運搬する設計思想です。本セッションでは、仕様・実装・実行結果をセマンティクスで接続するアーキテクチャと、その実践から得られた知見を共有します。

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

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

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

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

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

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

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

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

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

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

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

Feature Toggle を使って開発していますか？
Feature Toggle を使って開発をした後使わなくなったトグルを削除していますか？

このトークでは Feature Toggle を導入してから削除するまでどのように運用するといいか話します。

Feature Toggle は開発終わったら削除しようね！

このトークに技術の話はほとんど出てきません。ハウツーでもありません。
プログラミングと出会って25年、ようやくたどり着いた気づきを共有したいです。

技術が好きですか？
もうイヤになりそうなこと、ありませんか？

ぼくはずっと、ある選択をし続けてきました。意識してやっていたわけじゃない。
振り返ってみたら、そうなっていた。
それに気づいたときふと、改めてPHPの生みの親、Rasmus Lerdorfの言葉を読み直し…この気づきは間違いじゃなかったと思えました。

こんな人に聞いてほしいです。

• 新しい技術を追わなきゃと焦っている
• 周りについていくのがやっとで自信がない
• キラキラしたエンジニアにはなれないと思っている

すぐに何かを解決するものではありません。それでも「自分だけじゃない」と少しでも安心してもらえたら。

もしかしたら、ぼくが、ぼくたちがRasmusだ。

"技術選定" この言葉から何を感じるでしょうか？
「難しくてわからない…」と悩む人もいれば、
「あの技術を使ってみるのはどうだろう！」とワクワクする人もいるはず。

とりわけ事業、それもゼロイチのフェーズの新規プロダクトにおいては、
技術選定はその先のプロダクト開発の未来を大きく左右します。
事業づくりやその加速に最大限貢献できる技術選定とは、どんなものでしょうか？

このトークでは、技術選定を行う上で陥りがちな落とし穴や、
エンジニアリングと事業づくりをどうリンクさせ、事業づくりの加速に繋げられるのかをお伝えします。

候補を洗い出して、指標を評価して、いいものを選んでプロダクト責任者にいざ提案。
「いい技術選定ができたぞ！」と思っていたのに、実は見えていなかった視点があったことへの気づき。
LaravelやSvelteをはじめとする様々な技術の選定を進める上での失敗、不安、
そしてそれをどのように克服し、どう事業づくりの加速に繋げられたのか。
チーム唯一のエンジニアだった新卒3年目の私のリアルな経験に基づく学びをお伝えします。

このトークでする話

• 技術選定のリアルな経験とハマりがちな落とし穴
• 技術に閉じず事業目線で良い技術選定をするためのポイント
• 異なる立場の相手により伝えるための技術提案の観点

こんな方におすすめ

• 技術的な意思決定をする立場にあるエンジニア
• エンジニアから技術的な提案を受ける立場にある非エンジニア
• 技術選定に対して怖さを感じている若手
• 技術選定がどのようなプロセスで行われるのか知りたい方
• エンジニアサイドとビジネスサイドの意思疎通をもっと良くしたい方

これまで私はPHPを用いてダッシュボード向けのWebAPIを設計・実装してきました。また、それなりに多様なアプローチで開発してきた気がします。しかし、どのアプローチも完璧というわけではなく、それぞれに特徴と改善の余地がありました。

今回は自分の経験をもとにダッシュボードについてはもちろん、ダッシュボードを作る際のWebAPIのアーキテクチャスタイル(REST、GraphQL、 BFF)、開発、フロントエンドとの関わり、ログなどの非機能要件について紹介します。

話すこと(変更の可能性あり)
・ ダッシュボードとは何か
・ ダッシュボード向けWebAPIをどのように作ってきたか
・ 成功した点、苦労した点
・ WebAPIの設計、実装との向き合い方

話さないこと
・ Protobuf, RPCを利用した話し(経験がないため)
・ フロントエンド側の詳細な実装

PHP のコードは、データを「配列」に集約することから始まることが多いです。

「複雑なデータを整理しているはずなのに、なぜか読みやすい」
そんなコードに出会ったことはありませんか？
それらの多くは、 PHP という言語の特性である「強力な配列操作」を最大限に活かしているからだと思います。

本セッションでは、明日から現場で使える配列テクニックをお話しします。
・配列に集める技術：散らばった変数を整理するファーストステップ
・流れを作る技術：標準関数を組み合わせてロジックを表現する方法
・チームを動かす技術：可読性を高め、開発速度を上げるための共通言語としての配列

さあ、配列を武器に、試合をコントロールしましょう。

毎日インクリメントしてますかー！？

昨日の自分より 1 ミリでも前に進めたい、「インクリメント大好きおじさん」です！
何よりリリースして価値を届ける瞬間...最高ですよね。
でも最近、私が一番ハマっているインクリメント対象は、自分でもプロダクトでもありません。

「AI」です。

多くの人は AI をただのツールだといいますが、私は開発を加速させるジュニアエンジニアであり、
チームの新しい仲間だと考えています。

実際、本格導入から半年で、チームの実装時間は半分になりました。
その快適さを知ってしまった今、もはや彼らなしの開発には戻れません。

プロンプトを書く行為は、単なる命令ではありません。優秀な PHPer を育てる教育そのものです。

信頼できる PHPer が増えれば、それだけチームの判断力は上がり、実装スピードは劇的に変わります。
泥臭い調査は AI と協力して終わらせ、人間は「どう作るか」「何を作るか」の本質的な議論に集中できます。

人と人のレビュー文化に、AI という最強のパートナーを掛け合わせる。
チームを次の次元へ連れていく、開発の爆速インクリメント手法をお見せします！

新人の頃は毎日が新しい発見の連続でしたが、業務に慣れるにつれて似たような仕事が増え、成長曲線が緩やかになったと感じることはありませんか？
私は成長曲線を再び急勾配にするために、毎日個人的なふりかえりを 1 年実施しています。

本セッションでは、日々の業務経験を確実なスキルへと変換するために私が実践している、2 つのフレームワークを組み合わせたふりかえり手法をご紹介します。
具体的には、平日は 1 日 10 分で完結する「4 行日記（事実・発見・教訓・宣言）」でクイックに経験を言語化し、週末は「ORID」を用いて深く内省する手法です。

コルブの経験学習モデルに基づき、業務時間から最大の学びを抽出して成長し続けるための仕組み化
そして実践したことで感じた効果について、実例を交えてお話しします。

想定する聴講者
・ある程度業務に慣れ、成長の停滞感を感じている中堅エンジニア
・日々の忙しさに追われ、やったことを振り返る習慣がない方
・アウトプットへの苦手意識を克服したい方

「もし間違っていたらどうしよう」「環境を壊したら怒られるかも」 そんな不安から、提案を躊躇したり、調査ばかりで手を動かせなかった経験はありませんか？

私は元々、失敗を恐れて発言できないエンジニアでした。しかし、ある時ギャルマインドをインストールしたことで、劇的に行動が変わりました。 本セッションでは、単なる精神論ではなく、開発プロセスを改善するための実践知としてのギャルマインドを解説します。

ポジティブ： PHPバージョンアップ作業で調査より壊れてもいいからやってみるを選んで効率化した話
行動力： 完璧主義を捨ててとりあえず出す勇気
バイブス： 肯定的なコミュニケーションがチームの心理的安全性をどう高めるか

明日から心にギャルピースを掲げ、不確実性の高い開発現場をサバイブするためのマインドセットをお話しします。