UX / UI のデザインに強いWebシステムの開発と、BtoB Webマーケを支援するWeb制作を提供するN’s Creates (エヌズクリエイツ) 株式会社の西山です。

2025年7月18日(金)・19日(土)に神戸で開催された「PHPカンファレンス関西2025」に私も参加してきました！ 興味深いセッションを聴講しましたので、その内容をいくつかご紹介したいと思います。

基調講演：「ソフトウェア・デザインに向かおう ～ 世界を（ちょっとだけ）変えるソフトウェアを目指して」

今回の参加で特に印象深かったのが、杉本啓氏による基調講演です。会場後方からの聴講で一部聞き取りにくい箇所があったため、公開されているスライドの内容を中心にまとめてご紹介します。

ソフトウェア開発の二つの視点と「アーキテクチャ」の核心

講演の冒頭では、ソフトウェア開発における二つの重要な視点について説明がありました。

1. 外部設計: ユーザーが「どう使うか」という視点（UI/UX、機能など）
2. 内部設計: 開発者が「どう作るか」という視点（コード、構造、アルゴリズムなど）

同じソフトウェアという「道具」であっても、立場によって見え方は全く異なります。しかし、本質的にはどちらも一つのものを表していると強調されていました。この講演を通じて、ユーザーやビジネスが抱えるドメイン（問題領域）への深い知見を改めて深めることの重要性を感じました。

また、「アーキテクチャ」に関する定義も印象的でした。置かれた状況（問題）に対する「見立てと構え」があり、問題領域と解決領域を貫く、問題の見立てと解決の仕組みそのものが「アーキテクチャ」 であると説明されました。これは、単なるシステムの構造を指すのではなく、道具（ソフトウェア）とそれが使われる状況（ドメイン）の関係性そのもののデザインである、という深い示唆でした。

DXとドメイン知識の重要性 💡

講演の中盤から後半にかけては、DX（デジタルトランスフォーメーション） とアーキテクチャの変化について言及されていました。

• DXの定義: DXは、ITがもたらす新しいアーキテクチャが、従来の古いアーキテクチャを置き換えていく過程であると定義されました。
• ドメインの変化: 新しいアーキテクチャが導入されることで、それに合わせてドメイン（ビジネス領域や社会）自体も変化していくという点が強調されました。

エンジニアとして、ソフトウェアを使う視点から道具を捉える力を身につけ、ドメインに深く浸ることの必要性が強く述べられていました。今回の聴講を通して、改めてドメインへの深い理解が必要であると感じています。

階層化自動テストで開発に機動力を

次に聴講したのは、品質の高いテストコードを書くためのテクニックが紹介されたセッション「階層化自動テストで開発に機動力を」です。

この中で特にハッとさせられたのは、「品質」という言葉の定義でした。今まで品質とは「バグがないこと」だと漠然と考えていましたが、講演では「対象に本来備わっている特性が、要求事項を満たす程度」と明確に定義されました。この定義を基に、高品質なソフトウェアを達成するためには、テストを「レイヤー」ごとに整理し、それぞれのレイヤーで要求を明確にし、それを満たすことが重要だと述べられていました。

階層化自動テストとは？

階層化自動テストとは、テスト対象の関心事や完結できる単位（コンテキスト）に応じてテストを階層的に分割・整理する手法です。

各階層が独立して機能し、役割や責務が明確になることで、開発の機動力（スピードと品質の両立） が向上すると説明されました。

従来の課題とテストの再整理

従来のE2Eテストは、テスト範囲が巨大で維持コストが高く、少しの変更でも全体に影響が出やすいという問題点がありました。その主な理由は、テストの責務が過剰であり、開放閉鎖原則（ソフトウェアの要素は修正には閉じ、拡張には開かれているべきである）に反しているためだそうです。テストが一体化しすぎているために、修正の影響が連鎖しやすいのです。

この課題を解決するため、テスト対象を「見るべきもの」と「完結できる単位」に分割して整理する方法が提案されました。

• 「見るべきもの」の分割:
  • フロー: 複数の状態を横断する一連の操作（例: ログインから購入までのプロセス）。
  • 状態: 単一のURLリクエストに対する出力など、完結した結果（例: あるページの表示内容）。
• 「完結できる単位」の分割:
  • 複数リクエストの集約が必要なもの: セッションや永続化を伴う、複数URLへの一貫した操作（例: カートに商品を追加し、レジに進む）。
  • 単一リクエストで完結するもの: 単一URLレスポンス、変数への割り当て、入力検証、クラスや関数の入出力など。

このようにテスト対象を整理することで、それぞれのテストが持つ責務を明確にし、変更に強く、保守しやすいテストコードを構築できるという示唆を得ました。

現在弊社ではE2Eテストを導入・取り組んでいる最中なので、このセッションはとても参考になりました。

PHPでやってみよう！テストだけじゃない、デシジョンテーブル（決定表）実装の勘所

こちらは、デシジョンテーブル（決定表）をコードに落とし込む際のテクニックが紹介されたセッションです。

複雑な条件分岐が必要な箇所で、「Enumに条件を定義し、Generatorを使ってコードを生成する」という斬新な方法が紹介されていました。

「こんな方法があるのか！」と目から鱗が落ちる思いでしたね。これは聞いた直後からすぐにでも試してみたいと感じました。ぜひ、スライドでコードを確認してみてください！

副作用と戦う PHP リファクタリング ─ ドメインイベントでビジネスロジックを解きほぐす

このセッションでは、例えば会員登録の際に、裏側でメール送信、運営への通知、契約プランの作成など、仕様が増えることで発生するさまざまな副作用により、コードの見通しが悪くなったり、変更範囲が予測しづらくなったり、テストも書きにくくなったりする問題が取り上げられました。

これを解決するために、「ドメインイベント」を導入するという方法が紹介されました。

イベントの洗い出しの際は、ビジネス側の「〜したら」「〜の時」といった表現をヒントに、イベント図に出来事を洗い出すのが良いそうです。

特に勉強になったのは、非同期処理実行時に会員登録処理がロールバックする場合に、データがないのにイベントが発行されてしまう問題を回避する手法です。

具体的には、イベントをデータベースに保存しておき、バッチ処理で発行（publish）するというものでした。

Laravelには「イベント」「リスナー」機能があるので簡単に実装できますが、ドメインイベントでの設計・実装はこれまで経験がありませんでした。これを機にぜひ実践してみたいと思います。

Laravelで作るWebアプリを普通に真面目にちゃんとAWSにデプロイする方法 〜Franken PHPも試してみるよ

このセッションのスライドは公開されていないようです。

ここでは、ECSベースのAWS構成と、Franken PHPを使ったデプロイ方法が紹介されていました。現在インフラを勉強中なので、このセッションはとても参考になりましたね。

一緒に聴講していた方と、登壇後に質問やご挨拶もさせていただきました。ありがとうございました。

おわりに

初めてのカンファレンス参加でしたが、大変勉強になりました。何よりも、開発へのモチベーションに繋がるので、ぜひ次回も参加したいです。

来年は東京のカンファレンス参加も一つの目標にしたいと考えています。

UX / UI のデザインに強いWebシステムの開発と、BtoB Webマーケを支援するWeb制作を提供する
N's Creates 株式会社は、神戸三宮オフィスまで週１出社（それ以外はリモートワーク）できる「デザイナー」「エンジニア」を募集しています。

興味のある方は、カジュアル面談しますので気軽にお問い合わせください！