【システム設計・開発手法】従来のウォーターフォール開発における壁！「構造化分析/設計の限界」｜情報処理問題1000本ノック

基本情報技術者試験、応用情報技術者試験、システムアーキテクト試験の「ソフトウェア工学・構造化設計・オブジェクト指向」分野で頻出の重要テーマ。1970年代から広く用いられてきた「構造化アプローチ（DFDや機能分割中心）」が持つ本質的な限界と、それを克服するために登場した「オブジェクト指向」への移行理由を整理して攻略しましょう。

■ 構造化分析/設計（Structured Analysis / Design）の主な限界と課題

トップダウンで機能を細分化（機能分解）していく構造化アプローチは、小規模開発には有効ですが、システムの大型化や要件変更の頻発に伴い以下の深刻な限界に直面しました。

限界・課題の項目	概要と発生する問題点	具体的な症状・影響
1. 数量的爆発 (Document / Combinatorial Explosion)	システムやビジネスロジックが複雑化・大規模化するにつれて、作成・管理すべき仕様書（DFD、モジュール仕様書、データ辞書など）の数が爆発的に増大する現象。	・ドキュメントの維持管理が不可能な状態（管理不全）に陥る。 ・仕様変更時の整合性チェック（影響範囲追跡）が極めて困難になる。
2. 保守の困難性 (Maintenance Difficulty)	仕様変更やバグ修正を繰り返すうちに構造が崩れ、システムの複雑性が増大して全体構造の理解が困難（スパゲティコード化）になる現象。	・一部を修正すると予期せぬ箇所に影響（副作用）が出る。 ・開発当初の設計思想が失われ、改修コストやリスクが急増する。
3. データと処理の分離 (Data & Process Separation)	「処理（機能）」と「データ」を個別に分析・設計するため、データの構造変更が広範囲のモジュールに影響を及ぼしやすい弱点。	・共通のグローバル変数やDB構造が変わると、それを参照する大量のプログラム修正が必要になる。
4. 再利用性の低さ (Low Reusability)	特定のシステム手順に依存した機能分割を行うため、他のプロジェクトや機能へ部品（モジュール）を再利用することが難しい。	・似たような処理を毎回ゼロから作成（車輪の再発明）することになり、開発効率が上がらない。

試験対策の重要キーワード

• 機能中心アプローチ（POA：Process Oriented Approach）：構造化分析/設計の基礎となる考え方。「どんな処理を行うか」を中心にシステムを分割するため、データ側の変化に弱いという欠点があります。
• オブジェクト指向（OOA/OOD）へのパラダイムシフト：構造化手法の限界（数量的爆発や保守の困難性）を解決するために誕生した思想。「データ」と「処理」をカプセル化して一体化（オブジェクト化）することで、高再利用性と高保守性を実現しました。
• モジュール結合度とモジュール強度：構造化設計において保守性を高める指標。結合度は「弱く（疎結合）」、強度は「強く（高凝集）」設計することが基本原則とされます。

※例えるなら、構造化設計は「巨大なプラモデルの説明書」です。作品が巨大になるほど説明書のページ数も爆発し（数量的爆発）、途中でパーツの形を1つ変えると全体の組み付け手順が狂って直せなくなる（保守の困難性）問題が起きます。これをパーツごとに完結させた「ブロック（レゴ）」のように組み替えやすくしたのが、現代のオブジェクト指向です。