レギュラートーク(40分)

ドメインの蒸留から生まれたXaaS:アーキテクチャレベルで依存性逆転させた話

katzchum katzumi

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

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

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

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

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

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

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

3
レギュラートーク(40分)

抽象化をするということ - 具体と抽象の往復を身につける

soudai1025 曽根 壮大

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

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

話すこと

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

話さないこと

  • 具体的なソフトウェアの実装における抽象レイヤーの話
2
レギュラートーク(40分)

「雑に作る」に学んで始める、自己満がらくた作り -それはとても楽しい-

o0h_ きんじょうひでき

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

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

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

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

こんな人におすすめ

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

こんな話をします

  • 分解してみる、ガラクタを作ってみるの楽しさ・学習効果
  • 「やってみた」話
    • 最初はどこから読めばいいの?どう進めるの?の紹介
    • PHP製のいくつかのツールを例に、どんな「分解」「再構築」を進めていったか
  • この学習方法<遊び>で、身につく力
    • コードリーディングの力
    • エッセンスを理解する、抽象的に捉える力
2
採択
2025/03/22 16:15〜
Track B
レギュラートーク(40分)

Windows版PHPのビルド手順とPHP 8.4における変更点

matsuo_atsushi 松尾篤

WindowsでPHPをビルドする場合、PHP 8.0からPHP 8.3まではVisual Studio 2019を使ってビルドしていましたが、PHP 8.4ではVisual Studio 2022の使用が推奨されるようになっています。このトークでは、Windows環境におけるPHPのビルド手順や最新情報に興味がある方を対象に、ビルドに必要な準備や実際の手順についてデモを交えて解説します。Windows版のPHPをビルドするにあたって知っておきたい情報やPHP 8.4における変更点もあわせて紹介する予定です。

レギュラートーク(40分)

「オブジェクト設計スタイルガイド」に学ぶ、モダンなオブジェクト指向のベストプラクティス

Panda_Program プログラミングをするパンダ

「オブジェクト設計スタイルガイド」は、オブジェクト指向プログラミング(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

2
採択
2025/03/23 10:30〜
Track B
レギュラートーク(40分)

モジュラーモノリスでスケーラブルなシステムを設計・開発する

Panda_Program プログラミングをするパンダ

モジュラーモノリスは近年、マイクロサービスの代替として注目を集めています。このトークでは前半で設計の話を、後半で開発の話をします。

私が所属するBASE社では10年以上モノリシックなサービスでの開発が続いていましたが、デプロイ時間の増加や依存関係の複雑さにより機能提供のスピードに課題が出てきました。その課題を解決するためにモジュラーモノリスの新システムへの移行が始まって丸4年が経過しました。

本トークでは、モジュラーモノリスの基本的な設計概念から、その実現する方法論、また実践例について解説します。モジュールはコアドメインとサブドメインの考え方に基づいて区切られており、各モジュールの中ではアプリケーション層とドメイン層が分かれており、UnitOfWork での永続化管理やドメインイベントを用いた実装が可能になっています。

また、モジュラーモノリスを選択した際の利点とトレードオフについても議論します。具体的には、テストのしやすさ、デプロイの単純化、チーム間のコミュニケーションの向上など、エンジニアリング全体に与える影響を掘り下げます。メリットは多くありますが、それでも生じる課題についても触れていきます。

このトークを通じて、モジュラーモノリスというアーキテクチャの現実的な価値を理解し、チームやプロジェクトの規模に適したアプローチを選ぶための指針を得られれば幸いです。

採択
2025/03/23 13:35〜
Track A
レギュラートーク(40分)

PHPで作る電子計算機

shunsock しゅんそく

本セッションはPHPで計算機を自作します。環境構築からコード全体を解説します。

自分たちが使っているPHPのインタープリタとは何をしているのか、普段使っているPHPがいかに高度なことをしているのかを理解することが目的です。

本セッションは初中級者向けです。コードの記法などは解説致しません。計算機やプログラミングに興味があるが作り方が分からない方、PHPの内部実装の想像がつかない方を対象としています。

そのため、初心者でも理解しやすいように以下の工夫をします。

スタック型です
型をintegerとfloatに制限します
型キャストを使った明示的な型の管理を行います
逆ポーランド記法を使います
ユーザー定義関数を使いません

上記の特徴を持った言語を作ります。つまづきやすい、複数の型に対する演算の定義やASTを構築するタイプの言語における二項演算、ユーザー定義関数を意図的に避けています。

実装を解説し、ある程度計算機を理解したうえで、以下の話をします。

PHPがASTを構築し中間言語をVMで実行するタイプの言語であること、本セッションで実装した言語との違い。
通常の言語における二項演算の処理方法。式、文など。
ここまで作成した言語でHello,worldをする方法 (任意の要素を受け取れるprint文を作り、asciiとして解釈させる)

本セッションを通して視聴者は、計算機を構築するのに何が必要か理解し、自ら新しい計算機を作り出せるようになるでしょう!

3
レギュラートーク(40分)

「兵法」から見る"質とスピード"

effy_staffs wakaba

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

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

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

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

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

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

このトークで話さない事

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

2
採択
2025/03/23 13:35〜
Track C
レギュラートーク(40分)

PHP8.4におけるJITフレームワークIRと中間表現について理解を深める

コンパイルの世界では、中間表現というアイディアが存在します。
ソースコードを任意のデータ形式(中間表現)に変えてから、コンピュータが理解できるデータ形式(機械語)へ変換するというアイディアです。
一気に機械語へ変換するよりも、無駄な計算を省いたり複数フォーマットへの変換処理を効率化するなど効率化の恩恵をもたらします。

PHP8.0でJITによる高速化が導入されましたが、8.4では中間表現のアイディアを採用することで、さらなる高速化を図る変更が行われました。
https://wiki.php.net/rfc/jit-ir
中間表現を実現するにあたって、新しいフレームワークIRを使ってJITを実現しています。
https://github.com/dstogov/ir
このフレームワークでは、一体どのようにして中間表現を実現しているのでしょうか?

本セッションでは、まずJITと中間表現の基本概念を説明し、その後、PHP 8.4で導入されたフレームワークIRの詳細を解説します。
JITフレームワークIRを解説していくなかで、PHP8.4に導入されたJITでの中間表現について理解を深めていきます。

18
採択
2025/03/23 10:30〜
Track A
レギュラートーク(40分)

PHPで作るPHP~セルフホストできる言語処理系を作ろう~

nsfisis nsfisis

何らかの技術の理解を深めるのに最も適した方法は、その技術のサブセットを自分で実装することです。
PHP、ひいてはプログラミング言語というものを理解するために、PHP で PHP のサブセットを実装しましょう。
プログラミング言語処理系における「セルフホスト」とは、その処理系のソースコードをその処理系自身が処理できることを指します。つまり、今回作るPHP処理系の上でそのPHP処理系を動かすことを目指します。

話すこと

PHP で書く PHP 処理系(のサブセット)の作り方

  • 字句解析
  • 構文解析
  • 実行 (今回の実装では AST を直接実行します)

必要なソースコードはすべて公開され、このトークを聞かれた方が同じものを作成できるように構成します。

話さないこと

実際の PHP 処理系 (php-src) の実装方法に近づけることは目指していません。説明のしやすさや実装の容易さを考慮し、適宜アプローチは変更します。PHP 処理系へのコントリビュート等を目標としたものではありません。

採択
2025/03/22 13:35〜
Track A
レギュラートーク(40分)

私の愛したLaravel 〜レールを越えたその先へ〜

KentarouTakeda 武田 憲太郎

2年前、私は「Laravelへの異常な愛情」と題し、Laravelの基礎的な考え方と、そのレールがもたらす開発上の効果を紹介しました。Laravelをモデルに対するCRUDに特化したリソース志向フレームワークと捉え、コード量を削減しスタイルを統一する、これがLaravel Wayです。

しかし、現実のアプリケーションが、この枠組みの範囲に収まることはありません。

枠組みを超えた要件はプロジェクト固有の設計やルールで解決する必要があります。この試みは、成功することもありますが、それが「ほころび」となりコードベース全体の保守性を脅かすこともあります。これもまた、Laravelというフレームワークの特徴です。

逆に考えましょう。枠組みの外に出るのではなく、枠組み自体を拡張すれば良いのです。その手法を紹介します。

個別のテクニック

  • 認証の拡張
    認証プロバイダを理解し、Eloquentに依存しない認証や外部の認証基盤との連携を実現する
  • リクエスト処理の拡張
    Laravelの処理ライフサイクルを理解し、変則的な要件に対応する
  • Eloquentの拡張
    データベースドライバを理解し、データベース固有機能を自在に利用する
  • レスポンス処理の拡張
    Responsableを理解し、モダンフロントエンドへ対応する

拡張の考え方

  • あらゆるものを拡張
    Laravelの内部設計を知り、拡張の考え方を理解する
  • 再利用性と安定性
    パッケージ化による責務分離と、バージョンアップへの備え

題材として扱うOSS

  • Laravel Doctrine ORM
  • Laravel PostgreSQL Enhanced
  • Laravel Debugbar
  • Inertia.js
  • Testbench
レギュラートーク(40分)

使うデザインパターン、使わないデザインパターン

asumikam asumikam

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

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

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