ソフトウェアにおける保守性と拡張性の定義
page1｜page2

日立ソフトウェアエンジニアリング 野村佳弘
日本IBM 玉川憲
2005/12/16

本連載は、オブジェクト指向言語（Java言語など）の経験がある方に、オブジェクト指向における分析設計の流れ・考え方を理解していただくことにより、少しでも現状の改善に役立てられることを目標としています。

---

　一般的に、オブジェクト指向を使うと、保守性・拡張性に優れたシステムが作れるといわれています。しかし、実際には、「オブジェクト指向を使った開発手法のどの部分が保守性・拡張性に貢献するのか分かりにくい」というのが実情ではないでしょうか。この連載では、システム開発における分析から実装の中でも、特に保守性・拡張性の視点から重要なポイントをピックアップして、説明していきたいと思います。

　連載第1回は、まず、現状のシステム開発（ビジネス・アプリケーション）における分析設計手法の問題点を整理し、変更性・拡張性の重要性と定義を説明したいと思います。

◆ 現状のシステム開発における問題点

　 ビジネスアプリケーション開発といってもさまざまな開発手法があります。例えば、「機能分割」のような一般的な開発手法における問題点とは何でしょうか？ 筆者はシステム開発に長く携ってきました。入社して最初にプログラムのコーディングをしていたときは、至る所に重複したロジックや条件文が存在してしまう複雑なプログラムを作ってしまったことが多くありました（俗にいうスパゲッティコードです）。また、システムエンジニアとして上流工程の業務分析や要求定義、機能設計などを行っていたときも、ユーザーと検討した業務要件は機能を中心に整理し機能設計してきましたが、どうしても似たような機能が散在し、すっきりした機能仕様書を作成することはできませんでした。

　これまでのシステム開発における問題は、ほかにもたくさん挙げられると思いますが、まずは下記の2点に着目したいと思います。

1. 上流工程：機能仕様に似たような機能が散在
   
   
2. 下流工程：プログラム中に重複したロジックや条件文が散在

　現状のシステム開発の大まかな流れを見ていきながら、これらの問題を理解していきましょう。

◆ 現状のシステム開発の流れ

図1 現状のシステム開発の流れ（クリックすると拡大）

　上記の図1は、機能分割、DB設計、プログラム設計での一般的な設計を示しています。

（1）上流工程

　まず、機能分割の手法においては、業務要件から「料金を計算する」という機能を洗い出します。これを機能分割し、｢顧客をチェックする｣「固定電話料金を計算する」「携帯電話料金を計算する」などのシステム化可能な機能に分割します。このように階層的に、機能を分割していくのが特徴です。

　しかし、この手法では、似たような機能をまとめるのが非常に難しいといえます。例えば、「固定電話料金を計算する」「携帯電話料金を計算する」において、ほとんど中で行うのは同じような処理でも、扱うデータが違うだけで違う機能として扱わねばなりません。これらの機能を抽象的に考えてまとめるための手法がないのです。

　また、一方で、データベースのデータに関しては、正規化することで、重複をなくし、保守性・拡張性を確保することができます。しかし、機能については、データのように正規化する手法があまりなく、機能の重複をなくすことが難しいといえます。

　まとめると、現状のシステム開発の上流工程においては、機能を効果的に抽象化する手法がなく、機能やデータの構造を併せて分析することができないといえます。

（2）下流工程

　プログラム設計に入ると、システム化可能な機能を、プログラムで実装していきます。基本的な構成としては、メインプログラムで「データ読み込み」「チェック処理」「業務処理」「データ更新」というようにデータを順番に処理する設計になっています。この中の業務処理では、順番にビジネスロジックが実行されます。「固定電話料金を計算する」「携帯電話料金を計算する」などのビジネスロジックはサブルーチンなどで実装され、共有データ領域（グローバル変数）などを参照しながら実行されます。共有データ領域には、データベースから入力したデータや、料金を合計するときの集計エリアなどのワーク領域が保持されます。そして、最後に処理した結果によりDB更新を行います。このように、複雑なプログラムであっても、基本的には「入力処理」「業務処理」「出力処理」の組み合わせで構成されています。

　上記のような流れでプログラムを作成すると、機能仕様書に出てくる似たような機能を、それぞれ別のビジネスロジックとして作らねばならず、プログラム中に重複したロジックがたくさん出てきます。また、ビジネスロジックを実装したサブルーチンと共有データ領域の対応付けは、利用するプログラム側が管理しなければならず、条件文がはんらんしプログラムを複雑にしてしまいます。

　このようなプログラム構造だと、変更が入ったときの対応は非常に大変なものになります。例えば、「衛星電話料金を計算する」などの似たような機能が追加された場合、どうなるでしょうか。まず、機能仕様で「衛星電話料金を計算する」機能を追加設計します。そして、プログラムでは、「衛星料金を計算する」サブルーチンを作成します。さらに、衛星電話料金データが増えたことで、業務処理のプログラムには、衛星電話料金の場合に「衛星電話料金を計算する」サブルーチンを呼び出す条件式も追加せねばなりません（図2）。

図2 複雑なプログラム構造の弊害（クリックすると拡大）

　このように、データが増えると、データを処理するビジネスロジックを作成するとともに、そのビジネスロジックを呼び出すプログラム側も入力したデータを判断して該当するビジネスロジックを呼び出す処理を追加する必要が出てきます。これが1カ所ならよいのですが、往々にして、このようなビジネスロジックを呼び出すプログラムは、至る所に存在することが多く、修正が大変になります。

　まとめると、現状のシステム開発の下流工程においては、重複した機能を持つ機能仕様書を実装するためにプログラム中に重複したロジックが出てきますし、サブルーチンを呼び出す側でデータとビジネスロジックの対応付けを取るために条件文がたくさん出てきてしまいます。そして、そのせいで、変更が入ったときに、修正必要個所の特定が難しく、修正個所が散在してしまう、ということができます。

1/2

INDEX
保守性・拡張性に優れたシステムを作る（1） ソフトウェアにおける保守性と拡張性の定義
	Page1 ◆ 現状のシステム開発における問題点
	Page2 ◆ いま求められているシステム開発とは？

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）

情報マネージャのための「今日のひと言」 - 2010/2/10 『徹底する』　経営実践のコツは凡事徹底です。経営で最も慎まなければならないことは、うまい方法ばかりを探し求め過ぎることです。整理・整頓の……>>続きはクリック

操作もマニュアルも分かりやすい！ ユーザー視点で開発されたPC管理ツール New！

仮想化すればコストは削減できるか？ 仮想化に必要な「3つの視点」を解説する

情報漏えいで会社の社会的信用を失う前に ＠ITメールソリューションLive! in Tokyo

コスト削減・信頼性向上をまとめて満たす “高信頼Linux”を構築する方法とは？

SEの作業時間の大部分を占めるドキュメン ト作成。これを短縮するツールを紹介

＠IT Specialヘ