開発者の悩みその3 「ロバストネス分析から設計モデルを作成したが設計的に見ておかしいのではないか？」
ユースケースごとにロバストネス分析を行い、その流れでクラスを抽出し、設計につなげたが、ユースケースそれぞれに対し設計を行ってしまった。それによって、後で機能追加およびメンテナンスがほぼ不可能なシステムになってしまった気がする。
この問題の本質は、すでにお分かりのとおり、ユースケースごとに設計をしていることにある。大規模システムでは、このような開発をしているところを結構見かけたりする。
そもそもソフトウェアを動かすためのアーキテクチャは、その中で活用する情報の構造（例えばデータベース設計）や、ソフトウェア上で制御を行うための最適な仕組みを設計するものだ。アーキテクチャはシンプルなものから、重たいものまでさまざまだが、アーキテクチャというお皿のうえに、ユースケースとして作成するプログラムを乗せることになるのだ。それなのに、アーキテクチャを考えずに、それぞれにユースケースを実装してしまったら、プログラムの共通部分がバラバラに作成されてしまうのである。
ロバストネス分析には、このような落とし穴があるのだ。それを回避するために、ユースケース分析の前段階で、ビジネスの分析モデルを確立しておく必要がある。ユースケース記述からの流れでロバストネス分析を使うとしても、ホワイトボードで書く程度の非常にシンプルなものにし、分析モデルをユースケースで叩く（評価する）という観点で使用するのが望ましいのである。
これで、「現状のソフトウェア開発は間違っていないか？（手法編）」は終わりである。次回からは、第2巻「現状のソフトウェア開発は間違っていないか？（プロセス編）」に入る。プロセス編では、第1巻に引き続き、開発プロジェクトで起こる開発プロセスに関する諸問題について具体的な事例を基に述べることにする。また、その本質的な問題と解決策についても触れていく。
筆者紹介
株式会社 匠Lab 代表取締役社長
リコーソフトウエア株式会社 技術顧問
ケペル株式会社 フェロー
株式会社ニッポンダイナミックシステムズ フェロー
要求開発アライアンス 理事
萩本順三（はぎもとじゅんぞう）
2000年、ソフトウェアを人の思考に近い「もの」という単位で考えることで、分かりやすいソフトウェア開発を行えるというオブジェクト指向技術の企業、豆蔵を立ち上げ、ITアーキテクト、メソドロジィストとして経験を積む。現在は、ビジネスとITの可視化を行うための要求開発方法論を要求開発アライアンスメンバーとともに作成し、自らユーザー企業で実践しながら後進の指導に当たる。2008年7月、匠Labを設立し、IT業界のさらなる価値向上を目指す。
Copyright © ITmedia, Inc. All Rights Reserved.