トーク

「この関数、どこで何を呼んでるんだっけ？」「影響範囲が読めなくて、修正するのが怖い…」
アプリケーションのロジックが複雑になってくると、そんな不安を感じる場面が少しずつ増えてきます。

本トークでは、そうした不安をドメインイベントでどう乗り越えるかを紹介します！

ドメインイベントは、「〇〇が起きた」という事実をクラスとして扱い、処理の流れを“できごと”ベースで組み立て直すことで、依存を一方向に整える設計手法です。
また、「このイベントってこういう意味だよね」とチーム内で言葉を合わせやすくなるため、設計や仕様に関する会話もスムーズになります。
さらに、非同期処理への移行や、あとから機能を追加しやすくなるなど、スケーラブルな設計への第一歩としても効果的です。

以下のポイントをBefore / After のコードを交えながら解説します：

• ドメインイベントはなにか？従来のメソッド分割との違い
• PHPコードでの実装パターン
• 同期から非同期へ段階的に導入していく方法

設計を見直すヒントやチームでの議論のきっかけを提供します！

LaravelはWebアプリケーションを簡単に早く作成できる人気のフレームワークの１つです。Laravel本体の機能は非常に充実しており、3rd partyライブラリを使わなくても柔軟な開発ができます。しかしながら、デフォルトの設定や機能だけではLaravelの強みを十分に活かしきれません。例えば、マジックメソッドを多用したフレームワークなため、コア機能だけではEloquentモデルのプロパティやFacadeメソッドのコード補完が効きません。そこで laravel-ide-helper のライブラリを使うと自動生成されたヘルパーファイルによりコード補完が効くようになり、開発効率が上がります。不正なプロパティ・メソッド呼び出しもPHPStan/Larastanなどの静的解析ツールを入れることで事前検知ができ、より堅牢な開発ができます。

本トークではLaravelのアプリケーション開発で入れるべきツールや設定について紹介します。コード補完、静的解析、ロギング、パフォーマンス改善、デバッグ、フロントエンド、フォーマッター、ライブラリの定期アップグレードなど、それらを導入する理由やできることを紹介します。

このトークで紹介するツールや設定により、皆様のLaravelアプリケーション開発がもっと効率的で堅牢で楽しいものになれば幸いです。

皆さんは自分が新卒だったとき、どんな研修を受けましたか？その時どんなことを感じたでしょうか？
あるいはこれから就職をする方であれば、入社後に受ける研修はどんなものを想像するでしょうか？

押し寄せる講義、怒涛のスケジュール、成長の実感、メンターとの関係性、高まる期待、先輩たちとのコミュニケーション、せめぎ合う感情……
新卒研修の間は日々新しい挑戦の連続で、大きな成長もある一方で、壁にぶつかったり、戸惑い悩むことも多いのではないかと思います。
当時の私もそうでした。

このトークでは、そんな私が2年目の秋にクリエイター研修総監督に抜擢されて以来、3年目となった今日までにどんなことを考え、何を大切にして研修を作ってきたのかをお伝えします。

こんな方に聞いてほしい

• 新卒研修・育成に興味のある方
• クリエイターの育成を担当している / 関わる予定のある方
• 組織のカルチャーを大切にしている方
• 研修にネガティブなイメージがある方

生成AIによるコード生成が流行している昨今、0からプロダクトを立ち上げたり既存プロダクトの修正のハードルが一気に下がりました。
我々プログラマがプログラムを編集する必要はなくなるのでしょうか?

私の答えはNoです。

生成AIが進化すると全体のソースコードや文書の絶対量が増えるので、編集機会もおのずと増えます。
生成AIが認識しやすいプレーンテキストの重要性が高まるので、一日の長があるテキストエディタが有利になります。

本登壇では、テキストエディタの既存の問題をAIがどう解決したのか、生成AIがテキストエディタ界隈に与えたインパクトについて、今後どう組み合わせていけばいいのかお話しします。

Web業界においては他業種と比較してキャリアドリフトが比較的多く行われているものの、いざ自身が取り組もうと考えると、自身が他社でうまく活躍できるのかわからない、そういった悩みがあろうかと思います。
このセッションでは一つの企業で10年勤めた話し手が異業種に転職することになった時に、どういった戦略を持ってキャリアドリフトしたのか、それがどのようにうまく行ったか、または行かなかったのかを生々しい話で共有します。
AIの誕生によって唸りがある現代で、次のキャリアに悩むエンジニアの参考の一つになるような時間にしたいと考えています。

概要

Laravel開発でおなじみのコレクション操作、その裏側に潜む「yield」の力を最大限に引き出すのがLazyCollectionです。

本トークでは、PHPのyield構文の動作原理を紐解きつつ、なぜLazyCollectionが高速でメモリ効率が良いのか、Collectionとの違いについて内部の仕組みを追いながら丁寧に解説します。
また、実際に現場で使われているユースケースやテクニックについても紹介します。

ターゲット

• 大規模なデータを扱っている人
• ライブラリや処理系の実装から理解をしたい人

主に非エンジニア、WEBディレクターや初心者向けのセッションです。

対象:
• WEBディレクター
• 企業などのWebサイト管理者
• PHPにこれから触れるかもしれない人

ゴール：
エンジニアとの要件定義の確認や、ベンダーとのやり取りが少しでもスムーズになれば、という思いで企画しています。

内容:
開発中にエンジニアへ「それ、どういう意味ですか？」と何度も聞いてしまい、やり取りが止まった経験はありませんか？
本セッションでは、非エンジニアであるWEBディレクターが、PHP開発に関わる上で“最低限知っておきたいPHP用語”を、現場でのすれ違いエピソードとあわせて、やさしくご紹介します。

IT業界の初心者や、これからWEB業界を目指す学生の方にも「話がわかる」「参加してよかった」と感じてもらえるよう、専門用語をできるだけかみくだいてお伝えします。

開発者と“共通言語”を持つことで、プロジェクトはもっとスムーズに、もっと楽しく。
そんなヒントをお届けできればと思います。

「なぜこの設計になったのか？」「複雑な判断の根拠を説明できない...」「チームの知恵が個人に閉じ込められている...」
チームでこんな課題を感じていませんか？複雑化するシステム開発において、特定の個人に依存した知識管理ではなく、チーム全体の「知」を育み、新たな知識を創造することが成功の鍵です。

個人に知識が集中すると、その人の離職で暗黙知が失われ、プロジェクトが停滞するリスクがあります。また、複雑で不確実性の高い開発では、個人判断では視野が限られ、想定外の事態へのリカバリーも困難です。個人の暗黙知をチーム全体の知恵に昇華させる仕組みが求められています。

本セッションでは以下をお伝えします：

1. SECIモデルとは？知識創造の4つのプロセス
2. モブワークがSECIモデルを加速させる仕組み
3. 各プロセスを促進するモブワークプラクティス
4. 知識創造するチームへの変革事例

SECIモデルの「共同化」「表出化」「連結化」「内面化」という知識創造の4プロセスを、モブワークは自然な形で促進します。暗黙知の共有から始まるこのサイクルは、モブワークで驚くほど加速します。

これにより「部族記憶」や共通文脈が生まれ、背景情報の共有だけでなく、チームの知的相互作用から新しいアイデアや知見が生まれる土壌が形成されます。個人では到達できない創造的飛躍が、多様な視点の交わりから実現できると登壇者は考えています。

純粋関数(pure function)という言葉を聞いたことはありますか？ 簡単にいうと、同じ引数を渡せば必ず同じ結果を返す関数のことで、「数学的な関数」と説明されることもあります。

同じ引数で同じ結果ということは『確実な再現性がある』ということで、「純粋」の概念を知って純粋と不純な処理を切り分けられれば、コードを見通しよく、テストしやすいコードにすることもできます。

いくつかの静的解析ツールとIDEは純粋性について分析を提供しており、意味のない純粋関数の呼び出しについて警告を与えてくれます。
これと関連して、PHP 8.5向けには #[NoDiscard] というattributeも追加され、戻り値を処理する必要がある実装をマークすることもできます。

では、既存実装をPureあるいはNoDiscardに明解に分類できるかというと… 現実には一筋縄にはいかない、さまざまな考慮事項があります。

本トークでは「純粋」および「副作用」という概念、そしてそれらをとりまく周辺事情についてお話しします。

振る舞い駆動開発（BDD）は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。

本セッションでは、PHPでBDDを始めるための基本的な考え方と実践方法を紹介します。Behatなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。

PHPでテストを書いて、プロジェクトに無理なく導入できるBDDの第一歩を、これから始めたい方に向けてわかりやすく解説します。

「オブジェクト設計スタイルガイド」は、オブジェクト指向のパワーを引き出し、クリーンなコードを書きたいPHPerにとって必読の書籍です。本セッションでは本書の内容を紹介しつつ、チーム全員の目線が揃うアプリケーション設計やクラス設計に役立つ考え方を紹介します。

本セッションで紹介すること
・Service、EntityとValue Object、DTOの使い分け
・クエリメソッド・コマンドメソッド・モディファイアメソッドの違い
・インターフェースの作成基準

本セッションを通して理解できること
・MVCフレームワークから疎結合なアプリケーションとは何か
・サービス層とドメイン層という言葉が意味すること

本セッションに参加された方が現場に持ち帰って実践できること
・クリーンなコードを書くこと
・レビュー時にコードの良し悪しを言語化できること
・AIが出力するコードを採用するか判断できること

あと1年でデータ件数10億件間近…そうなればテーブル変更したくても怖くて触れない…！

そんな状況から始まった打刻テーブル移行の軌跡を語ります。（DBはMySQLです）
・ パーティションテーブル移行と影響調査
・ 更新・参照効率に合わせたテーブル分割
・ 更新パラメータ追加に伴うログ検証
・ 参照切り替えのシャドーテスト的アプローチ
・ 重複データとの戦い、そしてユニークキーの採用
・ βリリースを活用した影響調査

大規模リリースを避け、スモールステップで内側のテーブルをすげ替える試みの具体的な方法についてお話しします。
本セッションがみなさまのシステム改善やレガシーシステムの移行の一助になれば幸いです。

転職を機に新規でアプリケーションの実行環境を作ることになり、0から構築しました。もちろん今までに構築した環境をベースしましたが、セキュリティの向上という課題を踏まえて、
ここ数年話題に登ることが増えてきたDevOpsにセキュリティを意識した取り組みを組み込むDevSecOpsを意識して環境を構築しました。

新たな環境の構築に際してセキュリティを意識した自動化の取り組みをどのように組み込みつつ、効率的な開発プロセスを維持するために意識したことや、取り組みの具体的な方法と実践例をご紹介します。

引数をメソッドに渡すか、 __construct に渡すか......
どちらも機能しますが、本当に “どちらでも良い” のでしょうか？
動くのは間違いないですが、より「使いやすく」「保守しやすい」コードを目指すなら、最適な注入方法を選ぶ必要があります。
そこで、わたしの考える判断基準を具体例のコードに落としつつ紹介していきます。

• クラス設計・依存関係の整理
• テストの書きやすさ
• コードの可読性

また、このような話で一緒に出てくるのが依存性注入（DI）です。
具体例とともにあることでふんわり理解からじっくり理解にもっていきましょう。

このトークでは、実際のコード例を交えつつ、コンストラクタ注入とメソッド注入それぞれの判断基準を明確にしながら、DIの仕組みも合わせて紹介していきます！

PHPUnit、毎日（？）使っていますよね。
直接コマンドを叩いたり、便利なツールを介して使っていたりするかもしれませんが、
その中身に目を向けたことはありますか？

まずは、PHPUnitを「ちいさく作ってみる」ことで、その仕組みをひも解きます。
最低限必要な機能は何か？「最小限のPHPUnit」を作って 実際に動かしながら デモを行います。

その後、実際のPHPUnitと見比べ、どこに拡張の余地があるのか、また拡張の余地をどのように設計しているのかという部分を整理していきます。
これらは、自分たちの作るシステムにおいても「拡張の余地」の嗅覚に役立てられるはずです。

「ちいさく作る」そして「じっくり理解する」ことで中身を想像する足掛かりにしていただければ嬉しいです。
テストフレームワークの奥深さを一緒に覗いてみましょう！

みなさんはPHPでWebSocketサーバーを実装する際にどんな方法で実装しますか？
PHPでWebSocketサーバー実装する場合、いろいろなライブラリやミドルウェアがあります。
このセッションでは次のWebSocketサーバーの実装を紹介します。

• Ratchet
• amphp
• workerman
• Roadrunner
• swoole

PHPでは本来不得意な非同期処理を用いるWebSocketを実現できる方法は様々あり、PHPの面白さを共有できればと思います。

みなさんはFour Keysでどのクラスタに属していますか？

Four KeysはDORA（DevOps Research and Assessment）が提唱している開発チームのパフォーマンス指標です。Four Keysではパフォーマンスに応じて、Elite・High・Medium・Lowの4つのクラスタのいずれかに分類されます。

サービス開発においてEliteクラスタに属していないと、ビジネス競争力が低下するリスクがあります。近年ではEliteクラスタに属した上で競争力を高めるためにさらなる取り組みをしていくのは一般的です。

私が所属する合同会社DMM.com 二次元コンテンツ事業が開発に携わっている二次元コンテンツ事業のPHP製ECサービスは現在「High」クラスタに位置しており、Eliteクラスタを目指してさまざまな取り組みを積極的に進めています。

本セッションでは、まだEliteクラスタに属していないチームが具体的にどのようなアプローチを取ればよいのか、実際の取り組み事例を交えてご紹介します。

アジェンダ（予定）：

• Four Keysとは
• なぜFour Keysを使うのか
• スループットと品質の相関
• ECサービスの現状と課題点
• Eliteクラスタへ移行するための取り組み
  • スループット改善への取り組み
  • 品質改善への取り組み
    • リファクタリングに向けた準備
      • FakerとTestcontainersを用いたモデルベーステスト
      • Qodanaを用いたPHPアプリケーションの静的解析

対象者：

• Four KeysのEliteクラスタ入りを目指す開発チームのリーダーやメンバー
• 開発チームのパフォーマンスを具体的に改善したい方

PHP で今一番勢いのある Web アプリケーションフレームワークであるところの Laravel 、最近もマネージドサービスのローンチ、純正エディタ拡張機能の提供、静的解析への対応を進めるなど、様々な改善が進んでいます。

一方で思いがけないタイミングで互換性を損なう変更が入ることもあり、既存アプリケーションのアップグレード作業においては稀に罠を踏んでしまうことも...

今回は筆者が PHP にコントリビュートした領域である乱数 (ランダム) 周りにおいて、 Laravel 11 での "サイレント" な変更により、自ら罠にハマってしまった話と共に、プログラミングにおける "乱数" との付き合い方を今一度考えてみたいと思います。

「設計ドキュメントは必要か？」
開発現場でたびたび持ち上がるこの議論に、正解はあるのでしょうか。

ドキュメントが少ないことでスピードが出るチームもあれば、丁寧な設計が結果的に開発効率を高めるチームもあります。

複数の開発チームを経験する中、チームトポロジーを読んで「ドキュメントの最適なあり方は、チームの特性に依存する」という気づきを得ました。

本トークでは、以下の観点から「チームごとに適したドキュメント管理の考え方」について具体的にお話しします。

• ドキュメントの必要性に関するよくある議論
• チームが扱うドメインの種類
• チームタイプによるアプローチの違い
• 実際のチームで実践しているドキュメント管理方法

設計やチーム運営に関わるエンジニアにとって、明日からの開発をより良くするヒントを持ち帰っていただける内容を目指します。

「ちょっとWAFのブロックを追加したい」「S3のバケットを作りたい」──そんなとき、SREにチケットを出して数日待ち、という体験をしたことはありませんか？私たちの現場でも、PHPアプリエンジニアがインフラに手を出しづらく、SREに依頼が集中していました。その結果、SREは日々の対応に追われ、改善や新しい挑戦に手を出す余裕がなくなっていきました。

このセッションでは、私たちアプリケーションエンジニアがインフラ構築の裁量を広げることでどう現場を変えたかを紹介します。Terraformを使ったIaCのテンプレート化、GitHub Actionsを活用した安全なCI/CDパイプラインの構築、パススルーやWAF設定といったよくある変更の“自分でできる化”など、PHPエンジニアが安心してインフラに関われるようにした具体的な工夫をお話しします。

もともと私自身がPHPerからSREに仕事を広げたことから何に困り、どう整えてきたか。開発体験を良くするためにSREとアプリケーションエンジニアが整えるべき“やってよい設計”のヒントを、実際の試行錯誤や失敗談も交えてお届けします。