"Small is beautiful（小さいものは美しい）"
"Do one thing well（一つのことを、うまくやれ）"

これらはUnix哲学でも有名な格言で、ソフトウェアエンジニアなら聞いたことくらいはあるでしょう
小さく保つために「分割統治」をし、小さな単位で処理をするのはプログラムの基本です

ですが、本当にそうでしょうか？

このトークでは小さく分割することそのものが目的化した時に起こりうる問題に目を向けることで、

「オブジェクト指向完全に理解した！」
「クリーンアーキテクチャ最高！」

と叫びがちな初級者〜中級者がハマりやすい設計の罠について理解していきます

あなたの設計は本当に大丈夫？

現代のPHP開発は、Laravelなどのフレームワーク活用、複数のAPI連携、非同期処理、
JavaScriptやCSSを駆使した動的なユーザーインターフェースの実装など、私たちが担保すべき品質の範囲は広がる一方です。
しかし、これらの要素が複雑に絡み合うことで、予期せぬバグや機能の不具合が発生しやすい状況も生まれています。

そんなPHP開発者の皆さんに向けて、「Playwright」をご紹介します。
Playwrightは、実際のウェブブラウザをプログラムで操作し、ユーザーが行うような操作を自動で実行することで、
アプリケーション全体の動作をテストできる強力なツールです。
レンダリングされたHTML、CSSの適用結果、そしてJavaScriptの動作まで含めて、ユーザーが実際に体験する環境でのテストを実現します。

本セッションでは、まずPlaywrightがどのようなE2Eテストの世界を実現するのか、その基本的な機能と特徴、効率的なテスト設計、CI/CDパイプラインで自動テストまで紹介します。
明日から、手動テストを自動テストに置き換えてみましょう！

リモートワークから出社への回帰が増える中、我々には再び「コミュニケーション」について考えさせられる機会が訪れています。

「コミュニケーション」というと、言葉と言葉での会話や、チャットでのやり取りなどが思い浮かぶかと思いますが、本質はそれだけではありません。
事象や価値観などを伝えるためには、文字や言葉以外の伝え方や文章の残し方など、組織としての文化も密接に関わってきます。
つまり、「どう話すか」や「どう書くか」だけではなく、「どう受け止められるか」「どう残るか」にも配慮した設計が必要なのです。

このトークでは、私が日々の業務で意識している「ちょっとした工夫」や「しくじりから学んだこと」をベースに、エンジニアとして、またチームの一員としてどのようにコミュニケーションと向き合うべきかを紹介します。
「もっと伝えやすく」「もっと伝わりやすく」を模索している方、あるいは「最近チーム内のすれ違いが気になるな…」という方に、少しでもヒントになる話ができればと思います。

私がYAGNIという言葉に初めて出会ったのは、まだ経験が浅い頃でした。
そのときは、ただ求められていない機能は実装しないように気をつければ、自然と避けられるものだと思っていたのです。

そしてその後、実際に現場で様々なコードを見て、色んな苦労と開発の経験を重ねれば重ねるほど、もっと良い設計を、綺麗なコードを求めていくようになります。
色んなアーキテクチャや設計手法や考え方に触れると試したくなりますよね。新規で開発できるとなると尚更です。

しかし次第に以下のような問題がちらほら見えるようになりました。
・一見きれいに見えるけれど、機能やアプリの規模に対して、理解するのに時間がかかるコード
・拡張を意図して書かれたものの、結局拡張されなかったり、しまいには使われなくなってしまったコード
・開発速度が遅くなってしまっている

そうです。私はYAGNIに反するコードを書いてしまう罠にハマっていたのです。

このトークでは、「気づいたらYAGNIに反していた」自分の経験を通して、
なぜそうなってしまったのか、どんな思考や状況がそれを引き起こしてしまったのかを振り返ります。

そして、プロダクトの性質やシステムのレイヤー・チームの目標や開発の指針と照らし合わせながら、より「ちょうどいいYAGNI」との付き合い方について、一緒に模索していきましょう。

多くの機能が長年にわたり運用されてきたPHPベースの独自フレームワーク上で構築されているプロダクトでは、当時の要件や技術スタックに基づいた設計が、現代の開発観点から見て様々な制約となる場面が少なくありません。

OSSフレームワークへの移行が選択肢として取れない状況下で、既存の独自フレームワークを活かしながら、いかに開発体験をモダンに近づけていくか。本セッションでは、その現実的な選択と具体的な手法をご紹介します。

以下のような具体的な取り組みを中心に解説します。

• PSR準拠コードとの共存を実現する拡張レイヤーの設計
  • 既存の独自フレームワークの上に薄いレイヤーを重ねることで、PSR-7/15に準拠したミドルウェアやハンドラを導入可能な構造を構築
• リファクタリングを先送りしつつ、設計改善を進めるアーキテクチャ戦略
  • ヘキサゴナルアーキテクチャの導入により、既存コードへの依存を抑えながら新機能をクリーンに追加していくアプローチの紹介
• Controller粒度の振る舞いを検証可能なFeature Test基盤の整備
  • LaravelやSymfonyのようなテスト基盤を模倣し、リファクタリング耐性を向上するための自動テストを構築可能にする手法
• OpenAPIを活用したスキーマ駆動開発と開発支援ツールの内製化
  • OpenAPIスキーマをもとに、雛形コードを生成するスキャフォールディングツールの作り方
  • フロントエンド／バックエンドでスキーマを共有するための仕組み
• OpenAPIスキーマベースのバリデーション導入とパフォーマンスへの対策
  • 実運用を通じて見えてきた課題と、性能劣化を抑えながらスキーマバリデーションを有効活用するための具体的な改善手法を共有

システムが誰かに使われて初めて価値を発揮するように、ひとりひとりの持つ知識や技術も誰かに伝わってこそ価値が生まれると考えています。AI が急速に進歩するいま、これまでの知識や技術は少しずつ価値を失っていくことでしょう。
そうなった時に何が大切になるのか。伝える技術なのではないかと私は思うのです。
カンファレンスや社内勉強会、チームメンバーに対して情報の伝達だけではなく、心の芯まで届き、行動を変容させる衝動を喚起する力が、人と働く上でこれまで以上に強く意味を持つと考えています。

このトークでは主に1 対多の状況における伝える技術に焦点を当ててお話しします。

ターゲット

• 技術に重きを置いて生きてきた方
• 人前で話すことに不安を感じている方

聞いた方に渡したいもの

• 人に何かを使える際に必要な技術
• それを実行する勇気

アウトライン

• 語られた道理が目新しいのではない。だが、人は思い出させてもらうとき力を得る。
• 価値を生むのは所有ではなく共有。
• あなたはなぜそこにいるのか。
• 心の底から信じていることだけを言葉にする。
• 聞き手と歩調を合わせる。
• 音、色、動作で感情の波と思考を支配する。
• 事実やデータだけでは足りない。
• 最初の一歩を示す。

私のマネジメントする開発チームでは、GitHub Agentを活用した開発フローを取り入れており、今では「なくてはならない戦力」として定着しています。

とはいえ、導入当初からうまく活用できていたわけではありません。
「AIに任せたが期待通りのアウトプットは出なかった」などを中心に、いくつか悩みもありました。

本トークでは、実際の現場で行ってきた試行錯誤のプロセスをもとに、エージェントAIとの「共進化」の過程を振り返ります。
再現性のあるTipsを重視しつつ、以下のような観点から、「開発にAIを溶け込ませるために必要な視点」について掘り下げていきます。
・エージェントAIを活用する際の基本的な姿勢
・導入初期にまず取り組むべきこと
・開発業務で効果的に使うための準備と工夫
・開発以外の周辺業務での活用事例（例：PRレビュー補助、ドキュメントやSQL作成）

「とりあえず使ってみた」から一歩進み、エージェントAIをツールとして活用するには何が必要か？
そのリアルな知見と、成功も失敗も含めた経験談をお届けします。

Webアプリケーションのフロントエンド、気がつけばこんな課題に直面していませんか？

・フォーマッタ/静的解析の未導入による保守性・堅牢性の低下
・アセットのビルド/最適化がされていない
・テストコードの欠如
・脆弱性や不具合の温床となる古いライブラリ
・エラー検知の仕組みがない

解決策としての大規模リプレイスは不確実性が高く、時間やコストなど大きなリスクを伴います。

本トークではMPA（マルチページアプリケーション）におけるJavaScriptを題材に、段階的に、そして無理なくフロントエンドを良い感じにするための技術をご紹介します。具体的には、Viteによるビルドや開発体験の向上、Nodeモジュールを使ったバージョン管理、Vitestによるテスト実装、TypeScriptを使った型付け、BiomeによるフォーマットやLint、Sentryによるエラー管理、などモダンなフロントエンド開発に不可欠な要素についてお話します。

このトークが、フロントエンドの持続可能な改善への第一歩を踏み出すための、具体的で実践的な道標となれば幸いです。

商品数が数万件を超えるような大規模ECサイトにおいて、ショップのトップページのパフォーマンスは顧客体験や売上に直結する重要課題です。特に大量の商品一覧を取得するMySQLクエリでは、ソートや一時テーブルの利用が増え、処理速度が著しく低下するケースが頻発します。

本セッションでは、PHP製ECサイトにおいてショップトップページのパフォーマンスを改善した具体的な取り組みを紹介します。パフォーマンス問題の特定にあたり、NewRelicのクエリ分析機能を活用し、具体的なボトルネックを明らかにしました。その分析結果を基に、MySQLクエリの設計を抜本的に見直し、インデックスの効果的な利用やクエリ構造の最適化、無駄な並び替え処理の排除などを行いました。

結果として、ショップトップページのクエリレスポンスタイムは従来の1/3以下に短縮され、サイト全体の表示速度が改善されました。

トークを通じて、NewRelicによる問題の特定から実際のMySQLクエリ改善方法までを分かりやすく解説し、参加者が自身のプロジェクトでもすぐに活かせるノウハウを提供します。

エラーが発生したとき、ログを追ったりデバッグを繰り返したりするのは大切な作業ですよね。
でも、それだけだと「エラーが起きた後の対処」に留まってしまいます。もっと良い方法があるとしたら？

設計の段階から、エラーが「見つけやすい」仕組みや「そもそも起きにくい」コードの書き方を取り入れることで、
システムの信頼性がグッと上がり、あとから困ることも減ります。

このセッションでは、例外の基本的な役割や考え方から始めて、PHPのように例外を持つ言語と、RustやGoのように例外を使わない言語のエラーハンドリングを比較。
それぞれの特徴を活かした設計方法をお話します。

難しい話だけでなく、「こうすれば実務で役立つ！」という具体例も紹介しますので、チームのディスカッションにもぜひ活用してください！

本セッションでは、OpenAPIの定義ファイルを運用する際に静的解析やフォーマッターを導入する方法やメリットについてお話しします。

OpenAPI仕様は、RESTful APIの設計と記述に広く使用されており、APIの構造を明確にし、開発者間のコミュニケーションを改善します。しかし、スキーマ定義が複雑になると、エラーの発見や保守が困難になることがあります。これに対処するためには、静的解析ツールとフォーマッターを導入することで、コード品質を向上させ、一貫性を保つことができます。

本セッションでは、OpenAPIスキーマ定義に対して静的解析ツールとフォーマッターを導入し、以下の目標を達成する方法をお伝えします。

• スキーマ定義のエラーや不整合を早期に発見
• スキーマ定義のコード品質を向上
• 開発者間のコードスタイルの一貫性を確保
• メンテナンスの容易化

昨今のWebアプリ開発において、Webブラウザは切っても切れない存在です。
このWebブラウザには、HTMLとCSSからテキストや画像を描画する「レンダリングエンジン」が含まれています。

これがどのような仕組みで動いているのか、その裏側についてはご存知でしょうか?

このトークでは、超ミニマムな簡易レンダリングエンジンをPHPで実装することで、レンダリングエンジンの大まかな仕組みの理解を目指します。
また今回のトークで用いた、サンプルコードを他言語で再実装する勉強法も合わせてご紹介します。

このトークを聞き、レンダリングエンジンの裏側を垣間見ることで、Webアプリ開発におけるブラウザからの新たな視点を獲得できるでしょう。

対象の方

Webブラウザの仕組みに興味がある方
PHPでなにか書きたいけど作りたいものがない方

このセッションでは、LaravelとInertia.jsを組み合わせたモダンなフルスタック開発について紹介します。
Inertia.jsは、ReactやVueなどのモダンなフロントエンド技術のメリットを活かしながら、サーバーサイドアプリケーションのシンプルさを維持するためのツールです。これにより、複雑なAPIやクライアント側の状態管理なしで、モダンでインタラクティブなウェブアプリケーションを構築できます。
ReactやVue、TypeScriptと組み合わせて使用する方法や、Inertia 2.0で導入された新機能（Prefetch, Deferred Props, Infinite Scrollingなど）、UIコンポーネントライブラリのshadcn/uiの活用法、ライブバリデーションを実現するPrecognitionについても説明します。
また、Laravel Wayfinderを用いて、Laravel側のRouteをフロントエンドからTypeScriptの型としてシームレスに呼び出す方法についても紹介します。

Webサービスを立ち上げるなら、多くの場合に実装する「認証認可」機能。
たくさんのネット記事には、OIDC?, OAuth?などの用語が並び、初めて関わる人にとっては難しく感じることでしょう。

自前実装するのは労力もかかるし、セキュリティホールを作り込まないかも心配、、、
いい感じのManaged Serviceを使って楽に実装できないか、、

Amazon Cognitoを使えば、基本的な認証認可はもちろん、SMSによるパスワードレスログインなどを「安価に」実装できます。

このトークでは、(OAuth/OIDCなど)認証認可の基礎について解説した後、筆者が実際に関わったPHP x Cognitoの実装について、知見を余す所なくお伝えします。

このトークで話すこと

• 認証認可の概要
• Cognitoを使ってPHPアプリケーションに認証認可機能を追加する方法

PHPではtry-catchによる例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか？
過剰なエラーハンドリングや、catchしたけれど何もしていない“握りつぶし”が積み重なると、責任の所在が曖昧になり、コードの見通しや保守性にも悪影響を及ぼします。

こうした課題へのヒントとして、Rustなどの言語で採用されているResult型の考え方を、PHPに応用するアプローチがあります。
Result型は、失敗を型として明示的に扱い、成功も失敗も返り値で表現する設計手法です。
これにより、「どこで何が失敗しうるか」「どこまでが関数の責務か」がコードから読み取れるようになり、処理の流れや責任が明快になります。

本トークでは、Result型によるエラーの設計方法や、例外との使い分けについて、以下の観点から実装例を交えて解説します：

• エラーの分類と責務の整理
• 例外との使い分け
• PHPでResult型を実装する方法

Result型を導入するかどうかに関わらず、エラーをどう設計するかを見直すヒントとして、この考え方を持ち帰っていただけると嬉しいです！

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系エンジニア

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

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

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

私は主にPHPを書いてきたエンジニアですが、業務でGoを触る機会が増えています。
その中で、最も大きな衝撃を受け、書く上で一番苦労したのが「インターフェイス」の実装方法と思想の違いでした。
（PHPでimplementsに慣れた私にとって、Goの暗黙的に満たすインターフェイスは衝撃的でした）

このセッションでは、私なりの理解を基に、PHPとGoのインターフェイスの仕組みを比較しながら、それぞれの思想、メリット・デメリットをサンプルコードを交えて解説します。
PHPエンジニアがGoを書く上で躓くであろう最初のハードルを乗り越えるきっかけをお届けします。

PHPエンジニアでGoも書いてみたいなと思っている方、PHPとGoのインターフェイスの違いに興味がある方におすすめです!

話すこと

• 明示的な実装（PHP）と暗黙的な実装（Go）の違い
• PHPとGoそれぞれのコード例を交えた実装方法の解説
• PHPとGoのインターフェイスの置き場所の違い
  • 例）RepositoryのインターフェイスはPHPではDomain層、Goでは実装近くに置きがちなのはなぜか、など

話さないこと

• PHPとGoの基本的な文法
• PHPとGoの深い設計思想