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

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

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

さらにシステム設計における現実的な課題として、データ同期の遅延や書き込み負荷の増加についても触れ、
最終整合性の採用やSQSによるリクエストのバッファリングなどの解決策を提示し、生成AIを用いた学習コストの低減についても触れます

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

• 対象者

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

• 想定学習成果

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

近年、プロダクトや機能のライフタイム全体に責任を持つフルサイクルエンジニアを目指そうという考え方が普及しています。フルサイクルエンジニアとしてのスキルを拡張するために、バックエンドエンジニアがフロントエンドを学ぶ必要性が増しています。ただ、いきなりフロントエンドに挑戦するハードルは高いと感じる方も多いでしょう。

しかし、発表者はPHPを6年、React・Vueを5年書いてきた経験から、適切なメンタルモデルを身につけていれば両者の行き来は難しくないと感じています。

本セッションはオブジェクト指向プログラミング（OOP）の考え方を土台に、フロントエンドの「コンポーネント指向」を解説することで、バックエンドエンジニアがフロントエンドを学ぶ基礎を作ろうというものです。内容は私が執筆したReactの考え方の解説記事を、バックエンドエンジニア向けにアレンジする予定です。

「React を深く知るための入り口」
https://zenn.dev/panda_program/articles/deep-dive-into-react

まず、OOPの「クラス」「オブジェクトグラフ」「MVC」と、Reactの「コンポーネント」「UIツリー」「Flux」の違いや共通点を比較します。例としてブログ記事を題材に両者の設計や振る舞いを整理した後、Reactの基本的な機能と考え方を紹介します。

・状態があるコンポーネントと状態がないコンポーネント： React Hooks の useState と状態遷移
・状態管理とイベントハンドラ：ユーザーアクションへの対応と、UIの動的な更新の仕組みを解説
・プレゼンテーションロジック：フロントエンドとバックエンドのHTML描画の違い（JSX）

Reactの基本を押さえつつ、OOPの視点を活かしながらフロントエンド特有の設計思考を身につけましょう。

物理エンジンは、物体の運動のシミュレーションに用いられ、ゲームや学術研究など様々な用途のある技術です。

その動作原理を少しでも理解すべく、PHPで簡単な物理エンジンを作りました。
https://phpysics.net/

本トークでは、物理演算をプログラムに落とし込むための理論から入り、デモを交えつつ、具体的な実装方法の一部までをお話しします。

話すこと

• 物理法則をプログラムに落とし込む過程
  • 物理エンジンがやっていること
  • 位置の計算
  • 力の計算
• デモ
  • 引き合う2物体のシミュレーション
  • 振り子の運動
  • バネの運動

あなたも、自分で作ったプログラムの中で物体を動かして遊んでみませんか？

※PHPカンファレンス沖縄のトークのブラッシュアップ版です

15年以上にわたり、社内の売り上げを支え続けてきた基盤システムが存在しました。
このシステムは、事業ドメインの変遷に合わせて不断に拡張され、事業の成長を支えてきました。
しかし、その結果として、巨大なモノリシックレポジトリ、仕様書の欠如、1ファイルに集約されたJavaScript、そして無数のマジックナンバーという問題に直面しています。
これにより、不具合の発生頻度増加、開発生産性の低下、追加開発の難易度上昇といった「技術的負債」が無視できない状況になりました。

本トークでは、これらの課題を解消すべく、fuelPHP（PHP version 7.3）から社内で標準的に利用されているLaravel（PHP version 8.2）へのリプレイスを実施した事例についてお話しします。

具体的には以下のトピックについて詳しくお話しします。

• リプレイスに際して最初に決定した事項とその理由
• プロジェクトの実現可能性を高めるために考慮したスケジューリング
• 開発環境の技術選定プロセスとその選定理由
• 基本的なアーキテクチャ設計のアプローチ
• リリース時に行った対応策
• リプレイス後に得られた具体的な効果

PHPに関する深い技術的な議論は難しいかもしれませんが、技術的負債を抱える皆様にとって役立つ情報を提供できれば幸いです。
ぜひ、このセッションを通じて、皆様のプロジェクトの成功につながるヒントを得ていただければと思います。

PHP は 1995 年から続く Web 向けプログラミング言語であり、30 周年を迎える今、技術の進化が著しい中で、PHP も大きく進化を遂げています。

PHP がこの世に生まれた頃、私はまだ 10 歳くらいの少年でした。
PHP が 30 周年を迎える今、世の中の何もかもがもはや当時とは違っています。もちろん私も 40 歳のオッサンになりました。

このトークでは以下のようなトピックへ触れつつ、2025 年の PHP プログラミングの現況を雑多な観点からまとめて紹介していきます。
・エディタをはじめとした開発環境
・今の言語機能を活かした典型的なコードの姿
・コードの部品分割方法、構成方法
・パッケージシステム
・静的解析や自動リファクタリングなどの周辺エコシステム
・実行環境の選択肢
・フレームワークの選択肢
・かつて PHP では不可能・不得意とされていた非同期処理や OS とのインタラクションなど

このトークを通じて、PHP 4 や PHP 5 の時代しか知らない人からすれば信じられないような、PHP 7 が出た 10 年前を知っている人が見ても少し意外に思うような PHP の現在の姿を知ることができるでしょう。またこれまで PHP をあまりつかったことがない人向けには、どういった言語機能やツールを前提に言語を使っていけばよいかを古い情報に惑わされずひと巡りできるような、簡単な手引となることを目指します。

ScalaやErlangなどでアクターモデルは、1973年に発表された並行計算の数学的モデルの一種ですが、
長い間PHPでは実現が難しいとされてきました。
アクターモデルは、並行プログラミングにおける効率的な計算モデルであり、プロセス間の非同期通信も特徴の一つとしています
効率よくそれぞれが並行で動作し、簡単に状態を復元することができたりPHPのOSSなどではあまり見ない特徴を持っています。
PHPでももしそれが実現できたら・・・

しかし時間が経つにつれ、Swooleなどをうまく活用することで実現できそうなことがわかり、
PHPでフルスクラッチで開発したアクターモデルのツールキットがPhluxorです。

Phluxorは、PHPではあまり見られないメッセージングを活用した仕組みを持ち、
各インスタンスが独立して動作し外部から隔離されたアクターを実現しています。
さらに、物理的に異なるサーバ間でのアクター操作が可能な機能を実装しています。
Webフレームワークとは異なり、情報伝達設計に特化した仕組みを持ち、
PHPでは他に類を見ないヒエラルキー構造や自動復旧機能でアクターシステムをサポートしています。

これらは一体どのように実装して、どんな仕組みで動いているのか？
アクターモデルのツールキットの作り方について、詳しくお話します！乾杯！

本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、その仕様を様相論理の一種である時相論理を用いて厳密に記述し解析する技術について解説します。

みなさんは「ボタンをクリックすると機能 X が正しく動く」といったテストケースを目にしたことはありませんか？ お気づきの通り、このテストケースはあまり良くない例です。では、何が良くないのでしょう？ 一番の問題は、ここで言う「正しく」がどのような状態を指すのか、言い換えればこのテストケースが何を保証しているのか、が全く具体的ではない点です。

我々が何らかの方法でシステムの仕様を保証しようと考えた場合、テスト設計であるとか、あるいは自動化ツールのような、仕様を「テストする」ための方法論に目が行きがちです。しかしその前段階として、仕様を「記述する」というステップがあることは忘れてはいけません。入力に対して出力がある、いわゆる単体テストであればそれほど困らないかもしれません。しかし、例えば複数のサーバが協調して動く「分散システムの正しさ」だったら？ さらに、複数のサーバのうち一部が高負荷となってレスポンスを返したり返さなかったりする状況だったとしたら、全体の動作の「正しさ」にはどのような影響があるでしょうか？

自然言語による仕様の表現は、我々が普段なんとなくイメージしている以上の曖昧性を含みます。そしてその曖昧性を排してシステムに対するより良い理解と洞察を得るために、厳密な「共通言語」を定義したいという動機は、かなり旧い時代から現在に至るまで、一貫して計算機科学の興味の対象であり続けています。

本セッションでは、このような動機に応える様相論理とモデル検査について、可能な限り誤魔化さずに解説したいと思います。普段、分散システムを触っていて、何となく計算機科学の基礎が気になってきたぐらいの方にお薦めです。

私たちのチームはPHPとRDBMSを用いた受託開発を中心に開発をしてきました
チーム文化として、クライアントニーズに迅速に応えながら、時代の変化への柔軟性を持って開発を進めることを大切にし、
常に新しい技術や手法を積極的に受け入れることを得意としていました

そんな中、話者である私自身は「サーバーレス」を得意としていましたが、そのスキルを自分ひとりの武器として振るうのではなく、
チーム全体の文化や価値観に溶け込ませ、組織的な生産性・開発価値の向上につなげるにはどうすればよいのか、日々考え続けてきました

そこで目を向けたのが「Platform Engineering」の考え方です
Platform Engineeringは、開発者がインフラやツール選定に悩まず、本質的なビジネスロジックの創造に集中できるようなプラットフォームやサービスを用意し、組織内のエンジニアリングプロセスを最適化するアプローチです
サーバーレスが得意な「私自身」から離れ、あくまで「チームとしての開発価値向上」をゴールに据え、共通のプラットフォーム基盤としてサーバーレス技術を位置づけることで、メンバー全体がその恩恵を享受できる形が見え始めました
その結果サーバーレスDBとして価値のあるTiDBもスムーズに導入出来てコストメリットを享受しています

従来のLAMP系スタックを踏襲しながらもサーバーレス環境をチームにシームレスに組み込み、Platform Engineeringという視点で共通基盤として活用し続ける価値について話します
個々人がスキルやツールに依存するのではなく、チームとして得られる付加価値、そしてエンジニアリング体験の向上についてお話できれば幸いです

• 想定聴講者
  • サーバーレスをチームに浸透させたい人
  • Platform Engineeringが何か知りたい人

近年、大規模言語モデル（LLM）が急速に進化し、ナレッジグラフとの連携が重要性を増しています。LLMは膨大なデータを処理しながらも、特定分野の知識を正確かつ構造化して扱うには限界があります。ここで注目されるのがナレッジグラフ。データを構造化し、関連性を明確にすることで、LLMと補完し合いながら、より高度なアプリケーションが実現可能になります。では、PHPでナレッジグラフを扱うにはどうすれば良いのでしょうか？

本セッションでは、PHPを使ってナレッジグラフを活用する方法を解説します。ナレッジグラフとは何か、その基礎概念から始め、具体的にPHPでどのように操作・活用するかを探ります。まず、ナレッジグラフに関連するRDF、OWL、SPARQLなどを簡単に説明し、PHPでそれらを扱うためのライブラリ（例: EasyRdfやRdfPhp) を紹介します。その後、SPARQLクエリを用いてナレッジグラフからデータを取得・操作する方法を具体例とともに解説します。

さらに、PHPで構築した既存のWebアプリケーションにナレッジグラフを組み込むためのアーキテクチャ設計や、LLMとの統合方法についても議論します。たとえば、LaravelやSymfonyのようなフレームワークを利用して、ナレッジグラフを効率的にクエリ・操作し、APIを通じて他のシステムやLLMと連携するパターンを具体例で説明します。

最後に、ナレッジグラフとLLMの組み合わせによる具体的なユースケース（FAQシステムやレコメンデーションエンジンなど）を示し、ナレッジグラフの可能性を最大限に活用するための道筋を提案します。このセッションは、ナレッジグラフという新たな分野に挑戦するための第一歩となる内容です。LLM時代の今だからこそ必要とされる技術に触れ、一緒に未来のWebアプリケーションの可能性を広げてみませんか？

「言語設定」という言葉は普段の開発でよく耳にするものの、これまで深く考えたことがありませんでした。日本語や英語などの言語設定がどのように決められ、どのように利用されているのかを理解することで、国際化対応やユーザー体験の向上にどのように活かせるのか。本セッションでは、自身が初めて真剣に言語設定の仕組みと設計に向き合った経験をもとに、言語設定の基本から設計に至るまでの学びを共有します。

まず、OS（Linux、Windows、macOS）やブラウザがどのように言語設定を決定し、利用しているのかを解説します。その後、これらの情報がPHPアプリケーションに渡されたときにどのように利用されるのか解説します。

さらに、実際のアプリケーション設計において、どのように言語の対応を処理すべきかを検討します。具体的には、Accept-Languageヘッダーを基に動的に言語を切り替えるミドルウェアの設計や、クッキーやセッションを利用したユーザー固有の言語設定の永続化方法についても触れます。また、多言語対応におけるドメインの利用（例: example.jpとexample.com）やURLパス（例: /enや/ja）を使った切り替えの実装パターンについても議論します。

このセッションは、言語設定について初めて真剣に考えるエンジニアに向けた内容です。言語設定の仕組みを理解し、設計に落とし込むまでのプロセスを一緒に探ることで、これからの国際化対応に必要な知識と視点を得られるはずです。一緒に、言語の設計に一歩踏み込み、真剣に考えて見ませんか？

技術的負債はどこの開発現場でも多かれ少なかれ存在します。技術的負債ゼロな現場はありません。
技術的負債を継続的・定期的に返済できていれば問題はありません。しかし長年放置され「負債度」が高まった技術的負債を返済するのは非常に厄介で骨が折れる作業です。

私たちは約10年放置されてきたPHPアプリケーション（PHP5）をPHP8にアップグレードしました。
負債解消チーム立ち上げから苦節３年、メンバーの離脱もありつつもレガシーなPHPアプリケーションの移植およびアップグレードを完遂することができました。
しかしそれを終えて今、こう思うのです。なぜここまで大変になるほど放置してしまったのか―。

本発表では技術的負債はなぜ生まれてしまうのか、その組織的・構造的な問題に触れつつ、それにどう立ち向かい、そしてその後どうすべきなのか、私自身が経験したPHPの移植事例・アップグレード事例を踏まえて発表します。

話すこと

• 技術的負債の生まれ方
• 「技術的負債の倒し方」のはじめ方
• 技術的負債の倒し方
• 技術的負債の倒したあと

想定聴講者

• 技術的負債の解消をしたいと思っている方
• 現在進行系で技術的負債と闘っている開発者

※本発表は PHPerKaigi 2024 で発表した「10年モノのレガシーPHPアプリケーションを移植しきるまでの泥臭くも長い軌跡」の完結編となります。

目の前の仕事に対して課題を見つけて、その課題に関する知識を身に着けることで社会人として十分な成長と報酬を貰えます。
たったそれだけですが、簡単ではないのです。
しかし、簡単ではない = 私には出来ないこと ではありません。

何かを犠牲にするのではなく、目の前のことを一個一個やっていくことで成長できる。
そのために必要な方法や考え方を説明します。

私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。

「AIクレーム検知オプション」の開発に当たり、メールディーラーの史上初となるβ版をコンテナで構築して、
お客様に実証実験ご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減やパフォーマンスの分散化を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
将来的なアーキテクチャの構想も含めて、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例を交えて説明いたします。

AWSやコンテナは新しい技術ではありませんが、2001年にローンチしたメールディーラーにとっては違います。
メールディーラーは全機能がひとつのサーバに実装されており、WebサーバとDBですらひとつのサーバに集約されています。
また、フレームワークを導入しておらず、DBアクセスからprint文によるHTML出力が、1つのPHPファイルに実装され、
プログラムの陳腐化が急速に進んでいます。

その一方で市場開拓の必要性から新機能を定期的にリリースすることが求められています。
さらにLLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、
LLMを「導入していることがメリット」だったのが「導入していないことがデメリット」に変わりつつあります。

AIブームを背景に、ChatGPTを活用したクレーム検知機能をAWS上で構築し、無事リリースに至りました。
本セッションを通じて、新しい試みを試す参考になれば幸いです。

登壇者は現職で5年ほど、レセプト業務を扱うシステムの開発をしております。
レセプト業務はドメインが複雑でミスが許されず、また３年に一度の大きな報酬改定がありロジックがガラッと変わります。
またその改訂作業自体が非常に短期間で行う必要があり、年々と複雑化するシステムと向き合う必要があります。

その中で、ドメインに向き合い取り組んでいった結果、レセプト業務をRezept as a Serviceとして構築して報酬改訂を乗り越えることができました。
ただ最初からXaaS化しようと狙っていたわけではなく、

1. 2021年4月の報酬改訂に対応する為
2. ビジネス変化と2024年4月の報酬改訂に対応する為

上記の2回に渡って徐々にアーキテクチャを進化させていきました。
1回目のアーキテクチャ変更を経て感じた課題があり、更にビジネス上の環境の変化に対応する為にどの様にリアーキテクチャしていったのか紹介いたします。
コアドメインをX as a Service化して分かったメリットと勘所について深掘りしてお話したいと思います。

本セッションでは、次の点にフォーカスしてお話しします。

1. XaaS化までの道のり
2. なぜXaaS化を目指したのか.
   狙いと実際にどうだったのか？
3. XaaS開発における重要なポイント.
   • コアドメインの見極めと責務の明確化
   • ユーザーとのコミュニケーション設計と開発プロセス
4. 継続的な開発を通じて得られた知見.
   • 安定した開発を行うための勘所
   • コアドメインと向き合う方法、そのメリットと課題

ドメインの蒸留とはなにか？、コアドメインを切り出すとはどういうことか？の一つの事例として紹介いたします。

ソフトウェアエンジニアには抽象化の能力が重要と言われます。
では実際に抽象化とはどのような能力なのでしょうか？

実際の事例を交えながら、抽象化を理解し、実務に活かせるようにします。

話すこと

• 抽象化と具体化とは
• 抽象化のメリット
• 現実で身につける抽象化の階層
• 抽象と具象の往復とは
• ソフトウェアと抽象化

話さないこと

• 具体的なソフトウェアの実装における抽象レイヤーの話

発表者は電子工作をする訳ではないのですが、書籍『雑に作る』が大好きです！
「下手っぴでもいいから、自分なりに動くものを作るのは楽しいよ」と、ものづくりの初期衝動を思い出させてくれる一冊でした。

部品選びから始めてゼロから作るのが難しくても、 「100均の商品を分解して、中身を見てみよう！」「改造できそうなオモチャのパーツを取り出して使ってみよう！」と
簡単に取り掛かれそうなアドバイスが、とてもたくさん書かれています！

部品も既製品も、安全にさえ気をつければどう使っても良し。分解して特定の機能だけを動かしたり、組み立て直すのも楽しい。
色々なモノが動いている仕組みを、そうやって自分の目と手で理解していくことは大きな学びをもたらすでしょう。
本書ではコレを「テクノロジーを自分のものにする」と表現しています。

同じことをソフトウェアでもやってみたら、絶対に楽しいし力がつきそうですよね！
本トークでは、身近なツールを「分解」して、へっぽこガラクタを作って遊んでみた体験を共有します。

こんな人におすすめ

• 普段使っているツールに「詳しくなる」きっかけを探している
• 設計力や実装力などの地力を向上したい・勉強法を探している
• 何かおもしろソフトウェアを作ってみたいが、発明のアイディアがない!!

こんな話をします

• 分解してみる、ガラクタを作ってみるの楽しさ・学習効果
• 「やってみた」話
  • 最初はどこから読めばいいの？どう進めるの？の紹介
  • PHP製のいくつかのツールを例に、どんな「分解」「再構築」を進めていったか
• この学習方法<遊び>で、身につく力
  • コードリーディングの力
  • エッセンスを理解する、抽象的に捉える力

「オブジェクト設計スタイルガイド」は、オブジェクト指向プログラミング（OOP）の設計と実装におけるベストプラクティスを網羅した優れた書籍です。スタイルガイドという名前の通り、明日からすぐに実践できる内容であるため、オブジェクト指向の基礎を理解している開発者にとって有益な参考書です。

本セッションでは、まずオブジェクト指向設計の基本概念を確認し、その後に書籍の具体的なコーディングスタイルを紹介していきます。以下はテーマとコーディングスタイルのサンプルです（番号は書籍によるものです）。

・2.1 2種類のオブジェクト
→ サービス層とドメイン層の役割とその違い（オブジェクトを呼び出す側と呼び出される側）
・2.3 サービスロケータを注入するのではなく、必要なもの自体を注入する
→ 依存性注入（DI）

・4.1　エンティティ：変更を追跡し、イベントを記録する識別可能なオブジェクト
・4.2　バリューオブジェクト：置き換え可能、匿名、イミュータブルな値
→ エンティティとバリューオブジェクトの設計（ミュータブル／イミュータブルの設計指針を含む）

・6.7　クエリメソッドからはコマンドメソッドは呼び出さず、ほかのクエリメソッドのみを呼び出す
・7.5　情報を収集するためにクエリを使用し、その次のステップに進むためにコマンドを使用する
→ CQS（コマンドクエリ分離原則）の基本と実践

本セッションを通じて、開発者がOOPの原則を理解し、それを適切に活用する知識を提供することで設計力の向上を目指します。

なお、本発表は「軽量DDDはもういらない！ スタイルガイド本で OOPの実装パターンを学ぼう」という発表を、より PHPer 向けに深掘りしたものです。
https://speakerdeck.com/panda_program/no-more-lightweight-ddd

近年、急速に"(コードの)質と(質の高さからくる開発)スピード"が注目されるようになってきました。

一方で「何故、"質とスピード"を求めるのか」に対するお話はあまり見かけません。

このトークでは「兵法」から見た「"ソースコードの質"や"開発スピード"は何のために必要なのか？」、「"ソースコードの質"や"開発スピード"は本当に必要なのか？」についてお話します。

日本でも著名な「孫子の兵法」から現代戦で重視される戦術論「リズムとテンポ」などの観点から「市場を支配するために必要な"質とスピード"」に迫ります。

このトークで得られる知見

1 あらためて考える「なぜ"質やスピード"が必要なのか」
2 "質やスピード"を求める場合の基準
3 組織人として組織を持続可能にするために考える事

このトークで話さない事

1 孫子の兵法をはじめとした戦略論・戦術論の詳解

エンジニアとして始めると必ず知る概念、それが「デザインパターン」です（諸説あり）。
私は新卒の頃、輪読会としてデザインパターンの本を読みました。そして、その知識を持て余したものです。
”デザインパターンを勉強しよう”で知ったデザインパターンは、その適用に失敗することの方が多いように感じます。
「道具として自然に出てくること」が大事であること、そして「道具としてもう使われないものもあること」を認識するのが大切です。
普段使用するフレームワークやライブラリに出てくるデザインパターンを参考に、今でもよく使われるデザインパターンを紹介していきます。

話すこと
・デザインパターンとの向き合い方（共通言語として”デザインパターン”を知っておく）
・フレームワークやライブラリに出てくるデザインパターン
・好んで使わないデザインパターン

※GoFのデザインパターンのことを指します。