「モデリングのスキルがないのでクラス図を描けない、と自ら認めるITエンジニアでも、平気で業務フロー図を描いている。だからITの現場には、分かりにくかったり正確でなかったりする業務フロー図があふれる」──。

　日経SYSTEMS 7月号特集2「手戻りなし！業務フロー図作成の秘訣」の取材を別の記者と進めるなかで、上流工程担当のベテランエンジニアからこんな話を聞いた。

　少し言葉を補うと、クラス図も業務フロー図も、上流工程で作成するモデル図の一種である。このうちクラス図に関しては、その作り方を知らないエンジニアは手を出せないのだという。ここでいう作り方とは、何をクラスとするのか、どのような構造にするのか、関連線の多重度をどうするか──といったこと。そうしたノウハウが十分でないエンジニアはそのことを自覚していて、クラス図を描かない。

　ところが業務フロー図は、大まかに言えば、特定の業務を実行する上での人とシステムの処理（プロセス）を流れとして表すだけ。見よう見まねでそこそこ描けてしまう。そのためエンジニアは、自分のノウハウ不足に気付きにくいのだという。このことが、ダメな業務フロー図が作られる大きな原因の一つになっている、との指摘である。

　ダメな業務フロー図であっても、企画提案のフェーズで使う概要レベルのものなら、口頭で補足できるので、大きな問題にならないかもしれない。しかし、詳細レベルの業務フロー図が分かりにくかったり正確でなかったりすると致命的である。

　「この商品種別については例外的な処理を行う」といったようなビジネスルールの考慮漏れがあっても、ごちゃごちゃした分かりにくい業務フロー図ではその間違いに気付きにくい。そのため、ユーザーテストでようやく間違いが明らかになり、大きな手戻りが発生する。

　ではどうすれば、分かりやすく正確な業務フロー図を描けるのか。ここでは二つのテクニックを紹介しよう。

テクニック1：レーンを区切る

　一つ目は、よく知られている基本的なテクニックである。それは、対象業務に関係する組織やシステムごとに「スイムレーン」と呼ぶ領域を設け、それぞれのプロセスを分けて記述する、というもの。これは既に多くのエンジニアが実践しているだろう。

　この応用技として、時間軸のレーン分けがある。「日次（で実施する処理）」「月次（で実施する処理）」「締め日前日」「締め日」「締め日翌日」といった具合に、時間軸においてもレーンを設ける方法だ。比較的簡単な工夫だが、分かりやすさが高まる。