【アルゴリズム】中身をギュッと1つにまとめる！「凝集度（コヒージョン）」｜情報処理問題1000本ノック
プログラムの部品（モジュール）は、あれもこれもできる万能ツールにするより、1つの専門職にするのが正解。モジュール内部の「まとまりの強さ」を測る最重要モノサシを攻略しましょう。
1. 【 問題 】：モジュール設計の評価指標（凝集度）
【 問題 】 ソフトウェアの構造化設計において、作成した一つのモジュール（関数やクラスなどの部品）の内部に含まれる機能やデータが、「どの程度、そのモジュール内で単一の目的のために密接に関連し、独立しているか」という内部の結びつきの強さ（まとまり度合い）を表す指標はどれでしょうか？
① 凝集度 (Cohesion / コヒージョン)
② 結合度 (Coupling / カップリング)
③ 複雑度 (Complexity / サイクロマティック複雑度)
④ 網羅度 (Coverage / カバレッジ)
2. 正解：
正解： ① 凝集度 (Cohesion)
3. 解説：「中身のまとまり」と「外との繋がり」を絶対に見分ける
システムを修正しやすく、バグの起きにくい綺麗な状態に保つための基本原則が「高凝集（凝集度を高くする）」です。問題文にある通り、結合度とは視点の向きが180度異なります。
・凝集度（モジュール「内部」の視点）：今回の正解です。そのモジュールの中にあるコードが、どれだけ純粋に1つの専門機能のために集まっているかを示します。最も理想的なのは、1つのことだけを完璧にこなす「機能的凝集（強度）」です。 ← ココが問題の正解！
・結合度（モジュール「同士」の視点）：ひっかけのライバルです。モジュールAとモジュールBが、どれだけお互いに依存し合っているか（相手の変更に影響を受けるか）という「外部との繋がり」を示します。こちらは逆に、値が低い（疎結合・依存していない）ほど良い設計とされます。
★ ② 結合度：上記の通り、モジュール間の依存度を表す指標です。良い設計にするには「結合度は低く、凝集度は高く」する必要があります。
★ ③ 複雑度：以前学びましたね。プログラム内の条件分岐（if文など）の数から、コードの論理的なルートがどれだけごちゃごちゃしているかを数値化したものです。
★ ④ 網羅度（カバレッジ）：テスト工程において、作成したテストケースによって、ソースコード全体の何％を実際に実行してテストできたかという「テストの達成割合」を表す指標です。
1. 理解のコツ: 「会社の組織（チーム）と部署の連携」に例えてみましょう。
・「経理部」の中に、経理のプロだけが集まっていて、全員が経理の仕事（単一の目的）だけを黙々とこなしている状態。これが内部のまとまりが最高に強い高い凝集度です。もしここに「ついでに営業もやって、ついでに総務の仕事もして」と色々な機能を混ぜると、ごちゃごちゃになって「凝集度が低い（悪い状態）」になります。
・一方で、その経理部が仕事をするために、お隣の営業部から『データをどれくらい細かく、どんな形式でもらっているか（依存しているか）』というのが結合度です。営業部のルールが変わるたびに経理部のやり方も変えなきゃいけない状態は「結合度が強い（悪い状態）」です。『部署の中身はプロ専門（高凝集）、部署同士の連絡はシンプルな書類1枚だけ（疎結合）』が最高の組織ですよね。プログラムも全く同じです。
2. 試験対策の視点: 「モジュールの機能がどの程度、そのモジュール内にあるか」「内部の関連性の強さ」「単一の目的」という記述があれば「凝集度（強度）」が一択です。基本情報の科目Bや応用情報の午前試験において、凝集度の種類（機能的、情報的、連絡的、手続き的、時間的、論理的、偶発的）の強弱順を並び替えさせたり、結合度との関係を正しく理解しているかを問う問題は、ソフトウェア設計理論の王道中の王道です。
4. まとめ
「1つのモジュールにあれこれと仕事を詰め込まず、1つの目的のための機能だけをギュッと凝縮して独立性を高めるための設計モノサシ」。これが凝集度です。「凝集度は高く、結合度は低く」。この2大指標のセオリーをマスターすれば、美しいシステム設計の基礎は完全に制覇したも同然です！