業務フローを書くレベル

ビジネス系のシステムの要件定義を行うときに、業務フローはよく使われる。そして、この業務フローは比較的他のドキュメントよりもわかりやすく書きやすいものである。しかし実際に業務フローを書くとなると様々な問題がでてくる。

その問題に対処するためにまずは業務フローの役割から考えてみよう。
その目的は以下のようなものが考えられる。

・業務を理解するため
・As-Isの業務を明らかにするため
・ToBeの業務を設計するため

上記のことを目的に業務フローを書くが、実際に作られる業務フローは大きく分けると以下の２つに分けられるのではないだろうか。

・何となくこんな感じと　大雑把に書かれたもの
・詳細に書かれたもの

□何となくこんな感じ
業務の内容がよく分からないので「取り合えずこのレベルでまとめておこう」というケースか、もしくは「あまり詳細に業務を理解してもしょうがないので、このレベルにしよう」というケースのどちらかが考えられる。

□詳細に書かれたもの
このケースの場合はユーザ部門が協力的で詳細な業務の情報が手に入るケースにおいてよく見られる。

この両者はどちらが良い、悪いの問題ではない。

例えば「業務について共通の認識が得られればよい」ということであれば、大雑把であっても共通の認識に立てればそれで役割を果たしている。
逆に詳細な業務フローであっても使われなければ、無用なものに時間をかけただけになってしまう。

要は何に使うのかという役割にあったレベルで書かれていることが大事である。
先に挙げた３つの目的、それぞれについても使われ方によって記述レベル変わってくる。
そのレベルを意識して作成するのが良い。

RDRAではシステムの外部環境を把握するために業務フローを記述する。
その目的はシステムが使われる環境を明らかにすることである。
つまり、要件定義メンバーがシステム境界を求めるために必要な情報が得られればいいと考える。

従って、システム境界を求めるために適切なレベルで記述することが求められる。
そのレベルはその要件定義を行うメンバーに依存する。つまり、そのメンバーが理解できる内容であればよい。

このように何の目的で作成するのかを意識するだけで、業務フローに関する問題のいくつかは解決できる。