LASSIC Media らしくメディア

システム開発の発注担当者やプロジェクトマネージャーは、開発会社からの設計説明やレビューの場で「疎結合」「凝集度」という言葉を耳にすることがあるでしょう。意味をつかめないまま相槌を打つと、設計の良し悪しを判断する材料を持てないまま、仕様の合意や検収を進めることになりかねません。見積書や設計書に並ぶ専門用語の奥で、実際に何が起きているのかを知らないまま進めるのは、発注する側にとって心もとないものです。

この記事では、疎結合と凝集度という2つの指標が何を測っているのか、なぜ保守コストに直結するのかを、発注者・PMの視点で整理します。あわせて、依存性注入やマイクロサービスへの分割といった具体的な手段には立ち入らず、まずは設計品質を見る物差しとしての考え方に絞って解説していきます。具体的な手段の使い分けを知りたい場合は、別のテーマとして扱う内容になるとご理解ください。

疎結合と凝集度とは－設計の質を測る2つの物差し

疎結合と凝集度とは、ソフトウェアの部品どうしのつながり方と、部品内部のまとまりの良さを表す2つの指標で、保守や変更のしやすさを見るときの物差しになります。

結合度は、ある部品が別の部品にどれだけ強く依存しているかを表す指標です。依存が弱い状態を疎結合と呼び、強く依存し合う状態を密結合と呼びます。

一方の凝集度は、1つの部品の内部にある処理が、どれだけ1つの目的にまとまっているかを表す指標です。まとまりの良い状態を高凝集、関連の薄い処理が雑多に同居する状態を低凝集と呼びます。

呼び方は開発の現場によって幅があり、部品のことを「モジュール」「クラス」「コンポーネント」「サービス」など、設計の粒度に応じて呼び分けることがあります。呼び名は違っても、結合度と凝集度という2つの物差しで質を見るという考え方そのものは、どの粒度の部品にも共通して当てはまるものです。

設計の指針では、この2つをまとめて「疎結合・高凝集」という合言葉で語られる場面がしばしばあります。部品どうしのつながりを弱くし、部品内部のまとまりを強くする、という2方向の工夫を同時に意識することが、良い設計を目指すときの共通の目印になっているのです。

たとえるなら、部署ごとの役割分担がはっきりしていて、他部署とは正式な依頼窓口を通じてやり取りする組織は、疎結合・高凝集な状態に近いといえます。逆に、担当が曖昧なまま複数の部署が同じ業務に手を出し合い、口頭の連絡だけで仕事が回っている組織は、密結合・低凝集の状態に近いでしょう。ソフトウェアの部品も、これと同じ物差しで整理されているかどうかが問われます。

この2つの指標は、構造化設計と呼ばれる考え方の中で整理され、モジュールをどう分割するかを判断する基準として使われてきました。個々の技術やフレームワークが移り変わっても、部品のつながり方とまとまり方を見るという着眼点そのものは、現在のアーキテクチャ議論でも変わらず参照され続けています。

システムは一度作って終わりではなく、公開後も機能追加や仕様変更を重ねながら長く使われていきます。運用年数が延びるほど、当初の担当者が入れ替わったり、開発を依頼する会社が変わったりする場面も増えるでしょう。疎結合・高凝集な設計は、そうした担当の移り変わりが避けられない前提のもとで、変更のたびに発生する手戻りを抑えるための備えだと捉えられます。

結合度－部品どうしの依存が強いほど変更が波及する

結合度とは、ある部品が別の部品の内部事情にどれだけ踏み込んで依存しているかを表す度合いです。依存が強い状態を密結合、依存が弱い状態を疎結合と呼びます。

密結合な設計では、片方の部品の内部を変えただけで、もう片方も連動して動かなくなることがあります。ある機能がほかの機能の内部変数やデータ構造を直接参照していると、そのデータ構造を変更した途端に、参照している側もすべて手直しが必要になるでしょう。

疎結合な設計では、部品どうしが窓口となるインターフェースを介してだけやり取りします。内部の実装を差し替えても、窓口の約束事さえ守られていれば、相手側への影響は生まれません。

この対比が示すとおり、結合度は部品の壊れやすさと作り直しやすさを左右する指標だといえるでしょう。設計レビューの場では、部品どうしがどの経路でつながっているかを確認するだけでも、結合度のおおよその見立てができます。

ここで押さえておきたいのは、結合度をゼロにはできないという点です。部品を分けて協調させる以上、部品どうしのつながり自体はどこかに残ります。目指すのは結合をなくすことではなく、必要最小限の窓口だけを介した、弱いつながりに保つことだといえるでしょう。

結合の強さには段階があるといえるでしょう。他の部品の内部変数を直接書き換えるような結びつき方は特に強い結合とされ、必要な情報だけを窓口越しにやり取りする結びつき方は弱い結合とされます。強い結合が積み重なった設計では、1つの部品を直すたびに、関係する部品を芋づる式に洗い出す作業が発生しやすくなるのです。

発注者の視点では、複数の開発会社や複数のチームが同じシステムに関わる場面で、結合度の高さがそのままやり取りの手間に直結します。ある部品を変更するたびに、別の担当チームへ確認を取らなければ進められない状態は、結合度が高いことの表れといえるでしょう。窓口となるインターフェースを挟んで役割を切り分けておけば、チームをまたいだ確認の回数そのものを減らせます。

密結合が生まれやすい典型は、複数の部品が同じデータベースのテーブルを、それぞれ好きな形で直接読み書きしてしまう作りです。ある部品の都合でテーブルの列を1つ増やしただけのつもりが、そのテーブルを直接参照しているほかの部品まで動かなくなる、という不具合につながります。窓口となる処理を1か所に集め、ほかの部品はその窓口だけを呼び出す形にしておけば、テーブルの中身を変えても影響を1か所に閉じ込めやすくなるでしょう。

設定値を複数の部品に直接書き写している状態も、見落とされやすい密結合の一例です。接続先の情報や計算に使う定数をあちこちに直接書き込んでいると、1か所を変えたつもりでも、書き写した先を1つずつ探して直す作業が発生します。設定は1か所にまとめて置き、各部品はそこから参照する形にしておくと、変更の手間を大きく減らせます。

凝集度－1つの部品が担う役割のまとまり具合

凝集度とは、1つの部品（モジュールやクラス、関数など）の内部にある処理のまとまり具合を表す度合いです。1つの目的に沿って処理がそろっている状態を高凝集、関連の薄い処理が雑多に同居する状態を低凝集と呼びます。

高凝集な部品は、名前を見ただけで役割が想像でき、中身を読んでも脈絡のはっきりした処理が並びます。会員登録だけを担う部品であれば、入力チェックと登録処理に絞って置かれ、請求や通知といった別の関心事は含みません。

低凝集な部品では、会員登録の処理の中に請求計算やメール送信のロジックまで詰め込まれる、といった状態が起こりがちです。1つの部品が複数の役目を抱え込むほど、どこを直せば良いのか判断しづらくなっていきます。

凝集の強さにも段階があります。実行のタイミングがたまたま同じというだけで処理をまとめた部品は、弱い凝集とされます。

1つの機能を果たすために必要な処理だけを過不足なくまとめた部品は、強い凝集とされるのです。弱い凝集の部品は、名前だけでは中身を想像しにくく、変更のたびに全体を読み直す手間が生じがちです。

低凝集な部品が積み重なったシステムを引き継ぐ場合、新しく加わる開発者やチームが全体像をつかむまでに時間がかかりやすくなります。担当交代のたびに、引き継ぎのコストがふくらむ一因にもなるでしょう。反対に高凝集な部品が並ぶシステムでは、部品名の一覧を眺めるだけで、システム全体がどんな役割の集まりでできているかを把握しやすくなります。

低凝集の典型としてよく挙げられるのが、何でも屋のような巨大な部品です。当初は小さな役割だった部品に、後から関連の薄い処理を継ぎ足していった結果として生まれます。

この状態になると、ちょっとした修正のために巨大な部品全体を読み込む必要が生じ、テストの準備にも手間がかかるでしょう。役割ごとに部品を分け直し、それぞれを高凝集に保つことが、こうした肥大化を防ぐ手当てになります。

結合度と凝集度は、それぞれ別の軸を測る指標ですが、実務ではセットで語られることがほとんどです。部品どうしのつながりを弱め、部品内部のまとまりを強める、という2方向の工夫が、保守しやすい設計へとつながっていきます。

高凝集な部品には、役割が想像できる名前が付けられることが多く、部品の名前一覧が、そのままシステムの仕様書のような役割を果たすこともあります。逆に、部品名から中身が想像できない設計は、低凝集のサインの1つとして受け止めておくとよいでしょう。

発注者・PMが結合度と凝集度を見るべき理由

疎結合・高凝集な設計は、後から機能を足したり担当者が交代したりするときのコストを抑えます。反対に、密結合・低凝集のまま積み上がった設計は、直すたびに関連箇所を洗い出す手間が増え、いわゆる技術的負債として重くのしかかっていくのです。

発注者やPMがこの2つの指標を意識する場面は、主に設計レビューとコードレビューでしょう。開発会社から提出される設計書やクラス図を見るときが、その具体的な場面です。「この部品はどの相手と、どんな窓口でやり取りしていますか」「この部品は1つの役割に絞られていますか」と尋ねるだけでも、設計の質をうかがう手がかりになります。

見積もりの段階で結合度・凝集度への配慮が薄いまま進めてしまうと、後工程の改修や担当交代のたびに、想定より工数がふくらむ恐れがあります。契約時点で、設計方針としてこの2つをどう担保するのか確認しておくと、後々の手戻りを避けやすくなるでしょう。

RFPや要件定義の段階では、機能や納期ばかりに目が向きがちで、設計の質を測る観点が漏れやすいものです。評価項目の1つとして「変更のしやすさをどう担保する設計か」を加えておくだけでも構いません。提案してくる開発会社が結合度・凝集度をどれだけ意識しているかの違いが、そこから見えてくるでしょう。

特定の開発会社でなければ手を入れられないほど部品同士が絡み合った状態は、別の会社への切り替えや、複数の会社での分業を難しくします。疎結合な設計を保っておくことは、特定のベンダーへの依存を弱め、体制を見直す際の選択肢を残すことにもつながるでしょう。逆に、密結合・低凝集のまま放置された部分は、担当できる技術者が限られ、その技術者が離れた途端に手を付けられなくなる、という事態も起こり得ます。

結合度・凝集度は、テスト工程の見積もりにも影響します。部品どうしが強く依存し合っていると、1つの部品だけを切り離して動かす確認がしにくく、関連する部品をすべて用意したうえでの結合テストに頼らざるを得ないのです。疎結合に保たれた部品であれば、部品単体の自動テストを積み重ねやすく、テストにかかる工数の見積もりも立てやすくなります。

設計レビューの成果物として、部品どうしの依存関係を示した図やドキュメントの提出を求めるのも有効な進め方です。開発会社に依存関係の説明を求めたとき、図や文書で明確に示してもらえるかどうかを見てみましょう。その対応ぶりは、その会社が結合度・凝集度をどれだけ意識して設計しているかを映す手がかりになります。

要件定義書や設計書に、部品の分割方針や責任範囲をどこまで明記するかも、契約時に確認しておきたい点です。分割の方針が文書に残っていれば、後から別の担当者や別の会社が引き継ぐときにも、当初どんな考え方で部品を分けたのかをたどれます。口頭の説明だけに頼らず、方針を文書として残してもらうよう依頼しておくとよいでしょう。

新しく加わるメンバーの立ち上がりの早さにも、結合度・凝集度は関わってきます。疎結合・高凝集な設計であれば、担当してもらう部品の範囲を区切って渡しやすく、新しいメンバーもその範囲だけを理解すれば作業に取りかかれます。密結合な設計では、1つの部品を任せるために周辺の広い範囲まで説明する必要があり、立ち上がりまでの期間が延びやすくなるでしょう。

結合度・凝集度は、発注者と開発会社の間で認識をそろえるための共通言語にもなります。専門的な実装の是非を、発注者が判断するのは難しいものです。

ただ「この部品はどこと強くつながっているか」「役割は1つに絞られているか」という観点であれば、技術に深く踏み込まなくても会話に加われるでしょう。共通の物差しを持つこと自体が、両者のやり取りをかみ合わせる助けになります。

ここまで見てきた考え方を実際のレビューでどう使うのか、次の章で具体的な目安として整理していきます。

疎結合・高凝集の見極め方－ファイル数と説明のしやすさ

結合度や凝集度には、決まった数値の物差しがあるわけではありません。ただ、発注者やPMの立場でも確かめやすい目安がいくつかあります。

1つの変更で触るファイル数を数える

ある機能を1つ直したいだけなのに、関連する複数のファイルを同時に直さないと動かない場合、そこは密結合になっている可能性が高いといえます。逆に、直したい箇所が1つのファイルやモジュールの中で完結しているなら、疎結合が保たれているサインです。

開発会社に「先日の改修では、何ファイルを直しましたか」と尋ねてみるのも良い方法になります。機能の大きさに対して不釣り合いに多い答えが返ってくるようなら、注意して見ておきたい部分といえるでしょう。

部品の役割を一文で説明できるか確かめる

1つの部品（クラスやモジュール）の役割を、開発会社の担当者に一文で説明してもらう、という確かめ方があります。「これは何をする部品ですか」と尋ねたとき、「〜と、〜と、〜をする部品です」のように複数の役目が並ぶ答えが返ってくることがあります。そうした部品は、低凝集に傾いている恐れがあるでしょう。

過度な分割はかえって複雑になる

見極める際に注意したいのが、細かく分ければ分けるほど良いわけではない点です。部品を必要以上に細分化すると、今度は部品どうしの呼び出し関係が増え、全体を追いかけにくくなる場合があります。

1つの処理を実行するために10も20も部品をまたいでたどらなければならない設計は、疎結合というより、単に見通しの悪さを部品数の多さに置き換えただけの状態です。疎結合・高凝集は部品数を増やすこと自体が目的ではなく、変更のしやすさとのバランスを取るための指標だと捉えるとよいでしょう。

レビューで確認しておきたい質問を用意する

設計レビューやコードレビューの場では、次のような質問を投げかけると、結合度・凝集度のおおよその状態をつかみやすくなります。専門的な用語を使わずに答えを引き出せる点も扱いやすいところでしょう。

• この部品を直すとき、ほかにどの部品を確認する必要がありますか。
• この部品の役割を、一文でどう説明しますか。
• この部品は、別のプロジェクトでもそのまま使い回せますか。

これらの質問への答え方があいまいだったり、説明が長くなったりする部品ほど、結合度・凝集度の面で見直しの余地が残っている可能性があります。契約前の提案段階から、こうしたやり取りができる開発会社かどうかを見ておくと、後々の判断材料になるはずです。

ここまでの目安を一覧にすると、次のように整理できます。

まとめ

ここまでの内容を、発注者・PMの視点から整理すると次のとおりです。

• 疎結合と凝集度は、部品のつながり方とまとまりの良さを表す、設計品質を見る2つの指標である。
• 結合度が低い（疎結合な）設計ほど、変更の影響が狭い範囲にとどまり、再利用やテストがしやすい。
• 凝集度が高い設計ほど、部品の役割が明確になり、保守や引き継ぎの負担が軽くなる。
• 発注者・PMは、変更時に触るファイル数や、部品の役割を一文で説明できるかを目安に、設計レビューで確認できる。
• 部品数を増やすこと自体が目的ではなく、疎結合・高凝集はあくまで変更のしやすさを測る物差しである。

よくある質問

疎結合・高凝集は、どんな設計にも当てはめるべき目標ですか。

設計の質を見るときの目安にはなりますが、どんな場面にも一様に当てはまるものではありません。プロジェクトの規模や変更の頻度によって、部品をどこまで細かく分けるかの落としどころは変わってきます。短期間で使い切る小規模なツールと、何年も運用し続ける基幹システムとでは、求められる分割の細かさも変わってくるでしょう。疎結合・高凝集を意識しながら、過度な分割によるかえっての複雑さも避ける、という判断が求められます。

依存性注入(DI)やマイクロサービスへの分割との違いは何ですか。

依存性注入やマイクロサービスへの分割は、疎結合・高凝集な設計を実現するための代表的な手段です。結合度・凝集度は、その手段を使った結果として設計がどれだけ良くなったかを見る、評価の物差しにあたります。手段を導入したつもりでも、結合度や凝集度が改善していなければ、狙った効果は得られていないことになるでしょう。それぞれの手段の詳しい進め方は、別のテーマとして扱う内容になります。

設計書やコードを見なくても、結合度や凝集度の見立てはできますか。

詳細なコードを読まなくても、開発会社からの説明を聞くだけである程度の見立てはできます。ある機能の変更を頼んだときに、影響範囲の説明でいくつのファイル名が挙がるか、部品の役割をどれだけ簡潔に説明してもらえるかは、有効な手がかりになるでしょう。説明のたびに専門用語ばかりが並び、要点がつかみにくい場合も、注意して見ておきたいサインになります。最終的な精度を求めるなら、設計書やコードレビューでの確認もあわせて行うとよいでしょう。

凝集度が低いコードは、すぐに書き直さないといけませんか。

低凝集だからといって、すぐにすべて書き直す必要があるとは限りません。変更や追加の頻度が高い部品から優先して整理し直す、という段階的な進め方が実務的です。触る予定のない部分まで一斉に手を入れようとすると、かえって不具合を生む要因にもなりかねません。新しく追加する機能から疎結合・高凝集を意識し、既存部分は影響の大きい箇所から手を入れていく進め方が、費用対効果の面でも現実的でしょう。

疎結合を意識しすぎると、処理が遅くなることはありますか。

部品どうしのやり取りを窓口越しに揃えることで、直接呼び出すよりわずかな処理コストが生じる場合はあります。ただし、通常の業務システムでは、この差が体感できるほどの遅さにつながることはまれです。処理速度が特に厳しく問われる一部の処理に限っては、疎結合の徹底よりも速度を優先する判断もあり得ますが、その場合も影響範囲を限定しておくことが大切です。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• Wikipedia「結合度」
• Wikipedia「凝集度」
• Microsoft Learn「マイクロサービス アーキテクチャ スタイル」（Azure Architecture Center）