シナリオの図解化第1回

業務分析の難しさ

さて、業務分析を行うことのメリットは大きいのだが、問題は「誰もが簡単にビジネスアーキテクチャをモデリングできるものではない」ということだ。

第1に、モデリングを行うには抽象的で論理的な思考能力が必要である。たとえ分析対象業務に精通していても、モデリングのための思考方法を身につけないと業務モデルを作成することはできない。逆に、技術者は日頃から論理的な思考には慣れているものの、今度は分析対象業務の方が分からないので的確なモデルが作れるとは限らない。

第2に、モデルを表現するためのUMLやER図、DFDといった表記法が非技術者にとっては理解しづらい。UMLのクラス図を例に挙げると、一見「ただの箱」にしか見えない記号が、同じような性質を持つが状態が異なる複数の実体の類型（＝クラス）を意味する、といったことを理解しておかないと、モデルの正しい意味は読み取れない。「ただの線」の脇におまけのように添えられている「0..*」といった数字と記号が、実はとても重要な情報を含んでいるということを理解できるようになるためには相当の訓練が必要である。

シナリオによる業務分析

実は、業務分析におけるモデリングの際にUMLなどの形式的な表現を使わない方法もいくつかある。

その中の1つとして、自然言語を用いたシナリオによるものがあるので紹介しよう。Carrollは、将来の望ましい「状況」を記述したシナリオを作成することで、対話的システムを設計する「シナリオに基づく設計」を提案している（Carrollについては、最後の参考文献参照のこと）。

図2にこの設計法で用いるシナリオの例を示す。これは区役所で転居の届けを出すときの状況を記述したシナリオである。シナリオは、読んでいただければ分かる通り普通の文章である。UMLなどとは異なり、日本語が読めればだれでも理解できる。

さて、このようなシナリオがどのように役立つのだろうか？

例えば「区役所の業務における利用者の案内を改善する」というビジネス要求があったとしよう。そのために「利用者案内システム」を設計する、という視点で先ほどのシナリオをじっくり読み直すとどうだろう。

伊東さんは受付係に案内されて、その後窓口の所にいる別の係にも案内を受けている。これはシステム化により人件費を削減すべき部分ではないか？

住基カードの普及を促進させたいという立場からすると、住所変更の申請と住基カードの発行を同時にできるような案内をしてもよいのではないか？

読み直してみると、上記のような改善点が見いだされたかもしれない。シナリオに基づく設計では、このような分析に基づき、今度は「望ましい将来の状況」について新しいシナリオを作成する。それを読んでさらに問題分析を行い、またシナリオを書き直し・・・、といった作業を繰り返す。そして、最終的には「理想的な利用者案内システムが設置された区役所のシナリオ」を決定する。

図2のようなシナリオは具体的であるから、読み手は状況をイメージしやすい。その分、問題を発見することも容易である。また、技術者でなくとも日本語が読めさえすれば、問題分析の議論に参加できる。あるいは、UMLでモデルを作成することは無理でも、シナリオであれば書けるという人も多いはずだ。

しかしながら、Carrollの方法では最終的に理想的なシナリオを得るまでに、何回もシナリオを改訂することになるので、シナリオ執筆作業の手間がかかるという問題がある。また、日本語による文章で記述した具体的なシナリオから、実際のシステムの仕様に落とし込む明確な手順が提供されている訳ではないため、システム開発に用いるためにはもう一工夫必要だ。