既存の開発資産を活かしながら、《新規開発コスト抑制》と《開発体験向上》を両立する拡張アーキテクチャ事例

by kubell

Slide 1

Slide 1 text

既存の開発資産を活かしながら、《新規開発コスト抑制》と《開発体験向上》を両立する拡張アーキテクチャ事例山下祐 2025年5月8日

Slide 2

Slide 2 text

本セッションの概要 ● Chatworkでは「アカウント設定画面の刷新」を実施しました。 ● 本セッションでは、既存の開発資産を最大限に再利用して新規開発コストを抑えながら、開発者体験も同時に底上げした拡張アーキテクチャの事例を共有します。 2 Before After

Slide 3

Slide 3 text

自己紹介 3 ● 名前: 山下祐 (Yamashita Tasuku) ● 所属: 株式会社kubell（旧Chatwork株式会社） ○ 2019年12月〜 PHP部(入社) ○ 2022年10月〜モバイル管理画面チーム ○ 2023年06月〜認証チーム ○ 2025年04月〜 SREグループ（現職） ● SNS: ○ GitHub: tasuku43 ○ X: task2021

Slide 4

Slide 4 text

目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ

Slide 5

Slide 5 text

目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ

Slide 6

Slide 6 text

● 独自Webフレームワーク: ECF ○ Chatworkを10年以上支える基幹フレームワーク ○ Smartyテンプレートエンジンを利用したHTML生成が主体 ● 特徴 ○ フロントコントローラではなくページコントローラを前提にしたフレームワーク既存システムの構造と課題 6

Slide 7

Slide 7 text

既存システムの構造と課題 7

Slide 8

Slide 8 text

既存システムの構造と課題 8 リクエストを受ける

Slide 9

Slide 9 text

既存システムの構造と課題 9 ● 環境変数のロード ● （古いライブラリの）オートロードの仕組みのセットアップ ● etc…

Slide 10

Slide 10 text

既存システムの構造と課題 10 ● 認証・認可処理 ● DBコネクションの確率 ● etc…

Slide 11

Slide 11 text

既存システムの構造と課題 11 ● 一般的なフレームワークだと Controllerに当たるクラス ● ファットな場合もあるが、最近のものはライブラリ群に処理を委譲して薄くしてある

Slide 12

Slide 12 text

既存システムの構造と課題 12

Slide 13

Slide 13 text

既存システムの構造と課題 13 ミドルウェアの仕組みがないため、Actionに到達するまでの各エンドポイントの共通処理が追加しにくいエンドポイントがフレームワークのルールに縛られてしまう ECFに依存しているクラスが存在するライブラリがいくつか存在する

Slide 14

Slide 14 text

● 簡単な背景 ○ UIを刷新するため、FrontendではNext.jsを採用 ○ フロントエンドから叩かれる新規のWeb APIが必要 ● 実現したいこと ○ 既存の実装を流用しつつ、フロントエンドの要件に沿ったWeb APIを提供したい ○ Web APIの中身は既存ロジックの流用になるため、大きなリファクタリングはスコープ外としたい ○ チームの多くが既存システムに不慣れだったため、モダンフレームワークに近い開発体験を提供したい既存システムの構造と課題 - バックエンド刷新の技術的要件 14

Slide 15

Slide 15 text

目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ

Slide 16

Slide 16 text

フレームワークを完全に乗り換える選択はできない ● セッション認証の仕組みがECFに依存している ● 使いまわしたいライブラリのDB I/Oは、ECFの機能に密結合している ● 多くのライブラリはECFのオートロードの仕組みに依存しており、 ECFなしでは動作しない ● これらを解決するには大きな開発コストがかかる技術的制約と解決アプローチ - 技術的制約 16

Slide 17

Slide 17 text

フレームワークの機能は利用しつつ、拡張する方針へ ● 「軽量ルーティングライブラリ on 独自フレームワーク」というアプローチ ● ECFの上に薄いレイヤーを構築し、共存させる ● 既存機能は維持しつつ、モダンフレームワークの特徴を追加する技術的制約と解決アプローチ - 解決の方向性 17

Slide 18

Slide 18 text

技術的制約と解決アプローチ - 解決の方向性 18

Slide 19

Slide 19 text

技術的制約と解決アプローチ - 解決の方向性 19 league/route ● PSR-7/PSR-15 に準拠した軽量なルーティング／ディスパッチャライブラリ ● PSR-15 ミドルウェアに対応しており、HTTPリクエスト処理の分離・拡張がしやすい

Slide 20

Slide 20 text

技術的制約と解決アプローチ - 解決の方向性 20

Slide 21

Slide 21 text

技術的制約と解決アプローチ - 解決の方向性 21

Slide 22

Slide 22 text

技術的制約と解決アプローチ - 解決の方向性 22

Slide 23

Slide 23 text

技術的制約と解決アプローチ - 解決の方向性 23 フロントコントローラーパターンを採用し、ECFの伝統的なページコントローラーから脱却フロントエンドが求めるURL設計が可能にエンドポイントがフレームワークのルールに縛られてしまう

Slide 24

Slide 24 text

技術的制約と解決アプローチ - 解決の方向性 24 ● 認証・認可処理 ● DBコネクションの確率 ● etc… ● 認証認可処理は、ActionIndexでオーバーライドして「何もしない」ように ● 認証認可処理は、後続のミドルウェアで実施する

Slide 25

Slide 25 text

技術的制約と解決アプローチ - 解決の方向性 25 ● $_SERVER などの入力を PSR-7 ServerRequest に変換 ● Router・DI コンテナの初期化 ● ActionIndex.php の責務は「Routerのセットアップ」と「非PSR → PSR変換」のみに ● コントローラー的な責務

Slide 26

Slide 26 text

技術的制約と解決アプローチ - 解決の方向性 26 ● ルートに一致した PSR-7 準拠の Controller を呼び出し ● PSR-15 ミドルウェアチェーンの実行 ● コントローラー的な責務

Slide 27

Slide 27 text

技術的制約と解決アプローチ - 解決の方向性 27 $_SERVER などの入力を PSR-7 ServerRequest に変換 Router・DI コンテナの初期化

Slide 28

Slide 28 text

技術的制約と解決アプローチ - 解決の方向性 28 ● ルートに一致した PSR-7 準拠のController を呼び出し ● PSR-15 ミドルウェアチェーンの実行

Slide 29

Slide 29 text

目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ

Slide 30

Slide 30 text

リファクタリングを後回しにするための戦略 30

Slide 31

Slide 31 text

ヘキサゴナルアーキテクチャの採用 31 ヘキサゴナルアーキテクチャ（ポート&アダプター）とは？ ● アプリケーションのコアロジックを外部依存（UI、DBなど）から隔離するアーキテクチャ。 ● 2種類のPort（入口／出口）と、それぞれに対応するAdapterを用いて疎結合を実現する。 ● ※ 「primary / secondary」と表現されることもありますが、本資料では、役割と依存方向を明確にするため「inbound / outbound」を採用しています。入口出口

Slide 32

Slide 32 text

ヘキサゴナルアーキテクチャの採用 32

Slide 33

Slide 33 text

ヘキサゴナルアーキテクチャの採用 33 既存ライブラリや ECFへの依存や、外部サービスへの依存を局所化既存ライブラリやECFへの依存や、サードパーティライブラリへの依存を局所化

Slide 34

Slide 34 text

ヘキサゴナルアーキテクチャの採用 34 この中は既存ライブラリやECFに依存せず、自由に実装できる

Slide 35

Slide 35 text

HTTPリクエストをエミュレートするテスト基盤の整備 35 既存実装のリファクタリングは、必要になるまで意図的に遅延する方針 ● リファクタリングを行うべきタイミングが来た際に迅速に推進できるよう、既存機能を守るための仕組みが求められる ● そのためには、エンドポイント単位でのテスト基盤の整備が不可欠である ● テスト効率よりも、将来的なリファクタリング時の安全性の確保を優先する ● 一般的な「テストピラミッド」を目指すのではなく、システムの変更耐性を高める戦略を採用 ● Mockの使用は最小限に抑え、コントローラー以降の処理全体を通したテストを重視リファクタリング耐性の向上を重視

Slide 36

Slide 36 text

HTTPリクエストをエミュレートするテスト基盤の整備 36

Slide 37

Slide 37 text

HTTPリクエストをエミュレートするテスト基盤の整備 37

Slide 38

Slide 38 text

HTTPリクエストをエミュレートするテスト基盤の整備 38 ● Router・DI コンテナの初期化 ● テストコードでの入力を PSR-7 ServerRequest に変換 ● Router・DI コンテナの初期化 ● $_SERVER などの入力を PSR-7 ServerRequest に変換 ● Routerに処理を委譲

Slide 39

Slide 39 text

HTTPリクエストをエミュレートするテスト基盤の整備 39

Slide 40

Slide 40 text

HTTPリクエストをエミュレートするテスト基盤の整備 40

Slide 41

Slide 41 text

目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ

Slide 42

Slide 42 text

まとめ 42 本日は、私たちが「開発コスト」という制約と、「改善（開発体験向上）」という価値のバランスをどう取りながら設計し、構築を進めたか、その実践例をご紹介しました。同じような状況にある方にとって、何かしらのヒントになれば嬉しいです

Slide 43

Slide 43 text

働くをもっと楽しく、創造的に 46