LaravelのORMであるEloquent。さっと使いたい時はとても便利ですが、使い方を誤るとパフォーマンスの低下やセキュリティホールになりかねません。
そこで本トークでは実際にコードを見ながら、EloquentはどのようにしてDBを操作しているのかを見ていきます。

話すこと
・Eloquentの内部構造

話さないこと
・Eloquentを利用した実装

弊チームではこのたび、15年間誰も手をつけられなかったレガシーシステムを、バグ0でフルリプレイスすることに成功しました。

チーム発案のオリジナル検証手法をはじめ、シャドーテスト、カナリアリリース、ダークローンチ、フォールトマスキングなど、
多彩な手法を駆使することで、リスクを最小限に抑えながら安全に倒し切ったリリースを実現することができました。
どのように予期せぬトラブルを未然に防ぎ、計画通りのリプレイスを成し遂げたのか。その実践的なプロセスについて、詳しく解説します。

他のプロジェクトでも応用可能な知見を共有しますので、レガシーシステムへの手入れを検討している方は必見の内容です。

本セッションの対象者
・日々レガシーシステムと向き合っている方
・テストや検証手法に興味のある方
・フルリプレイス挑戦記と聞いてワクワクした方

$_GETや$_POSTなどのスーパーグローバル変数と呼ばれる変数はPHPの実行形式上、無くてはならない存在です。
PHPの入門書でもかなり序盤の方で登場し、その後様々な場面で登場するはずです。

さて、ここで大きな疑問が湧きます。
グローバル変数は良くないと本に書いてあるのにPHPの本ではスーパーグローバル変数をゴリゴリに利用している！こんなことが許されて良いのでしょうか？？？？
いいや良くない！！！

ということで本トークではスーパーグローバル変数における問題点について言及したいと思います。
また、そのスーパーグローバル変数の問題を、有名なフレームワークではどのように解決しているのか、我々はどのように解決したら良いのかについてお話したいと思います。

タグ

• グローバル変数
• ミュータブル・イミュータブル
• テスト
• PSR7

良い設計は「コードの書き換えやすさ」をもたらします
そのためには、関心の分離や抽象度の調整といった仕事が必要です。難しそうですね¯\(ツ)/¯

見方を変えれば 今、一緒に考える?後回しにしたい?を意識すれば、良い感じになりそう と言えるでしょう
コードを書きながら「ここ面倒臭いな」と思う場面、ありますよね？そこにヒントが眠っています

原則やパターン等の形式知だけでなく、感覚に頼って「良い設計」を手に入れられるはず！！というのが本トークの主張です

話すこと

• プログラミング中の「(誰しも)あるある話」を取っ掛かりに
• 実はそれがチャンスであることと、対処法を示し
• 「何故それで良いと言えるのか」の論理的な補強を行う

ねらい

• こんな人に: 「設計って難しそう・自分にはまだ早い」と感じている人
• こんなお土産を: 「良い設計を目指す最初の一歩」になる

「ライブラリが古いせいでやりたいことが出来ない」「利用バージョンのドキュメントが既にこの世に無い・・・」そんな経験はありませんか？

古いライブラリはセキュリティリスクをもたらし、技術的負債にも繋がります。
本トークでは週次でのライブラリバージョンアップを1年以上続けている実体験をもとに、継続的バージョンアップのメリットや安全に実施するために出来る工夫、はじめ方についてお話します。

想定観客

• バージョンが古いせいで苦しんでいるかた
• ビッグバンバージョンアップでつらい思いをしたかた
• セキュリティやパフォーマンスに敏感なかた

お話しすること

• なぜライブラリをバージョンアップするべきか
• バージョンアップ時に見るべきポイント
• 安全に上げるために整えている仕組み
• 継続的バージョンアップのはじめ方と文化作り

Laravelの魅力の一つであるORM「Eloquent Model」。
雰囲気でも動くものが書けてしまう反面、特定条件下では正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのコード、nullが返ってきたとき死にます
• そのコード、クエリ1,000回発行されるけど大丈夫？
• そのコード、メモリ1GB使うけど大丈夫？
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

仕様確認の遅れや認識のズレで開発が滞ってしまった経験はありませんか？

私は「エンジニア↔︎営業」と「営業→ユーザー」の2つのフェーズで課題に直面しました。
前者は、話し合いが後回しになっていたため、仕様確認の遅れや認識のズレが原因で開発が滞りました。
後者は、エンジニアが思い描くユーザーへのアプローチ方法が営業でうまく使ってもらえず、ユーザーへ価値がうまく届いていませんでした。また、営業にリリースした機能の価値が十分に伝わっていなかったこともありました。

そこで、以下の取り組みを行いました。
・ 何を決めたい時間かがひと目でわかる会議名をつける
・ リファインメントやランチで関係を深める
・ リリース後のアプローチ方法を営業と一緒に決める

このトークでは、エンジニアと営業が協力し、リリース後の価値を最大化するための取り組みと、その結果生まれた変化を紹介します！

PHPアプリケーションをサーバレス環境で動かしたいと思ったことはありませんか？軽く調査していくといくつかやり方はあるようです。

このセッションでは私が実際に様々な方法で簡単なPHPアプリケーションをデプロイしてみてわかったことを共有します。
ホスティング先の参考になれば嬉しいです。

時間の許す限り、以下のようなプラットフォームやツールをセッション中扱う予定です:

• AWS Lambda
• Google Cloud Functions
• Google Cloud Run
• Vercel Functions
• fly[.]io
• Serverless Framework
• Bref

DRY（Don't Repeat Yourself）原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。
私が直面したのは、二つの似た処理を一つのメソッドに統合し、フラグで細かい違いを切り替えるコードでした。しかし、片方の処理を変更すると、もう片方にも影響が出てメソッドが複雑化する…これ本当にDRYなん？と思いました。

このトークでは、当時はDRYだったものが、時間とともに保守性を損ない、結果的にDRYではなくなったケースについて紹介します。
何を共通化し、何を分離すべきかを考え直し、どのようにリファクタリングを行ったかについて具体的な事例を交えてお話します！

「当時はこうでよかったが、今ここに大変更を加えたい」と感じている方や、似たような体験をした方にとって、私の対処方法が参考になれば嬉しいです！

PHPUnitには多くの便利なアサーションが用意されていますが、
わたしたちが普段使っているフレームワークにも独自のアサーションが実装されていることをご存知でしょうか？

普段便利に使わせてもらっているアサーションの中身がどうなっているか、みたことはありますか？
「まだ、みたことない・・・！」という方、このセッションでテストの裏側にある仕組みにDeep Diveし、テストライフをさらに快適にしていきましょう！

話すコト

• PHPUnitがどのようにアサーションの結果をOK/NGと判断しているのかを知る
• 各フレームワークにあるいろいろなアサーションを知る
• 自分でカスタムアサーションを作成するという選択肢を知る

私はスクラムを使って日々プロダクトを作っています。
その中で、スプリントレビューに「手応え」を感じたことがありました。
一方で、手応えがないレビューの時、自分では「うまくいっていない」と気づいていなかったことに後から気づきました。

効果的なスプリントレビューを体験したことで、
過去に「うまくいっていなかった」ことが明らかになり、改善の余地を見つけられました。

このセッションでは、経験主義に基づいて学んだ「うまくいくスプリントレビューのコツ」を具体例と共にシェアします。
また、どのロールの人でも実践できる、スプリントレビューを成功に導く方法についてお話しします。

話すコト

• なぜスプリントレビューを「うまくいかせたい」のか？
• 「うまくいかない」レビューとは？原因は？
• 「うまくいく」レビューの具体例と成功のコツ
• 各ロールごとの素敵なスプリントレビューを創るためのHOWTO

最近、私は多くの人と一緒にプロポーザルを考える機会が増えています。
その中で気づいたこととしては、「話してみたい」と思っていても、それを具体的なトークにまとめるのが難しいと感じる人が多い、ということです。

そんな人たちの背中を、私はこれまで何度も押してきました。
このLTでは、その「背中の押し方」を共有します。
あなたも、身近にいる「トークをしたいと思っている人」や「トークができそうな人」の背中を押してみませんか？

話すコト

• なぜ「トーク応募」を促すのか？〜相手のため、自分のため〜
• どのように「トーク応募」を応援しているのか：問いかけと引き出し
• 受からなくても活かせる方法はたくさんある！

「タスクが大きすぎて進めにくい」「タスク同士が依存して足を引っ張り合う」「ああ、またコンフリクト…」
といった状況に心当たりはありませんか？
少なくとも私は、この悩みを何度も繰り返し経験してきました。

良いプロダクトを迅速に届けるため、開発タスクを効率よくmainブランチに統合していきたい。
その思いを胸に、試行錯誤しながらタスクを「疎」にするための方法を自分なりに編み出してきました。

しかし、「疎にできるけど、疎にしないほうが良いタスク」も存在することに気づいたのです。
この発表では、爆速で効率よくチーム開発をするための「タスクのちぎり方」について話します。

話すコト

• そもそも、なぜタスクを疎にしたいのか？
• 疎にすべき場面とそのパターン
• 疎にしないほうが良い場面とその理由
• リソース効率 vs フロー効率のバランス
• タスクを疎にするテクニックN選（時間の許す限り）

テストに必要なPHP環境を設定できるGitHub ActionsのアクションであるSetup PHP Actionは、PHPの各バージョンに対応しているだけでなく、さまざまな拡張モジュールやツールを活用できます。さらに、マルチプラットフォームに対応しており、LinuxだけでなくWindowsやmacOS上で手軽にテストを実行させることも可能です。このLTでは、テストやOSSのコントリビュートにも役立つ、Setup PHP Actionの使い方を紹介します。

関心を持ち続けながら勉強会に参加していると、ふとしたことがきっかけでさまざまな情報がつながり、点から線そして面に変わり、勉強会で学んだ情報が業務に役立つことがあります。

勉強会でプログラムの本質的構造を示すASTのハッシュ値が同じであればプログラムの変更前と変更後の間に差分がないと判断できるという発表を聞いたことがきっかけで、実際のプロダクト開発においてPHP 8.1からPHP 8.2にバージョンアップする作業の一部をスムーズに進められることに気づき、結果として大幅にテスト工数を削減できました。

この発表では、ASTを取得およびそのハッシュ値を比較する方法やハッシュ値の確認時に留意する点を解説しつつ、ASTがPHPのバージョンアップ時にも役立った事例の1つを紹介します。

登壇をする内容の概要
プロダクト開発を成功させるには、重要な機能にリソースを集中させることが不可欠です。重要な機能にフォーカスすることで、最大の価値と競合差別化を生み出せます。
一方で、重要でない機能を含む全体的なリファクタリングや、コードベースの保守性向上だけでは、こうした成果は得られません。
この登壇では、重要な機能についての考え方とLaravelを使った重要な機能とそうでない機能のコストをかけない機能の実装方法も提示します。

話を聞いた人に持ちかえってほしいこと
聞いた人には、プロダクトの機能を再評価し、リソース配分の優先順位を考え直すきっかけにしてほしいです。また、その考え方をチームで共有し、ディスカッションを通じて話し合う機会を持っていただきたいです。

主な内容

• プロダクトの価値を考える必要性
• どのように優先することを決めるか
• Laravelを使った実装例

自分の書いたコード、レビューもされるし後で自分で見るかもしれない...！
そんな時に「読みやすい、わかりやすい」コードってどういうものだろうか？
を"ちょっと考えてみよう"というトークです。

ジュニアの方もシニアの方も誰でもハードル低く聞ける、けどやっぱり大事だよねっていうトーク内容にする予定です！

SOLID原則・凝集性・結合度・関心の分離・DDD・クリーンアキテクチャ...
設計を考える際、学ぶべき原理や手法が多すぎて圧倒されてしまうこともありますよね。

しかし、これら設計原則は、実は私たちがよく知っている「英語の文法」にヒントが隠されているかも...?
英文法の基本的なルールに着目することで、仮に設計原則を知らなくても、シンプルで明確な設計ができるようになるかもしれません！

このトークでは、SVO・SVOCなど基礎的な英語文法がどのようにコード設計に応用できるかを具体的に解説します。
例)

• S(主語)やV(動詞)の明確化が単一責任原則の遵守に繋がること
• 「S(主語)がV(動詞)した」とクラス設計を考えることの恩恵
• コード上での形容詞・副詞の在り方

想定聴講者

• 設計詳しくないけど興味がある人
• 設計に原理・手法多くてなかなか手を出せないでいる人

弊社の主要な検索機能では、Laravel Eloquentを用いたRDS上の検索クエリにおいて、複数テーブルのJOINや複雑なクエリ構造が検索パフォーマンスに影響を及ぼしていました。特に、利用頻度の高いクエリがレイテンシー増加の主因となっていたため、その改善策としてOpenSearchを導入しました。

導入後、検索速度が飛躍的に向上し、レイテンシーも大幅に改善されました。
また、OpenSearchのPHP DSLライブラリを導入することで、クエリの構築をシンプルにし、保守性を高める工夫も行いました。

Laravel eloquentとの共存を図りながら、検索機能のパフォーマンス最適化を実現しました。
これらの経験を基に、検索機能改善の実例を紹介します。

このトークは、パフォーマンスに課題を抱える開発者や、検索機能の改善に興味のある方に向けた内容です。

サービスは生き物のようなもので、放置すれば腐ってしまいます。
適切なメンテナンスとアップグレードが必要です。
本セッションでは、古くなったPHPフレームワーク(Laravel)を再生するための具体的な戦略を解説します。

ユニットテストの導入、Laravelアプリケーションのコンテナ化によるインフラ刷新、Laravelアプリケーション/MySQLのバージョンアップなど、数々の挑戦とそれを克服した方法を紹介します。

これにより、デプロイ頻度の向上、テストコードによる仕様の明文化、システムの安定性を向上させることができました。

実際の成功事例を通じて、参加者はPHPプロジェクトの持続的な進化を支える具体的な戦略を学ぶことができます。