疎結合とは何か？ソフトウェア設計における結合バランスについて考える #phpcon_niigata

PHPカンファレンス新潟2026の登壇資料です
https://fortee.jp/phpconniigata-2026/proposal/8ae18ca3-3db5-4ffa-8c27-1fe5d65da631

2. 梶川 琢馬 𝕏 @kajitack 株式会社 TechBowl VPoT TechTrain の開発/メンター PHP カンファレンス新潟は 2 回目 佐渡島（200km）を自転車で 1 周したことがある スライドは X で公開します！ x.com/kajitack 2/56
5. 「もっと疎結合に」と言ったこと、 言われたことはありますか？ 5/56
6. 今日のゴール 「疎結合に」の代わりに、強度、距離、変動性で言える AI やチームと、設計の話を一歩深くできる 6/56
7. 結合度 関数やクラス、システムなどのまとまり（コンポーネント）の関係性 ある特定の変更について片方を変えると、 もう片方も変えざるを得ないとき、 その 2 つは結合している 7/56
8. 結合度が高いと？ 変更の難易度が上がり、システムの柔軟性と 信頼性が低下する コンポーネントに変更を加えた場合、依存している 他のコンポーネントも一緒に変更やテストをしなければならない 頻度が高くなる 8/56
9. 結合は悪？ 結合はシステムをまとめ上げる接着剤 相互作用、つまり結合がなければ、 システムの目的を達成できない 結合をゼロにすることは不可能 目的を実現するための良い結合を目指す 9/56
10. 結合の振り返り 片方の変更で、もう片方も変えざるを得ない関係が結合 結合がなければ、コンポーネントは協調できない 結合をなくすのではなく、目的に合う結合を考える 10/56
11. 結合バランス 11/56
12. ソフトウェア設計の結合バランス 著者は Vlad Khononov（ヴラド・ホノノフ） 前著『Learning Domain-Driven Design』 （邦訳『ドメイン駆動設計をはじめよう』） 1 冊をまるまる「結合」に割いた本 12/56
13. 結合の3 次元 強度 距離 変動性 13/56
14. 強度、距離、変動性で色んなことが分かる 言葉 式 安定性 NOT (変動性 AND 強度) 変更コスト 変動性 AND 距離 モジュール性 強度 XOR 距離 複雑性 NOT (強度 XOR 距離) メンテナンスの労力 強度 × 距離 × 変動性 均衡度 (強度 XOR 距離) OR NOT 変動性 意味 上流の変更が下流へ連鎖しにくいこと 変動性か強度が低ければ安定 連鎖的な変更を合わせる実際のコスト 変動性が高く距離が遠いと高い 変更に要る認知負荷を小さく抑える能力 強度と距離が対照的だと高い 変更や理解に要る認知負荷 強度と距離が等しいと高い 依存関係を維持するために予想される労力 3 つのどれかが低ければ小さい 設計がモジュール性と複雑性のどちらに向かうか モジュラーか、変動性が低ければ高い 14/56
15. 結合の強度 15/56
16. 強度 共有する「知識」が多いほど、強度は高い 知識には、メソッド呼び出しの引数や共通のルールなど、さまざまな形がある 相手が公開していない 内部の知識を使う 相手の振る舞いと 前提の知識を持つ 相手のモデルの 知識を共有する 統合用に用意した 知識だけを使う 例：具象クラスの継承、 trait の use 例：new、静的 メソッド呼び出し 例：引数と戻り値 の型 例：interface への依存 （侵入結合） （機能結合） （モデル結合） （コントラクト結合） 共有が多い 共有が少ない 16/56
17. 公開されていない内部の知識を使うと、強度はいちばん高い （侵入結合） class Customer { private string $status; } PHP 別のモジュール // $property = new ReflectionProperty(Customer::class, 'status'); $status = $property->getValue($customer); クラスの作者は、外から読まれていることを知らない プロパティ名を変える度に変更が必要 17/56
18. 同じルールの知識を別々に持つと、強度はやや高い （機能結合） 注文モジュール // function isFreeShipping(Order $order): bool { return $order->totalCost > 1000; } PHP 配送モジュール // function isFreeShipping(Order $order): bool { return $order->totalCost > 1000; } 呼び出し関係はないのに、ルールが変わると両方を同時に直す必要がある 18/56
19. モデルの知識をまるごと共有する場合、強度は低め （モデル結合） 顧客管理モジュール // class CustomerRepository { public function get(string $id): Customer { /* ... */ } } PHP 分析モジュール // $status = $repository->get($customerId)->status; 欲しいのはステータスだけなのに、Customer 全体の構造を知っている 19/56
20. 統合用に用意した知識だけを使うと、強度はいちばん低い （コントラクト結合） 顧客管理モジュール // class CustomerRepository { public function getStatus(string $id): Status { /* ... */ } } PHP 分析モジュール // $status = $repository->getStatus($customerId); Customer の中身が変わっても、分析モジュールは影響を受けない 20/56
21. データベースの共有 A ↓ B ↓ A の DB（非公開） A ↓ B ↓ A の DB（読み取り可） A の DB を、B が 勝手に SELECT する A ↓ （侵入結合） 同じテーブル （機能結合） B が A のテーブルの 列をそのまま読む A ↓ B 向けの最小限の 列だけを読む （モデル結合） 公開用のビュー B ↓ B ↓ 同じ入力チェックを A と B の両方に書く （コントラクト結合） 21/56
22. 非同期処理 非同期にすること自体は、強度を下げない 共有の仕方 専用の DTO を渡す コントラクト結合 Eloquent モデルをそのまま渡す モデル結合 別のリスナが終わっている前提で動く 機能結合 失敗したら呼び出し元で打ち消しが要る 機能結合 統合用ではないキューを直接読む 侵入結合 なぜその強度か 受け手は DTO の形だけを知る。送り手の内部モデルは漏れていない 受け手がテーブルの構造まで知ることになる 処理の順番を、受け手が前提にしている 全部成功か全部失敗か、という約束を両方で守る 統合のために用意されていない経路を使っている 22/56
23. 強度が低いほうがなんとなく良さそうだけど、 それが疎結合ってことなの？ 強度だけでは決まらないよ 次は距離について考えてみよ 23/56
24. 結合の距離 24/56
25. 距離 知識が移動する空間の広さ ファイルの中身からディレクトリ構成、外部との連携やシステム単位など 変 更 の コ ス ト 文 メソッド オブジェクト 名前空間 ライブラリ サービス システム 25/56
26. 同じ知識を、サービス境界の向こうで共有すると 改善前。同じ計算が、別の境界にある 注文サービス // final class Tax { public function of(int $price): int { return (int) ($price * 0.1); } } PHP 請求サービス // final class Tax { public function of(int $price): int { return (int) ($price * 0.1); } } 同じ知識を、サービスの外で共有している 26/56
27. 同じ知識は、同じ境界の近くで共有する 改善後。同じ境界の中で、1 つの計算を使う 同じサービスの中 // final class Tax { public function of(int $price): int { return (int) ($price * 0.1); } } PHP $orderTax = $tax->of($price); $billTax = $tax->of($price); 近くで共有すると、1 箇所を直せばよい 27/56
28. 距離が遠いと、調整もリリースも分かれる 注文アプリ（リリース ） // A $rate = $this->billingApi->taxRate(); PHP 請求アプリ（リリース ） // B public function taxRate(): float { return 0.1; } 税率を変えるとき、2 つのリリースのタイミングを合わせるように調整が必要になる 28/56
29. 距離が近いと、リリースの単位を同じにできる 同じアプリケーション // final class Tax { public function rate(): float { return 0.1; } } PHP $order->tax = $tax->of($price); 関係する変更を、同じリリースで反映できる 29/56
30. 人、チーム、部門 勤務地やタイムゾーンも、距離になる （ソシオテクニカルな距離） 同じチームと、別チームでは、調整のコストが違う 同じチームの中での結合は、その場で直せる 別チームのサービスを変えるときは、予定を合わせ、デプロイも別になる コードの場所が近くても、担当する人が違えば距離は遠くなる 30/56
31. 疎結合とは、強度が低く、距離が遠いこと モジュール性 = 強度 XOR 距離 変更に要る認知負荷を小さく抑える能力 複雑性 = NOT (強度 XOR 距離) 変更や理解に要る認知負荷 強 度 高 強 度 低 高凝集 密結合 一緒に変わるものが近くにある 一緒に変わるのに遠い モジュラー 複雑 低凝集 疎結合 関係が薄いのに近くにある 関係が薄く、離れている 複雑 モジュラー 距離 低 距離 高 31/56
32. 結合の変動性 32/56
33. 変動性 今後そのコンポーネントが変わる見込み 受付 → 予定の変更 → 割り当て モデル結合、距離は遠い、変動性は低い 同じ結合でも、変わる見込みで改善の優先度が変わる 33/56
34. 変動性の見積もり方は 2 つ ドメイン的に重要な変更なのか、他の変更に影響されていたりバグ修正が多かったりするのか ドメイン分析 ソースコード分析 見るもの サブドメインの種類（コア、支援、汎用） モジュールごとのコミット数 向く場面 これから変わりやすいかを予測する 既存のコードで、実際の変わり方を見る 注意 将来の予測は難しい 修正と機能追加を分けて数える 変更が少なくても、触れないから変わらないだけのことがある 34/56
35. 結合バランスの論理式 モジュール性 = (強度 XOR 距離) バランス = モジュール性 OR NOT 変動性 = (強度 XOR 距離) OR NOT 変動性 モジュール性が高いか変動性が低ければバランスが取れている状態 35/56
36. 結合バランスは、コードだけでは決められない 例：一般会員と法人会員の割引計算が、 現在は同じ式になっている 今後も一緒に変わるのか、 たまたま一致しているだけなのかは、 コードだけでは分からない コードから測れるのは、 依存関係や変更頻度まで 測れる事実と業務知識を合わせて判断する speakerdeck.com/kajitack/coupling-metor 36/56
37. 結合バランスの振り返り 強度：共有する知識の量 距離：知識をどこで共有するか 変動性：今後変わる見込み この 3 つの組み合わせで、結合の状態と改善の優先度を判断する 37/56
38. 実際のプロジェクトを整理してみる 38/56
39. これから紹介する事例 現在の構成と、これまでのリファクタリングを紹介する 適した構成は、各社のドメインやチーム構成によって変わる ここは強度が高いから、 距離を近づけようか？ 変動性も高いね 先に見直そう 39/56
40. ケーススタディ 01 同じコードベースの設計 同じコードベースの中 たとえば、課題とユーザーが、同じアプリの中にある場合 書き方 ユーザーが、課題の内部テーブルを直接読む 侵入結合 同じ判定を、課題とユーザーの両方に書く 機能結合 ユーザーが、課題の Eloquent モデルをそのまま使う モデル結合 ユーザーが、課題の用意した DTO だけを使う コントラクト結合 なぜその強度か 課題が公開していない内部を使っている ルールが変わったら、両方を同時に直す必要がある 課題のテーブルの構造まで知っている 課題が公開すると決めた形だけを知っている 40/56
41. ケーススタディ 01 同じコードベースの設計 外側から内側へ依存する Presentation Application 依存は内側へ Domain ドメインは外側の 実装を参照しない Infrastructure 41/56
42. ケーススタディ 01 同じコードベースの設計 同じコードベースのまま アクセスの仕方を分けた 同じアプリケーション 書き込み ユースケース API 集約とリポジトリ 読み取り DB クエリサービス 書き込みは集約の整合性を扱い、読み取りは必要な形で取得する 42/56
43. ケーススタディ 02 管理画面の移行 管理画面が別リポジトリで 同じデータベースを共有していた 改善前。距離は遠く、強度は高い 利用者向け API Laravel 管理画面 別リポジトリ ↓ ↓ 同じデータベース 43/56
44. ケーススタディ 02 管理画面の移行 同じリポジトリの Filament から ドメイン層を再利用する 改善後。コードを近づけ、確認する場所を同じドメイン層にまとめた 同じリポジトリ 利用者向け API Filament の管理画面 ドメイン層を、再利用する 44/56
45. ドメインイベント 購読側 発行側 ユーザー登録 起きた事実を発行 イベント ユーザー登録済み UserRegistered 何が起きたかを共有 メール送信 通知 プラン作成 発行側は購読側の処理を直接呼び出さない 45/56
46. ケーススタディ 03 イベントによる後続処理の分離 副作用を、その場で順番に全部呼び出す 改善前。本体が後続を直接知っている public function register(User $user): void { $this->users->save($user); $this->mailer->sendWelcome($user); $this->crm->sync($user); $this->notifier->notify($user); } PHP 46/56
47. ケーススタディ 03 イベントによる後続処理の分離 同期のまま強度を下げてから、非同期化する 改善後。先に事実の通知へ切り替える public function register(User $user): void { $this->users->save($user); $this->events->publish( new UserRegistered($user->id), ); } PHP 47/56
48. ケーススタディ 03 イベントによる後続処理の分離 キューを挟んでもモデル結合のままになりうる 改善前。送り側のモデルをキューに乗せる final class User { public string $name; public string $email; public string $passwordHash; } PHP $queue->push($user); 非同期にしただけでは強度は下がらない 48/56
49. ケーススタディ 03 イベントによる後続処理の分離 統合用の契約だけを流すと強度は下がる 改善後。キューに乗せるのは統合用の契約 final class UserRegistered { public function __construct( public string $userId, ) {} } PHP $queue->push(new UserRegistered($user->id)); コントラクト結合へ寄る 49/56
50. 実践例の振り返り 同じコードベースでも、共有する知識によって強度は変わる 管理画面では、コードを近づけて同じドメイン層を再利用した イベントでは、通信方法より何を共有するかで強度が変わる 50/56
51. 設計を学ぶ意味 51/56
52. 複雑性は超線形に増え、 認知の限界は成長しない 複雑性 （超線形） 機能 （線形） 認知の限界 （成長しない） システムの規模 出典: 『ソフトウェア設計の結合バランス』図12.6をもとに作成 52/56
53. 複雑性の爆増への対処 要素同士の関係が増えると、変更の影響を把握しにくくなる 技術的な層をまたいで一緒に変わるコードを、機能ごとにまとめる 強く関係するものの距離を縮め、別の機能とは分ける 強度や距離を調整することでモジュール性を保つ 53/56
54. AI エージェントによる開発では システムの理解がより大事 「変動性」を、リファクタリングの優先度やどこまで理解を手放せるかの判断に使える それらを統合した結合バランスは、コードからサービス、組織まで、 マイクロサービスやポートアダプターパターンなど特定のアーキテクチャではなく、 どの粒度の設計にも使える物差し 54/56
55. 結合は抽象度が上がっても同じ考え方を使える メソッドからクラス設計、レイヤードアーキテクチャやマイクロサービスなど、 色んなレイヤーの設計に結合は現れる エンジニアの仕事の抽象度が上がって、ソフトウェアファクトリーのように 「システムをつくるシステム」を設計するときにも、設計の物差しが活きてくる ソフトウェア システム サービス コンポーネント クラス ファクトリー メソッド 55/56
56. ソフトウェア設計における結合バランス 「疎結合」は強度が低く距離が遠い、 「高凝集」は強度が高く距離が近い （変更容易性が高い＝モジュール性） ソフトウェア設計では複雑性が爆発的に増える 形状を変え、強度と距離を調整してモジュール性を維持する 「変動性」は、リファクタリングの優先度や 理解を手放す判断に使える 結合バランスは、どの粒度の設計にも使える物差し ソフトウェアファクトリーのように 「システムをつくるシステム」を設計するときにも、 この物差しが活きる 56/56