皆さんはDaemon（デーモン）をご存じですか？Daemonとは、バックグラウンドで実行され続けるプログラムのことです。ジョブキュー、バッチ処理、アプリケーションサーバー、クローラーといった役割を担うプログラムがその例です。

このトークでは、PHPを用いてDaemonプログラムを「飼いならし」、実用的に運用する方法についてお話します。具体的には、Daemonとはどのようなものなのか、その基本構造や必要な技術を解説します。PHPでのメインループの実装、シグナル処理、終了時のリソース解放といった基礎から、安定稼働を支えるスーパーバイザー（systemdやコンテナ）との連携、監視の仕組み、さらには並列処理やワーカーの協調についても取り上げる予定です。

もし、まだデーモンを「飼いならした」ことがない方は、Daemonという言葉だけで少し身構えるかもしれません。でも安心してください。初心者でもわかるシンプルなDaemonプログラムの構築方法から丁寧にお話しますので、召喚する楽しさ、支配するスリルと万能感を得られる要になると思います。

単純なウェブアプリや、Cronによるバッチで物足りないPHPerのあなたも（あるいはそうでないあなたも）、この機会にDaemonを造り、飼いならしてみませんか？

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

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

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

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

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

• 対象者

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

• 想定学習成果

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

php-fpm は PHPアプリケーション の実行環境として広く利用されていますが、その内部処理についてご存知でしょうか。

PHP プログラマから見ると、php-fpm はランタイムですが、php-fpm 自身は単に C 言語で実装されたアプリケーションにすぎません。これは我々が日頃から実装している PHP アプリケーションと領域や抽象度は異なりますが、一つのアプリケーションであるという点は同じです。

ただ、php-fpm ではより低いレイヤを扱っています。これは PHP アプリケーションレベルでは隠蔽されている処理が実装されているともいえます。普段、PHP コードを書くだけであればこうした底レイヤを意識する必要はありません。しかし、こうした下のレイヤがどのように動作しているのかを知ることはより深く PHP とそして自らが書いた PHP コードの挙動を理解することができます。そして、何より自分が書いたコードが内部でどのような仕組みで動いしているのかを知ることは楽しいものです！

本セッションでは、一歩レイヤを下りて、php-fpm がリクエスト受信から PHP アプリケーションを実行してレスポンスを返すまでの流れを内部実装やデバッガを元に追いかけてみましょう。

Web アプリケーションのセキュリティ設計において、特定のユーザーに対してどの操作を許可するかという認可の設計は欠かせない要素です。近年では、マイクロサービスやゼロトラストの考え方が普及し、サーバー間の認可を含むより複雑な機能が求められています。

このような複雑な認可を効果的に管理する方法の一つとして、認可ロジックをアプリケーションから分離し、外部化して再利用可能なポリシー言語で定義する手法があります。AWS IAM はこのようなポリシー言語の一例ですが、AWS に限定されない一般用途にも Open Policy Agent (OPA) が広く知られています。

本セッションでは、認可の課題に対する新たなキラーソリューションとして、Cedar を紹介します。Cedar は AWS によって開発されたポリシー言語で、Amazon Verified Permissions としてマネージドサービスが提供されているほか、AWS 以外の環境でも使用可能な OSS としても公開されています。

OPA と比較した Cedar の顕著な特徴は、大量のルールを定義した場合のパフォーマンスにあります。このパフォーマンスは、一度評価された条件を部分的にキャッシュし再利用する仕組みにより実現されており、そのキャッシュ戦略の正当性は数学的に厳密に証明されています。このように、Cedarは高度な理論が実際のプロダクトに価値を提供する興味深い事例といえるでしょう。

Cedar は 2024 年に論文が発表されたばかりであり、理論的な詳細に関する日本語情報はほとんど存在しません。そのため、本セッションでは参加者が認可エンジンの内部機構と特性を深く理解し、実際のアプリケーションのセキュリティ設計に役立てられることを目指して、Cedar に対して応用と理論の両面から Deep Dive します。

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

しかし、発表者は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 をあまりつかったことがない人向けには、どういった言語機能やツールを前提に言語を使っていけばよいかを古い情報に惑わされずひと巡りできるような、簡単な手引となることを目指します。

皆さんはDaemon（デーモン）をご存じですか？Daemonとは、バックグラウンドで実行され続けるプログラムのことです。ジョブキュー、バッチ処理、アプリケーションサーバー、クローラーといった役割を担うプログラムがその例です。

このトークでは、PHPを用いてDaemonプログラムを「飼いならし」、実用的に運用する方法についてお話します。具体的には、Daemonとはどのようなものなのか、その基本構造や必要な技術を解説します。PHPでのメインループの実装、シグナル処理、終了時のリソース解放といった基礎から、安定稼働を支えるスーパーバイザー（systemdやコンテナ）との連携、監視の仕組み、さらには並列処理やワーカーの協調についても取り上げる予定です。

もし、まだデーモンを「飼いならした」ことがない方は、Daemonという言葉だけで少し身構えるかもしれません。でも安心してください。初心者でもわかるシンプルなDaemonプログラムの構築方法から丁寧にお話しますので、召喚する楽しさ、支配するスリルと万能感を得られる要になると思います。

単純なウェブアプリや、Cronによるバッチで物足りないPHPerのあなたも（あるいはそうでないあなたも）、この機会にDaemonを造り、飼いならしてみませんか？

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年9月にECサイト構築用のOSS開発者から、企業向けバックオフィスのSaas開発会社に転職しました。
両者ともにPHPをメインの開発言語として置いていたのですが、「開発へのアプローチの仕方」や「PHPであること」の
意味合いはかなり異なったものでした。

例えば、以下の例

• 可読性を重視するのか、パフォーマンスを重視するのか
• 開発スピードを重視するのか、品質担保を重視するのか
• セキュリティをコードで担保するのか、ミドルウェアに任せるのか
  等々・・・

ソフトウェア開発における「あるある」でもあり、この問題と対峙している人は多いのではないかと思います。
OSS開発とWeb系Saasという2つの視点から、PHP開発における価値のあり方についてお話します。
筆者が実際に直面した課題もできる範囲でお話します。

対象者

• 開発におけるQCDSで優先順位どうするか日々悩んでる人
• 2つの宗教に挟まれた時に「どこに着地点を持っていくか」で悩んでいる人
• OSS開発のノウハウとWeb系Saas開発のノウハウを単純に比べて聞きたい方

得られるもの

• PHPのWeb開発における一つの価値基準
• 立場が変われば同じPHPでも取り組む姿勢が変わるという視点
• ソースコードとインフラの役割分担の考え方

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

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

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

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

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

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

このセッションではPHPのマイクロサービスアーキテクチャにおける分散トランザクション管理の新たな方法として、
アクターモデルとPhluxorを使ったSagaパターンの実装を紹介します。

PHPによる分散処理を諦めた方は多いのではないでしょうか？
並行処理の理解やサーバについての知識、結果整合への理解や、
障害対応方法や復旧方法など分散システムになればなるほど難しくなり、PHP以外の知識が要求されます。
アクターモデルはそれらを強力にサポートしてくれる仕組みがたくさんあります。
そんな仕組みを活用したデータ整合性の維持やレジリエンス向上に役立つ例として、
在庫管理やショッピングカートなどをテーマに実践的なアプローチを実装コードを交えて解説します。
アクターモデルによるメッセージングや、アクターによる振る舞いの変更、
state管理やSupervisionの活用、アクターの永続化などを用いて詳しく解説します。
複雑なワークフローをシンプルにし、スケーラビリティとフォールトトレランスを向上させる具体的な手法を習得しましょう！

インターフェイスという言葉は、さまざまな文脈で使用されます。具体的には以下のようなものがあります。

• プログラミング言語に備わっているInterface（オブジェクトインターフェイス）
• interface型
• Web API（のI）
• ユーザーインターフェイス（UI）
• コマンドラインインターフェイス（CLI）
• etc.

本セッションのスコープとなるインターフェイスは「その全て」です。

本セッションではソフトウェア開発において意識せざるを得ないインターフェイスというものについて考えてみます。
前述したようにひとことでインターフェイスといってもさまざまな種類があります。
それぞれのインターフェイスの特性を明らかにし、それらに共通する要素を探ります。この共通点を本セッションでは「インターフェイスという考え方」と呼ぶことにします。

本セッションではソフトウェア開発において強力な武器となるインターフェイスという考え方について、私なりに言語化して共有します。

例えばテストも、名前重要も、スキーマ駆動開発も、モジュラモノリスも、CQRSも、全てインターフェイスが意識されています。
インターフェイスという考え方は、空気のように当たり前に自然と活用されている一方、意識するだけで開発に新たな視点を得られるものだと感じています。

本セッションを通じて、参加者の皆さんがインターフェイスという考え方に改めて気づき、インターフェイスを意識することで、参加者が自身の開発プロセスに新たな視点を得ることができるようになることを目指します。