プロポーザル

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PHPでResult型（クラス）を再現してみるセッションです。
Result型とは、処理結果を「成功（Ok）」または「失敗（Err）」のいずれかの値として表現し、例外を使わずにエラー処理を構造的に記述するための手法です。

本セッションでは以下について話す予定です。
・Result型（クラス）の説明
・PHPでResultを実現するとどんな感じになるのか（コード例を交えて解説）
・自分なりに考えるPHPでResult型（クラス）を使うメリット・デメリット

多くのレガシーな PHP コードベースでは、インスタンスクラスを使わず、静的メソッドを関数のように扱うスタイルが一般的に採用されてきました。

しかしこの設計は、特にユニットテストの観点から見ると、静的メソッドのモックが難しいという課題があります。一般的なテストフレームワークでは静的メソッドのモックがサポートされておらず、そのため開発者は StaticMock のようなライブラリに頼る必要があります。

ただし StaticMock では、モック対象のメソッドが静的解析されないため、IDE のコードジャンプ機能が効かないといった不便さがあります。

そこで注目したいのが、PHP 8.1 から導入された「第一級 callable」構文です。これを使えば、静的メソッドをクロージャとして渡すことが可能になります。

本トークでは、この新しいアプローチとその実践的な活用方法について紹介します。

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

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

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

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

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

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

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

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

対象者

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

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

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

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

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

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

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

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

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

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

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

「抽象化していますか？」ーー抽象化と聞くと、設計やモデリングをイメージするかもしれません。他にも、interface のような言語機能を利用することを思い浮かべる方もいるかもしれません。たしかにこれらも抽象化の一つですが、それだけではありません。また、抽象化には難しそうなイメージを持たれがちですが、実はソフトウェア開発を行なっている私たちにとっては日々利用している身近なものです。

本セッションでは、抽象化（と具体化）という考え方を整理し、設計や言語機能だけでなく、物事の理解や共有、課題解決、トラブルシューティングといった開発現場の広い場面でも活用できる「思考の技術」として具体的な例とともに紹介します。

「使える思考のツール」として抽象化を一緒に見ていきましょう。

概要

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

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

ターゲット

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

概要

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 の交代ユーザー方式を利用して安全かつ効率的にパスワードローテーションを行う実装パターンを紹介します。