トーク

AWS Lambdaは、小規模かつシンプルな設計が推奨されていますが、実際には複数の事業ドメインをマイクロサービスとして分割し、継続的な機能追加や変更が求められるケースが増えています
こうした構成では、特定の関数がSQSやEventBridgeに直接依存するなど局所的な実装が積み重なり、DTOの定義が乱れることでフロントエンドへの影響も無視できません

本セッションでは、Lambda上でClean Architectureを実践し、変更容易性と構造の一貫性を保つ手法を具体例を交えて紹介
ユースケース層とドメイン層をLambdaの制約に依存させず、インフラ層のみ非同期処理・初期化の制約に最適化することで、依存逆転の原則と明確な責務分離を実現
Adapterパターンを用いたイベント抽象化や、JSON Schemaを活用したDTO設計による型整合性の維持など、具体的な実践ノウハウもお届けします

Lambdaの制約を超える長時間処理についてAWS Fargateへ基盤を切り替え、設計を維持したまま柔軟に基盤を選択する方法もご紹介します

Lambdaだからこそ、変更に強い設計が必要です
複数サービス、UIと連携するマイクロサービスにおいて、基盤と設計が協調したアーキテクチャ構築のヒントを学びましょう

• お話すること

  • Lambda上で実践するClean Architectureの具体構成
  • Adapter実装でLambdaの非同期・初期化制約を乗り切る方法
  • DTO設計によるフロントエンド・API間の型整合性担保

• 想定聴講者

  • Lambdaやサーバレス環境でClean Architectureを実践したい方
  • マイクロサービス設計で拡張性と柔軟性を確保したい方
  • UI/API間の連携設計に課題を感じている方

この設計、本当に正しいのかな…？そんな迷いに出会ったとき、どうしますか？
本セッションでは、「とりあえず書いてみる」「すぐに壊してまた作る」という軽やかなプロトタイピングスタイル＝VibeCodingを通して、設計を具体的なコードで試し、磨き上げる方法を共有します

VibeCodingは、一見直感的で自由にコードを書くように見えますが、実は『何度も作り直して設計の輪郭を探る』ことを積極的に肯定した開発スタイルです
生成AIや補完ツールとテンポよく対話しながらコードを書くことで、頭の中の設計と実際のコードとのギャップを素早く埋め、設計が実際にどう動くのかをリアルタイムで検証できます

セッションでは、VibeCodingによって得られた具体的な知見を共有します
『壊しやすい構造』『変更を戻しやすい設計単位』『生成AIと開発者の思考のギャップ』など、具体的な観点から、短時間で設計を試し、評価し、改善するサイクルの構築法をお伝えします

議論やドキュメントだけで設計を詰めるのではなく、『まずコードを書いて試し、壊してまた考える』という積極的な開発姿勢を後押しし、設計に迷いなく取り組む方法を掴んでいただきます

お話すること
　- VibeCodingの定義と設計への応用
　- 生成AIを用いたプロトタイピングと考察ループの構築
　- 書きやすさ・壊しやすさ・戻しやすさから設計を掘り下げる視点

想定聴講者
　- 設計の妥当性に迷う方
　- プロトタイピングで設計検証を繰り返したい方
　- 生成AIと共に“考えるように書きたい”すべての開発者

Clean ArchitectureやDDDを導入するPHPチームが増えていますが、多くの現場で「設計がコード内だけに閉じ込められた」状態になっています
せっかく設計を綺麗にしても、デプロイが属人化して変更が難しく、テスト環境が不安定で、プレビュー環境も整備されていなければ、設計のメリットは現場に十分浸透しません

本セッションでは、PHPプロジェクトにPlatform Engineeringを適用し、コード外の「設計支援」を実践する方法を紹介します
設計の再利用性や責任分離を高めるCI/CDパイプライン、テスト自動化、プレビュー環境の構築、モノレポ管理など、具体的な仕組みを共有します

チームトポロジーの『Enabling Team』『Platform Team』『Stream-Aligned Team』をベースに、
Platform Teamが単なるインフラ担当を超え、「コード外から設計思想を現実化する戦略的なパートナー」になる方法をお伝えします

お話すること
　- チームトポロジーに基づく設計支援の構造
　- Platform Teamが設計再利用や責務分離を支える仕組み（CI/CD、テスト自動化）
　- プレビュー環境・モノレポ管理による設計体験の向上

想定聴講者
　- PHP開発チームの設計力を基盤面から支援したい方

• 設計と組織構造の関係に興味がある方
• Platform Engineeringを取り入れたいSRE・DevOps系エンジニア

「この設計、本当にいいのか？」そう迷ったとき、ずっと考えているだけでは答えが出ない──そんな経験はありませんか？
このLTでは、まず手を動かしてみる、壊してみる、またすぐ書いてみる
そんな軽やかな反復によって設計を確かめるアプローチを紹介します

近年、生成AIやコード補完ツールの進化により、考えたことをすぐ試せる環境が整いました
この流れの中で生まれた文化のひとつが「VibeCoding」
BGMや気分に乗せて、直感とリズムを大切にしながら、楽しく試行錯誤を繰り返すコーディングスタイルです
PoCやプロトタイピングとの相性も抜群です

このLTでは、そんなVibeCodingのリズムの中で見えてきた

• 書きながら気づく「壊しやすさ」と「戻しやすさ」
• 補完と自分の意図がズレる瞬間の設計的示唆
• 30分1セットで設計を“体感”するテンプレート思考

といった実践的な視点を紹介します。
設計を頭の中だけで完結させず、「ノリで書いて確かめる」ことで得られる気づきを、少しでも持ち帰っていただければ嬉しいです。

• 想定聴講者
  • 設計の良し悪しをコードで確かめたい人
  • 生成AIを“動く設計ツール”として使いたい人
  • 設計と集中のバランスに悩んでいるすべての開発者

設計の話をしているはずなのに、なぜか現場でうまく伝わらない、そんな経験はありませんか？
Clean Architecture や DDD を実践し、責務の分離やドメインのモデリングをコード上で実現しても、
それがチームの動き方やプロジェクトの進め方と一致していないと、せっかくの設計がうまく活きないことがあります

本LTでは、設計を「コードの構造」に閉じるのではなく、「チーム構造」「責任分担」「役割」にまで広げて考えるアプローチを紹介します、キーワードは「チームトポロジー」
アプリケーションの内部構造だけでなく、開発者の関係性や組織の構造にもドメインの境界や責務を適用することで、設計と運用のねじれを解消することができます

例えば、認可や監査といった横断的関心事に対して Platform Team がどのように設計支援を行うか
あるいは、ユースケースの責務とチームの責務がズレたときに、実装がどんなふうに崩れていくか
短い時間ではありますが、「設計はコードにとどまらない」ことを提示します

設計・組織・開発体験がバラバラになってしまっているチームにとってのヒントになれば幸いです

• お話すること
  　- 設計とチーム構造を接続するための観点
  　- チームトポロジーを活かしたドメイン適用の工夫

• 想定聴講者
  　- 設計と組織のねじれに悩む方
  　- 設計やチーム構造に興味を持ち始めた初学者の方

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

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

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

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

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

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

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

「抽象化していますか？」ーー抽象化と聞くと、設計やモデリングをイメージするかもしれません。他にも、interface のような言語機能を利用することを思い浮かべる方もいるかもしれません。たしかにこれらも抽象化の一つですが、それだけではありません。また、抽象化には難しそうなイメージを持たれがちですが、実はソフトウェア開発を行なっている私たちにとっては日々利用している身近なものです。

本セッションでは、抽象化（と具体化）という考え方を整理し、設計や言語機能だけでなく、物事の理解や共有、課題解決、トラブルシューティングといった開発現場の広い場面でも活用できる「思考の技術」として具体的な例とともに紹介します。

「使える思考のツール」として抽象化を一緒に見ていきましょう。

「抽象化していますか？」ーー抽象化と聞くと、設計やモデリングをイメージするかもしれません。他にも、interface のような言語機能を利用することを思い浮かべる方もいるかもしれません。たしかにこれらも抽象化の一つですが、それだけではありません。また、抽象化には難しそうなイメージを持たれがちですが、実はソフトウェア開発を行なっている私たちにとっては日々利用している身近なものです。

本セッションでは、抽象化（と具体化）という考え方を整理し、設計や言語機能だけでなく、物事の理解や共有、課題解決、トラブルシューティングといった開発現場の広い場面でも活用できる「思考の技術」として具体的な例とともに紹介します。

「使える思考のツール」として抽象化を一緒に見ていきましょう。

PHPやLaravelで開発したことのある人なら、「CSRF」という単語について聞いたことはありませんか?

例えば、Laravelで新しく作ったフォームを開いたら、「419 | Page Expired」のようなエラーを見たことがある人は多いのではないでしょうか?
(そして、とりあえず @csrf というおまじないを書いたらエラーが直った経験もありませんか?)

CSRF (クロスサイトリクエストフォージェリ) は脆弱性の一種で、
これを対策しないと、ユーザーが意図しない操作（例えば、商品の購入など）を強制的に実行させられてしまう可能性があります。

じゃあどういうコードを書くとCSRF脆弱性を仕込めるのでしょうか?
このトークでは、サンプルのフォームにCSRF脆弱性を仕込み、実際に攻撃した後、脆弱性を仕込まずに済む対策について紹介します。

アウトライン (案)

1. CSRFって何?
2. こんな場面で見たことありませんか?
3. CSRF攻撃って結局どういう攻撃なの?
4. どういうコードで起こり得るの? (映像による実演)
5. じゃあどうすればCSRF脆弱性を作り込まずに済むの?

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

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

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

以下のポイントを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による運用改善に興味のある方
• チーム内でのスキーマ共有・認知コストを下げたいと考えている方

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

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

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

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

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

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

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

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

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

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

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

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