10
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

技術書『ソフトウェア設計の結合バランス』は良い

10
Last updated at Posted at 2025-11-03

書籍情報

Vlad Khononov著 ”Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems”(2023)が、島田 浩二さんの翻訳によって『ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則』(2025)として出版されました。

この本は、その重要性にも関わらず「結合」について深く理解されていないのが実情という背景の下、まず構造化設計やオブジェクト指向設計に用いられてきた「結合」に関するモデルや評価手法を包括的に解説。さらに、複雑性を管理し、モジュール性を高める設計ツールとして「結合」を使用する新たなアプローチを提案します。

著者は『ドメイン駆動設計をはじめよう』(オライリージャパン)と同じVlad Khononov氏となります。
ちなみにこの方、今度のFindyアーキテクチャカンファレンス2025でもキーノートスピーチがあります。

参考資料

原著者さんによるSpeaker Deckや講演記事があるので、こちらでも外観を掴めるかと思います。

個人的なおすすめポイント

  • ソフトウェアコンポーネントの観点で「結合」「複雑性」の解像度が上がります
  • 特に、良いとされている「疎結合」とは一体どの程度が疎なのか?という問いへの解答があります
  • 本書では、曖昧になってしまった結合を再定義し、3つの次元(強度、距離、変動性)を導入して、そのバランスを考える設計手法を提唱しています

翻訳者さんによるご紹介も併せてどうぞ。

また、原稿翻訳レビューに参加したので、その内容については以下をどうぞ。

第1章 結合とシステム設計

本書の主題である結合について、その意味や意義を考える章です。

image.png

結合は疎であればあるほど良いと言われたりしますが、無結合ではそもそもシステムとして成り立たないものとみなします。

結合は必ず必要なもので、むしろ結合自体がシステム設計の本質であると捉えようとするのが本書です。

結合とは何かについて、ここまで言語化して深掘りするこの本は珍しいと思います。

第2章 結合と複雑性:クネビン

意思決定のフレームワークであるクネビンについて解説しています。

クネビンは、対象がどんな状態なのかを一次元的な尺度で把握するのに役立ちます。

具体的には、以下の順序で状態の複雑度が上がっていきます。

  1. 明確系: 何をすれば良いか分かってる状態
  2. 煩雑系: 他の詳しい人に聞けば解決する状態
  3. 複雑系: 実験結果で推論できる状態
  4. 混沌系: 実験結果でも推論できない状態
  5. 無秩序系: どの状態か分かってない状態

クネビンで状況把握できれば、その状態に応じたアクションを取り、より下位のレベルの状態に変えていくことが指針となり得ます。

複雑とは一体どういう状態なのか、をこのクネビンフレームワークに基づいて整理する事で、システムやコンポーネントの結合の複雑さという概念に対する解像度を上げていきます。

このフレームワークは、ソフトウェアの結合に限らず、様々な状況で活用できると感じました。

第3章 結合と複雑性:相互作用

3章は結合と複雑性を、コンポーネント間の相互作用の視点から議論します。

image.png

例えば、システムの複雑性はシステム規模とは無関係であることや、複雑性には本質的なものと偶発的なものがあるなど。

更に、自由度という概念を導入して、効果的な制約が自由度を落とし、システムの複雑性を下げるという概念を説明しています。

ただ、論じている自由度の定義が曖昧で、あまり実践的ではないとも感じました。

一方で、「結合とは、コンポーネントを統合する際の制約、許可する相互作用と許可しない相互作用を定める設計上の決定だ。」という説明は良い言語化だとも感じました。

第4章 結合とモジュール性

ここでは、モジュール性の定義と抽象化について議論しています。

image.png

コンポーネントとモジュールの違いについても触れながらモジュールを定義します。

端的に言うと、情報を隠蔽するものです。

また、抽象化とは物事を曖昧にすることではなく、抽象化したものが絶対的に正確になるような新しい意味レベルを作り出すことにあると説明しています。

モジュラーモノリスやモジュール設計という言葉の背後にある意味を考えさせてくれる良い章です。

第5章 構造化設計におけるモジュール結合

懐かしのモジュール結合レベル(内容結合、共通結合、外部結合、制御結合、スタンプ結合、データ結合)の説明の章となります。

image.png

自分もIPAの試験以来でした。業務で読んだコードがどの結合レベルだったのか振り返りながら読むと楽しかったです。

この分類はオブジェクト指向プログラミング以前の考えなので、やや古いとのことですが、本書で導入する統合強度の概念に組み込まれるため、復習されることをお勧めします。

第6章 コナーセンス

コナーセンスは、オブジェクト指向プログラミングにおける結合レベルを分類するものとして、Meilir Page-Jonesという方が1996年に発表したものです。

image.png

モジュール結合レベルとは違い、より知識の共有に焦点を当てた分類と理解しています。

詳しくは、翻訳者の島田さんによる記事をご参考ください。

第7章 統合強度

本書では結合を評価するための3つの次元を導入するのですが、その1つ目となる統合強度について解説しています。

image.png

統合強度は、モジュール結合レベルとコナーセンスではカバーできない依存関係を表すための新しい評価軸として導入されます。これらを包含しつつ、分類は4つに集約されているので、覚えやすいです。

  • 侵入結合:ネーミングでいかにも駄目な感じが伝わってくる。
  • 機能結合:動的コナーセンスの拡張って感じです。
  • モデル結合:データモデルが共有されている状況。スタンプ結合に近い。
  • コントラクト結合:DTOパターンやデータ結合に近い。

既存のアーキテクチャを維持しつつ、疎結合にしようとしてコントラクト結合を導入する場合は注意です。

単にDTOを追加するだけでは不十分で、”何の知識もカプセル化しない統合モデルは、システムをシンプルにしないばかりか、不要な「可動部分」を導入することでシステムをより複雑にしてしまう”と指摘しています。

“A Philosophy of Software Design”で広まったdeep moduleをここでも心がけることが重要であると主張しています。

第8章 距離

2つ目の次元は距離です。

結合するものが、メソッドで結合しているのか、ライブラリとして結合しているのかなどによって距離が変わり、距離に応じて変更コストが高くなると考えていきます。

image.png

また、距離を取ることで、互いに結合する個々のモジュールの変更ライフサイクルがより独立的に、柔軟になっていきます。

逆に距離を近づけたほうが良いケースは、知識の共有が強いモジュール同士です。

これに反する場合、例えばマイクロサービス化によって、システムの大域的な複雑性が上がるだけであると指摘しています。

第9章 変動性

3つ目の次元は変動性です。

あるモジュール同士が結合していたとしても、その結合を眺めるだけでは結合の良し悪しは付きません。

それらのモジュールがどんな頻度で変更されるかも重要な要素であると主張しています。

例えば、依存先が頻繁に更新していた場合、それに釣られて変更を強いられることがどの程度あるのか?というのが重要になります。これがしょっちゅうなら、例えサービスが別れていても強い結合とみなされます。

image.png

この章では、このようにして各モジュールの更新頻度(変動性)が結合を評価する重要な要素であることを説明し、変動性を分類する方法も紹介しています。

第10章 結合の均衡化

結合の3つの次元(強度、距離、変動性)を組み合わせて、結合のバランスを論じる本書の核となる章です。

image.png

3つの次元それぞれが高低の二値しか取らないと仮定するシンプルな理論から出発していきます。

統合強度と距離の組み合わせで、高凝集と疎結合が再定義されます。

また、変動性を組み込むことでメンテナンス性や安定性を定義します。

最終的に全ての次元の組み合わせを考えると、全部で8通りあります。これによって、均衡度の高低を評価していきます。

更に、正確な科学ではないという前置きを置いて、高低の二値からより定量的な十値のスケールで評価する方程式も導入します。

この方程式を用いて、いろんなサンプルケースでの結合の均衡度を評価する方法を学びます。

定量的に評価するツールを提供することで、コードのdiffや異なる設計間の均衡度を比較することが可能となり、設計の意思決定に役立ちます

第11章 結合の再均衡化

この章では初期設計からの変更というシナリオのケーススタディを通して、結合状態を3つの次元でリバランスさせる事例が説明されます。

結合のバランス(均衡度)を評価しても、システムは変化していくので、その変化に気を配らなくてはいけません。

そのバランスが崩れたら、他の次元を調整して、バランスを回復させる必要があることを説きます。

再均衡化という考えは、理想的な設計がありつつも、合理的な根拠をもって現実的な意思決定のためのオプションを提供してくれているのかなと思いました。

第12章 ソフトウェア設計のフラクタル幾何学的性質

ソフトウェアシステムは都市や生物のようにネットワーク型システムと捉えることで、理解が進むと言っています。

image.png

ソフトウェアシステムはフラクタルのようなもので、どの抽象化レイヤーにおいても結合のバランスを保つことが必要になってくることを説明しています。

むしろ、均衡結合モデルがどの抽象化レイヤーでも成立するという強みをもつ点が重要なんだと理解しました。

ただ、あまりその話はここまでの章で手厚く説明されてなかったので唐突感があったように感じました。

第13章 均衡結合の実践

この章では、リファクタリングやリアーキテクチャのシナリオでいくつかのケーススタディをします。

この中で、均衡結合モデルを使った設計の意思決定を実践していきます。

実際に用いるソリューションは、戦術DDDに偏った内容になっていました。

なので、その点を学ぶと言うよりは、なぜそういう設計変更の意思決定をしたのか、という肉付けを均衡結合モデルで説明する方法を学ぶ建付けであることに注意が必要です。

個人的まとめ

冒頭でポイントとして紹介したとおり、結合に対する解像度をグンッと引き上げてくれる書籍です。

「なんとなく疎結合だし良さそう」という設計判断からのレベルアップや、意図的な密結合を導入するなど、より意図を込めた設計を支援してくれるツールです。

チーム開発では、個人がこの理論を主張しても議論は成立しなさそうです。チーム内で読みあって、設計判断ツールとして組み込んでいくか、自分の設計に迷ったとき、言語化のツールとして活用していけると良いかもです。

個人的な実践としては、生成AIに均衡結合モデルの方程式を評価するコマンドやスキルを与えておくことで、設計時に評価してもらうようにしました。

10
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?