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

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

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

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

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

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

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

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

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

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

「このエンドポイント、なんか遅いんだよね」

勘と経験でコードを眺め、怪しそうな箇所を修正する
本番にデプロイして「速くなった気がする」で終わる
あの言葉がよぎります。「推測するな、計測せよ」

Traces・Metrics・Logsの3つのシグナルを収集することで、パフォーマンス改善の景色が一変しました
Tracesでリクエストの流れを可視化し、どのスパンで時間がかかっているか特定する
Metricsでp95/p99レイテンシ、スループット、エラーレートを継続的に監視する
Logsでトレースと紐づけた詳細なコンテキストを取得する
3つのシグナルを相関させることで、ボトルネックの特定から改善効果の検証まで、データに基づいた意思決定ができるようになりました

本セッションでは、PHPアプリケーションに対してテレメトリーシグナルを活用したパフォーマンス改善の具体的な手法をお伝えします
サンプリング戦略、属性設計、Collector構成など、本番運用で直面する課題と解決策も紹介します

勘と経験に頼らず、シグナルが導く改善を始めましょう

• 想定する聴講者
  • パフォーマンス改善を勘と経験で行っている方
  • Observabilityに興味があるがどこから始めればいいかわからない方

PHPerとして働いていると、普段の開発の中や役割が変わるタイミングなど、さまざまなシーンで「思うようにできていない」「期待に応えられていないのでは」と不安を抱く場面は少なくありません。
タスクの優先順位、仕様変更、レビュー文化、ステークホルダー調整など──“自分ではコントロールしきれないこと”は日常の中に多く存在します。

私自身、プログラマからマネージャーへと役割が変わる過程で、無力感や焦りに振り回される時期がありました。
そんな中で助けになったのが「コントロールの三分法」という考え方です。
物事を「コントロールできること」「影響を及ぼせること」「まったくできないこと」に分けて捉えることで、不安な状況でも少しずつ前に進めるようになった感覚があります。

このトークでは、不安や焦りを抱えたときにどのように自分と向き合い、考え方を整えていったのかを共有します。
キャリアステージや役職に関係なく、エンジニアは常に不確実性の中で仕事をしています。
このセッションが、どんな立場の方にとっても「今の状況をどう捉え、どこから前に進むか」を考えるきっかけになれば嬉しいです。

仕事において「Webフロントエンドでサービス開始されたが、あとからネイティブアプリも必要になった」という状況が起こり得ます。

そのときに起こりがちなのが、React Native製ネイティブアプリとReact Router v7以降（元Reimix）などのWebフロントエンドで、独自にAPIクライアントが生えてしまい、仕様変更のたびに2倍のコストで改修することになる問題です。
本セッションでは、このカオスを避けるために、API通信ラッパーをどこまで共通化するのかという現実的な戦略を共有します。

特に以下の3点を扱います。

• ネイティブとWebフロントエンドの違い（ネットワーク品質・バックグラウンド実行・ストレージ・オフライン対応・認証方式・エラー表現など）を踏まえた、バックエンドのAPI設計において配慮すべきポイントと具体例
• API通信ラッパー共通化のためのレイヤー構成（型付き共通クライアント層／トークン管理やナビゲーション連携などのプラットフォーム依存層）と、実行環境の差分を吸収する実装パターン
• Orvalを用いたOpenAPI＋型生成、HTTPクライアント、SWR系ライブラリを選定する際の判断基準と、「ネイティブだけ別実装にしてしまい後から辛くなった」「最初に共通ラッパーへ投資して変更が楽になった」といった実例

[持ち帰ってもらうこと]

• ネイティブアプリ追加時にも破綻しないAPI設計・レスポンス設計のチェックリストを自チームで作成できるようになる
• React Native／Webフロントエンドの両方から使い回せるAPIラッパー構造を、自プロダクト向けに設計し直す際のたたき台を持ち帰れる
• フロントエンド／ネイティブアプリ／バックエンド間で「どこまで共通化し、どこから分けるか」を合意形成するための議論のフレームワークを得られる

TLSは、HTTPSなどで普段使用する際に暗号化を担っている技術ですが、私自身、「HTTPSの裏側でいい感じに暗号化してくれるやつ！」くらいの漠然とした理解しか持っていませんでした。

そこで、TLSを理解するために、TLSプロトコルを実装することに挑戦しました。

このトークでは、TLSの基本的な仕組みについて説明し、どのようにTLSを実装したか、そのプロセスについてお話しします。
また、実装を通じて得られた学びや、ソケット通信に触れることの楽しさについても共有します。

話すこと

TLSの仕組み
PHPでどのように実装したか
得られた学び・ソケット通信に触れる楽しさ

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

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

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

候補を洗い出して、指標を評価して、いいものを選んでプロダクト責任者にいざ提案。
「いい技術選定ができたぞ！」と思っていたのに、実は見えていなかった視点があったことへの気づき。
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」を用いて深く内省する手法です。

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

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

普段使用している Nginx や Apache の仕組みを知っていますか？
Webサーバーは、ブラウザからリクエストを受け取り、PHPに処理を渡し、レスポンスを返すという当たり前の仕事をしていますが、その内側で具体的にどんな会話が交わされているのか、コードレベルで説明できる人は意外と少ないかもしれません。

・TCPソケットの確立
・生のHTTPリクエスト文字列のパース
・RFCに則った正しいHTTPレスポンスの生成
これらをPHPという「アプリケーション側の言語」で書き下すことで、HTTP通信のライフサイクルを完全に理解することを目指します。

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

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

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

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

アプリケーションを運用していると、外部サービスの遅延や内部の重い処理が原因で応答速度が不安定になることがあります。
私自身、サービス間の連携やドメインイベントの実装に取り組む中で、メインフローが時間のかかる処理と密結合していることが、遅延や障害につながるケースを経験しました。

こうした状況では、時間のかかる処理をメインフローから切り離し、QueueやPubSubなどメッセージングを使って非同期で実行するアプローチが有効な場合があります。
これにより応答速度が安定し、メイン処理と周辺処理を分離することで、変更に強い構造を作りやすくなります。

一方で、非同期化には同期処理では現れにくい落とし穴があります。
整合性のズレ、処理順序の乱れ、重複実行など...
適切な対処をせずに導入すると、期待した改善よりも複雑さが増すケースもありました。

本セッションでは、メッセージングによる非同期化を進める際に押さえておきたいポイントを、次の観点から整理して解説します。

• なぜメッセージングによる非同期処理を行うのか
• 非同期処理特有の落とし穴と対策
• 非同期処理をどのように切り分けるのか

イベント駆動アーキテクチャなどメッセージング導入について議論のきっかけになると嬉しいです！

さてここを覗かれてるあなた、もしかしてプロポーザルに興味がおありでしょうか？
出してみたい気持ちがおありでしょうか？

出してみたいけどふんぎりがつかない。そんなお悩み抱えてますか？
このトークでそのお悩みを少しでも軽くできればと思います。
カンファレンスをより深く楽しめるようになりますよ！

ターゲット

• プロポーザルを出してみたいけど一歩踏み出しきれてない方
• プロポーザル出す人の心理を知りたい方

お話すること

• なぜプロポーザルを出す（カンファレンスに登壇する）のか
• 心理的ハードルの洗い出し
• 心理的ハードルへの考え方、対策
• どうやってネタを出しているのか
• 出すときに意識していること
• 出したらどうなるか

何が得られるか

• プロポーザルを出す勇気
• ネタのひねり出し方

PHPではtry-catchによる例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか。
例外を過度に使用すると、本来の処理の目的が曖昧になり、可読性の低下や予期せぬバグの隠蔽につながることがあります。

こうした課題へのヒントとして、Result型の考え方をPHPに応用するアプローチがあります。
Result型は、成功と失敗を返り値として明示的に扱える型であり、エラーの種類や責任範囲の整理に役立ちます。
結果として、処理の流れや責務が明確になり、例外を多用せずにエラー設計が可能になります。
PHPでは標準で実装されていないものの、軽量な自前実装によって導入できます。

本セッションでは、例外（try-catch）を前提とするPHPプロジェクトに、以下の観点を中心にResult型を取り入れる方法を紹介します。

• エラーの分類と責務の整理
• 例外との使い分け
• PHPでResult型を実装する方法

Result型を導入するかどうかに関わらず、エラーをどう設計するかを見直すヒントを持ち帰っていただけると嬉しいです！

エンジニアとして学び始めた頃の私は、「どう作るか」という手段ばかりを追いかけていました。
意識が向いていたのは以下のことです。

• 完璧にやる
• とにかく100点を目指すこと

一方で、「なぜそれを作るのか」「誰の何を解決するのか」という目的にはほとんど目を向けられませんでした。
背景には初学者としての不安や失敗したくない完璧主義があり、手段だけを追うことで安心していました。
しかし、その結果、受動的な開発から抜け出せず、本質に気づけませんでした。

そんな自分を変えたのは、先輩エンジニアの一言です。

• 「まず目的を一緒に整理しよう」

目的を言語化し、ユーザーの状況を想像して価値を定めてから手段を選ぶプロセスを意識したことで、開発の視界が広がりました。
完璧主義の方向性も変わり、以前は「100点」を目指していたのが、今は「60点を100点として目指す」ようになり、
余裕を持って自分から問いを投げかけられるようになりました。

具体的には、

• 「この仕様の意図は？」「もっと良い体験にできる？」と問いを立てる
• 受動的だった開発が主体的な創作に変わる
• 意味のある選択

こうして問いを立てる余裕が生まれ、開発の視点も行動も大きく変わりました。

このトークでは、

• 初学者だった私が手段中心に陥っていた理由
• 目的を取り入れたことで生まれた具体的な変化（完璧主義の方向性も含む）

についてお話しします。
初学者や若手エンジニアにぜひ聞いてほしい内容です。
作ることの楽しさが一段深くなるきっかけになれば嬉しいです。

※初心者向けトークです

このトークの対象者

• 「ポリモーフィズム？それ美味しいの？」と思う人
• 名前は知っているが、自分の言葉で説明できない人
• ベテランの方で、他人に説明する自信がない人

トークが目指すゴール

• オブジェクト指向の良さを体感できる
• テストを書く時に効率的に書くヒントを得られる
• クラス設計そのものが楽しくなる（大事）

Javaから始まったオブジェクト指向の波はPHPにも波及し、今やPHPは立派なオブジェクト指向言語になっています。
プログラミング初心者が抱く疑問「ところでオブジェクト指向の何が良いの？」という命題について。
これを改めて解説して「確かに良いね！」「便利だね！」「テストに活かせるね！」とみなさんに再認識してもらうのが目的です。
またそれと併せて日常生活に潜むポリモーフィズムの例を出しながら、わかりやすさに特化します。

さらに、日常生活に潜むポリモーフィズムの具体例を紹介し、わかりやすさを追求します。
熟練のエンジニアであっても、「頭では理解できるけれど、初心者にわかりやすく説明するのは難しい」と感じることがあります。高齢化が進むPHP界隈で、PHPの魅力や便利さを伝える流れの中で、オブジェクト指向の良さも一緒に解説しましょう。

「これ以上触らない」ことが決まっているレガシーシステムを、どう安全に未来につなげますか？

PHP5.6で動くレガシーシステム。詳しい人はもういない。新規開発の停止が決定してから3年が経過しているが、毎月しっかりと売上を生んでいる。そんなシステムのPHP8.3へのジャンプアップを、最小限の工数で安全に実現した戦略の解説です。

新規開発を停止している以上、「リファクタリングしてから」「テストを書いてから」と時間をかけることはできません。システムの詳細を理解している人がいない以上、少しでもリスクのある修正は取り入れられません。このような強い制約の下での現実的バージョンアップ戦略を共有します。理解度の低いシステムに対するPHPバージョンアップへの不安を解消し、具体的な対策を持ち帰っていただける内容です。

対象

• なかなか手をつけられないレガシーなプロダクトを抱えている方
• アプリケーションのPHPバージョンアップで苦戦している方
• auroloadなど「PHPの仕組みの部分」を実践的に活用したい方

話すこと

新規開発はしない、現状維持できれば問題ないお金を稼いでる以上、いつまで使われ続けるかわからない
こう言った状況で力を入れすぎず、楽かつ安全にバージョンを上げる実践例を紹介します。

学べること

• AIのバージョンアップ作業での活用
• ワンコードでバージョンアップする戦略
• テストを書かずに安全を確保する戦略
• 段階的移行でリスクを最小化する戦略

内容

• AIでバージョンアップの影響を調査させる工夫
• 同じコードでPHP5.6と8.3の両方を動かす方法
• ミラーリングサーバーとアクセスログリプレイで実トラフィック検証
• エンドポイント単位の段階的移行(path-based routing)

市場の要求に応じた大規模な新機能の追加は、プロダクトの成長に不可欠です。
しかし、2001年ローンチの「メールディーラー」のようなレガシープロダクトは、その挑戦が特に困難です。

メールディーラーは全機能が一台のサーバーに集約され、フレームワークなしのPHPファイルでDBアクセスとHTML出力を行う陳腐化が著しいシステムが背景にあります。

その一方で、LLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、「AIを導入していないことがデメリット」へと市場の要請が変化。
私たちは、この状況に対応するため、「AIクレーム検知機能」をサービスに導入することを決定しました。
しかし、大規模なリファクタリングが困難な中、私たちはAI機能を既存システムから外出しする戦略を採用。
史上初のβ版をDocker互換のコンテナであるPodmanで構築し、実証実験を通じてChatGPTの精度を向上させました。

さらに製品版をAWSで構築することで実用レベルの精度を実現し、設計時の見積りより約65%のコスト削減に成功しました。

本トークでは、テクニカルリーダーである私が、このレガシーの壁を越えた戦略を具体的な事例を交えて公開します。

・AWS導入にあたり、利害関係者へ目的を整理し、どのように説得・合意形成したか。
・ベータ版での精度向上の試行錯誤と、AWS移行によるコスト削減とパフォーマンスの向上をどのように達成したか
・AWSのSQSを使い、レガシーと新システムとをどのように接続したか？

本セッションを通じて、レガシーなシステムに対して、市場の変化と最新技術を取り込む新しい試みの参考にしてください。