ソフトウェア方式設計とは
ソフトウェア方式設計とは、変更に強い構造を目指して、モジュールの責任や依存関係を決める設計です。

一か所を変えたら無関係な機能まで壊れる設計では、変更のたびに負担が増えます。部品の責任を分けることが大切です。
基本の仕組み

送料計算を一つのモジュールへまとめれば、送料ルールの変更時に画面ごとに修正する手間を減らせます。呼出し側は必要な入力と結果だけを扱います。
凝集度は一つのモジュール内の仕事のまとまり、結合度はモジュール間の依存の強さです。責任が明確で、内部実装への依存が少ない構造を目指します。
単にファイルを細かく分けても、互いの内部状態を直接書き換えるなら依存は強いままです。境界と公開するインタフェースを考えます。
結合度と凝集度の段階

モジュールの独立性は、結合度が低いほど、凝集度(モジュール強度)が高いほど高いと評価します。外部に見せるインタフェースを明確にして内部の実装を隠す(情報隠蔽)と、内部を変更しても利用側を直さずに済みます。
結合度は、モジュール間で何を受け渡すかで段階が分かれます。必要なデータ項目だけを引数で渡すデータ結合が最も弱く望ましい結合で、他のモジュールの内部を直接参照・変更する内容結合が最も強い結合です。
凝集度は、高い順に機能的強度、情報的強度、連絡的強度、手順的強度、時間的強度、論理的強度、暗合的強度です。一つの機能だけを実行するモジュールが最も望ましく、「初期化処理をまとめただけ」のように実行時期が同じだけのもの(時間的強度)や、無関係な処理の寄せ集め(暗合的強度)は低い評価です。
| 結合度(弱い順) | 受け渡し・依存のしかた |
|---|---|
| データ結合 | 必要なデータ項目だけを引数で渡す |
| スタンプ結合 | 構造体(レコード)ごと渡し、その一部だけを使う |
| 制御結合 | 処理を切り替えるフラグなどの制御情報を渡す |
| 外部結合 | 外部で宣言した単一のデータを複数のモジュールが参照する |
| 共通結合 | 共通域の構造化データを複数のモジュールが参照する |
| 内容結合 | 他のモジュールの内部を直接参照・変更する |
試験に出る
- 凝集度は「モジュール内のまとまり」、結合度は「モジュール間の依存の強さ」として区別します。
- 変更に強い設計は、責任が明確で結合度が低い方向を目指す点。
- ファイルを細かく分けても、内部状態を直接書き換えれば依存は弱くならない点に注意します。
- 公開するインタフェースを決め、内部実装への依存を減らす考え方。
- 送料計算のように変更が多い処理を一つにまとめる例の理解。
- 結合度はデータ結合が最も弱く(望ましく)、内容結合が最も強い。凝集度は機能的強度が最も高い、という段階の順序。
重要な言葉
- 凝集度
- 一つのモジュール内の仕事のまとまりの度合い。
- 結合度
- モジュール間の依存の強さ。低いほど変更に強い。
- インタフェース
- モジュールが外部へ公開する入力と結果の窓口。
- データ結合
- 必要なデータ項目だけを引数で受け渡す、最も弱く望ましい結合。
確認問題
確かめよう他の部品の内部変数を直接変更する設計は変更に強い?
いいえ。内部の変更が利用側へ波及しやすくなります。
凝集度はモジュール間の依存の強さを表す。
他の部品の内部変数を直接書き換える設計は、変更の影響が広がりやすい。
モジュール内の仕事のまとまりの度合いを表すのは?
変更に強い設計が目指す方向は?
モジュール結合度が最も弱く、望ましいとされるものは?
一か所を変えたら無関係な機能まで壊れる設計では、変更のたびに負担が増えます。を分けることが大切です。
送料計算を一つのモジュールへまとめれば、送料ルールの変更時に画面ごとに修正する手間を減らせます。呼出し側は必要なだけを扱います。
は一つのモジュール内の仕事のまとまり、はモジュール間の依存の強さです。責任が明確で、内部実装への依存が少ない構造を目指します。
単にファイルを細かく分けても、互いの内部状態を直接書き換えるなら依存は強いままです。と公開するインタフェースを考えます。
出典・参考資料
試験の公式案内と、この記事の参考にした学習資料です。
- IPA:基本情報技術者試験 ↗
- IPA:現行制度の公開問題 ↗
- IPA:試験要綱・シラバス ↗
- IPA:基本情報技術者試験シラバス Ver.9.2(2026年1月) ↗
- Scrum Guides:The Scrum Guide(2020) ↗
編集:Pinternet Works · 更新日:
教材の編集方針・訂正について
