プロポーザル

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

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

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

以下のポイントを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の誕生によって唸りがある現代で、次のキャリアに悩むエンジニアの参考の一つになるような時間にしたいと考えています。

概要

PHPでWebアプリケーションを作る際、ほぼ全てのケースでデータ永続化の為にデータベースを利用するでしょう。
長年運用していくにつれ、テーブル数やカラム数の増加によって、認知コストやコミュニケーションコストが増加する一方です。
これらの負荷を下げる為に「DBスキーマを可視化する」ということは非常に有用であり、tblsは継続的な運用に耐えうるだけの機能を持ち合わせています。

本トークではtblsの便利な機能の紹介や、実際に運用している時に得られた知見、AIによるSQL生成などのTipsを紹介します。

ターゲット

• ドキュメントの自動生成やCIによる運用改善に興味のある方
• チーム内でのスキーマ共有・認知コストを下げたいと考えている方

概要

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

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

ターゲット

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

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

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

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

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

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

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

PDOオブジェクトを利用してデータベースアクセスを実装している旧来のPHPプロダクトが抱える課題、具体的には「クエリー記述の煩雑さ」と「SQLインジェクション脆弱性への懸念」に対し、既存の処理との互換性を考慮しつつ、段階的にクエリービルダーを導入することでこれらの問題を解決した方法についてご紹介します。

PHPのロゴがどんなデザインか、皆さんは即座に思い浮かべられますか？
「たしか楕円…」「青と紫の中間色？」「あれ、今のロゴって何代目？」「というか背景色あったっけ？」などなど、さまざまな疑問が頭をよぎるかもしれませんね。

このトークでは、PHP公式ドキュメントを眺めながら最新の正しいロゴとその使い方を隅々まで確認していきます。
さらに、せっかくの機会なのでPHPで書かれている公式ドキュメントのソースコードも、少し覗いてみたいと思います。

PHPを始めたばかりの方にも、長年PHPと向き合ってきたガチ勢の方にも新たな発見がある…かも？しれません！！
このトークが終わる頃には「PHPのロゴを使いたくなってウズウズしちゃう！！！」そう感じていただける時間をお届けできたら幸いです。

Slackでの通知があまりに多すぎて、本当に必要な重要なメッセージが埋もれてしまう問題に直面したことはありませんか？
「@channelだらけでミュートしたくなってしまい、結局重要な通知を見逃してしまった」とか、「通知は届いていたのに、誰も対応できかった」なんて経験はありませんか？

このLTでは、Slackの通知設定を見直し、必要な情報だけが確実に目に入るように改善した方法について紹介します。
どんな方法で通知の過剰を整理し、チーム内の重要なアクションを促進したのか、実際の改善事例とともにお話しします。
これからSlack通知で迷わず、必要な情報を効率的に受け取るためのヒントとなれば幸いです。

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

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

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

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億件間近…そうなればテーブル変更したくても怖くて触れない…！

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

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

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

そんな状況から始まった打刻テーブル移行のハイライトを5分で語ります。（DBはMySQLです）
・ 更新パラメータ追加に伴うログ検証
・ 参照切り替えのシャドーテスト的アプローチ
・ βリリースを活用した影響調査

動いているAPIを動いたまま内側のテーブルをすげ替えるために行った工夫にをお話しします。
本LTがみなさまのシステム改善やレガシーシステムの移行の一助になれば幸いです。

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

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

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

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

開発を進めていくと、「このAPIってどんなリクエスト/レスポンスをするんだろう」「こんなAPIがあったんだ」となることよくありますよね？
特に外部公開を目的としないプロダクトではAPIドキュメントを書かないので、さらに謎のAPIが生まれたり、コードを読まないといけなくなります。
このような苦労があるものの、いざ0から作るのは大変です。

今回上記の課題を解決するために、dedoc/scrambleというライブラリの紹介ができればと思います。
Laravelで作られたプロダクトであれば、設定なしでOpenAPI記法でのjsonをエクスポートできちゃいます。

本LTは下記聴講者が対象です。

・APIドキュメントを作りたいけど、0から作るのは面倒
・LaravelでよいAPIドキュメント生成ツールを知りたい方