CQRSは、読み取り操作と書き込み操作を分離することでシステムの効率性を向上させる設計パターンです
本来は大規模で複雑なシステム設計で用いられることが多いですが、あえて小規模・シンプルなケースでCQRSを採用した場合、その真価をどのように引き出すことができるのでしょうか？

このセッションではAWSのサーバーレスアーキテクチャを活用することで問題解決に取り組みます
複雑さを抑えつつ柔軟性と拡張性、コストメリットと実装コストのバランスを考え小規模システムにおける適用の実装例を提示を行います

具体的には、DynamoDBをデータストアとして活用し、DynamoDB StreamsやAWS Lambdaを組み合わせることで効率的なデータ同期を実現します
またAPI Gatewayを使用したデータ提供やAWS X-Rayを用いたモニタリングによる運用の最適化も触れ、シンプルなユースケースでも長期的なコストメリットを享受できる設計が可能になります

AWSを活用したCQRSの実装例を通じて、シンプルなケースでも有効な設計手法を学び、シンプルなシナリオでもCQRSを採用する意義を再発見しましょう！

• 対象者

  • CQRSに興味があるエンジニア
  • サーバーレスアーキテクチャの導入を検討している方
  • 小規模システムでのコスト効率を追求したい開発者

• 想定学習成果

  • CQRSの基本的な考え方とサーバーレスを利用した実装方法を理解
  • 小規模システムにおけるCQRS導入の具体的メリットと課題を把握

• 話さないこと

  • 課題に対する細かな解説と考察内容
  • 実装に対する細かな解説（GitHubでのソースコード解説を用意します）

opentelemetry 拡張では任意の関数やメソッドをフックして、実行前後に PHP コードを差し込むことができます。つまり、DB への SQL 文発行や外部 API 呼び出しなどの実行をフックして計測コードを追加して計測を行っています。この機能は自動計装で有効であり、いくつかの自動計装パッケージではこの機能が利用されています。

PHP は内部の主要な関数が関数ポインタとなっているので、内部処理を差し替える、いわば内部動作をハックすることでこうした機能は実現可能でしたopentelemetry 拡張ではどのような仕組みで動いているのだろうと調査したところ、PHP 8 から追加されている Observer API （通称）で実現されていることが分かりました。Observer API を利用することで内部関数を差し替える事なく、関数やメソッドをフックする処理を追加できるようになっています。

この仕組みは PHP 内部で実装されているものなので、PHP コードから直接利用することはできません。つまり、独自に PHP 拡張を実装するか、opentelemetery 拡張のようにすでに実装されているものを通じて利用することになります。実は、opentelemetry 拡張以外にも Datadog の PHP 拡張である dd-trace では Observer API が利用されており、間接的に利用している人もいるかもしれません。

このセッションでは、PHP の Observer API という興味深い機能に焦点を当てて、その動きや PHP 内部の実装を見ていきます。

PHP開発者の皆さん、普段から使用しているvar_dumpやvar_exportの関数について、内部でどのように動作しているのかを考えたことはありますか。
このトークでは、これらの関数の違いを簡単に紹介しながら、PHPのソースコードをC言語でどのように実装しているかを一緒に読み解いていきます。

var_dumpとvar_exportは、あらゆる変数を扱える強力なツールです。これらを詳しく読むことで、PHPの型や変数がどのように動作しているのかを深く理解することができます。
具体的には、php-srcのvar.cファイルやZendのマクロ関数を順に追いながら、PHPの細かい仕様について紐解いていきます。

このセッションは、php-srcのソースコードリーディングを初めて体験したい方や、過去に挑戦したことがあるけれども細部まで追ったことがない方を対象にしています。
このトークを通じて、PHPの詳細な仕様を理解するために「php-srcを直接読みに行く」という選択肢が広がることを願っています。

デザインシステムって「ルールの塊」や「UIライブラリ」みたいなイメージを持ちます。でも実際は、それだけではありません。デザインシステムの本質は、 運用を含む仕組み にあります。

たとえば、デザインレビューを通じて品質を保ったり、デザイナーとエンジニアでフィードバックをし合いながら改善を続けたり、変更があったときにガイドラインやドキュメントを更新して全員が迷わないようにしたり。これらの運用があってこそ、デザインシステムは単なるルールやライブラリから「使えるシステム」に進化していきます。

このセッションではプロジェクトでデザインシステムを立ち上げた経験を元に「どう作るか」「どう運用するか」をエンジニア視点でのポイントを紹介します。

Webサービスの開発で、認証・認可が必要になる場面が多々あると思います。
Laravelで認証・認可を実装しようとすると、Laravelが提供しているライブラリだけでもFortify、Sanctum、Passport、Socialiteなどなどたくさんの選択肢があります。
各ライブラリの具体的な特徴や、どのような状況で使用すべきでしょうか？

本トークでは、それぞれのライブラリの違いや使い所を紹介します。

システム開発の現場ではヒューマンエラーによるシステム障害・トラブルは避けられない課題です。
うっかりミスで損害を出してしまったときに再発防止を図る際に「今後はもっと注意する」では実効性もなくビジネスサイドからの納得も得られません。
一方で製造業から輸入された「なぜなぜ分析」は「なぜ」を5回繰り返すという単純な方法で広く普及しましたが、簡単過ぎる故に本来の問題事象への対策検討という目的に反して個人攻撃に使われてしまう現場もあり、辛い思いをされた方もいるのではないでしょうか。

本トークでは、IPAの先進事例を元にヒューマンエラー分析手法と効果的な対策を紹介します。
ヒューマンエラーを時系列と要因分析により事実関係を把握し、対策発想マトリクスによって個人を責めることなくバグを生み出した環境を改善することを目指します。

話すこと

• なぜなぜ分析の何が良くなかったのか
• スイスチーズモデルによる事故発生メカニズムの理解
• 他業種における問題分析の紹介
• 個人への責任追及ではなく、システム改善に繋げるための分析手法
  • ヒューマンエラー分析手法の５つのステップ

AWS CDKでサポートされていないPHPでInfrastructure as Code的なことをやるとしたら？という興味とその実装が本発表の論点です。
AWS SDK for PHPから提供されるクラスを使用して全てのインフラリソースをコード化し、その場合の構成管理や関連するAWSとPHPの知見を共有する内容になります。
今回のインフラ構成の題材としては、下記のサービスを使用したシンプルなServerlessApplicationを考えています。
APIGateway, Lambda, DynamoDB, EventBridge, IAM

扱いたいトピック

• SDK for PHPから提供されるクラスの概要
  • Aws\ApiGateway\ApiGatewayClient
  • Aws\Lambda\LambdaClient
  • DynamoDb\DynamoDBAttribute
  • Aws\EventBridge\EventBridgeClient
  • Iam\IAMService
• ServerlessApplicationの基礎とSDK for PHPでの実装コード
• AWS CLIから発生するログの読み解き方
• SDKで作成するリソースのResourceName重複を避けるロジック（CDKなら書く必要がないが）
• インフラリソースのSDKによるライフサイクル管理（CRUDの実装）

PHPユーザーがあまり使わないクラスの使用例を挙げつつ、楽しくPHPとAWSについてを学べるセッションにできればと思います

PHP のアップグレードしたけど、既存コードを新しい構文へ更新する時間がない。
そんな悩みありませんか？

えんさがそっ♪ でも、PHP のアップグレードを随時実施していますが、新しい構文への追従が十分にできていませんでした。
単純にリファクタリングする時間を確保できなかったからです。
しかし、そんな課題を解決してくれる神ライブラリを発見しました。その名は...rector！

rector を使えば、従来なら数週間かかるリファクタリング作業をわずか数分で完了させることが可能です。
さらに CI へ追加することで、自動的にリファクタリングしてくれる優れもの！
これにより、継続的なレビューの効率化やコードの品質向上も期待できます。

皆さんも快適な rector ライフを過ごしませんか？

LaravelとInertia.jsによるモダンなフロントエンド開発において、Vue3 Composition APIを活用した保守性の高い設計パターンを解説します。
Composablesパターンによるロジックの再利用性、Laravelのバックエンドとの効率的な統合、テスタビリティの向上について、実装例を交えて紹介します。
Inertia.jsは、モノリシックとSPAのベストプラクティスを融合させた革新的なアプローチです。フロントエンドが複雑化する中で、開発者は保守性の高いコードベースの実現に課題を感じています。

本セッションでは、LaravelとInertia.js、Vue3の実践的な組み合わせに焦点を当てます。特にComposition APIを活用したComposablesパターンにより、ビジネスロジックの再利用性を高め、テストしやすいコンポーネント設計を実現する方法を解説します。フォームハンドリング、状態管理、APIリクエストなど、実際の開発現場で直面する具体的な課題に対する解決策を、実装例を交えながら紹介します。

Laravelの強力なバックエンド機能とVue3の洗練されたフロントエンド機能を最大限に活かし、保守性と開発効率を両立させる設計パターンを、ぜひ一緒に探求しましょう。

Laravel 11で導入されたStreamlined Application Structureの主な特徴と利点を詳しく解説します。

新しいbootstrap/app.phpの役割や、変更されたディレクトリ構造、
そして一元化された設定管理がプロジェクトにどのような影響を与えるのかを紹介します。
はたして設定や構成の管理が容易になるのか、コードの可読性と保守性が向上するのか、といった観点を交えながら、
既存のプロジェクトへの適用方法についても共有いたします。
さらに、これらの変更が実際の開発プロセスにどのように寄与するのかを探っていきます。

新しいアーキテクチャを自分のプロジェクトに効果的に取り入れるためのヒントになれば幸いです。

近年、プロダクト開発におけるフルサイクルエンジニアリングの重要性が高まっています。これに伴い、バックエンドエンジニアがフロントエンドスキルを習得するニーズも増加しています。しかし、フロントエンドの学習に対して「自分には難しい」という心理的なハードルを感じる方も多いのではないでしょうか？

本セッションでは、オブジェクト指向プログラミング（OOP）の知識を土台に、Reactを使ったフロントエンドの基本的な考え方をわかりやすく解説します。バックエンドエンジニアが親しみやすいOOPの概念と、Reactの「コンポーネント指向」の類似点や相違点を比較しながら、フロントエンドの基礎的なメンタルモデルを解説します。

具体的には以下の内容を取り上げます。

・OOPとReactの共通点と違い: クラスとコンポーネント、オブジェクトグラフとUIツリー、MVCとFluxの対応を具体例を用いて比較。
・状態とイベントの管理: React Hooks (useState) を使った状態遷移を解説。

これらをブログの記事「Articleクラス」と「Articleコンポーネント」を比較して解説します。

短時間でフロントエンドのエッセンスを把握することを目指すこのセッションを通して、「フロントエンドもできるエンジニア」を目指す一歩を踏み出すきっかけをお届けします。

OSSへのコントリビュートは敷居が高いと感じていませんか？「何から始めればいいのかわからない」「自分のスキルでは貢献できない」といった壁を感じる方も多いでしょう。
しかし、自分のプロダクトのPHPのバージョンアップ作業をきっかけに、自然とOSSにコントリビュートを始めることができます。

本セッションでは、以下の内容をお話しします：

PHPのバージョンアップで直面した課題とその解決方法
バージョンアップ作業を通じてOSSプロジェクトにフィードバックを返す方法
初心者がOSSコントリビュートに取り組むための具体的なステップ
実際の体験を交えながら、どのようにOSSコントリビュートを「ハードルの高いもの」から「身近なもの」に変えられるのかをお伝えします。PHPのバージョンアップは単なる技術負債解消にとどまらず、コミュニティ全体の改善に貢献する第一歩でもあります。
初心者でも始められるシンプルな方法を知り、開発者としての新たな一歩を踏み出しませんか？

私はEM1年生。 2024年4月に新規プロダクトをリリースし、現在はそのプロダクトをなんとか成長させていくべく邁進しています。

新規プロダクトのリリース、そしてその後のグロースにあたってはさまざまな進行上の課題がチームに襲い掛かりました。

・ スクラムを解釈した開発イベントがなぜかうまくいかない
・ 社内や社外からのフィードバックが集まらない
・ プロダクトマネージャーとタスクの温度感がすり合わない
・ プロダクトの課題が無限に積まれ、さばいてもさばいてもなくならない
......

これらの課題が発生した背景には、新規プロダクト開発においてはフェーズごとに求められる立ち回りが大きく変化するというものがありました。

本セッションではそのような状況に対応するため、繰り返し見直し、変更・改善してきた開発手法の変遷について、良かった点と反省点の両軸から振り返ります。

「どのような開発手法を採用すればいいか分からない」、「なぜだか現状の開発手法がしっくりきていない」といったお悩みを抱える方へ、
実践的な改善方法やそのヒントとなる知見をお伝えできたら幸いです。

画面開発で、こんな悩みを抱えていませんか？

• 画面ごとに統一感のないデザイン、曖昧なレビュー基準に振り回される
• 開発のたびにゼロからデザインとコーディングを繰り返す
• CSSの保守性が低く、改修のたびに手間がかかる

例えば、新しい画面が追加されるたびに微妙に異なるUIが作られたり、レビュー時に明確な基準がないことでデザインの決定が長引いたりした経験はないでしょうか。こうした課題が積み重なると、チーム全体の開発効率やモチベーションが著しく低下してしまいます。

これらの課題に対する解決策として、「デザインシステム」を導入しました。

今回のトークでは、既存のデザイン案を基に、FigmaやStorybookなどのツールを活用しながらデザインシステムを整備し、プロダクトへの導入を進めた一連の取り組みをご紹介します。

話す内容

• デザインシステムとは何か
• 導入に向けた具体的なステップ
• 導入前の課題と導入後に得られた効果
• 導入が進まなかった要因と成功に繋がった工夫

こんな方におすすめ

• 画面開発で課題を感じているエンジニア、UI/UXデザイナー
• レガシーなフロントエンド構成に悩んでいる方
• デザインシステム導入に興味がある方

トークを通じて、みなさんの開発現場でも役立つヒントをお届けできればと思います。

世の中には大小様々な企業があり、多様なチームが存在すると思います。
カンファレンスに参加されているみなさまはよいチームビルディング、よいチームを形成しているところに所属されていることが多いのではないでしょうか？

しかし、「よいチーム」とは現時点でも氷山の一角であると、現実で直面する場面は多いのではないでしょうか？
私も様々な現場を歩いてきた身として、多くの「よいチーム」「わるいチーム」というのを見てまいりました。
そういった現場では良いも悪いも関係なく、レガシーコードと向き合う機会が必ずやってきます。
さて、ご自身のチームはレガシーコードに立ち向かうことはできる「よいチーム」となっているでしょうか？

今回私がご提唱するのは、レガシーコードに取り組むのであれば、最初にチームを改善することで何が変わっていくのか、というものでお話をさせていただければと思います。

話すこと

• レガシーコードコードとは
• 「よいチーム」ってなに？
• 会社は「文化」、チームは「規約」
• 本題（レガシーコードの前にチームを改善する）

話さないこと

• 詳細なコードの事例とか

想定聴講者

• チームに不満を持っている人
• 昇格したチームリーダー、マネージャー
• レガシーコードにこれから立ち向かおうとしている方

本セッションでは、仕様書がなくテストコードもないシステムのLaravelへのリプレイスプロジェクトで、安全にリプレイスを行えるようになった方法論を紹介します。

プロジェクト初期は、仕様書がないこともあり、網羅的なテストが行えない状況でした。その結果、結合テスト時に不具合が多発してリリース延期を余儀なくされたり、プロジェクト期間の延長が発生していました。

そこで、移植方針やテスト方法の見直しを行った結果、オンスケでプロジェクト推進ができるようになりました。

以下のトピックを扱います。

• 仕様書のない中で安全に移植を行うための方針
  • 移植方針の見直し
  • 網羅的なテストケースを作る方法
• 計画を推進するためのマネジメントの方針

皆さんは普段、下記のような環境で開発をしていますか？

• コンテナ化され本番とほぼ同じ開発環境
• 手厚いソースコードレビュー
• 整備されたCI/CD
• 充実したテスト
• 安全な運用ルール

しかし、世の中にはこのような整備された安全な環境でない現場もあります。
では、何がよくないのでしょうか。
このセッションでは、開発環境のアンチパターンをもとに、何がよくないのかを解説していきます。

トーク概要

いつものようにコーヒーを片手にミックスナッツを食べながら、今日もコードレビューの時間がやってきました。

プルリクエストを眺めながら、こんなことを思ったことはないでしょうか？

• 差分でかすぎる...これ正しくレビュー出来る人いる？
• ここまで実装進んでから指摘しにくいなぁ...
• フィードバックするのはこれで何度目だろうか...

恥ずかしながら私の部署でも、このようなことはよくありました。

このセッションでは、コードレビューの存在意義とは一体何なのか？を改めて考え、私たちの部署で普段行われているコードレビューやプルリクエストに対するガイドラインをご紹介します。
このセッションが終わる頃には、明日からのコードレビューが楽しみになる事間違いなしです！（カリッ）

話さない内容

• 具体的なGitHub ActionsのCIの組み方
• GitHubの設定

想定読者

• コードレビューという作業でもやもやを感じる人
• レビュー指摘に対してモヤモヤを感じる人
• チームのパフォーマンスを改善したい皆様

任意の時点の PHP プロセスのメモリ状態のスナップショットをとり、SQL で「一番大きな文字列」「あるクラスの全インスタンスにおける特定プロパティに格納された配列の平均サイズ」「前回取得時のスナップショットから生き残り続けているオブジェクト」といった情報を自由に取り出せるとしたら、とてもおもしろいと思いませんか？

え、何の役に立つのかって？そりゃ何かの役には立つでしょう。何かの役に立つという確信はありますが、しかしそのような実用一辺倒の観点でものごとの価値を決めつけていくのは、あまり豊かな生き方とは言えません。役に立とうが立つまいが、とにかくスクリプトの状態を SQL でクエリするのです。

このトークは自作のメモリプロファイラ Reli に、登壇駆動開発で機能追加をするための枠です。採択されトークが行われることで、世界中の PHPer がメモリリークの心配なく long running な PHP スクリプトを安心して作ったり動かしたりできる、そんな夢のある世の中へ一歩近づくこともできます。
トーク内容そのものは PHP 処理系の内部状態をどう RDB のテーブル構造で表すかというマニアックな話が延々続くこととなります。
PHP スクリプトによる大道芸に興味のある方には、大道芸として面白く聞こえるかもしれません。
聞く人がほぼ全員置いてけぼりになるけれど喋ってる本人は妙に熱量が高いという、その温度差を眺めて苦笑いしたり、運が良ければ「こんな変なことやっていいなら俺も/私も変なことをやるぞ」と妙な熱量が伝染したような気持ちになることもできるかもしれません。

CTOとして内製開発チームをゼロから立ち上げ、現在では社員・業務委託を含め約20名の規模にまで成長させてきました。このチーム拡大の過程では、採用難が叫ばれる時代の中、スキルやマインドを見極め、自社にフィットする人材を見つけることに真剣に向き合ってきました。
その一方で、採用活動ではさまざまな課題にも直面しました。理想の人材と巡り合えないことや、採用後に感じるミスマッチなどの試行錯誤を繰り返してきた中で、一つの有効な手法としてコーディング試験を導入しました。この取り組みによって、候補者の技術力や考え方をより深く理解し、チームに適した人材と出会う手ごたえを得ることができました。
本セッションでは、コーディング試験導入の背景や実際の運用方法、そこで得られた成果や課題、そしてそれを通じて得た学びを共有します。同じように採用の課題に直面している方々にとって、実践的なヒントとなれば幸いです。

◆対象者
・エンジニアの採用に関わるエンジニア
・新規の開発チーム立ち上げをしている人

◆話すこと
・なぜ採用プロセスを改善しようと思ったのか？
・PHPer採用の課題感
・技術力を客観的に評価する必要性
・テスト内容の作成
・実施してみた結果
・候補者の反応やフィードバック
・実施したうえでの改善
・どのようなポイントを評価したか
・採用プロセスにおける成果
・コーディングテストの有効性