プロポーザル

登壇者はここ2年ほど、複数のプロダクトから利用されるレセプト業務を X as a Service（XaaS） として開発しています。
本セッションでは、次の点にフォーカスしてお話しします。

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

本セッションを通して、XaaSの開発における具体的な戦略と経験を共有し、コアドメインと真摯に向き合うことの重要性をお伝えします。

Interfaceの設計、していますか？

適切なInterface設計はコードの再利用性を高め、保守性を高める一方
不適切な設計をしてしまうと不要な複雑性を周辺に生み出し保守性に大きな悪影響を及ぼしてしまいます

このトークでは

• 「Interfaceを設計する」とは？
• 「良いインターフェース」とは？
• インターフェース設計とその先

といった切り口に対して

• サンプルコード
• 有名な設計原則
• 書籍の引用

などを用いながら「良いInterface設計」についての考察とその効果について解説します

クリーンアーキテクチャを学ぶと、まず目にするのがあの同心円構造です。
そのため、構造、レイヤーの配置に注目されがちですが、本質は依存の向きを整えることにあるとわたしは思っています。

クリーンアーキテクチャが伝えたいのは、構造や配置ではなく、オブジェクトの依存関係を制御することで得られる柔軟性や保守性を高めるための考え方です。

当トークでは、この「依存の向き」と「依存の制御」がなぜ重要なのかを深掘りし、以下の点に焦点を当てます。

■ 依存の向きの重要性
「依存性は、内側だけに向かっていかなくてはならない」というルールがなぜ重要で、システムの安定性にどう貢献するのか。

■ 依存性逆転の原則（DIP）
SOLID原則の一つである依存性逆転の原則を取り上げ、依存の制御がシステムの柔軟性と保守性にどうつながるのか。

一緒に依存の向きの大切さを理解し、設計へ活かす方法を学びましょう。

みなさんはシステムの設計を進めた後で、「こうしておけばよかった」と思う瞬間はありませんか？私はたくさんあります。

初めてテックリードとしてプロジェクトにアサインされ、技術選定やシステム設計を試行錯誤して進めました。
プロジェクト当初はうまくできたと感じていましたが、開発メンバーが増え、プロジェクト規模も大きくなり、振り返ると「こうすべきだった」と思う場面が増えてきました。

特に痛感したのは、技術選定やシステム設計といった基盤部分は、後からの変更が難しく、当時の判断がプロジェクト全体に大きな影響を与えることです。
本セッションでは、そんな経験を踏まえ「もしもう一度やり直せるならこうする」という視点で、以下の内容を中心にお話しします。

・テスト設計について
・アーキテクチャ設計について
・ドキュメント設計について

技術選定や設計に悩んでいる方にとって参考になる情報をお伝えします！

とある機能を実装していたときのことです。その機能には、動的に作成・削除されるファイルの存在有無によって分岐する処理がありました。
検証環境でのテストも問題なく、満を持して本番環境にデプロイしたところ、なんと大量のエラーアラートが！
エラー内容を見てみると、どうやら削除したはずのファイルがなぜか存在すると判定されてしまっているようなのです。
調査の結果、PHPの意外な仕様が原因であることがわかりました。

上記の経験をもとに、あなたの知らない（かもしれない）PHPのファイル操作にまつわる仕様とその対策をお話しします。

皆さんは使われていない不要なコードを消していますか？？
長い期間運用保守しているものだと使われなくなったコードはたくさんできてくると思います。
そのような不要なコードを削除するって結構大変です。

そこでこのトークでは、どんなコードが不要なのか、それをどのような手順で削除していくのかについて話をしていきます！

話すこと

• 不要コードとは？
• 不要コードはなぜ生まれ、なぜ消さないのか
• 不要コードを消す手順

仕事でもプライベートでも多くの方が目標設定をしていると思います。
私が目標設定をする際に、次のような悩みを抱えている時期がありました。

• 同じような失敗を繰り返している
• 何も行動出来ず時間だけが過ぎる
• 行動してるけど思った様な成果が出ず目標達成できない

改善方法を探す中で様々なふりかえり手法に出会い、取り入れたことで以前のような悩みが無くなりました。
その結果、設定した目標を達成できる事が多くなりました。

このトークでは私が目標達成に向けて利用しているふりかえり手法を具体的な事例を交えてご紹介します。
過去の私のように目標達成までの道のりで迷子になってしまっている方にお届けしたい内容です。

PHPアプリケーションの課題解決のために使われる有用なツールとしてXdebugなどのデバッガ、ベンダの提供するAPMツールなどがあります。

一方でこれらのツールでもカバーされない領域としてPHPのC拡張や実行エンジン内部のイベント情報などがあります。

eBPFを利用してこれらのイベントにフックすることにより、課題解決に役立つより詳細な情報をピンポイントで得ることができます。

本セッションでは、eBPFツール（ebpf_exporterなど）とPrometheusスタック（Prometheus/Grafana）を組み合わせ、PHPのアプリケーションコードを変更することなく、低コストで、継続的なモニタリングツールを作成する方法をお話します。

得られること

• eBPFの概要とPHPにおける適用可能領域、始め方を知る
• コードとデモを通して現実の問題に対する活用のイメージを得る

複雑な条件分岐を含むビジネスロジックは、if文の入れ子で実装されがちです。
しかし、この方法では条件の追加や変更が困難で、保守性が著しく低下します。

デシジョンテーブル（決定表）は、複数の条件と結果の組み合わせを表形式で整理できる強力なツールです。
このテーブルをコードとして実装することで、ビジネスロジックの可視性が高まり、条件変更への耐性も向上します。

本セッションでは、デシジョンテーブルの実装パターンと実践的なコード例を紹介します。
さらに、ユニットテストとの相性の良さ、仕様変更への強さなど、実装のメリットを実例とともに解説します。
明日のコーディングから活用できる具体的な実装テクニックをお持ち帰りいただけます。

Laravel でのドメインバリデーションをどこに書くか迷いますよね。

Controller に直接書くか、Model に public メソッドを生やすかのどちらかが一般的ですが、Model のライフサイクルイベントに対するフックで行うという方法もあります。

本LTでは、実際に行った実装を例にフックを使ったドメインバリデーションを紹介します。

OpenAPI仕様は、RESTful APIのドキュメント化において事実上の標準として広く採用されています。
しかし、そのエコシステムの豊富さゆえに、ツールやエディタの選択、コードファーストかドキュメントファーストか、自動生成アプローチの選定など、多くの判断を迫られます。

これらの課題の本質は「APIドキュメントとコードの同期維持」にあります。ドキュメントの陳腐化を防ぎ、開発効率とチーム全体での一貫性を確保することが重要です。

本セッションでは、新しいアプローチとしてライブラリ「eg-r2」を紹介します。
eg-r2は、コードとドキュメントの緊密な統合、効率的な更新メカニズム、開発ワークフローへのシームレスな統合を実現します。
参加者は、最新のベストプラクティスと実践的な指針を得られ、即座に活用可能なテクニックを学ぶことができます。

コードレビューは、チームの成長やコードの品質向上に欠かせないプロセスですが、組織やチーム体制によって位置づけや進め方が変わります。
本トークでは、コードレビューを効果的に運用するための工夫や、期待できる効果・避けるべきリスクについて考えてみましょう。

本トークで話す内容

• チームや組織ごとに異なるコードレビューの役割
• コードレビューに期待できること、気をつけるべき点
• レビュアーとレビュイーそれぞれの心構えと準備

データベースエラーに困ったことはありませんか？本トークでは、よくあるデータベースエラーを例にとり、そのエラーを再現するコードを使いながら、原因と防止策をわかりやすく解説します。エラーの発生を深く理解し、データベースと仲良くなって、今後のトラブルを未然に防ぎましょう。

本トークで話す内容

• よくあるデータベースエラーの紹介
• エラーを再現するコード例と解説
• エラーが示す原因と、その意味
• エラーを防ぐためのコーディングのポイント

Laravel・Symfony をはじめとする PHP のフルスタックフレームワークの多くは、DI コンテナを提供しています。
もちろん、そのようなフレームワークを使わなくても、PHP の DI ライブラリ は OSS として利用できるものがたくさんあるため、適宜導入が可能です。

もはや我々にとってなくてはならぬ存在となった DI コンテナですが、みなさん一度は自分で作ってみたいと思ったことがあるのではないでしょうか？

このセッションでは、最低限、どのような要件を満たせば DI コンテナと言えるのか、PHP で広く知られる規約であるPSRの定義を起点に、各種フレームワーク・ライブラリの実装を追いかけながらなんちゃって DI コンテナの要件定義をやってみようと思います。

DDD（ドメイン駆動設計）に興味があるけど、どの本から読めばいいか迷ったことはありませんか？

数多くのDDD関連書籍をすべて読むのは大変ですが、安心してください！とりあえず、手に入る本は全部読んで見ました！
本トークでは、どんな人がどのDDD関連本を読めばいいのか、独断と偏見で発表します！

PHP では、\Traversable を起点に数多くのイテレータクラスが存在します。

極論を言えば、どんな反復可能な処理でも配列を使えば実現できますが、イテレータクラスを適切に活用することで、保守性を高めたり、パフォーマンスを向上させることができます。

本セッションでは、 SPL を含めた PHP がビルトインで提供する様々なイテレータクラスについて、その活用法と合わせて紹介します。

何かしらのツールを入れたいが、予算がない・・・
なら、コストを削って予算を作ってみませんか？

本講演では、AWSを活用したシステム運用において、
使用頻度が高いサービスのコストを削減するためのテクニックを紹介します。

手軽にコストをカットする方法をはじめとして、
時間の許す限り、注意点も交えながら、以下のような内容を説明します。

主要サービスの特性理解と最適化: EC2、RDS、S3、Lambdaなど、よく使われるサービスでのコスト削減方法
・インスタンスの選択: リザーブド活用によるコスト最小化など
・ストレージコストの管理: S3でライフサイクルポリシーによる不要データの自動アーカイブ
・サーバーレスアーキテクチャの活用: LambdaでPHP

フロントエンドとバックエンドのリポジトリが分かれているという状況があり
いざ、サーバーを建てるときに2台必要なんだっけ？と疑問を抱いた事はありませんか？

既にサーバーが2台たっているが、MPAでは１台で済んでいたのでどうにかしたいといったケースもあると思います。
特に、テスト環境ではそこまでリソースが必要なく、コストも削りたいところですよね。
しかし、インフラに明るいものがいないため手がついていないという事もあるかと思います。

本講演では、フロントエンドとバックエンドのSPA（シングルページアプリケーション）を1台のサーバーで構築する方法を解説します。

「この関数の実装、頭に入りきらないな...」「結局このコード何がしたいんだ...?」
みなさんこんなことを思った経験はないでしょうか？
これ、もしかすると抽象レベルが整っていないことが原因かもしれません。

このセッションでは

• 認知負荷を抑えたロジックを書く方法
• ロジックの情報量をコントロールする方法
• 抽象レベルを整えるとなぜ関心の分離ができるのか

などをお話しします。

レイヤードアーキテクチャをはじめ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ、いわゆるクリーンアーキテクチャ、他には独立したコアレイヤーパターンやADOPなど様々なレイヤ化アーキテクチャが存在していることからわかるように、レイヤを元にアプリケーションを構造化することはとても良いアイデアです。

しかし一方でレイヤを増やしたもののあまりメリットを享受できない場面も存在します。

このセッションでは

• なんのためにレイヤ化をするのか
• どういった観点でレイヤが作られるのか
• レイヤ化することによってアプリケーションの複雑性がどのように管理しやすくなるのか

といったことを考えてみたいと思います