PHPのパフォーマンスを飛躍的に向上させる次世代のPHPサーバー「FrankenPHP」とLaravel Octaneを組み合わせることで実現する高速なPHPアプリケーション開発について紹介します。
本セッションでは、FrankenPHPの基本概念、従来のPHP FPMとの違い、Laravel Octaneとの統合方法、そしてリアルタイム機能や高トラフィック対応の具体的なユースケースについて解説します。

他社がどのようにスクラムを行っているか、気になったことはありませんか？
このセッションでは、私たちがどのようにスクラムを実践しているか、その具体的な取り組みをシェアします。

私たちのチームでは、サーバーサイド、フロントエンド、そしてネイティブアプリのエンジニアが同じチームで協力しながらスクラムを進めていますが、それゆえに発生する課題も少なくありません。
使用しているツールやスクラムイベントの実施方法はもちろん、発生した課題とその対策について詳しく話します。
また、モチベーションを高めながら楽しく仕事を進めるための工夫も紹介します。
これからスクラムを始めようとしている方や、スクラムの進め方に悩んでいる方にとって、少しでも役立つヒントになれば幸いです。
セッション後は、ぜひ皆さんのスクラムについても教えてください！

話さないこと
　・PHPに関すること m( )m

メンタルは崩れると業務のパフォーマンスに大きな影響を及ぼします。
比較的メンタルが弱い私が継続して業務に携わるため実践してきたセルフケアやレジリエンスと言われる回復力の鍛え方をお話します。

聞いてほしい方

基本的にどなたでもではありますが。

• 若い方（早めに身に着けておいて損はない）
• メンタル弱い自覚のある方

お話すること

• メンタルが不調になる要因
• 実践してきたセルフケア
• レジリエンスの鍛え方
• 実践したことにより得られた業務での成果

得られること

• メンタルが不調になりがちなときの対処法を学べる
• 業務でのパフォーマンスを安定させるためのセルフケアのコツ
• 落ち込んだときからの回復力（レジリエンス）の向上方法
• 長期にわたりモチベーションを保つための具体的な戦略

正規表現はテキストの抽象表現です。ソフトウェアでは入力値のチェックやテキストの整形などに用いられるので、私たちプログラマにとって馴染みが深いものの一つです。

ところで、正規表現の「正規」という名前が「良い性質」という意味を持っていることをご存知でしょうか？ 実際、統計の分野では良い性質を持ち、理論の根幹となる分布に正規分布という名前が付けられています。同様に、シンプルで汎用性の高い正規表現もまた、正規という名前に相応しいといえるでしょう。

しかし、開発者に正規表現の話題を振ると 「複雑で可読性・編集容易性が低くく、辛い」 という話題になりがちです。本セッションでは、正規表現が何故複雑になり、読めなくなってしまうのかという疑問に答え、その解決方法を示します。

なお、本セッションはPHPerKaigi 2024で発表し、改良したものです．

本番運用においても、ローカルで開発を行う場合においても、Dockerなどのコンテナ技術およびAWS ECSなどの周辺サービスを利用するのはすでに一般的かと思います。
ただ、確かに便利な技術ではあるのですが、運用を続けていくうちに以下のような課題に出くわすことがあります。

・CIの実行に時間がかかる
・本番・CI・ローカル環境ごとにライブラリ・パッケージをインストールする記述が分散しておりメンテが面倒
・aptなどでバージョン固定してインストールしているパッケージが、リリース用イメージのビルドタイミングでインストール失敗しリリース時に困る

このトークでは、実際にPHPのDockerイメージを毎日自動ビルド・プッシュすることで上記のような課題を解消した事例についてお話しします。

昨年のカンファレンスで「CodeReviewerが求められること」について発表させていただきました。
その中で、Revieweeが
・気づきや学びが欲しい
・自信を持ちたい
と感じていることが明らかになりました。
またその時の発表では触れませんでしたが、Revieweeは「楽しく働きたい」とも考えていることがわかりました。

しかし、コードレビューにおいて、Reviewerが気づきや学びにつながるようなコメントをしたとしても、伝え方次第でRevieweeから楽しさや自信を奪うことがあります。
本セッションでは、Revieweeが不快にならない伝え方を探究し、PHPerエンジニアへのインタビューも交えながら、心地よいコメントの条件を考察します。
コードレビューの場が楽しくなり、組織が活発になる一助となれば幸いです。

対象者：コードレビューを行う全エンジニア（役職問わず）

みなさんは、どのような時にパフォーマンスが上がったと感じますか？
PHPコードが綺麗に書けた時、コードやDBを最適化できた時、
上司から評価してもらった時、単に体調が絶好調の時 etc.

その中でも今回お話ししたいのは、「自分で」「今すぐに」できるパフォーマンスの上げ方として
自分に合った開発スケジュールの立て方についてお話しします。

私は今年の4月に新卒入社し、半年間の社会人経験を経て「自分の意志でスケジュールを立てることの重要性」に気付くことができました。

今回は
・社内のPHPエンジニアにアンケートを取り、性格（MBTI）や経験年数などから考えられるスケジュールの取り方の傾向
・私自身のスケジュールを立てる上で大切にしていること
・（上記を踏まえて）育成側に立たれている方に考えてみてほしいこと
をお話ししたいと思います。

求人サービス「エンゲージ」はサービス開始からLaravelのモノリスなアプリケーションとして開発が行われてきました。サービスの内製化を目指して組織が急拡大していますが、毎回の機能追加のたびに発生する大規模な影響調査、チーム間のコミュニケーションコストの増加等の理由で開発速度が低下し、ビジネスサイドと開発サイドが協調して素早くサービスの価値を最大化するという、内製開発のメリットが活かしづらい状況でした。

弊社はそのような問題に対して、イベントストーミングやドメイン駆動設計、モジュラーモノリスといった開発を選択し、開発速度の向上やオーナーシップの強化を目指して取り組んでおり、その取り組みの軌跡や失敗の経験、今後の展望についてお話しします。

普段からドメインを意識した開発に取り組まれている方、これから組織に導入していこうと考えている方をはじめ、一つの事例として参考にしていただけると幸いです。

It is the year 2024 and PHP developers are still arguing about double quotes vs single quotes.
Lets explore if that actually still matters, see why it does not, learn what happens before your code gets executed and find the answer to the question: What has the OPcache ever done for us?

サービスは生き物のようなもので、放置すれば腐ってしまいます。
適切なメンテナンスとアップグレードが必要です。
本セッションでは、古くなったPHPフレームワーク(Laravel)を再生するための具体的な戦略を解説します。
ユニットテストの導入、Laravelアプリケーションのコンテナ化によるインフラ刷新、Laravelアプリケーション/MySQLのバージョンアップなど、数々の挑戦とそれを克服した方法を紹介します。
これにより、デプロイ頻度の向上、テストコードによる仕様の明文化、システムの安定性を向上させることができました。
実際の成功事例を通じて、参加者はPHPプロジェクトの持続的な進化を支える具体的な戦略を学ぶことができます。

年月を経たレガシーなアプリケーションの検索処理は、肥大化したロジックによりパフォーマンスが劣化しがちです。本セッションでは、実際に直面した検索遅延を、OpenSearchを活用して改善した実例をもとに、選定理由から実装の課題、実際の効果までをお話します。

ターゲット

• OpenSearch導入を検討している方
• レガシー環境でのパフォーマンス改善に悩む方

お話すること

• OpenSearchの概要
• 社内で抱えていた課題
• 選定理由
• 実装時の躓き
• 実装後の効果
• 今後の課題

何が得られるか

• OpenSearchの強みと効果
• レガシーな環境での落とし穴

バックエンド開発を担当しながらスクラムマスターを務めることになり、気づけば約1年が経過しました。この1年間、開発チームの速度を向上させるために、さまざまなアプローチを試み、試行錯誤を重ねてきました。

チーム内のコミュニケーションの改善、プロセスの見直し、ツールの導入など、いくつかの施策を実施してきましたが、特に効果が現れた方法に焦点を当ててお話しします。

本セッションでは、実際に取り組んできた施策の背景、その成果、そして今後の展望についても触れながら、皆さんと共有したいと考えています。

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

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

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

PHPは言語仕様として様々な条件分岐を持っています。if, else, elseif, switch, 三項演算子, match, &&, ||...職業PHPエンジニアの皆さんは日々これらを使いこなして仕事をしていることと思います。では、ユーザー要求や要件の中に、あるいは要求以前のビジネスの中に、仕様書やフローチャートに表される前の条件分岐の形を見出す力はどうでしょうか？自信ありますか？
このトークでは、PHPの様々な条件分岐を概観した上で、日常で人間が行っている様々なビジネス上の判断をPHPの条件分岐に落とし込む考え方についてお話しします。
様々な条件分岐が「見える」生活をしてみませんか？

This session bridges the gap between PHP and JavaScript by comparing modern features like arrow functions, classes, and destructuring in both languages. Attendees will see how PHP has evolved to include features familiar to JavaScript developers, simplifying cross-language development.

みなさんのプロジェクトは、どのようなソフトウェアアーキテクチャを採用していますか？
明確なアーキテクチャが決まっておらず、各メンバーが異なる設計をしているプロジェクトも少なくないかもしれません。
私たちのプロジェクトもその傾向にありました。

本セッションでは、プロジェクトのリニューアルを機にオニオンアーキテクチャを導入した経験について、以下の内容を中心にお話しします。

• オニオンアーキテクチャを採用した理由
• Laravelにオニオンアーキテクチャを導入する際の具体的な手法
• Laravelでの実装時に直面するであろう課題とその解決策
• アーキテクチャを維持するための取り組み
• 導入によるメリットとデメリット

「オニオンアーキテクチャって難しそう」「導入してみたけどうまくいかなかった」
という悩みを持っている方々にとって、参考になる情報をお伝えします！

驚くほど人間的な回答で世間を賑わせたChatGPT。
しかし2024年時点では工夫をせずに依頼をすると「突然英語で回答する」「架空の資料を元に回答する」など、ビックリさせられます。

本トークでは、ChatGPTに思い通りの回答をさせるためのマインドやTipsを紹介し、少しでも思い通りな回答をさせる方法についてご紹介します。

お話しすること

• ChatGPTに上手い回答をさせるためのマインド
  • ChatGPTの裏側 (LLM) を知る
  • 人間と思って接しない
• ChatGPTに変な回答をさせないためのコツ
  • Custom instructions
  • プロンプトエンジニアリング
• 業務で使う場合の注意事項
  • 学習オプトアウト
  • 機微情報のマスク

コミュニケーションは様々な場面でギャップが生じてしまいます
発された言葉「以外」の解釈コストが高くなると、受け手のイラッ・モヤッに繋がります
(何が伝わっていないの？」など)

「明瞭な部分の比率を高める」のは有効です
例えば、発言時や受信時には「事実・解釈,意見・評価,要求」の区分が助けになります
こうした工夫が、自他を尊重した態度の表現に繋がります

発表者自身が「気にしている事」「気にしすぎないために考えている事」を共有します

役に立つ事

• コミュニケーションのgood/ungoodを知ることで、仕事の「邪魔」な要素を減らす
• 言語化・形式知化された情報を手に入れることで、現場の「モヤッ」にフィードバックしやすくなる

例題

• 「肯定？否定？」「主張したいこと」がハッキリすると楽
• 「褒め」が大事なのか、あるいは必須なのか
• 「〜では？」が何故イラつかせるのか

良いコードは拡張しやすくて、そのためには適度な抽象化が必要でね──

プログラマーとしての向上を目指すと、いつでも「抽象化筋」が立ちはだかります。
が、「抽象化をできるようになるには？」と聞くと、抽象的な答えが返ってきがちで。
こいつは何だ？

私自身が「抽象に依存する、なるほど」「インターフェースって便利」と思えたきっかけの1つが、
「たぶん何かがここら辺にあって、そこに良い感じに話しかけると、きっと処理してくれるだろう」
で進む開発するスタイルに触れた事でした。

裏を返せば「話しかける相手は分からないけど、欲する事は明確である」が求められます。
抽象化思考の1つのヒントが、正にこの「過不足なく欲求を明確にし、表現する」にあるのです。

このトークでは、こうした感覚的な部分の言語化と共有を試みます。
更に、この思考とコードの記述を繋ぐ手法として「テスト駆動開発」の実践方法を紹介します。

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

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

想定観客

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

お話しすること

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