みなさん、PHPのテストを書くときに「他のクラスや依存関係のせいでテストが難しいな…」と思ったことはありませんか？
そんなときに役立つのが、PHPのモックフレームワーク Mockery です！

Mockeryを使えば、依存するクラスやインターフェースの動作をモックして、テストをもっとシンプルに、効率的に進められます。このトークでは、Mockeryの基本的な使い方から実際の業務で役立つテストケースまで、具体例を交えて解説します。

取り上げる予定の内容はこちら！

• モックを使ったメソッド呼び出しの検証方法
• 高度な引数の比較を使った柔軟なテスト
• 実務でのテストケースの実例紹介

Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

「アジャイルなんてオシャレな自社開発企業だけの特権でしょ？」

そう思っていた時期が自分にもありました。

その後、自組織へのアジャイル導入を主導し、実践を重ねた今となっては、アジャイルはチーム単位や、ひとりからでも始められる！と確信しています。

このセッションでは、アジャイルの魅力、そして「はじめの一歩の踏み出し方」についてお話しします。

こんな人に聞いて欲しい

• アジャイルのことは知っているけど、まだ実践できていない人
• 受託開発だからアジャイルは無理、とあきらめてしまっている人

お話しないこと

スクラムや XP などについての細かいお話はしません。

現在担当しているプロダクト（建設DX領域のバーティカルSaaS）で多言語対応プロジェクトに参画した際の学びを共有したいと思います。

背景

プロダクトは10年以上運用しているものでリポジトリのファイル数は3千を超えます。
図面を見たり写真を撮ったりという標準的な機能のほか、外部機器と連携して検査をするというオプショナルな機能をあわせると30以上機能があります。
標準的な機能は多言語対応が完了していましたが、オプショナルな機能をこれから多言語対応していくというタイミングでした。

本トークで話すこと

• サービスを多言語対応をするうえでそもそも起こりうる、日本語と英語で文字数や記号による違いなど、表現について。
• 長く運用しているプロダクトの複雑な仕様を理解しながら進める多言語対応。
• 考慮不足によって発生したバグからの学び。

発表者について

プログラミング歴約2年半で転職して入社した会社での話し。
入社から数カ月後に参画したプロジェクトが多言語対応でした。

対象者

これから多言語対応をする予定の方、今多言語対応している方。
多言語対応で起きる問題に興味がある方。

皆さんはパスキーと聞いて何を思い浮かべますか？
なんか新しいすごいやつ、パスワードがいらないやつ、顔認証するやつ、デバイス間で同期してくれる、公開鍵暗号、チャレンジ………

このトークでは、近年GoogleやGitHubなど主要なWebサービスでも採用されてきている新しいユーザー認証方法「パスキー」に入門します。

• パスキーとは何か
• パスキーで何ができるのか
• なぜパスキーが推されているのか
• 従来のユーザー認証と何が違うのか

などのような基本的な部分から、

• パスキーでログインをするために必要な実装
• パスキーを実装する上での注意点
• パスキーを運用する上での注意点

など発展的な部分まで、一通りパスキーでの認証ができるようになるレベルを網羅します。

このトークがお勧めな人

• パスキーに興味がある人
• ID / パスワードによる認証とさよならしたい人
• よりセキュアなユーザー認証を実現したい人

このトークで得られること

• パスキーの仕組みの理解
• パスキーの実装方法
• パスキーの運用のあれこれ

皆さんはゲーム大好きですか？
わたしもネットがあまり普及されてない頃、攻略本を片手にずっとゲームをやってました。

実はPHPにも攻略本があります。ナ、ナンダッテー！？
全て印刷したら六法全書になるであろうボリューム。その名はPHPマニュアル！
本当にコントリビューターの方々には頭が上がりません。いつもありがとうございます。

もちろん、、、PHPerと名乗るからにはPHPマニュアルマラソンをやったことありますよね？
え？やってない？
それなら、一緒に習慣化するしかない！

この発表を経て、PHPの素晴らしさを再認識しましょう！

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

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

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

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

テストコード実装によるアプリケーションの実装設計や中長期の運用メンテナンス性に変化が出た話をします。
当初、ファットコントローラーや行数の多いメソッド、ライブラリへの依存性高い設計などが原因で、メンテナンスしにくいPHPアプリケーションを運用していたチームがテストコードの実装から技術負債を徐々に解消していけるようになりました。
理由は「テストコードを入れやすい実装と設計」をするようになったこと。
挙げた課題へどのような実装・設計の変化が起きたかリファクタリングの具体例や、テストコード導入によるコード設計の変化を紹介します。
またテストコードによるリプレイスを叶えたアプリケーションを立ち上げた事でPHPやフレームワークバージョンアップへの適用性、テストコード実装スピード向上やコードレビュー時のコミュニケーションの変化についても語ります。

新卒から6年間所属した部署から大異動で全く別のチームに配属された先には鳴り響くアラートの日々が待っていました。
みなさんも、プロダクトの監視の状況で以下のようなケースに出会ったことはないでしょうか？

• 何をしたらいいのか、何が問題なのかわからないアラート
• 既存チームメンバーから無視され続けているアラート
• アラートが来ても反応するメンバーが限られている、対応できるメンバーが限定的
• アラートが頻繁に来ていてチームがアラート対応に疲弊している

上記のアラートについて見ていくと異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• ほとんどのケースにおいて問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• メンバー間のアラートに対する認識齟齬

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• 一緒に見直していく仲間を増やしていきたい人

皆さんは、Laravelでの定期実行をどう実現していますか？？

我々のチームでは、サービスをECSにてデプロイしていることもあり、Laravelのタスクスケジュール機能を使わない選択をしました。

しかし、ECSのLaravelサービスに対して定期実行する方法には、以下のようなものがあります。
・ECSのスケジュールされたタスク
・Amazon EventBridge SchedulerからのECSタスクの実行
・Amazon EventBridge SchedulerとLambdaを使用したAPI呼び出し
この中から「早くて安くて安心な」手段を選ばねばなりません。
そこで、AWSのコストを抑えつつ、必要な要件を満たし、運用が簡単な方法を見つけるべく我々はアマゾン（AWS）の奥地へと向かいました。

そして冒険の果てに見つけた、最適な定期実行の方法をお話します。

DKIM、DMARC、SPF
これらを説明できるでしょうか？

これらの技術はメール認証技術であり、フィッシングやスパムから守るために重要な役割を果たします。
2024年4月から本格的に始まったGmailのガイドラインに基づくメールの受信拒否設定によって、メールセキュリティの考慮は他人事ではなくなりました。
これは、非エンジニアにとっても同じです。
場合によっては、サービスの利用者にGmailガイドラインに対応するよう依頼する必要があるからです。

しかしながら、これらの知識はどうしても専門的な技術知識なしでは説明しづらく、非エンジニアにとってはなおさら理解しづらい分野です。
難しい専門用語を使わないよう注意しながら、非エンジニアの方に理解してもらおうと頑張って資料を用意して説明した方も多いのではと思います。

この発表では、非エンジニアの人にも伝わるよう、今押さえておくべきメールセキュリティについて解説します。

仕事の内容をドキュメント化することで得られるメリットはたくさんあります。

• 多数の人に内容を共有できる
• 言った言わなかったの議論にならない
• 後から見返して経緯がわかる

しかし、実際にドキュメントに起こそうとすると面倒に感じ、なかなか実行に移せていない人も多いのではないでしょうか？
また、チームメンバがなかなか仕事内容をドキュメントに起こしてくれず、困っているマネージャーもいることでしょう。

たしかに、物事をドキュメントに起こすことは面倒です。
しかし、逆にドキュメントへ起こさないことによってどのような問題が発生するかを知ることができればドキュメントに起こす気になるのではないでしょうか？

この発表では、仕事内容をドキュメントに起こさないことで発生するデメリットの具体例を示し、なぜドキュメント化をする必要があるのかをドキュメント化を避けるメンバ向けに説きます。

開始前から炎上を宣言されているプロジェクトに参画したことはありますか？

私は昨年、そんな「炎上必須」と言われたプロジェクトに参画し、プロジェクトのマネジメントを行い、無事に完了させることができました。
本トークでは、このプロジェクトにおいて、炎上を抑え込むためにチームで行なった施策とその効果を紹介します。

自社プロダクトを開発している場合、大抵はリリース日程をずらすことで、大炎上を避けることができるでしょう。しかし、稀に何らかの理由で納期必須の開発が行われることがあります。
私たちのチームは、外部システムとの連携が必要なプロジェクトを短納期で開発することになりました。
プロジェクト開始当初のスケジュールでもすでに期限通りの開発は厳しく、また複数の組織が関係することによる仕様決定の遅れが予想され、会社内でも誰もが炎上を覚悟していました。

そんな中、開発チームは様々な工夫をすることで無事高品質な状態でスケジュール通りに開発を終えることができました。
仕様策定、開発手法、チーム構成などをどのように工夫し、どんなカードを切り、工数を抑え、稼働を確保し、プロジェクトを推進したか... 聞いた人が自分のプロジェクトでも活かせるようにそのTipsを解説します。

開発生産性はソフトウェアの品質と市場投入へのスピードに直結します。本トークでは、PHPをメイン言語で扱うチームとして、又は1人のPHPerとしてプロダクトの開発生産性向上へ行ったことを紹介します。

• チームで開発生産性に向き合う文化醸成や改善への行動。
  ┗どのようにPRを分割するか・設計時に考慮すべきポイント・チームの士気向上などの変化について
• 中長期的な開発生産性向上への行動。
  ┗テストコード設置やPHP・フレームワークバージョンアップ運用とアプリケーション基盤作りについて
• リリースサイクルを上げるための取り組み。
  ┗PHPプロダクトでのFeature Flag導入や運用フローの変化について

個人・チーム開発で生産性向上を目指していける具体的な手法や経験談の話をします。

backward compatibility、訳すると「後方互換性」です。タイトルをかっこ良くしたかったので英語にしています。
本発表は、リリースエンリニアリングの観点から、後方互換性というテーマに絞った内容になります。
サーバ運用やSchema管理、テスト環境におけるデータの差異がもたらすリスク、Mobile Appのバージョン管理まで、リリース時に頭を抱えない為のTipsと実例について解説します。

・リリースエンジニアリングと「後方互換性」
・テストが担保する後方互換性と、担保しない後方互換性
・サーバ運用時の後方互換性と、リリース順序、ロールバック
・GraphQL schemaの後方互換性と、Schema変更時のルール
・Mobile appの後方互換性と、強制アップデートのユーザー影響

概要

我々PHP界隈は最近、高年齢化が危惧されています。
「若手が居ない、育たない」と嘆いているそこのあなた！！具体的に対策できてますか？
その原因は主に以下の2つと考えます（偏見）

• 凝り固まったシニア層がやり方を変えないため新しい風が起きにくい
  • 新しい技術の導入が最近少なくないですか？
• 若手が参入しようにも入る余地がなさそうに見える
  • 若手が活躍する場が限られていませんか？

この問題を解決するために最適なソリューションが読書会です。
他の言語でもフレームワークでもフロントエンドの技術でも。
何でも良いので、普段自分がいない集団の読書会に参加してみましょう。
今まで知らなかった新しい考えや全然違った常識にきっと打ちのめされるはずです。
でもそれで良いんです。知らないことを知るっていうことはそういうことです。
シニアエンジニアもまだまだ知識とチャンスを得る機会があるんです。

我々シニアのエンジニアがもっとネットワークを広げ、かつ若手を取り込むための第一歩。
その読書会がいかに良いソリューションであるかをお話します。

対象の人

• ベテランのエンジニア
• PHP以外の界隈と普段交流を持たない人
• 若手にもっと来て欲しい人

得られるもの

• 若手を増やすことの要素で何を大事にしないといけないか
• 凝り固まった価値観に意外と支配されているという気付き
• 自分が普段属していないコミュニティの人たちと触れ合うことによって得られる視点や知識

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

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

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

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

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

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

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

聞いてほしい人

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

私が担当しているメール共有サービスのメールディーラーではE2Eテストを導入することで、一定以上の品質を担保することに成功しました。

E2Eテストを導入したことの効果やテストコードの実装やテストケースの作成で工夫しているポイントなど、
メールディーラーのテクニカルリーダである私が可能な限り具体的に事例をもって説明いたします。

メールディーラーは2001年にローンチしましたが、フレームワークを導入しておらず、
DBアクセスとHTMLの生成をひとつのプログラムで行っています。

内部構造のアーキテクチャもさることながら、プログラム構造の陳腐化がリリースを行うごとに進みました。
いわゆる「スパゲッティコード」が散在し、それらがサービスの品質にまで影響するようになりました。

具体的には、ある共通関数が別の共通関数を呼び出し、
それが繰り返されることでプログラムが複雑にネスト化しています。

その結果、コード全体の把握が難しくなり、修正前に十分な影響調査ができない状況が生まれました。
このような状況下で、思ってもみない機能に不具合が混入し、
新機能のリリース直後に改修していないはずの機能で「画面が表示できなくなる」といった致命的な障害が発生しました。

そこで対策としてE2Eテストの導入と自動化を行いました。

通常の開発と並行して約3ヶ月という期間で273画面に対してテストコードを実装し、
導入後は「画面が表示できなくなる」といった致命的な不具合の発生を防止することができました。

限られた期間とリソースでどのようにして、当初の目標通りの成果を出すことができたか？をご説明いたします。
本セッションを通じてE2Eテストの導入や品質担保の参考になれば幸いです。

Promiseについて、「分からん！」から「そんなものもあるんだ」を経て、「そういう風になっていて、そう動くのか」に至るためのトークです。
Promises/A+の世界観や、概念レベルの「何を課題とし、どう解決を試みるパターンなのか」の共有から入り、
PHPでの実装例を参考にしながら「こうやるんだね」を見ていきましょう。
最後には、低機能で愚直なPromiseオブジェクトを生み出す所まで話を進めます。

PHPを利用した普段の開発では、 Promise を目にすることはあまり無いかも知れません。
しかし、ライブラリの中身などを読んでいると「意外と出てくるよな」と私は感じました。
guzzlehttp/promisesやreact/promiseといったPHP実装が、しばしば登場します。
コイツと仲良くなれたら、少し幸せになれるのではないか…？と感じたので、解剖してやろうと考えたのです。

特に、「Guzzle使っていてPromiseクラス出てきたけど良くわかんないで雰囲気でやっているなー」という人には役に立つはずです。

概要

Promiseパターンについて興味がある人に向けて、概念の説明とPHPでの実装例を示します

このトークで得られるもの

• Promiseについて知る
• 「PHPでできること」「PHPっぽい実装」について知る

あまり話さないこと

• ライブラリ自体の詳細、活用法

対象とする人

• 「Promiseって聞いたことがある気がするな」レベルの人
• 「ふんわりとは知っているけど、PHPでの実装は考えたことがなかった」という人

おそらく対象外であろうと思われる人

• JavaScriptやPythonなどの他言語で、日常的にPromiseを扱って精通している人

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

リッチな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におけるフロントエンド技術選定の参考になれば幸いです。