手戻りなし ！ 業務フロー図 作成の秘訣

特集
！
し
な
り
戻
手
特 集
業務フロー図
作成の秘訣
手戻りなし！　業務フロー図 作成の秘訣
要件定義や基本設計で作成する詳細レ
ベルの業務フロー図は、複雑になりや
すく分岐条件が漏れるなどして手戻りに
つながりやすい。分かりやすく正確に描
く現場の秘訣を紹介する。
（島津 忠承）
54
NIKKEI SYSTEMS 2013.7
＜イラスト：ミオササノッチ＞
四つめは「注釈だらけで重要な箇所
テムの開発プロジェクト。順調に開発
詳細レベルの業務フロー図が分かり
が分かりにくい」である。必要な情報
が進んだが、ユーザーテストで問題が
にくいときの典型例として、次の四つ
をすべて盛り込もうとして個々のプロ
起きた。
「商品種別によって在庫の引
が挙げられる（図2）
。
セスの意味やシステムの要件などを注
き当て方を変える必要があるのに、そ
一つめは、
「人の活動かシステムの
釈として書くと、ごちゃごちゃして分
の選択肢がシステムの画面に出てこな
処理なのかはっきりしない」である。
かりにくくなってしまう。
い」という指摘が入ったのだ。
業務の流れに、システムの処理が区別
では、分かりやすく正確な詳細レベ
原因は、要件定義フェーズで作成し
なく混在している図がそうだ。
ルの業務フロー図を作るにはどうすれ
た業務フロー図にあった。それは、経
二つめは「
（業務フローを構成する）
ばいいのか。業務フロー図の作成につ
営層や利用部門に対する提案などに活
プロセスの粒度がバラバラになる」
。
いて周囲から評価の高いITエンジニア
用する「概要レベル」の業務フロー図
業務フロー図の中で、プロセスによっ
に取材したところ、その秘訣が浮かび
とは別に作ったもの。利用部門による
て詳しく記述されていたり、大雑把に
上がった。以下では、
「人の活動かシ
新業務のチェックと合意形成や、アプ
記述されていたりすることを指す。
ステムの処理なのかはっきりしない」
リケーション設計の材料にすることを
「分岐で図が複雑化する」
。これが三
「プロセスの粒度がバラバラになる」
目的とした「詳細レベル」の業務フロー
つめの典型例だ。業務フローにはさま
「分岐で図が複雑化する」
「注釈だらけ
図である（図1）
。
ざまな分岐条件があるもの。詳細レベ
で重要な箇所が分かりにくい」という
このプロジェクトでは、商品種別に
ルの業務フロー図では、分岐パターン
四つのダメな典型例に分けて、そうな
よって在庫の引き当て方を変えること
が多くなる。それらをすべて業務フ
らないようにするための秘訣を順に紹
になっていた。しかし詳細レベルの業
ロー図に描くと極めて複雑になる。
介する。
手戻りなし！　業務フロー図 作成の秘訣
事例のような手戻りを引き起こす。
特 集
物流業務の改革に伴う在庫管理シス
務フロー図からこの記載が漏れた。し
かもこの業務フロー図の表現が複雑で
本特集で対象とする業務フロー図
分かりにくかったために、記載の漏れ
ム要件に盛り込まれなかった。
主な用途
に誰も気付かず、必要な機能がシステ
分かりにくい典型例は四つある
要件定義や基本設計を担当するIT
エンジニアであれば、誰しも業務フ
ロー図を描いたことがあるだろう。し
概要レベルの業務フロー図
・経営層や利用部門への提案
・現状業務の問題点のヒアリング
詳細レベルの業務フロー図
・利用部門による新業務のチェッ
クと合意形成
基本設計へ
・基本設計（アプリケーション設
計）
の材料
1 2レベルの業務フロー図とその用途
図
業務フロー図には大きく二つのレベルがある。提案やヒアリングに活用する「概要レベル」と、新業務のチェッ
クと合意形成、基本設計の材料とする「詳細レベル」である。ここでは後者を対象に、その描き方を解説する
かし、詳細レベルの業務フロー図を分
かりやすくかつ正確に描くのは容易で
典型例（1）
ない。
「業務の流れを厳密に描こうと
人の活動かシステムの
処理なのかはっきりしない
するあまり複雑にしてしまう人が多
典型例（3）
分岐で図が
複雑化する
い」とオージス総研の中澤祥浩さん
（ソリューション開発本部 コンサル
ティング・サービス部 業務改善推進
典型例（2）
グループリーダー）は指摘する。
プロセスの粒度が
バラバラになる
そうして詳細レベルの業務フロー図
が複雑になると、関係者がその内容を
十分にチェックできなくなり、冒頭の
典型例（4）
注釈だらけで重要な
箇所が分かりにくい
2 詳細レベルの業務フロー図が分かりにくいときの典型例
図
NIKKEI SYSTEMS 2013.7
55