"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 対多の状況における伝える技術に焦点を当ててお話しします。

ターゲット

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

聞いた方に渡したいもの

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

アウトライン

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

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

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

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

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

このトークで話すこと

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

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 のような言語機能を利用することを思い浮かべる方もいるかもしれません。たしかにこれらも抽象化の一つですが、それだけではありません。また、抽象化には難しそうなイメージを持たれがちですが、実はソフトウェア開発を行なっている私たちにとっては日々利用している身近なものです。

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

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

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

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

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

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