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

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

[萩本順三，匠Lab]

開発者の悩み

その1　「ユースケース図について、ユーザーから『ピンとこない』といわれる」

　ユースケース図を書いてユーザーに説明しても、「よく分からない」「ピンとこない」といわれてしまう。そのため、ユーザーがシステムをどう使いたいのか整理できないまま開発を進めてしまった。

　この問題の本質は、要求を点としてとらえてしまっていることだ。よって、開発者も要求を理解しているとはいい難い状態である。ユーザーの業務は、面（一連の業務の中でシステムを利用する）ととらえるべきである（図１）。具体的には、業務フローを可視化することによって実現できる。この問題は、ユースケース図を業務フローとセットで見せることで、緩和される。

図１　業務は面で考えるべき

その2　「ユースケース記述を詳細に書きすぎてメンテナンスができない」

　ユースケース記述とは、ユースケース図の中の（1つ1つの）ユースケースについて、アクターとシステム双方のやりとりをシナリオ的（イベントフローという）に記述したものである。このユースケース記述を（例外処理や代替処理、あるいはシナリオ記述などまで）細かく書きすぎ、ドキュメント量が膨大になってしまった。書いていることの一貫性が図れなくなり、しまいには管理不能状態に陥った。

　 さらに問題となったのが、画面仕様との乖離（かいり）（図2）。ユースケース記述と画面仕様を別々に管理してしまったため、最終的に画面仕様を頼りに開発を進めるはめになった。結果的に、ユースケース記述を何のために書いたのかがまったく分からなくなった。

　この問題の本質を理解するには、「なぜ詳細化を図ろうとしているのか」を考えなければならない。ユースケース記述を詳細に書く理由は、要求をシステムの仕様につなげたい意図があるからだ。この典型例として、「ロバストネス分析」がある。ロバストネス分析の問題については後述するが、ユースケース記述を細かく書けば書くほどシステムに対する要求はよく分からなくなることを意識しなければならない。ユーザーも開発者もユースケース記述の細かい論理的矛盾を取り除くことだけに着目し、システムに対する本質的な要求が見えなくなるのである。本来ユースケースとは、システムづくりの観点で記述するものではなく、ユーザーがビジネスを実施するためのシステム利用事例として、簡潔なストーリーを記述するものではないだろうか？ その中で、画面イメージやモックアップなどを有効に活用すべきではないだろうか？ こういう点を考えてみると、本来どうすべきかが見えてくるだろう。

図2　詳細化しすぎるユースケース記述、画面仕様と乖離する

その3　「ロバストネス分析に多大な工数をかけたが成果が出ない」

　ロバストネス分析から、シーケンス図などを使って動作検証を図り、分析モデルを作り上げる作業までには多くの工数を要した。しかし、その結果作成された分析モデルは設計モデルにつながりにくく、何のためにシーケンス図などを使って検証したのか、作成したエンジニアたちにも分からなかった。

　問題の本質は、ロバストネス分析の使い方にある。ロバストネス分析とは、ユースケース記述を基に、B（Boundary）、C（Control）、E（Entity）に分類する手法で、多くのユースケース利用者に使われている。このやり方は、ユースケースから分析モデル（分析レベルのクラス図）につなげていくための、シームレスかつ美しいやり方として教育的にも人気があるようだ。私もシステムに境界を付けるため、画面などをB、制御部分をC、データ部分をEに分離するのはよい方法だと思う。しかし、ユースケース記述から、B、C、Eを導き出し、その中から責務の共通化を図り、分析モデルを完成させるやり方は適切ではない。教育的な手順が開発に向くかというとそうではないのだ。

　このやり方の問題をまとめると、次のページの2点である。