変更に耐えるシステム構造とモデルの関係（上）

日立ソフトウェアエンジニアリング
野村佳弘

2006/6/2

1　2　3｜次のページ

◆ 保守性の考え方

　 保守性とは、「予想できなかった機能変更・追加を最低限のコストで実施できること」です。では、予想できない機能変更はどんなときに起きると思いますか。わたしは大きく2つあると思います。すなわち、「使いにくい」「使えない」など、要求が正しく実現されていないとき、あるいは、使ってみると新たな要求が出てくるときです。これは、システムの機能とビジネス要求の乖離（かいり）が原因だと考えられます。このような場合、結局は、仕様変更を余儀なくされます。（広い意味での）バグと考えてもいいでしょう。

　ビジネス環境が変化することで、構築したシステムに機能の追加が要求されたり、短時間で機能変更が要求される場合もあります。著者が担当したシステムでも、「従来はサービスインに3カ月かかっていた開発作業を、3週間で行わなければ競争に勝てない」と主張する企業がありました。柔軟な機能追加や機能変更は、情報システム開発を行ううえで必ず考慮しなければならない要素となっています。

　システムの機能とビジネス要求の乖離という問題は、システム構築の際にどのような機能が要求されているのかを正しく分析できなかった（当然設計もできなかった）ことから起こります。

　機能追加や変更に対応できないという問題については、構築したシステムの構造があらかじめ変更に耐え得るものになっていないことが原因です。通常、作ってしまったプログラムには手を入れられません。そもそも、出来上がってしまったものに変更を加えると、かなりの期間や工数がかかります。前回お話しした「普遍的な構造」と「固有の構造」を基にしてシステムを設計すると、変更部分のほかの領域への影響範囲を最小化することが可能となるのです。

　このような議論を踏まえて、今回は2回に分けて、要求を忠実に反映したシステム分析の方法と、変更に耐えるシステム構造を作る方法を解説します。前編である今回は、実際の分析作業を行う前に知っておくべき知識の整理をしておきます。

1　2　3｜次のページ

	Page 1 保守性の考え方
	Page2 観点と視点
	Page3 モデルとモデリング

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