「オブジェクト設計スタイルガイド」は、オブジェクト指向のパワーを引き出し、クリーンなコードを書きたいPHPerにとって必読の書籍です。本セッションでは本書の内容を紹介しつつ、チーム全員の目線が揃うアプリケーション設計やクラス設計に役立つ考え方を紹介します。

本セッションで紹介すること
・Service、EntityとValue Object、DTOの使い分け
・クエリメソッド・コマンドメソッド・モディファイアメソッドの違い
・インターフェースの作成基準

本セッションを通して理解できること
・MVCフレームワークから疎結合なアプリケーションとは何か
・サービス層とドメイン層という言葉が意味すること

本セッションに参加された方が現場に持ち帰って実践できること
・クリーンなコードを書くこと
・レビュー時にコードの良し悪しを言語化できること
・AIが出力するコードを採用するか判断できること

最近、「なぜ動くか説明できないコードをプッシュしていた」自分に気づかされました。
レビュワーの指摘を受けて初めて「この中ってこうなってたのか」と気づいたり、それをスラッと追う先輩への驚きを感じたのを覚えています。
そこで、自分なりに「ちゃんと読めていない」原因や改善策、コードを書く上での行動を振り返りました。
結果として、バリデーションの中身を理解した上で既存コード修正→マージまで持っていくことができたので、
本トークでは上記を通じて見つけた、以下手法についてお話しします。

• 「読めたつもり」を防止する読み方
• 「説明責任を果たすコードが書けたか？」を問うセルフチェック方法

ぜひ聴いていただきたい層

• 自分のように「感覚で読んでいる」「読めたつもりが起こる」といった悩みを抱えた初学者
• 後輩や新人とコードを読む／レビューする立場の先輩やベテラン

ブログであれば『下書き』や『公開』、『承認待ち』など、様々な状態を持っているデータがあります。
その状態はサービスの至るところで更新する機会がありますが、思ってもいない状態に遷移して
開発後に頭を悩ました経験がないでしょうか？

そんな"状態遷移"に悩まされた経験談と、それを一元管理する『ワークフロー』の導入と開発、
それによって得られた恩恵についてお話しします。

かつてLaravelプロジェクトにドメイン駆動設計（DDD）を導入したものの、
期待した効果が得られず、プロジェクトは思うように進みませんでした。

その当時は以下のような課題がありました。

• いわゆる軽量DDD的なものにならざるを得なかった
• 開発工数が増えるばかりで効果を実感できなかった
• チーム内での理解が進まなかった

このセッションでは、DDDがうまく機能しなかった理由や直面した課題を振り返り、
改善のためにどのようなアプローチが有効かを考察・共有します。

さらに、Kent Beck氏の著書『Tidy First?』が、私の経験を言語化し理解を深めてくれたことについても紹介します。

本セッションはDDDを否定するものではなく、実践の中で得た教訓と再挑戦のヒントを共有することを目的としています。
DDDを活用するための一助となれば幸いです。

約10年間事業を支えてきたLaravel製のシステムを関数型スタイルでリファクタして得られた知見を話すセッションです。

「背景」
事業とともにシステムが成長していくなかで技術負債も多く抱えることになり、その結果システムの認知負荷が高まってしまいました。
そんな現状を改善するため、「関数型ドメインモデリング」の要素を取り入れて一部リファクタリングを実施しました。
本セッションでは、その活動のなかで得られた知見をお届けします。

「注意点」
PHPで関数型を再現する訳ではなく、関数型プログラミングの中でPHPで取り入れられる要素を使ってリファクタリングを行っています。

本LTではAWS Lambdaを題材にLambdaで開発したアプリケーションにおけるセキュリティリスクの1つの解説し、そのリスクをみなさんにも体験していただきます。
お手元に用意いただくのはスマートフォンのみです。

5分でセキュリティリスクを体験してみましょう。

■背景
決済プロダクトのバックエンドエンジニアをしています。
これまでずっとJavaで開発をしていましたが、プロダクトの面白さに惹かれてPHPを技術スタックとしている会社に転職しました。

■テーマ
今では転職して約1年が経ちます。
別の技術スタックからPHPをベースとしたシステムの開発現場に入るとどんな大変さがあって、それをどう乗り越えてきたかを経験からお話します。

■ポイント
・コードを読んでアウトプットする
・ローカルルールを学ぶ
・テストコードと向き合う
・PHPの良いところ
・Javaの経験が活きた場面

知らず知らずのうちに技術的負債が溜まっていませんか？機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、 SOLID原則への理解不足や誤解にあるかもしれません。

SOLID原則はソフトウェア開発において保守性の高いコードを書くための重要な原則の一つですが、難しい言葉が並んでいて理解が難しかったり、誤解されやすい面があります。

本トークでは、SOLID原則についてアンチパターンやPHPでの実践例を交えながら解説し、その活用方法やメリットについてお話しします。このトークを聞けば、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

対象者

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則は聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていない人

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

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

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

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

ジョシュアツリーの法則って知ってますか？
「名前を知ればそれを認識できるようになる」「名前を知らないと認識できない」といった現象のことです。

我々エンジニアの身の回りには様々な現象があり、中にはみんなが経験したことがあるものも多数存在します。
そんな「現象」や「事象」の中にはあまりにも名前が付けられ、事象の解消や共有が行われているものがあります。
名前を知ることは認識すること！
この発表を聴いてそんな""あるある""の名前を知り、事象を正しく認識して、次に生かしましょう！

ローンチから2年が経ち、最低限の機能が一通り揃ったプロダクトにおいて、次に取るべき行動は何か...

プロダクト立ち上げ直後は、ユーザへ価値を提供できる最小限の状態を目指して開発を進める必要があります。しかし、その後はどうすればいいでしょうか？
私が担当する保育園探しのプロダクト「えんさがそっ♪」では、立ち上げ当初に予定していた機能が大体揃い、次に進むための検討を始めたところでした。
これにより、次の一手をビジネスチームと一緒に考えることになりましたが、ビジネスサイドからの要求を実装することがメインの仕事であった開発チームが主体的に動けるようにするためには、いくつかの仕掛けが必要でした。
複数のサービスを運営する組織の中で、率先してプロダクトを次に進めるチームをつくるために行ったこととその考え方をお話しします。

レイヤードアーキテクチャをはじめとした多くのレイヤ化アーキテクチャでは、依存の逆転を用いてレイヤレベルで技術的な関心を分離しています。
なぜこれがアーキテクチャとして好ましい構造につながるのでしょうか？

このセッションでは、技術的関心を分離することが実利に結びつく理屈を変更コストや優先順位、認知負荷などの観点から全力で考察し、いわゆるインフラ層についての理解を深めることを目指します。

概要

カンファレンス登壇してみたいけど、難しそう。。。
そんな印象をお持ちな方（もしくは持っていた方）結構いらっしゃるんじゃないでしょうか？

しかしその印象はもしかしたら誇張して見えてる高いハードルかもしれません。
テストを書くかの如く、テストケースを洗い出してステップを明確に可視化し、登壇に挑戦してみてはいかがでしょうか？

ターゲット

• 登壇に興味はあるけど、一歩踏み出せない方

概要

DevinはCognition AI社が開発した自律型AIエージェントです。
使いこなせれば便利なのは想像がつくけれども、ついつい自分で書いてしまう癖が抜けない。
このままでは全く習得できず、変化に適応できない焦りから、とあるAPI実装をDevinでやりきる意思を持って挑んでみました。
果たしてその結末やいかに。

ターゲット

• Devinに興味はあるけど、手を出せていない方
• Devinの実際の使用事例を知りたい方

お話すること

• Devinに依頼したタスクの概要
• Devinがうまくやってくれたこと
• Devinが苦手なこと
• Devinが生み出した成果
• 今後のDevinとの付き合い方

概要

PHPでWebアプリケーションを作る際、ほぼ全てのケースでデータ永続化の為にデータベースを利用するでしょう。
長年運用していくにつれ、テーブル数やカラム数の増加によって、認知コストやコミュニケーションコストが増加する一方です。
これらの負荷を下げる為に「DBスキーマを可視化する」ということは非常に有用であり、tblsは継続的な運用に耐えうるだけの機能を持ち合わせています。

本トークではtblsの便利な機能の紹介や、実際に運用している時に得られた知見、AIによるSQL生成などのTipsを紹介します。

ターゲット

• ドキュメントの自動生成やCIによる運用改善に興味のある方
• チーム内でのスキーマ共有・認知コストを下げたいと考えている方

概要

2025年現在、生成AI関連のソフトウェアは次々と登場しており、PHPerとしてもこの波に乗り遅れるわけにはいきません。
業務効率化や開発生産性の向上を目指すうえで、AIの活用はもはや無視できない選択肢となっています。

とはいえ、AIまわりのトレンドは変化が激しく、2週間もあれば新しい技術やサービスが登場するような状況です。
何から手を付けていいのかわからず、情報収集に疲れてしまっている方も多いのではないでしょうか。

本登壇では、ChatGPTのような有名サービスから、話題にならないツールまで、幅広く紹介します。
実際の事例を交えながら、「PHPerが今、AIとどう向き合うべきか」を具体的にお伝えします。

ターゲット

• AIに興味はあるけれど、何から始めればいいか迷っている方
• 最新ツールを業務に取り入れて、開発を効率化したいと考えている方

概要

Laravel開発でおなじみのコレクション操作、その裏側に潜む「yield」の力を最大限に引き出すのがLazyCollectionです。

本トークでは、PHPのyield構文の動作原理を紐解きつつ、なぜLazyCollectionが高速でメモリ効率が良いのか、Collectionとの違いについて内部の仕組みを追いながら丁寧に解説します。
また、実際に現場で使われているユースケースやテクニックについても紹介します。

ターゲット

• 大規模なデータを扱っている人
• ライブラリや処理系の実装から理解をしたい人

近年、データベースのパスワードを定期的に更新することをセキュリティ要件として課す組織が増えています。
しかし、対象となるデータベースが多くなるほど手動での更新作業は難しくなります。

AWS Secrets Manager の自動ローテーション機能を使えば運用を自動化できますが、シークレットをキャッシュする仕組みを組み込む際、PHP アプリケーション側の実装が煩雑になりやすいという課題があります。
本セッションでは、この問題を解決するために、PHP から Secrets Manager の交代ユーザー方式を利用して安全かつ効率的にパスワードローテーションを行う実装パターンを紹介します。

概要

PHPの実行環境として長らく主流だったApacheやNginx＋PHP-FPMに対し、近年登場したFrankenPHP。
本セッションでは、Laravelによる実アプリ検証を通じて、移行時に検討すべきポイントや設定値の相違点などの観点から紹介します。

紹介ポイント

• 従来のApache/Nginx + PHP-FPMとの設定値や挙動の互換性
• Laravelでの動作確認と制限事項
• セッション・ファイルアップロード処理の注意点
• Docker・CI/CD環境との連携や調整ポイント
• そもそもどんなプロジェクトでFrankenPHPは向いているのか？
  etc

従来環境との違いを踏まえ、FrankenPHP導入の難易度やメリット・デメリットをお伝えします。

ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというものです。

このトークでは私が作成した2つのバージョンのCPUを題材に、以下の様なことをお話します。

• 少ないGPIOで多くの信号線をコントロールする工夫
• CPUを作るというのは具体的に何をするのか
• 手配線で作るCPUと基板発注して作るCPU
• 自作CPUのデバッグ方法
• Linux上でプログラムを動かすことのメリットとデメリット
• 全てを手放して速度を得る - ベアメタル開発

このトークを聞いた方が「CPUを作るというのはどういうことか」をちょっぴり理解し、CPUやハードウェア自作が好きになることを願っています。そしてあわよくば一緒に自作CPUを楽しみましょう！