「ITエンジニアは職人気質を取り戻すべき」：ソフトウェア開発の匠（1）（3/3 ページ）

» 2008年11月26日 00時00分公開

（1）ユーザーも開発者も理解しづらい産物を作りかねない

　ユースケース記述からロバストネス図へつなげると、アクターとシステムの挙動を精密にとらえようとしすぎ、いつの間にか、ユーザーから見たシステムの使われ方をユーザーの視点で説明する観点を忘れてしまう。その結果、ユーザーが理解できないユースケース記述になる。揚句の果てには、システム開発者でさえユースケース（要求）とは程遠い世界にどっぷりと漬かってしまうのである。

図3　ユースケースが要求から仕組みの世界へ変化する

（2）分析モデルを作るまでに多くの工数を要する

　先にも述べたが、ロバストネス分析は教育的であり、実際の開発には不向きである。なぜなら、ロバストネス活用のゴールは、ビジネスの中で重要な語彙（ごい）をクラス名とした、実装アーキテクチャに依存しない基本構造を分析モデルとして構築することにあるからだ。しかし、分析モデルは、要求開発（注）段階で作成されたビジネスシナリオや業務フローから抽出すれば、容易に作成できるものである。それなのに、多大な時間をかけて、ロバストネス分析で分析モデルを作る意味があるのだろうか？

　また、一度ユースケースに分類した業務概念を、ロバストネス分析でバラバラにし、共通点を見つけながら分析モデルを作り上げるというのは、実は大変難しい作業である。

　もしロバストネス分析を使うとするなら、ToBeビジネスを理解する段階で、概念モデルを作成しておくことが重要である。もちろん、私はそのように教育してきているのであるが、いままでの問題プロジェクトを見ると、概念モデルがなく、ロバストネス分析を介して分析モデルを作成していくやり方がまん延しているようなのだ。

図4　ユースケース記述からロバストネスへつなぐ流れの問題点

（注）要求開発：システム開発の前段階でToBeビジネスをデザインしITにつなげていくための考え方で方法論として要求開発アライアンスが提供している。

　いかがだろうか。ユースケースモデルは使い方を誤ると要件定義の問題だけではなく、設計にも支障がでてしまう。ここでは、解決策のヒントについて少しだけ書いている。読者も、この問題をどう捉え、どうしたら解決できるのか、しっかり考えておいてほしい。さて次回は、分析モデル・設計モデルについて、現状の問題を明らかにする。

筆者紹介

株式会社　匠Lab 代表取締役社長
リコーソフトウエア株式会社技術顧問
ケペル株式会社フェロー
株式会社ニッポンダイナミックシステムズフェロー
要求開発アライアンス理事

萩本順三（はぎもとじゅんぞう）

2000年、ソフトウェアを人の思考に近い「もの」という単位で考えることで、分かりやすいソフトウェア開発を行えるというオブジェクト指向技術の企業、豆蔵を立ち上げ、ITアーキテクト、メソドロジィストとして経験を積む。現在は、ビジネスとITの可視化を行うための要求開発方法論を要求開発アライアンスメンバーとともに作成し、自らユーザー企業で実践しながら後進の指導に当たる。2008年7月、匠Labを設立し、IT業界のさらなる価値向上を目指す。

「次回」へ

「ソフトウェア開発の匠」バックナンバー