基本情報のモジュール結合度・凝集度｜強い弱いの覚え方

基本情報技術者試験でモジュール結合度と凝集度が出てくると、名前が似ていて一気に覚えにくく感じますよね。データ結合、スタンプ結合、制御結合、機能的強度、情報的強度など、用語だけを並べると暗記科目に見えます。

ただ、この分野は丸暗記だけで押し切るより、設計として何が良い状態なのかを先に押さえる方が安定します。結論から言うと、モジュール同士の結び付きは弱く、モジュール内のまとまりは強いほど良い設計です。

この記事では、基本情報のモジュール結合度と凝集度を、試験で選択肢を見分けるための言葉に落とし込んで整理します。ソフトウェア設計の細かい理論が苦手でも、過去問で判断できる状態を目指しましょう。

基本情報のモジュール結合度を攻略する

モジュールとは何か

モジュールとは、ソフトウェアを構成する部品のような単位です。大きなプログラムを一つのかたまりとして作ると、どこを直せばよいのか分かりにくくなります。そこで、入力をチェックする部分、計算する部分、データを保存する部分、画面に表示する部分のように、役割ごとに分けて考えます。この分けた一つ一つがモジュールだと考えると理解しやすいですね。

基本情報技術者試験では、実際のソースコードを書く力よりも、モジュールを分けると保守しやすくなる理由を問われることがあります。料金計算のルールが変わったとき、料金計算モジュールだけを直せば済むなら影響範囲は小さくなります。逆に、表示、保存、計算が一つの巨大なモジュールに混ざっていると、少し直しただけで別の場所に不具合が出る可能性が高くなります。

ここで重要になるのが、モジュール同士の関係です。モジュールは分ければ終わりではありません。分けたモジュールが互いに強く依存していると、結局は一つの巨大な処理と同じように扱いづらくなります。モジュールAを直すたびにモジュールB、C、Dも確認しなければならない状態では、分割したメリットが薄くなります。

試験では、モジュール分割の目的として、独立性、保守性、再利用性、テストしやすさがよく絡みます。設計図を読む問題では、基本情報のUML図の見分け方と同じく、部品同士の関係を落ち着いて見ることが大事です。モジュールは単なる箱ではなく、変更に強くするために役割を切り出したものだと押さえておきましょう。

モジュールは役割ごとに分けた処理の単位です。分けたあとに、他のモジュールへどれくらい依存しているかを見るのが結合度、モジュール内の処理がどれくらい一つの目的にまとまっているかを見るのが凝集度です。

結合度は低いほど良い

モジュール結合度とは、モジュール同士の結び付きの強さを表す考え方です。結合度が高いということは、片方のモジュールを変えたときに、もう片方へ影響が出やすい状態です。あるモジュールが別のモジュールの内部データを直接書き換えている場合、書き換えられた側の実装を少し変えるだけで、呼び出している側も壊れる可能性があります。

逆に、結合度が低い状態では、モジュール間のやり取りが必要最小限です。処理に必要な値だけを引数として渡し、結果だけを受け取るような形なら、内部の作りを変更しても相手側への影響を小さくできます。基本情報では、この「変更の影響範囲を小さくする」という発想がかなり重要です。

結合度は、強いほど良いと勘違いしやすい用語です。日本語だけ見ると「強く結び付いている方が頑丈そう」と感じるかもしれません。しかしソフトウェア設計では、強く結び付いているほど保守が難しくなります。試験では、結合度は低いほど良い、凝集度は高いほど良い、と反対向きで覚えるのが最初の壁になります。

もう一つ大事なのは、結合度の問題は「モジュール同士が何を共有しているか」を見ることです。単純な値だけを渡すのか、構造体ごと渡すのか、制御用フラグを渡すのか、グローバルなデータを共有するのか、相手の中身を直接触るのか。この違いで結合度の種類が決まります。

学習中に迷ったら、結合という言葉の印象ではなく、変更時の影響を基準にしてください。片方の修正で相手まで直す必要があるなら結び付きは強く、相手の中身を知らなくても使えるなら結び付きは弱い、と判断できます。

結合度の6種類を覚える

基本情報でよく整理されるモジュール結合度は、弱い方からデータ結合、スタンプ結合、制御結合、外部結合、共通結合、内容結合です。すべてを一字一句で覚えるより、受け渡すものが「単純な値」から「相手の内部」へ近づくほど悪くなる、と段階で見るのがおすすめです。

最も弱いデータ結合は、処理に必要な単一のデータ項目だけをパラメータとして渡す関係です。数量と単価だけを渡して合計金額を計算するような形ですね。必要な情報だけでやり取りしているため、相手の内部構造に依存しにくく、変更に強い設計になります。

スタンプ結合は、レコードや構造体のようなまとまったデータを渡す関係です。必要な項目だけでなく、使わない項目も含む構造体を渡すことがあるため、データ結合より結合度は少し高くなります。制御結合は、処理の流れを変えるフラグのような制御情報を渡す関係です。呼び出し先の動作を外から指示するため、さらに依存が強くなります。

外部結合と共通結合は、どちらも大域的なデータを複数モジュールで使う点に注意します。外部結合は単一の外部データ、共通結合は共通域のデータ構造を共有するイメージです。内容結合は最も強く、あるモジュールが別のモジュールの内部を直接参照したり変更したりする状態です。これは変更の影響が大きく、試験では避けるべき悪い結合として扱われます。

弱い順	結合度	判断の目安
弱い	データ結合	必要な単一データだけを渡す
やや弱い	スタンプ結合	レコードや構造体を渡す
中間	制御結合	動作を変えるフラグを渡す
やや強い	外部結合	外部宣言されたデータを共有する
強い	共通結合	共通域のデータ構造を共有する
最強	内容結合	他モジュールの内部を直接使う

表を暗記するときは、最初と最後を先に固定すると楽です。最も弱いのはデータ結合、最も強いのは内容結合です。中間は、構造体、制御フラグ、外部データ、共通域というように、相手への入り込み方が深くなる順で並べると崩れにくくなります。

過去問で見る判断ポイント

過去問でモジュール結合度が出たときは、最初から用語を思い出そうとするより、問題文の表現を分類する方が安定します。まず見るのは、モジュール間で何を受け渡しているかです。「単一のデータ項目」「レコード」「制御情報」「共通域」「内部を参照」のような言葉があれば、それぞれ対応する結合度に結び付けます。

「パラメータだけで受け渡す」「必要なデータ項目だけを渡す」という表現ならデータ結合の可能性が高いです。「データ構造」「レコード」「構造体」という言葉があればスタンプ結合を疑います。「処理を制御する」「フラグを渡す」「呼び出し先の動作を変える」は制御結合です。このように、問題文の名詞と動詞を拾うだけでかなり絞れます。

注意したいのは、選択肢に「結合度が最も弱いもの」「結合度が最も強いもの」「保守性が高いもの」のような聞かれ方があることです。最も弱いのはデータ結合、最も強いのは内容結合です。保守性が高い設計を選ぶ問題では、原則として結合度が低い選択肢を優先します。

また、結合度はテストとも関係します。結合度が高いと、単体テストで切り離しにくくなり、修正後の確認範囲も広がります。テストの種類や同値分割などを復習したい場合は、基本情報のテスト技法の解説も合わせて読むと、設計とテストのつながりが見えやすくなります。

• 単一データだけならデータ結合
• レコードや構造体ならスタンプ結合
• フラグで動作を変えるなら制御結合
• 内部を直接参照するなら内容結合

過去問演習では、正解を確認したあとに「問題文のどの言葉が根拠だったか」まで線を引くと定着します。用語名だけを覚えるより、言い換え表現に慣れる方が本番で使いやすいです。

過去問演習では、正解を確認したあとに「問題文のどの言葉が根拠だったか」まで線を引くと定着します。用語名だけを覚えるより、言い換え表現に慣れる方が本番で使いやすいです。

悪い設計を選ばないコツ

結合度の問題で迷ったときは、「この設計は変更に強いか」と自問すると判断しやすくなります。複数のモジュールが同じグローバル変数を書き換えている設計では、どの処理が値を変えたのか追いにくくなります。修正やテストのたびに他のモジュールへの影響を疑う必要があり、保守性が下がります。

特に避けたいのは、相手モジュールの内部を直接利用する内容結合です。相手の中身に依存しているため、相手側の実装を変えるだけで呼び出し側も壊れます。基本情報の問題では、内容結合は結合度が最も高い、つまり望ましくない設計として覚えておくとよいです。

制御結合も少し注意が必要です。フラグを渡して呼び出し先の処理を変える形は便利に見えますが、呼び出す側が呼び出し先の内部動作を知っている前提になります。フラグが増えるほど条件分岐が複雑になり、何のためのモジュールなのか分かりにくくなります。試験では、制御情報という言葉が出たらデータ結合より強いと判断しましょう。

一方、結合度を下げるとは、何も連携しないという意味ではありません。モジュールは必要な情報を受け渡して協力します。ただし、相手の内部や共通データに入り込まず、必要なデータだけを明確なインタフェースで渡すのが理想です。これは、DFDで処理とデータの流れを分けて読む考え方とも近いので、基本情報のDFDの読み方ともつなげて理解できます。

悪い設計を選ばないためには、共有、直接参照、制御フラグという言葉に敏感になることが大切です。これらは便利に見えても依存を増やしやすく、試験では保守性を下げる方向として扱われやすいです。

基本情報のモジュール凝集度を攻略する

凝集度は高いほど良い

凝集度は、モジュール内の処理がどれくらい一つの目的にまとまっているかを表す考え方です。基本情報ではモジュール強度という名前で扱われることもあります。結合度がモジュール同士の関係を見るのに対して、凝集度は一つのモジュールの中身を見る、と切り分けると分かりやすいです。

凝集度が高いモジュールは、役割がはっきりしています。消費税を計算するモジュールが税額計算だけを担当しているなら、何をする部品なのかすぐ分かります。変更が必要になったときも、そのモジュールを確認すればよく、テスト対象も明確になります。これは保守性の高い設計です。

一方、凝集度が低いモジュールは、関係の薄い処理が寄せ集められています。初期化、印刷、ログ出力、料金計算、画面更新が同じモジュールに入っているような状態です。こうなると、モジュール名から役割が読み取りにくく、修正するときにどの処理へ影響するのか分かりにくくなります。

ここでも、結合度と逆向きで覚えるのがポイントです。結合度は低いほど良い、凝集度は高いほど良い。つまり、モジュール同士はゆるくつながり、モジュール内は一つの目的に強くまとまっている状態が理想です。英語で言えば、low coupling and high cohesion という考え方です。

凝集度は「中身のまとまり具合」です。役割が一つにまとまるほど高く、関係のない処理をまとめるほど低くなります。試験では高い凝集度を良い設計として選びます。

凝集度は「強度」という名前で出ることもあるため、用語の揺れに注意しましょう。モジュール強度、モジュール凝集度、コヒージョンは近い文脈で使われます。試験では名前よりも、一つの目的にまとまっているかどうかを見るのが実用的です。

凝集度の7種類を覚える

モジュール凝集度は、高い方から機能的強度、情報的強度、連絡的強度、手順的強度、時間的強度、論理的強度、暗合的強度の順で整理されます。名前だけ見ると難しく感じますが、上に行くほど一つの目的にまとまっていて、下に行くほど寄せ集めに近いと考えると覚えやすいです。

最も高い機能的強度は、一つのモジュールが一つの機能だけを実行する状態です。税込価格を計算する、パスワードを検証する、平均値を求める、といった明確な一目的のモジュールです。情報的強度は、同じデータ構造に関する複数の操作をまとめる状態です。会員データの登録、更新、削除、検索を会員データ操作としてまとめるようなイメージですね。

連絡的強度は、複数の処理があり、前の処理の出力を次の処理が使うようなまとまりです。手順的強度は、順番に実行されるけれど、データの関連は連絡的強度ほど強くありません。時間的強度は、起動時処理や終了時処理のように、同じタイミングで行う処理をまとめた状態です。

論理的強度は、似た分類の処理をまとめ、引数などでどの処理を実行するか切り替える状態です。暗合的強度は、関係のない処理が偶然一つにまとめられている状態で、最も凝集度が低いとされます。過去問では、最高は機能的強度、最低は暗合的強度をまず押さえ、中間は問題文の「データ」「手順」「時間」「引数で選択」を拾うと判断しやすくなります。

高い順	凝集度	判断の目安
最高	機能的強度	一つの機能だけを実行する
高い	情報的強度	同じデータ構造への操作をまとめる
中高	連絡的強度	前の処理結果を次の処理が使う
中間	手順的強度	決まった順番で実行する
低め	時間的強度	同じタイミングの処理をまとめる
低い	論理的強度	引数で実行処理を切り替える
最低	暗合的強度	関連の薄い処理の寄せ集め

結合度との違いを整理

結合度と凝集度は、どちらもモジュール設計の良し悪しを見るための指標ですが、見ている場所が違います。結合度はモジュールの外側、つまりモジュール同士の関係を見ます。凝集度はモジュールの内側、つまり一つのモジュールに入っている処理のまとまりを見ます。

この違いを意識しないと、用語を覚えていても問題で迷います。問題文に「モジュール間」「受け渡し」「共有」「参照」といった言葉が出ていれば結合度を疑います。反対に、「一つのモジュールに含まれる処理」「同じ機能」「同じデータ」「処理のまとまり」といった言葉が出ていれば凝集度を疑います。

良い設計は、低結合・高凝集です。モジュール同士は必要以上に依存せず、一つ一つのモジュールは明確な目的を持つ。これを一文で覚えておくだけでも、選択肢の読み方がかなり楽になります。必要な単一データだけを渡す設計は低結合に近く、一つの機能だけを担当するモジュールは高凝集に近いです。

逆に悪い設計は、高結合・低凝集です。グローバルデータや内部参照で強くつながり、さらに一つのモジュールに関係のない処理が詰め込まれている状態です。こうなると、変更の影響範囲が広く、テストもしづらく、再利用も難しくなります。試験では、保守性や独立性という言葉が出たら、低結合・高凝集を思い出しましょう。

二つの用語を同時に聞かれたら、まず視点を切り替えてください。外部のモジュールとのやり取りなら結合度、内部の処理のまとまりなら凝集度です。この視点の違いを固定できれば、強い弱いの方向も自然に整理できます。

問題文のキーワードを読む

基本情報のモジュール結合度と凝集度は、暗記表を頭から再現できなくても、問題文のキーワードを拾えれば解けることが多いです。結合度なら、パラメータ、レコード、制御情報、外部データ、共通域、内部参照。凝集度なら、一つの機能、同じデータ、処理結果の受け渡し、手順、同じ時間、引数による切替え、関連なし。まずはこの対応を短い言葉で押さえましょう。

特に、結合度の問題では「最も弱い」「最も強い」という聞かれ方が多いです。最も弱い結合はデータ結合、最も強い結合は内容結合です。凝集度の問題では、最も高いのは機能的強度、最も低いのは暗合的強度です。最高と最低を先に固定すると、中間の選択肢にも落ち着いて対応できます。

中間の種類で迷った場合は、具体的な動きを想像します。構造体を丸ごと渡しているならスタンプ結合、フラグで処理を変えるなら制御結合です。同じ順番で実行するだけなら手順的強度、前の処理結果を次の処理が使うなら連絡的強度です。「順番がある」だけで連絡的と決めないように、データの受け渡しまで見るのがポイントです。

また、IPAの公式シラバスでは、基本情報技術者試験の出題範囲にソフトウェア設計手法や構造化設計が含まれています。最新の試験範囲を確認したい場合は、IPAの試験要綱・シラバスを見ておくと安心です。ただし、普段の学習では公式資料を読むだけでなく、過去問の言い回しに慣れることも大切です。

• モジュール間の受け渡しなら結合度を見る
• モジュール内のまとまりなら凝集度を見る
• 結合度は低いほど良い
• 凝集度は高いほど良い

問題文を読むときは、最初に「外の話か、中の話か」を分けるだけで迷いが減ります。そのうえで、受け渡しているもの、共有しているもの、まとまっている理由を探してください。用語暗記よりも、この読み方を練習する方が得点につながりやすいです。

まとめ

基本情報のモジュール結合度と凝集度は、用語数が多いので最初は暗記しづらく感じます。ただ、設計の考え方としてはかなりシンプルです。モジュール同士は必要以上に依存しない方がよく、モジュール内の処理は一つの目的にまとまっている方がよい。これが低結合・高凝集です。

結合度は、弱い方からデータ結合、スタンプ結合、制御結合、外部結合、共通結合、内容結合です。試験では、受け渡すものが単純なデータなのか、構造体なのか、制御情報なのか、共有データなのか、内部参照なのかを見ます。最も弱いのはデータ結合、最も強いのは内容結合です。

凝集度は、高い方から機能的強度、情報的強度、連絡的強度、手順的強度、時間的強度、論理的強度、暗合的強度です。試験では、モジュール内の処理が一つの機能にまとまっているのか、同じデータを扱うのか、順番や時間だけでまとまっているのか、関係のない寄せ集めなのかを見ます。最も高いのは機能的強度、最も低いのは暗合的強度です。

最後にもう一度だけ、方向を確認しておきましょう。結合度は低いほど良い、凝集度は高いほど良い。外とは弱く、中では強く。この一文を軸にして、あとは問題文のキーワードを拾えば、丸暗記に頼りすぎずに選択肢を選べます。

復習するときは、結合度と凝集度を別々に暗記するだけでなく、同じ設計問題の両面として見てください。外部との依存を減らし、内部の目的をそろえる。この考え方が分かると、ソフトウェア設計の他のテーマにもつながります。

復習するときは、結合度と凝集度を別々に暗記するだけでなく、同じ設計問題の両面として見てください。外部との依存を減らし、内部の目的をそろえる。この考え方が分かると、ソフトウェア設計の他のテーマにもつながります。