日本版SOX法(注1)の3点セットでは、業務フローチャート(注2)が中心的な役割を担うにもかかわらず、その作成方法には公式が少なく、いざ作成を開始するとさまざまな課題に突き当たってしまう。
連載2回目の今回は、代表的課題である、業務バリエーション、すなわち現場で実際に行われている多数の例外処理を、どのように業務フローチャートとして可視化していくのかについて考える。
業務フローチャートのそもそもの目的は「業務プロセスの可視化」であるから、業務プロセスを現実に行われているとおりに記述することに意義がある。実際の業務プロセスは、何も問題が起こらずスムーズに進むような理想的なパターン、いわば「本筋」ばかりでは済まない。現実の現場は本筋に収まらない、原因も頻度も多種多様な「例外」に満ちている。現実の業務プロセスが、例外処理というバリエーションに富んでいるのであれば、業務フローチャートも現実を反映したものでなければ、本来は意味がないはずである。
それに、実務において、ミスが起こりやすい処理、上司や熟練者の判断を仰ぐ必要のある処理は、往々にして例外処理である。例外処理こそ、どういうときに起こり得るのか、どう対処するのか、知っておく必要性が高いともいえる。
しかし、実際に業務フローチャートを作成すると、例外処理を盛り込む際に困難に直面する。その原因は何であろうか。
一番の原因は、例外処理の存在を知らないことである。担当者と業務フローチャートを作成する人が別の場合は、業務フローチャートを作成する人が知らなかったということも、担当者自身が聞かれたときに忘れていたということもあり得る。しかし、これは業務フローチャート作成の前段階の問題であり、ここでは触れない。
様式、つまり作成時の技術的な問題を業務フローチャート作成担当者に聞いてみると、以下の2点に集約される。
(1)について、さらに聞いてみると、「PowerPointを利用しているから」という点に帰着することが多い。Microsoft PowerPointは、スライドとして描くスペースが決まっているために、このようなことが起こる。業務フローチャートに盛り込む例外処理が増えるにつれて、文字のポイント数を落としていき、6ポイントくらいになったところで音を上げるというのが典型的なパターンである。
では、Microsoft Visioを利用すれば解決するのであろうか? 例外処理を複数の場合分けで表現すると、下の図に示すように担当者別のスイムレーンの幅が広がってしまい、ほかのスイムレーンを圧迫して、全体が小さくなり過ぎる。結局、描き切れないということになる。
(2)は、(1)を避けようとして起こる問題である。全体が小さくなるのを防ぐために、作業をぎっしりと配置した結果、線が絡み合ってしまうのである。
つまり、2つの問題を引き起こす根本的な原因は、「担当者や担当部署によって仕切られたスイムレーンに作業をプロットする」という従来の発想なのである。
Copyright © ITmedia, Inc. All Rights Reserved.