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

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

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

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

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

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

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

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

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

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

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

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

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

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

2024年11月24日にPHP8.4がリリースされました！皆さんは既に8.4へアップデートしましたか？

私は昨年にPHP7.3→8.2化をしたので、「余裕でしょ」と思っていたら、PHP8.3→8.4化で300個近くのテスト、10個近くのライブラリが落ちてしまい、全くすんなり行かないことが分かりました。

とは言え、マイナーバージョンアップをサボっていると、後のアップデートで苦労する羽目になります。

そこで、PHP8.4化をテンポ良く行うために、リファクタリングツールのRectorや簡単にパッチを当てられるcomposer-patchesといったツールを駆使し、実際に取り組んだ手法を5分で解説します！

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

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

概要

筆者は2024年9月にECサイト構築用のOSS開発者から、企業向けバックオフィスのSaas開発会社に転職しました。
両者ともにPHPをメインの開発言語として置いていたのですが、「開発へのアプローチの仕方」や「PHPであること」の
意味合いはかなり異なったものでした。

例えば、以下の例

• 可読性を重視するのか、パフォーマンスを重視するのか
• 開発スピードを重視するのか、品質担保を重視するのか
• セキュリティをコードで担保するのか、ミドルウェアに任せるのか
  等々・・・

ソフトウェア開発における「あるある」でもあり、この問題と対峙している人は多いのではないかと思います。
OSS開発とWeb系Saasという2つの視点から、PHP開発における価値のあり方についてお話します。
筆者が実際に直面した課題もできる範囲でお話します。

対象者

• 開発におけるQCDSで優先順位どうするか日々悩んでる人
• 2つの宗教に挟まれた時に「どこに着地点を持っていくか」で悩んでいる人
• OSS開発のノウハウとWeb系Saas開発のノウハウを単純に比べて聞きたい方

得られるもの

• PHPのWeb開発における一つの価値基準
• 立場が変われば同じPHPでも取り組む姿勢が変わるという視点
• ソースコードとインフラの役割分担の考え方

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

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

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

概要

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

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

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

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

対象の人

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

得られるもの

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

私はアドテクノロジーを扱う会社で、広告配信の制御や入稿を行うための管理システムの開発を行っています。そのシステムでは社内用の広告配信設定の管理、メディア用レポート閲覧、広告配信設定機能が行えます。

歴史的経緯から3つの管理システムが存在してます。

• 10年以上の歴史を持つ古い社内・社外向け管理システム(PHP + CodeIgniter)
• 社内向け新管理システム(PHP + Slim)
• 社外向け新管理システム（Go）

1番のシステムは10年以上保守運用されており、システムも運用も把握しきれない部分が多く、フレームワークの保守も厳しくなってきました。過去に何度も古い管理システムを葬ろうと挑んでは、志半ばで取り組みが終わることを繰り返してきていました。今回、古い管理システム の葬りが完了する目処が立ちました。

今回の発表では、 「過去、なぜ、移行しきれなかったのか」、「今回、なぜ、移行の目処が建てられたのか」、「今回の移行戦略」 をお話します。

具体的には以下の戦略を取りました。

• ロードマップを作成
• ステークホルダーに宣言
• 移行をやり切るためのサポート（ヒアリング、移行アナウンスや進捗の分かるシートへのリンクを表示）
• 旧管理画面の解像度を上げる工夫（Xdebug によるデバッガ、OpenTelemetry + Jaeger による SQL ログなど）
• 自動テストの拡充

聞いてほしい人

• 長年改修されてきたシステムのリプレイスや移行を考えている人
• 移行タスクが志半ばで終わった経験がある人
• フルサイクル開発の仕事の進め方に興味がある人

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

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

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

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

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

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

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

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

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

私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。

「AIクレーム検知オプション」の開発に当たり、メールディーラーの史上初となるβ版をコンテナで構築して、
お客様に実証実験ご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減やパフォーマンスの分散化を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
将来的なアーキテクチャの構想も含めて、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例を交えて説明いたします。

AWSやコンテナは新しい技術ではありませんが、2001年にローンチしたメールディーラーにとっては違います。
メールディーラーは全機能がひとつのサーバに実装されており、WebサーバとDBですらひとつのサーバに集約されています。
また、フレームワークを導入しておらず、DBアクセスからprint文によるHTML出力が、1つのPHPファイルに実装され、
プログラムの陳腐化が急速に進んでいます。

その一方で市場開拓の必要性から新機能を定期的にリリースすることが求められています。
さらにLLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、
LLMを「導入していることがメリット」だったのが「導入していないことがデメリット」に変わりつつあります。

AIブームを背景に、ChatGPTを活用したクレーム検知機能をAWS上で構築し、無事リリースに至りました。
本セッションを通じて、新しい試みを試す参考になれば幸いです。

Laravelの監査ライブラリ「Laravel Auditing」は、Eloquentモデルでのレコードの作成、変更、削除を詳細に追跡する強力なツールです。しかし、Query Builder経由の操作は監査対象外のため、重要な変更が見落とされるリスクがありました。
私たちのチームでは、この課題を解決するため、Query Builderによるレコードの作成、編集、削除も監査ログに残せるように拡張を行いました。

本LTでは、以下の内容をお届けします。

・Query Builderの操作をログに含める必要性
・Laravel Auditingの仕組みを理解するポイント
・Query Builder操作のログ拡張方法（実装の工夫や設計の考え方）
・拡張後のメリットと運用のポイント
これにより、監査ログが取りこぼされるリスクを大幅に低減させ、システムの透明性と信頼性を向上させる方法をご紹介します。

EloquentとQuery Builderの両方を活用するチームにとって、日々の開発に役立つ内容をお届けします。

対象者
・Laravelを使ってシステム開発を行うエンジニア
・Laravel Auditingを導入している、または導入を検討しているチーム
・EloquentとQuery Builderを併用して開発を進めている開発者

Promiseについて、「分からん！」から「そんなものもあるんだ」を経て、「そういう風になっていて、そう動くのか」に至るためのトークです。
Promises/A+の世界観や、概念レベルの「何を課題とし、どう解決を試みるパターンなのか」の共有から入り、
PHPでの実装例を参考にしながら「こうやるんだね」を見ていきましょう。
最後には、低機能で愚直なPromiseオブジェクトを生み出す所まで話を進めます。

PHPを利用した普段の開発では、 Promise を目にすることはあまり無いかも知れません。
しかし、ライブラリの中身などを読んでいると「意外と出てくるよな」と私は感じました。
guzzlehttp/promisesやreact/promiseといったPHP実装が、しばしば登場します。
コイツと仲良くなれたら、少し幸せになれるのではないか…？と感じたので、解剖してやろうと考えたのです。

特に、「Guzzle使っていてPromiseクラス出てきたけど良くわかんないで雰囲気でやっているなー」という人には役に立つはずです。

概要

Promiseパターンについて興味がある人に向けて、概念の説明とPHPでの実装例を示します

このトークで得られるもの

• Promiseについて知る
• 「PHPでできること」「PHPっぽい実装」について知る

あまり話さないこと

• ライブラリ自体の詳細、活用法

対象とする人

• 「Promiseって聞いたことがある気がするな」レベルの人
• 「ふんわりとは知っているけど、PHPでの実装は考えたことがなかった」という人

おそらく対象外であろうと思われる人

• JavaScriptやPythonなどの他言語で、日常的にPromiseを扱って精通している人

このセッションではPHPで作成したアプリケーションをVercelにデプロイする方法を紹介します。

Vercelは「Vercel のフロントエンド クラウドは、開発者にフレームワーク、ワークフロー、インフラストラクチャを提供し、より高速でパーソナライズされた Web を構築します。」(X：@vercelより引用)で、PHPのイメージはありませんが、PHPのアプリケーションをデプロイすることができます。

また、VercelにはVercel PostgresというPostgreSQL(データベース)を提供するサービスもあります。PHPとVercel Postgresを用いてアプリケーションを作成し、Vercelで公開することができます。

このセッションでは、VerceでPHPを用いたアプロケーションを公開する方法とVercel Postgreの紹介をします。

PHPフレームワークとして広く採用されているLaravel。その最初のコミットは 2011年6月8日 のことでした。
それから約14年。Laravelは進化の過程で何を大切にし、どのような機能追加を重ねてきたのでしょうか。
本トークでは、ChatGPT、Claude、Geminiを活用し、14年分のGitHubのコミットメッセージを分析。Laravelの設計思想の進化を取り上げます。

特に以下の観点から解説します：

• 黎明期のシンプルさから、モジュール化への進化（Laravel 3-4）：Composerの採用とFacadeパターン導入
• 現代的アーキテクチャへの転換（Laravel 5-8）：サービスコンテナ導入がもたらした開発体験の変革
• パフォーマンスとスケーラビリティの追求（Laravel 9-）：Octaneの採用に見る実行モデルの転換点

生成AI時代だからこそ、コードを書くだけでなく「なぜそのような設計を選んだのか」を理解することが求められる今日。
先人たちの試行錯誤から、私たちの開発に活かせるアイデアの種を見つけましょう！

私はコミュニティ活動として、PHPTeaNightというオンラインイベントを定期開催しています。

その会でPHPStanをテーマとして参加者の方からいただいたPHPStanとの向き合い方がとても良かったので共有したいと思います。
baselineは減らすにはどうしたら良いのか？そもそも減らすべきなのか？レベルはどのくらいが良いのか？
など普段疑問に思っていることを利用者はどう感じて、どうPHPStanと向き合っているのかLTでお伝えできればと思います。

（あと、そんな利用者の声が聞けるPHPerTeaNightについても知ってもらえたらと思います）

皆さんyield使っていますか？
使う人は結構使うし、使わない人はとことん使わないyield文ですが、非常に味わい深い挙動となっています。
サンプルコードに対しての期待値を皆で考えてみて学ぼうという趣旨です。
時間が足りなくて銅鑼が鳴るか？それともネタが尽きるのが先か？そんなネタLTです。

このセッションではPHPのマイクロサービスアーキテクチャにおける分散トランザクション管理の新たな方法として、
アクターモデルとPhluxorを使ったSagaパターンの実装を紹介します。

PHPによる分散処理を諦めた方は多いのではないでしょうか？
並行処理の理解やサーバについての知識、結果整合への理解や、
障害対応方法や復旧方法など分散システムになればなるほど難しくなり、PHP以外の知識が要求されます。
アクターモデルはそれらを強力にサポートしてくれる仕組みがたくさんあります。
そんな仕組みを活用したデータ整合性の維持やレジリエンス向上に役立つ例として、
在庫管理やショッピングカートなどをテーマに実践的なアプローチを実装コードを交えて解説します。
アクターモデルによるメッセージングや、アクターによる振る舞いの変更、
state管理やSupervisionの活用、アクターの永続化などを用いて詳しく解説します。
複雑なワークフローをシンプルにし、スケーラビリティとフォールトトレランスを向上させる具体的な手法を習得しましょう！

インターフェイスと聞いて何を思い浮かべますか？

プログラミング言語に備わっているInterface（オブジェクトインターフェイス）でしょうか。
それともinterface型でしょうか。
それともWeb APIのIでしょうか。
UIのIかもしれませんね。
もしかしてCLIのIですか。

本セッションのスコープとなるインターフェイスは「その全て」です。

本セッションではソフトウェア開発において意識せざるを得ないインターフェイスというものについて考えてみます。
前述したようにひとことでインターフェイスといってもさまざまな種類があります。
それぞれのインターフェイスについて、出来る限りそれらの特性を明らかにしていきます。

それらを並べて見ていくと、朧げながら共通点が見えてきます。本セッションではそれを「インターフェイスという考え方」と呼ぶことにします。

本セッションではソフトウェア開発において強力な武器となる、インターフェイスという考え方について、私なりに言語化して共有します。

例えばテストも、名前重要も、スキーマ駆動開発も、モジュラモノリスも、CQRSも、全てインターフェイスが意識されています。
インターフェイスという考え方は、空気のように当たり前に自然と活用されている一方、意識するだけで開発に新たな視点を得られるものだと感じています。

本セッションを通じて、参加者の皆さんがインターフェイスという考え方に改めて気づき、インターフェイスを意識することで、参加者が自身の開発プロセスに新たな視点を得ることができるようになることを目指します。