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

2025年5月8日(木)に開催された「技術的負債への向き合い PHP編｜10年越えプロダクトを提供する3社が語ります！」イベントでの発表資料です。
イベントページ：https://codmon.connpass.com/event/347561/
登壇者：株式会社kubell 山下 祐

Transcript

1. 既存の開発資産を活かしながら、 《新規開発コスト抑制》と《開発体験向上》 を両立する拡張アーキテクチャ事例 山下 祐 2025年5月8日
2. 本セッションの概要 • Chatworkでは「アカウント設定画面の刷新」を実施しました。 • 本セッションでは、既存の開発資産を最大限に再利用して新規開発コ ストを抑えながら、開発者体験も同時に底上げした拡張アーキテク チャの事例を共有します。 2 Before After
3. 自己紹介 3 • 名前: 山下 祐 (Yamashita Tasuku) • 所属: 株式会社kubell（旧Chatwork株式会社） ◦ 2019年12月〜 PHP部(入社) ◦ 2022年10月〜 モバイル管理画面チーム ◦ 2023年06月〜 認証チーム ◦ 2025年04月〜 SREグループ（現職） • SNS: ◦ GitHub: tasuku43 ◦ X: task2021
4. 目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ
5. 目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ
6. • 独自Webフレームワーク: ECF ◦ Chatworkを10年以上支える基幹フレームワーク ◦ Smartyテンプレートエンジンを利用したHTML生成が主体 • 特徴 ◦ フロントコントローラではなくページコントローラを前提にしたフレー ムワーク 既存システムの構造と課題 6
7. 既存システムの構造と課題 7
8. 既存システムの構造と課題 8 リクエストを受ける
9. 既存システムの構造と課題 9 • 環境変数のロード • （古いライブラリの）オー トロードの仕組みのセット アップ • etc…
10. 既存システムの構造と課題 10 • 認証・認可処理 • DBコネクションの確率 • etc…
11. 既存システムの構造と課題 11 • 一般的なフレームワークだと Controllerに当たるクラス • ファットな場合もあるが、最 近のものはライブラリ群に処 理を委譲して薄くしてある
12. 既存システムの構造と課題 12
13. 既存システムの構造と課題 13 ミドルウェアの仕 組みがない ため、Actionに到 達するまで の各エンドポイントの共 通 処 理が追加しにくい エンドポイントがフレーム ワークのルールに 縛 られてし まう ECFに 依 存 しているクラスが 存 在 するライブラリがいくつ か存在する
14. • 簡単な背景 ◦ UIを刷新するため、FrontendではNext.jsを採用 ◦ フロントエンドから叩かれる新規のWeb APIが必要 • 実現したいこと ◦ 既存の実装を流用しつつ、フロントエンドの要件に沿ったWeb APIを提供したい ◦ Web APIの中身は既存ロジックの流用になるため、大きなリファ クタリングはスコープ外としたい ◦ チームの多くが既存システムに不慣れだったため、モダンフレー ムワークに近い開発体験を提供したい 既存システムの構造と課題 - バックエンド刷新の技術的要件 14
15. 目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ
16. フレームワークを完全に乗り換える選択はできない • セッション認証の仕組みがECFに依存している • 使いまわしたいライブラリのDB I/Oは、ECFの機能に密結合している • 多くのライブラリはECFのオートロードの仕組みに依存しており、 ECFなしでは動作しない • これらを解決するには大きな開発コストがかかる 技術的制約と解決アプローチ - 技術的制約 16
17. フレームワークの機能は利用しつつ、拡張する方針へ • 「軽量ルーティングライブラリ on 独自フレームワーク」というアプ ローチ • ECFの上に薄いレイヤーを構築し、共存させる • 既存機能は維持しつつ、モダンフレームワークの特徴を追加する 技術的制約と解決アプローチ - 解決の方向性 17
18. 技術的制約と解決アプローチ - 解決の方向性 18
19. 技術的制約と解決アプローチ - 解決の方向性 19 league/route • PSR-7/PSR-15 に準拠した軽量なルーティング／ディスパッチャライ ブラリ • PSR-15 ミドルウェアに対応しており、HTTPリクエスト処理の分離・ 拡張がしやすい
20. 技術的制約と解決アプローチ - 解決の方向性 20
21. 技術的制約と解決アプローチ - 解決の方向性 21
22. 技術的制約と解決アプローチ - 解決の方向性 22
23. 技術的制約と解決アプローチ - 解決の方向性 23 フロントコントローラーパターンを 採 用 し、ECFの 伝 統 的 なページコントロー ラーから脱却 フロントエンドが求めるURL設 計が可 能 に エンドポイントがフレームワークのルー ルに縛られてしまう
24. 技術的制約と解決アプローチ - 解決の方向性 24 • 認証・認可処理 • DBコネクションの確率 • etc… • 認証認可処理は、ActionIndexでオーバーライド して「何もしない」ように • 認証認可処理は、後続のミドルウェアで実施する
25. 技術的制約と解決アプローチ - 解決の方向性 25 • $_SERVER などの入力を PSR-7 ServerRequest に変換 • Router・DI コンテナの初期化 • ActionIndex.php の責務は「Routerのセットアッ プ」と「非PSR → PSR変換」のみに • コントローラー的な責務
26. 技術的制約と解決アプローチ - 解決の方向性 26 • ルートに一致した PSR-7 準拠の Controller を 呼び出し • PSR-15 ミドルウェアチェーンの実 行 • コントローラー的な責務
27. 技術的制約と解決アプローチ - 解決の方向性 27 $_SERVER などの入力を PSR-7 ServerRequest に変換 Router・DI コンテナの初期化
28. 技術的制約と解決アプローチ - 解決の方向性 28 • ルートに一致した PSR-7 準拠のController を 呼び出し • PSR-15 ミドルウェアチェーンの実行
29. 目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ
30. リファクタリングを後回しにするための戦略 30
31. ヘキサゴナルアーキテクチャの採用 31 ヘキサゴナルアーキテクチャ（ポート&アダプター）とは？ • アプリケーションのコアロジックを外部 依存（UI、DBなど）から隔離するアーキ テクチャ。 • 2種類のPort（入口／出口）と、それぞ れに対応するAdapterを用いて疎結合を 実現する。 • ※ 「primary / secondary」と表現され ることもありますが、本資料では、役割 と依存方向を明確にするため「inbound / outbound」を採用しています。 入口 出口
32. ヘキサゴナルアーキテクチャの採用 32
33. ヘキサゴナルアーキテクチャの採用 33 既存ライブラリや ECFへの依存や、 外部サービスへの依存を局所化 既存ライブラリやECFへの依存 や、サードパーティライブラリへ の依存を局所化
34. ヘキサゴナルアーキテクチャの採用 34 この中は既存ライブラリやECFに 依存せず、自由に実装できる
35. HTTPリクエストをエミュレートするテスト基盤の整備 35 既存実装のリファクタリングは、必要になるまで意図的に遅延する方針 • リファクタリングを行うべきタイミングが来た際に迅速に推進できるよう、既 存機能を守るための仕組みが求められる • そのためには、エンドポイント単位でのテスト基盤の整備が不可欠である • テスト効率よりも、将来的なリファクタリング時の安全性の確保を優先する • 一般的な「テストピラミッド」を目指すのではなく、システムの変更耐性を高 める戦略を採用 • Mockの使用は最小限に抑え、コントローラー以降の処理全体を通したテスト を重視 リファクタリング耐性の向上を重視
36. HTTPリクエストをエミュレートするテスト基盤の整備 36
37. HTTPリクエストをエミュレートするテスト基盤の整備 37
38. HTTPリクエストをエミュレートするテスト基盤の整備 38 • Router・DI コンテナの初期化 • テストコードでの入力を PSR-7 ServerRequest に変換 • Router・DI コンテナの初期化 • $_SERVER などの入力を PSR-7 ServerRequest に変換 • Routerに処理を委譲
39. HTTPリクエストをエミュレートするテスト基盤の整備 39
40. HTTPリクエストをエミュレートするテスト基盤の整備 40
41. 目次 CONTENTS 01 | 既存システムの構造と課題 02 | 技術的制約と解決アプローチ 03 | リファクタリングを後回しにするための戦略 04 | まとめ
42. まとめ 42 本日は、私たちが「開発コスト」という制約と、「改善（開 発体験向上）」という価値のバランスをどう取りながら設計 し、構築を進めたか、その実践例をご紹介しました。 同じような状況にある方にとって、何かしらのヒントになれ ば嬉しいです
43. 働くをもっと楽しく、創造的に 46