3.1モジュール分割の原則

ソフトウェア方式設計の出発点は「システムをどうモジュールに分割するか」です。分割の良し悪しは感覚ではなく、凝集度と結合度という2つの尺度で客観的に評価できます。システムアーキテクトにとって重要なのは尺度の名前を暗記することではなく、「なぜこの設計は1箇所の変更が他へ波及するのか」を凝集度・結合度のどちらの問題かを見極め、具体的な改善策を選べることです。

3.1.1凝集度：モジュール内の結束

• 凝集度＝モジュール内部の要素（処理・データ）がどれだけ強く関連し、単一の目的に集中しているかを示す尺度。凝集度は高いほど良い設計とされる。
• 代表的な種類（弱い順の例）：機能的な関連が薄いのに1モジュールにまとめただけの偶発的凝集（最も弱い）→処理の実行順序だけで束ねた逐次的でない手続き的凝集→…→単一の明確な機能だけを果たす機能的凝集（最も強く最良）。強い凝集度ほど「このモジュールが何をするか」が一文で説明でき、変更の影響範囲が狭くなる。

3.1.2結合度：モジュール間の依存

• 結合度＝モジュール間がどれだけ強く依存し合っているかを示す尺度。結合度は低いほど良い設計とされる（凝集度と評価の向きが逆であることに注意）。
• 代表的な種類（強い＝悪い順の例）：モジュールの内部構造そのものを直接参照・書き換える内容結合（最も強く最悪）→大域変数を共有する共通結合→制御フラグを引数で渡し相手の内部分岐を左右する制御結合→…→必要なデータ項目だけを引数でやり取りするデータ結合（最も弱く最良）。弱い結合度ほど、相手モジュールの内部実装を変えても自モジュールへの影響が及びにくい。
• 凝集度と結合度は独立した尺度ではなく相関する：機能的凝集の高いモジュールに分割し直すと、自然と各モジュールの責務が明確になりデータ結合まで弱まることが多い。逆に無理に処理をまとめた偶発的凝集のモジュールは、他モジュールとの依存も内容結合や共通結合になりやすい。

あるシステムアーキテクトが、既存の受注管理システムの保守を任されたとします。現場から「配送料の計算ルールを1箇所変更しただけなのに、在庫引当処理と請求書発行処理まで動作がおかしくなった」という報告が上がってきました。ソースを調査すると、OrderProcessorという1つの巨大モジュールが「注文受付」「在庫引当」「配送料計算」「請求書発行」という本来無関係な4つの機能を1モジュールに詰め込んでいる（偶発的凝集に近い状態）ことが判明しました。さらに、これら4つの処理はモジュール内で共有するグローバル変数orderContextを介して状態をやり取りしており（共通結合）、配送料計算のロジックがorderContextの値を書き換えると、その値を後続の請求書発行処理が読むため、関連のない機能同士が意図せず影響し合う構造になっていました。これが「1箇所の変更が広範囲に波及する」根本原因です。改善策として、まずOrderProcessorを「注文受付」「在庫引当」「配送料計算」「請求書発行」という単一責務ごとの機能的凝集モジュールに分割し、次に共通結合していたorderContextを廃止して、各モジュール間は必要なデータ項目のみを引数として渡すデータ結合に置き換えるべきです。こうすれば配送料計算モジュールの内部ロジックを変更しても、渡すデータの形式（インタフェース）さえ変えなければ請求書発行モジュールに影響は及びません。「変更の影響範囲が予期せず広がる」という症状を見たら、まず凝集度（機能がバラバラに詰め込まれていないか）と結合度（大域状態や内部構造を介した依存がないか）の両面から原因を診断するのがシステムアーキテクトの判断です。

3.1.3この節のまとめ

• 凝集度は高いほど良く、最良は機能的凝集・最悪は偶発的凝集
• 結合度は低いほど良く、最良はデータ結合・最悪は内容結合（評価の向きが凝集度と逆）
• 「1箇所の変更が広範囲に波及する」症状は、機能が無関係に詰め込まれた低凝集と、大域状態や内部構造への依存による高結合の両面から原因を診断する