トーク

「フレームワークに依存するなと言っても、フレームワーク移行なんてほぼ起こらないのでは？」
そう思っていた頃が私にもありました。では、いま使っているフレームワークが開発停止になったらどうしますか？
かつて、symfonyはv1.4で開発を停止し、Symfony v2.0という名前で全く新しいフレームワーク（Symfony v2〜最新のv7は連続性があり、v1のみ別）に生まれ変わりました。
維持されたのは名称とMVCアーキテクチャベースであることだけ。使い方も、考え方も大きく変わってしまいました。当然、symfony v1を使ってアプリケーションを開発していた世界中の開発者は大混乱。
「ほぼ起こらないのでは？」と言われつつも、私がフレームワークに依存しない開発を求めてしまう原動力となっている当時の大混乱をふりかえり、フレームワークに依存しないことのメリット・デメリットと現代でのやり方についてお話します。

OpenAPIはAPIの仕様を記述するための仕様で、リクエストやレスポンスの詳細をYAMLまたはJSON形式で記述することができます。これを採用すると、記載内容を統一できる、バージョン管理しやすいなど様々なメリットがあります。
しかし、単なる仕様書と考えていると、徐々に実装との乖離が生まれてしまうリスクがあります。

これを防ぐための仕組みとして、OpenAPIドキュメントを使ってコードを生成したり、実行時に検査をする手法があります。
本セッションでは、Slimフレームワークを採用したシステムにOpenAPIドキュメントを用いたバリデーションとテストを導入した実例をご紹介します。
具体的には以下のような内容を含みます。

• OpenAPIを導入する際のポイントと注意点
• 具体的な実装方法 (league/openapi-psr7-validator)
• 導入の効果と進め方の反省点

Slim以外のフレームワークをお使いの方にも役立つセッションになるはずです。

リッチなUIを実装するために多くのアプリケーションでjQueryが利用されています。JavaScriptのAPIやCSSの機能拡充によりjQueryの出番は減ってきているものの、導入の簡単さ、APIの使いやすさ、プラグインの豊富さから「MPAで画面の一部をリッチなUIにすること」においてはjQueryはまだまだ最適な技術の１つです。しかしながら、DOM操作の命令的なコードはロジックやUIが複雑になると保守性が悪くなる傾向があります。

一方で、ReactやVue.jsなどのフレームワークは、宣言的UIにより保守性が上がるものの、学習コスト・運用コストの点でtoo muchになるケースも少なくありません。実際、LaravelをAPIサーバーとして利用するようなフルSPAよりも、MPA + 小〜中規模のJavaScriptで十分に要件を満たすアプリケーションがほとんどではないかと思います。

そこで、jQueryに代わる選択肢として注目されているのがAlpine.jsです。Alpine.jsはMPAでリッチなUIを構築するのに適したJavaScriptフレームワークです。Livewireの作者が開発したOSSですのでLaravelやLivewireとの連携も簡単で、ビューファイル内に宣言的UIとして実装できるため保守性が高いことが特徴です。

本トークではLaravel MPAにおけるフロントエンドの実装手法についてお話します。Alpine.jsを使ったフロントエンド実装を中心に、宣言的UIと比べたときのjQueryの優位性、ViteによるビルドやNodeモジュールを使ったバージョン管理、JavaScriptの管理パターン、Blade連携、コンポーネント化について紹介します。このトークが、Laravel MPAにおけるフロントエンド技術選定の参考になれば幸いです。

依存性注入(DI)は、単体テストを書きやすくして、変更容易性を上げるために有効なアプローチです。また、Laravel等のフレームワークでも使われており、その動作を把握するためには、DIの理解が必要になります。

しかし、学び始めたタイミングでは直感的ではないため、難しく感じることもあるかもしれません。

このトークでは、依存という概念を「使う・使われる」という、簡単な言葉で整理して、理解しやすくすることを目標とします。

話すこと

• 「依存している」とは「使っている」ということ
• 依存すると何が困るのか
• 依存を外から与える(注入する)メリット
• DIの実装例

私が現在開発に携わっている販売管理サービス「楽楽販売」は誕生して15年以上経つプロダクトです。
フロントエンドにフレームワークは利用しておらず、長年にわたり静的に生成されるHTMLの画面部品コードがコピペされ続けており、共通化が行われていない状況に陥っています。
その結果コピペコードは新画面を作成するたびに増殖していき、PhpStormが親の仇の如く「Duplicated Code」を指摘してきます。

この課題を解消するため、私たちは以下の2つの目標を重視し「画面部品のUIコンポーネント化」に取り組みました。
　・新しい画面を作成する際に、コピペする必要がない環境を構築する
　・画面の構成パーツに何があるのかを容易に把握できる仕組みを作る

ゴールは以下２点です。
・複数画面から共通利用可能なUIコンポーネントを作成する
・将来的なコピペを駆逐すること

本セッションでは、取り組みの背景の課題から具体的な解決策、さらに実践例までを詳しくご紹介します。

■お話しすること
　・なぜUIコンポーネント化が必要か
　・どのようにコンポーネント化を進めたか
　・コンポーネント部品を活用してもらうための施策

■想定する視聴者
　・技術負債を解消したい人
　・フロントエンドのフレームワークを利用していない人
　・画面部品のUIコンポーネント化に興味がある人
　・レガシープロダクトから脱却したい人

みなさん、ドメインイベントって使っていますか？

このトークでは、ドメインイベントを使ってPHPコードをリファクタリングする方法についてお話しします。
ドメインイベントは、ビジネスドメインで発生する「出来事」を表現するモデルです。注文の完了やユーザー登録のようなビジネスプロセスの特定の状態変化を表現できます。
これをうまく使うことで、副作用をわかりやすく整理し、システムをシンプルにできます。

ドメインイベントを導入してみると、「あ、こんな風に設計すれば良いんだ！」と新しい発見があるはずです。リファクタリングを通じて、どうやってドメインイベントを設計し、活用するのか、その具体的な手法をお伝えします！

話すこと

• ドメインイベントって何？
• リファクタリングでドメインイベントをどう導入するか
• システム間の連携を簡単にするイベントの使い方

オブジェクト指向大好きPHPerのみんなで、構造化プログラミング以前のスタイルで考えてみよう というトークです
クラスも無ぇ、制御フローもマトモに無ぇ、globalやgoto頼り！！！
非構造化の世界で、ぼくらの「認知負荷」は、どうなっちゃうの・・！？

開発生産性や変更容易性が特に重んじられる昨今、「認知負荷」との闘いに多くの時間が費やされます。
プログラミング言語もまた、こうした課題を解決する「あるべき姿」へと進化してきました。

一方で、「解決済み」の問題は見えにくいものです。
関数を定義できる、if-elseが使えることに、感謝の気持ちを抱いていますか？

それを理解するためには、温故知新のアプローチが役立ちます。
時代を遡ってみましょう。
オブジェクト指向以前の・・・手続き型？いいえ、もっと根源へ──
脱・構造化です！

この探求の先に、「今とは全く違うように見えるパラダイム」と「現在の姿」が地続きであると実感することでしょう
そして今の世界にも通じる「良さ」の再確認へと繋がるトークを提供します

みんなでスパゲティを食べに行きましょう

対象者と得られること

• 「どうしたら読むのに疲れるコードを生み出せるのか」に興味がある人
• 逆説的に「普段の開発で避けるべきこと」を知る

話すこと

• 構造化プログラミングの簡単なおさらい(定義・歴史)
• 「非構造化」のルールに則って書いたコードの紹介: お題 => 簡易CMS
• これらを踏まえ「我々が普段やっている&戦っていることはどんな意味があるの？」の確認

「非構造化」のルール(一部)

• 使わない: クラスや例外、while(true)以外のループ、名前空間
• 制限する: ユーザー定義関数 => 引数は使わない、値を返さない
• 使う: gotoや標準関数は使う

レガシーと向き合い続けるって大変ですよね。
大小様々な問題を抱えながらも、小さなパッチを当て続けることで生き抜いてきた、まさにプロダクトの中枢。
これはそんな「レガシーシステムのフルリプレイス」という大きな課題と向き合った、とある小さなチームの挑戦記です。

弊チームでは先日、大きな障害を出すことなく、レガシーシステムのリプレイスを終えることができました。
その際に以下の検証手法・リリース手法を組み合わせて、リスクを最小限に抑える「安全に倒し切ったリリース」を実現しました。

• チームオリジナルの検証手法「ペンギンテスト」
• シャドーテスト
• カナリアリリース
• ダークローンチ
• フォールトマスキング など

特筆すべきは「ペンギンテスト」で、これは以下のような特徴を持ったオリジナルの検証手法です。

• 本番環境で実際のデータを使いながらも
• ユーザー影響は出さない
• 未然に徹底的に見落としを削ぐための検証

この「ペンギンテスト」についてを主軸に、どのようにして予期せぬトラブルを未然に防ぎ、
計画通りのリプレイスを成し遂げたのか、その実践的なプロセスについて詳しくお話しします。

他の組織、チーム、プロダクトでも応用可能な知見を共有するので、
今同じような壁に直面している方には、有用な解決策の一つとして聞いていただけます。
安全に倒し切ったリリースを必要としている方、そして日々レガシーシステムと向き合う方は必見の内容です。

PHPフレームワークとして広く採用されているLaravel。その最初のコミットは 2011年6月8日 のことでした。
それから約14年。Laravelは進化の過程で何を大切にし、どのような機能追加を重ねてきたのでしょうか。
本トークでは、ChatGPT、Claude、Geminiを活用し、14年分のGitHubのコミットメッセージを分析。Laravelの設計思想の進化を取り上げます。

特に以下の観点から解説します：

• 黎明期のシンプルさから、モジュール化への進化（Laravel 3-4）：Composerの採用とFacadeパターン導入
• 現代的アーキテクチャへの転換（Laravel 5-8）：サービスコンテナ導入がもたらした開発体験の変革
• パフォーマンスとスケーラビリティの追求（Laravel 9-）：Octaneの採用に見る実行モデルの転換点

生成AI時代だからこそ、コードを書くだけでなく「なぜそのような設計を選んだのか」を理解することが求められる今日。
先人たちの試行錯誤から、私たちの開発に活かせるアイデアの種を見つけましょう！

本セッションでは、CSVファイルのダウンロード速度が遅すぎて切り戻しになった知見をもとに、Laravelアプリケーションのパフォーマンス改善のデモンストレーションを行います。
「頑張って作ったのに遅すぎて使ってもらえない」では悲しすぎるので、ご参考にしていただけますと幸いです。

以下のテーマに沿ってデモをしていく予定です。
・ しくじり談
・ DBからのデータ取得時に気をつけること
・ 取得したデータを加工するときに気をつけること
・ 加工したデータを出力するときに気をつけること

キーワード
・ Eloquentとクエリビルダ
・ N+1問題
・ メモリ
・ ジェネレータ

想定視聴者
パフォーマンスを意識したコードを書ける・レビューができるようになりたい方

ISUCON は「いい感じにスピードアップコンテスト」の略で、ほぼ同様の処理をするよう作られた Web サービスの参考実装が複数の言語で用意され、参加者は競技中好きな言語を選んでその性能改善をしていきます。2024 年に実施された ISUCON14 でも PHP 用の参考実装が用意され、実際に PHP を使って参加し、良い成績をおさめたチームもありました。

このトークでは ISUCON14 の問題の PHP 参考実装を使い、時間制限を気にせず、参加者の感想ブログの取り組みを平然とパクりつつ、PHP で優勝チームに勝てるスコアを出せるか試した際の知見をお話します。

かつて PHPerKaigi 2023 で ISUCON12 本選問題を使って同様の試みを行った際は、

• 計測の重要性
• DB ネックの間は他言語と同じような改善が効く
• 処理系へボトルネックが移ると同じやり方は使えない
• AltFPM の有効性
• CPU をより多く割り当てる必要性
• 徹底的にやれば PHP でもスコアは出る

といった知見が得られました。
今回もそれらの知見にもとづき同様の改善の道筋をなぞりつつ、FrankenPHP や PHP 製アプリケーションサーバに PHP 8.4 など、前回は存在しなかった・試せなかった取り組みを上乗せで行っていきます。

みなさんPHPStanを使っていますか？ PHPStanはオープンソースで開発されているので誰でもソースコードを読んで仕組みを学ぶことができ、理に適った提案であれば取り入れてもらうこともできます。

ところが静的解析ツールはPHPや標準関数の仕様通りに実装すれば完成すればるというわけでなく、さまざまな考慮事項や現実との折り合い付けかたなどがあります。

本トークでは私がこれまでPHPStanに送信したPull Request(※トークプロポーザル時点で未マージ含め49件)について分類して紹介します。

• 取り入れられた提案
• マージされたPR
• マージされなかった
• マージされたが後にrevertされた提案
• 投げ出してしまって完成していないPR

想定聴講者

• 会計システムや EC サイトなどでお金を扱う開発をしている人
• PHPのstring, float, intがどのように相互変換されるのか挙動に興味がある人
• 設計に興味がある人

話すこと

• PHPでstring, float, intを相互変換するとどのような問題が起きるのか、どのように実行されているのか
• センシティブな数値を扱う時、どのように扱うべきなのか

話さないこと

• 既存の技術選定について
• 既存システムの苦悩と戦いについて

普段開発している時はあまり意識せずに数値を型変換することがあると思いますが、そこには思いもよらぬ潜在的なバグに繋がる挙動が潜んでいます。

会計システムを作る時にPHPの数値仕様をしっかり理解した上で作らないと、後々大変なことになってしまう可能性があります。
小数点以下の誤差によって1円が消えたり増えたりしてしまうことがあり、1円の行方を巡って終わりのない、解決もしない調査の旅に身を投じることになるでしょう。
それが今なのか、いつなのかは分かりませんが、知っていれば防げる問題でもあります。

本セッションでは数値にはどんな問題があり、扱う時に何を気をつける必要があって、さらに扱いやすくするためにおすすめの方法をお話しします。

私はアドテクノロジーを扱う会社で、広告配信の制御や入稿を行うための管理システムの開発を行っています。そのシステムでは社内用の広告配信設定の管理、メディア用レポート閲覧、広告配信設定機能が行えます。

歴史的経緯から3つの管理システムが存在してます。

• 10年以上の歴史を持つ古い社内・社外向け管理システム(PHP + CodeIgniter)
• 社内向け新管理システム(PHP + Slim)
• 社外向け新管理システム（Go）

1番のシステムは10年以上保守運用されており、システムも運用も把握しきれない部分が多く、フレームワークの保守も厳しくなってきました。過去に何度も古い管理システムを葬ろうと挑んでは、志半ばで取り組みが終わることを繰り返してきていました。今回、古い管理システム の葬りが完了する目処が立ちました。

今回の発表では、 「過去、なぜ、移行しきれなかったのか」、「今回、なぜ、移行の目処が建てられたのか」、「今回の移行戦略」 をお話します。

具体的には以下の戦略を取りました。

• ロードマップを作成
• ステークホルダーに宣言
• 移行をやり切るためのサポート（ヒアリング、移行アナウンスや進捗の分かるシートへのリンクを表示）
• 旧管理画面の解像度を上げる工夫（Xdebug によるデバッガ、OpenTelemetry + Jaeger による SQL ログなど）
• 自動テストの拡充

聞いてほしい人

• 長年改修されてきたシステムのリプレイスや移行を考えている人
• 移行タスクが志半ばで終わった経験がある人
• フルサイクル開発の仕事の進め方に興味がある人

皆さんOpenSearchを活用してますか。

自社プロダクトのパフォーマンスを上げるためにAmazon OpenSearch Serviceを採用してます。
今まで事業部の人が事業運営する上で欲しいデータをエンジニアが直接DBから抽出して、都度共有していました。
OpenSearchからじゃないと取得しづらいデータがあり、そのデータが必要になるたびにエンジニアが稼働していました。
そこでエンジニアの負担を減らすために誰でもGrafanaからデータを見れるようにしました。

実際に可視化する上でつまづいた点を実践的なステップで紹介します。

本LTが参考になる人
・可視化する上で選択肢として何があるのか分からない
・どういう観点でデータを可視化すべきか分からない
・AWSアカウントを跨いでデータを可視化したい
・データを可視化するためだけでOpenSearchを外部公開したくはない

本LTを通じて、皆さんもOpenSearchとGrafanaの翼を授かって、新しい世界に羽ばたきませんか？

「テストがないコードはレガシーコードだ！」
Webアプリケーション開発においてテストコードが書かれることは一般的になってきました。

ですが、テストにかかる時間は適切でしょうか？ テストにかかる時間は開発スピードに大きな影響を及ぼします。
本トークでは自動テストを高速化するための考え方やテクニックについてお話します。

想定観客

• テストにかかる時間を短縮したい方

お話しすること

• Google提唱の「Test Sizes」を取り入れて、テスト対象をCIとローカルで変えるテスト戦略
• テスト実行の並列化 (Makefile, xargs, paratest)
• CIをジョブ分割して体感速度を上げる
• OPcache有効化とXDebug無効化による高速化

私たちは、プロダクトコードの中でさまざまなコードをtry-catchで囲み、ばしばしエラーを処理しています。
そしてエラー処理にはさまざまな選択肢があることを知ります。
例外を投げっぱなしにする（そもそもキャッチしない）、例外をキャッチして処理する、あるいは例外をキャッチしてうまく戻り値を定義する、など...です。

これまでプロダクトコードのみでの経験だった私は、OSSのコードを見て、「こんなアプローチもあるんだ」と新たな視点を得ることが多くありました。
特に例外処理に関しては、さまざまな場面での使い方や選択肢を知り、自分の考え方が広がりました。
このトークでは、プロダクトコードを書いていく中で実践的に得た知見と、OSSを通じて新たに学んだ例外処理の手法や考え方を深掘りします。

話すこと

• プロダクトコードにみる"例外処理"の扱い方
• OSSにみる"例外処理"の扱い方
• キャッチしたい場面・したくない場面
• 投げっぱなしにしたい場面・したくない場面
• 最適な選択肢をどう選ぶか

本番環境のプロファイルを継続的に取得する継続的プロファイリングは、ログ・メトリクス・トレースに続く可観測性ツールにおける4つめの柱として近年注目を集めています。
Datadog や Blackfire などの商用サービスもPHP向けの継続的プロファイラをリリースしており、PHPアプリケーションのモニタリングでも今後さらに注目されていくことでしょう。

さて、OSS の可観測性ツールとしてとても人気がある Grafana を開発する Grafana Labs は 2023 年、Pyroscope という継続的プロファイリングツールを買収しました。
私も Grafana を使っているので、Grafana で PHP アプリケーションのプロファイルも監視できるようになるのでは？と思ったら、なんと Pyroscope は現在 PHP に対応していません😭

「Grafana で PHP アプリケーションのプロファイルが見たい！ Grafana にメトリクスやトレースと一緒にプロファイルが並ぶかっこいい画面が PHP でも見たい！」
この夢を叶えるために、PHP プロファイラである xhprof のプロファイル結果を Pyroscope で受け取れる形式に変換するライブラリを自作しました。

本トークでは、

• PHP プロファイラ（ xhprof, phpspy など）の仕組み
• xhprof のプロファイル結果を Pyroscope に送る方法
• 継続的プロファイリングによる PHP アプリケーションのパフォーマンス改善
  についてお話しします。

本トークを通じて、

• 継続的プロファイリングを使ったパフォーマンス改善の明日役に立つ実践的な知識
• PHP プロファイラの2種類の仕組みや pprof フォーマットについての明日役に立たない豆知識
  をお届けできれば幸いです。

ECサイトでのオンライン決済は当たり前の時代となっています。
オンライン決済の中でもクレジットカードでの決済を利用した方はかなり多いのではないでしょうか。
しかし今、クレジットカードの不正利用が問題となっており、経済産業省は2025年3月31日までに3Dセキュア2.0の導入を義務化しています。
3Dセキュア2.0とは何なのか、何を考慮すればよいのかをLaravelとStripeをサラッと使いながら軽く説明します。

今すぐ社内用のWebツールを作らなくてはいけなくなったので、いまからこの部屋で、20分だけ仕事をさせてください!

2025年現在、OpenID Connectが多くのIDプロバイダーに実装され、とても良い時代になりました。
PHPでのライブラリも多くあり、OktaやOneLoginなどを社内で使っている方なら、すぐに社員にアクセスを限定した簡単なWebサービスを作成可能です。

今回は、OpenID Connectで社員情報を認証、認可するところまでをBref(serverless on AWS Lambda)でライブコーディングし、
20分で社内Webツールが初心者でも簡単に作れるところまでを実践します。

みなさん、もっと気軽に会社のアカウントで認証認可、やっちゃいましょう!