この記事は以下の記事の続きになります。

システム開発の要件定義で、業務フロー図をはじめとするドキュメントを作成すると決め、いざ作業を始めると、現場では必ずと言って良いほど、次の2つの問題が起こります。

1つは「業務マニュアルとして利用したくなる」ということ、もう１つは「業務フロー図をための話をしているのに、画面や帳票の話になる」ということです。

この2つの問題により、業務フロー図を作成する範囲が広がり、１つ１つの業務フロー図に細かい情報が記載されるようになります。

すると、業務フロー図の枚数もその情報量も膨大なものとなります。その結果、要件定義において本来明らかにすべき情報、後行程のシステム開発において必要となる情報が埋もれ、あるいは漏れてしまうということが起こってしまいます。

後工程の設計者が要件定義の情報をもとに開発を進めることができなくなってしまうのです。

2.1 　業務マニュアルとして利用したくなる

要件定義で業務フロー図を作成しようとすると、必ずと言っていいほど「せっかく作るのだから業務マニュアルとしても利用できるようにしよう」という話になります。

業務フロー図の作成はかなりの手間がかかる作業で、さらに業務部門に主体的にかかわってもらう必要もあります。

そういった背景から、協力を仰ぎやすくするために、システム部門としてもついつい提案したくなってしまいます。

業務を可視化・標準化することは良い取り組みであり、それ自体を否定するつもりはありません。

しかし、この「せっかくだから」というのは、とても危険です。

その程度の気持ちで安易に進めると、業務マニュアルとしてもシステムの設計書としても中途半端なドキュメントを作成してしまうことになります。

業務マニュアルとして耐えうるレベルの情報を記載した業務フロー図と、システム開発をする目的で作成する業務フロー図は作成する範囲も記述する情報量も大きく異なります。

業務マニュアルとしても利用できるようにするために付加した情報は、必ずしもシステム開発において必要な情報ではないからです。

「業務の単位の粒度が一貫しない」

業務フロー図は、業務の流れを図として表現するものですが、図2のように業務の単位（アクティビティ）をどう捉えるのかによって書かれる内容が変わってきます。

業務の単位を「申請書を受け取って処理する」のひとつとして捉えることもできますし、「申請書を受け取る」と「申請を処理する」という二つに分けて捉えることもできます。

また、「申請書を受け取る」を「トレイから申請書を取り出す」「その申請書をスキャンする」「処理済のトレイに移す」と分けて捉えることもできます。

さらに細かくすることもできて、「前回のスキャンから時間が経っている場合は、機器のスイッチを入れて準備完了状態になるまで待つ」といったところまで記述することもできます。

こうした単位の大きさのことを粒度と呼びます。

粒度をどの大きさにして、どのように揃えるのか、というのは、業務フロー図を作成する上で非常に重要なポイントになります。

どの粒度が一番良いのかは、業務フロー図を作成する目的によって変わってきます。

図2の場合、一番大きな粒度は、組織内での事務分掌を定義するのに適しています。

二番の粒度はシステムが行うべきことと、自分が行うことが分けやすいので、システムの要件設計には適した粒度です。

三番目の粒度は、細かく確実に作業を引き継ぐためには必要なレベルです。

四番目の粒度は細かすぎて非現実だと思うかもしれませんが、機器の処理の自動化をするような場合に必要になります。

たとえば、スキャナーに書類を置いて、スタートボタンを押したときには前回のスキャンから時間が立っていれば、ウォームアップするまで待ってから処理を行うというのは、機器の内部処理を明確にするには重要な記述になるからです。

「業務マニュアルのために情報が増える」

業務マニュアルとして利用しようとすると、業務フロー図をシステム要件定義より細かい粒度で記載したくなります。

図2で言うと、確実に作業を引き継ぐために必要な三番目の粒度、またはそれ以上に細かい粒度になります。

業務フロー図は、階層構造で作成して複数の粒度を表現することもできますが、業務マニュアルで使おうとすると1つのフローで全てを確認したくなります。

また、業務マニュアルとして作る場合は、システム化範囲外の業務、手作業のみで行っている業務についても業務フローを作成する必要があり、作成の範囲も広がります。

すると、業務フローのなかで条件分岐が増えたり、他のフローへの遷移も増えたりするということが起こります。

同じ業務を表す場合でも、フローがより複雑になってしまうのです。(図3)

　私たちが経験した事例では、市外から転入した際の届け出を受け付ける保険系の業務フロー図において、システム開発に目的を絞って作成した業務フロー図ではページ数にして2ページでしたが、業務マニュアルにもなるように作成した業務フロー図は11ページにもなりました。

また、双方の業務フロー図を比較したところ、業務マニュアルにもなるように作成した業務フロー図は、情報量の多さや複雑さによる可読性の低下で、機能の共通化やシステムテストのテストケースの抽出が難しくなることも分かりました。

2.2　業務フロー図をための話をしているのに、画面や帳票の話になる

要件定義で業務フロー図を作成するために打ち合わせをしていると、参加しているメンバーから「業務フロー図だけではイメージできない」という声があがります。

そして、具体的なイメージを持ってもらうために、画面や帳票のレイアウトやイメージが用いて、それらを見ながら打ち合わせが行われるようになります。

一見良いことのように思えますが、これを放置していると、業務フロー図を作成する打ち合わせのはずなのに、「この画面の項目がいる、要らない」といった、どんどん機能の詳細の話になっていきます（図4）。

時には画面や帳票だけでなく、「実装が分からないと議論ができない」といって、ファイルやデータベースまで話がおよび、「○○マスタを作って、そこから抽出して、○○の条件でソートする」などという、実装レベルでの打ち合わせが繰り広げられるということも起こります。

そして、「せっかく議論したのだから」と、実装レベルの打ち合わせ内容が、業務フロー図のなかにコメントや補足情報といった形で大量に追記されていきます。

すると、そもそもの業務フロー図を作成する目的である利用シーンの情報が埋もれ、欠落してしまいます。

せっかく業務フローを作って要件定義をしたのに、仕様が膨れたり使い勝手が悪くなったりしてしまうということが起こるのです。

続きはこちら