PHPStanはPHP開発者にとって頼れる相棒ですが、そのエラーは時に悩ましいもの。このセッションでは、私が独断と偏見で選んだ実例をもとに、PHPStanのエラーがどのような場面で発生するのか、具体的な修正方法をお伝えします。「PHPStan初心者」から「ちょっと苦手」な人まで、役立つ情報をギュッと詰め込みました。今日からPHPStanをあなたの最高の同僚にしましょう！

循環参照、聞いたことはあるけれど実際に遭遇したことがある方はどれくらいいるでしょうか？私もまさか遭遇するとは思っていませんでしたが、ついにその“おとぎ話”のような存在に出会ってしまいました。そして、それを解決するために地獄のような改修作業が始まりました…。
このセッションでは、循環参照が引き起こす問題やその発見方法、解決するために取った具体的なアプローチを共有します。さらに、再び循環参照に遭遇しないための防止策についてもお話しします。二度と同じ目に遭わないために、一緒に循環参照の対処法を学びましょう！

副業でPHP（Laravel）を教える中で、技術力だけでなく、自分のエンジニアとしての姿勢やスキルにも大きな変化がありました。

「このエンジニアに教わりたい」と思ってもらえる存在を目指し、GitHubの自己紹介やブログに力を入れたり、プライベートでコードを書く時間が増えたりと、活動の幅が広がりました。
また、人に教えるには深い理解が必要なため、「分からないことを徹底的に調べる」「ドキュメントやコードを読む」「一次情報にあたる」などをこれまで以上に重視するようになりました。
教える中では、短時間での原因切り分けやペアプロのナビゲーションを行う場面もあり、そこで得た経験と気づきは、自分の成長に大きく寄与していると思います。実際業務でデバッグするときにも、まず現状を把握する、どこまでできているかを探る、1次情報に当たるなどがより一層実践でき、課題を解決するまでの時間を短くできているのではと思います。

このセッションでは、副業での教える経験を通じて得た学びがどのように業務に活かされているかを具体的にお話しし、参加者の皆さんが自分自身の成長に役立てられるヒントを提供します。

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

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

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

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

Laravelでの開発経験者ならおなじみのBladeテンプレート。
あなたは本当に使いこなせていますか？

このセッションは、まず日常的に使う基本的なディレクティブ @if や @foreach といったディレクティブをおさらいし、意外と知られていない隠れたディレクティブのご紹介や、 @csrf などのディレクティブの裏側で行われている処理内容、さらには独自のニーズに応えるカスタムディレクティブの作成方法まで幅広くご紹介します。

「実はこんな使い方ができたのか！」と思わず驚くトピックを盛り込みつつ、テンプレートコードをシンプルかつ可読性を高めるコツをお伝えします。

このセッションを通じてBladeディレクティブを使いこなし、テンプレートを効率的に管理するスキルを身につけ、日々のLaravel開発を一層効率化しましょう！

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

私が携わっている長年稼働しているサービスには、巨大連想配列$resultsが存在します。これは、元々は小さな配列だったものが、改修を重ねる中で次第に肥大化していきました。
巨大連想配列は可読性やメンテナンス性を低下させるため、私は以下のアプローチで改善を進めています。

1. Xdebugの活用
   配列の構造を可視化し、一目で理解できるようにする。
2. 新規部分の改善
   新しく作る部分は値オブジェクトを導入して書き換える。
3. 分離と整理
   大きなキーを別の変数に切り出したり、I/O形式が異なる場合はメソッドを分ける。

お話しする内容

• 配列の構造を一目で把握するためのXdebug活用術
• 巨大連想配列を生み出さないコツ
• 巨大連想配列を分解して整理する方法

巨大配列で頭を悩ませている方の改善のヒントになれば嬉しいです。

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

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

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

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

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

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

LaravelのEloquetにはupsert関数があって便利だなぁ♪
あれ？updateOrCreate？
あれあれ？updateOrInsert？

一体どれを使えばいいんだーーー！！！

本セッションではこんな悩みを解決するために、それぞれの関数の説明とどう使い分けるかについてお話します。

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

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

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

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

技術的負債はどこの開発現場でも多かれ少なかれ存在します。技術的負債ゼロな現場はありません。
技術的負債を継続的・定期的に返済できていれば問題はありません。しかし長年放置され「負債度」が高まった技術的負債を返済するのは非常に厄介で骨が折れる作業です。

私たちは約10年放置されてきたPHPアプリケーション（PHP5）をPHP8にアップグレードしました。
負債解消チーム立ち上げから苦節３年、メンバーの離脱もありつつもレガシーなPHPアプリケーションの移植およびアップグレードを完遂することができました。
しかしそれを終えて今、こう思うのです。なぜここまで大変になるほど放置してしまったのか―。

本発表では技術的負債はなぜ生まれてしまうのか、その組織的・構造的な問題に触れつつ、それにどう立ち向かい、そしてその後どうすべきなのか、私自身が経験したPHPの移植事例・アップグレード事例を踏まえて発表します。

話すこと

• 技術的負債の生まれ方
• 「技術的負債の倒し方」のはじめ方
• 技術的負債の倒し方
• 技術的負債の倒したあと

想定聴講者

• 技術的負債の解消をしたいと思っている方
• 現在進行系で技術的負債と闘っている開発者

※本発表は PHPerKaigi 2024 で発表した「10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡」の完結編となります。

最近の学生エンジニア界隈ではTypeScript, Go言語, Rustを学ぶ人がかなり多くなっており、PHPを現在進行系で学んでいる人は自分の周りではあまり見ません。
(書いたことある！という人は見ます)

私も、もちろんそれらの言語を書き、開発体験が良いと感じることが多くありました。
そんな中、自称関西学生PHPer最後の砦という責任感を持って今でもPHPを書いています。
そんな自分がPHPを書いていて良いなと思った点を言語機能やコミュニティの観点、ソフトウェア開発を学ぶといった様々な観点から色々話します。

学生目線というところが肝です。似たような話にはしません！
自己満LTになりそうですが、面白いトークを目指します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目の前の仕事に対して課題を見つけて、その課題に関する知識を身に着けることで社会人として十分な成長と報酬を貰えます。
たったそれだけですが、簡単ではないのです。
しかし、簡単ではない = 私には出来ないこと ではありません。

何かを犠牲にするのではなく、目の前のことを一個一個やっていくことで成長できる。
そのために必要な方法や考え方を説明します。

今、めっちゃ流行ってますよね、AI。
抽象的な質問しても、結構いい感じで答えを提示してくれます。

コーディングもさせることが出来て、「◯◯のアプリを作って」みたいな指示で
コードを仕上げてくれます。割といい感じでそのまま使えるものもあれば、
エラーハンドリングがまだまだのものもあります。
たまに、全然意図を履き違えてるものもあります・・・笑

今回は、そんなAIに作ってもらったコードをみなさんで見ながらワイワイしましょう。
ツッコミ大歓迎。プロンプトと出力結果を見比べて、どう改善したら良いかをXで呟くのもアリ。
今回ばかりはマサカリも飛ばしてもらって良いですよ

概要

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

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

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

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

対象の人

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

得られるもの

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

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

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

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

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

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

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

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

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

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