分析モデルはユーザー視点でシンプルに：ソフトウェア開発の匠（2）（1/3 ページ）

匠Lab 代表取締役の萩本順三氏が、既存のソフトウェア開発プロセスにメスを入れる！

[萩本順三，匠Lab]

　連載第2回の今回は、現在のソフトウェア開発の問題点（手法編）の続きとして、分析モデル・設計モデルを取り上げる。ここで取り上げる問題の中には、ユースケースモデル作成の流れで発生するものもある。そのために、前回（「『ITエンジニアは職人気質を取り戻すべき』」）の内容も見ながら理解した方がよいだろう。

分析モデル・設計モデルを有効に生かせていない

　分析モデル・設計モデルは、両方とも、ビジネスの変化に耐え得るソフトウェアシステムを開発するために作成される。しかし、これもまたユースケースモデル同様、生かされていないことが多い。

　両モデルともソフトウェアシステムの開発ドキュメントの中で何らかの形で埋め込まれる。代表的な分析モデルに、クラス図、シーケンス図、パッケージ図などがある。設計モデルには、これらに加え、状態図、コンポーネント図、配置図などが加えられる。

開発者の悩みその1　「分析モデルを時間かけて作成したが、まったく生かせなかった」

　第1回「『ITエンジニアは職人気質を取り戻すべき』」で挙げたロバストネス分析を使って分析モデルを作ってみた。当初、ビジネスドメインを表すモデルの重要性は認識していたはずであった。しかし、結果として、ユーザーも理解できないモデルを作成してしまった（これは前回ロバストネス分析の問題として挙げた）。さらに、分析モデルから設計がうまくつながらず、設計は別で進めてしまった。いま思うと、分析モデルに時間をかけた意味が分からないし、分析モデルの必要性も分からない。

　この問題の本質は、分析モデルの有効性がITの進化によって変化してきているのに気が付いていないことだ。いまやオープン系が主流のWebシステム開発においては、設計モデルのベースとなるフレームワークありきで開発を進めるスタイルになっている。

　分析モデルをすでに存在する設計（ベース）モデルに適合することで、設計モデルを作り上げる必要が出てきている。その際、分析モデルは設計の都合で大きく変化することが多い。例えば、分析モデルで抽出されたクラスをサブクラス化すると、分析モデルで表現していた意味的な関連が切れてしまう。つまり、制御がフレームワーク側に移り、スーパークラスの関連によって、サブクラス化されたクラス同士の関連が表現されるのである。あるいは、分析モデルで作成された概念（Entity）は、設計上パフォーマンスを考慮していないこともあるのだ。

　よって、分析モデルの構造と、フレームワークをベースにした設計モデルの構造は、大きく異なる。

　そうなると、分析モデルは何のために作成するのであろうか？ 筆者はこのような状況だからこそ分析モデルが必要になると主張する。それはビジネスアーキテクチャとソフトウェアアーキテクチャをつなぐ懸け橋として重要なのである。

　これに比べて、昔はスクラッチ開発が多く、分析モデルを拡張することで設計モデルにつなげていきやすかった。そのために、分析モデルの動作検証としてシーケンス図を使うことが有効だったのかもしれない。

図1　分析モデルから設計モデルへ移行する（過去と現在）

　しかし、いまとなっては、このような箱庭の世界（分析モデル）を動かして何がうれしいのかを考えなければならなくなった。分析モデルは、図1のようにビジネス構造を理解するもの（理解のモデル）としてとらえるべきだ。一方、設計モデルは、設計の構造を理解するためのもの（理解のモデル）に加えて、実装責任を負うモデルとして作らなければならないのだ。

　このように整理していくと、分析モデルを作る際に、実装責任を負うモデルとして作ろうとすることが、ユーザーからは理解不能な産物を作りだしたり、多大なコストがかかかってしまったり、結果的に設計モデルとしては使えないものを作ってしまう、問題の主原因だとお分かりになるだろう。

　分析モデルは、ユーザーの視点で、ビジネス構造を理解するということを大切に、あまり時間をかけずにシンプルに作ることが重要なのである。

図2　分析モデルと設計モデルの違い