仕事の流れを「見える化」する

第2回 仕事の流れを「見える化」するには･･･

連載第２回目の今回は、従来型の業務フローチャートの代表的課題の一つである「たくさんある業務バリエーション（現場で実際に行われている多数の例外処理）をどのように業務フローチャート上に反映させ、業務プロセスを可視化していくのか」について、考えていきましょう。

●例外処理がかけないのはなぜか
業務フローチャートのそもそもの目的は「業務プロセスの可視化」ですから、業務プロセスを現実に行われているとおりに記述することに意義があります。実際の業務プロセスは、何も問題が起こらずスムーズに進むような理想的なパターン、いわば「本筋」ばかりでは済みません。現実の現場は本筋に収まらない、原因も頻度も多種多様な「例外」に満ちています。現実の業務プロセスが、例外処理というバリエーションに富んでいるのであれば、業務フローチャートも現実を反映したものでなければ、本来は意味がないはずです。

それに、実務において、ミスが起こりやすい処理や上司や熟練者の判断を仰ぐ必要のある処理は、往々にして例外処理であり、例外処理こそ、どういうときに起こり得るのか、どう対処するのか、知っておく必要性が高いともいえるでしょう。

しかし、実際に業務フローチャートを作成すると、例外処理を盛り込む際に困難に直面します。その原因は何でしょうか。

一番の原因は、例外処理の存在を知らないことです。当該業務の担当者と業務フローチャート作成者が別の場合は、業務フローチャートを作成する人が知らなかったということも、担当者自身が聞かれたときに忘れていたということもあり得ます。しかし、これは業務フローチャート作成の前段階の問題であり、今回の連載では触れません。

様式、つまり作成時の技術的な問題は、以下の2点に集約されます。

(1)については「PowerPointを利用しているから」という点に帰着することが多いようです。Microsoft PowerPointは、スライドとして描くスペースが決まっているために、このようなことが起こります。

では、Microsoft Visio（スライドサイズが決まっていない描画ソフト）を利用すれば解決するのでしょうか？ 例外処理を複数の場合分けで表現すると、担当者別のスイムレーンの幅が広がってしまい、ほかのスイムレーンを圧迫して、全体が小さくなり過ぎてしまうことで、結局、描き切れなくなります。

一方、(2)は(1)を避けようとして起こる問題です。全体が小さくなるのを防ぐために、作業をぎっしりと配置した結果、線が絡み合ってしまうのです。

つまり、「担当者や担当部署によって仕切られたスイムレーンに作業を配置する」という従来の発想そのものが、上記の2つの問題を引き起こす根本的な原因なのです。

●ケーススタディ：新発想の業務フローチャート
連載第１回目では、具体的な例をもとに、従来からの一般的な様式による業務フローチャートを作成してみました。今回は同じ例をもとに、「担当者や担当部署によって仕切られたスイムレーンに作業を記載する」という従来の発想を捨て去って、業務フローチャートの記載ルールを考えてみましょう。

前回、業務フローチャートは「要素」と「流れ」によって表現されると説明しましたが、その組み合わせは、従来の様式の業務フローチャート以外にも様々なパターンを考えることができます。たとえば、次のような定義に従って作成 してみましょう。

ルールに注目してください。前回みた従来の発想をもとにした定義との大きな相違点は、「誰が」と「どうする」のスイムレーンを分けた点にあります。流れを示すのは、従来の定義と同じく「どうする」です。

これにより作成される業務フローチャートは以下のようになります。

図２　新発想による業務フローチャート

いかがでしょうか？ 一般的な業務フローチャートに慣れた人にはなじみのない形ですが、業務フローチャートの本来の目的である「業務の流れ、つまり業務プロセスを可視化する」という視点では、目的を果たしていることがわかります。

さらにこの図において特徴的なことは、従来の様式が、作業の要素である「誰が・何を・どうする」を1つのスイムレーン内に１点で示していたものを、「誰が」と「何をどうする」とに分離して、2つのスイムレーンにプロットされた2つの点から表していることです。

●お絵かき的発想からの脱却
このように見てくると、業務フローチャートの構成単位である作業を平面上の１点で表すという固定概念から、解放されたのではないでしょうか？業務フローチャートは、「要素」と「流れ」の組み合わせで、どのような様式でも描くことができます。作業を表すために、必ずしも1つのスイムレーン内に１つの点として配置する必要はないのです（図３）。

図３　従来の発想にとらわれない業務フローチャート

また、新発想による様式では、バリエーションを表す「流れ」が複数のスイムレーンを行ったり来たりせずにシンプルになっているので、図４のように「例外処理、つまり多数のバリエーションが盛り込める」ことも直感的に理解できるでしょう。

図４　例外処理を描き込んだ新発想の業務フローチャート

連載一回目のケーススタディで、従来の様式に従って例外処理を盛り込むとどうなるかをイメージしてください。3人の担当者のうち、森山さんと田中さんの話の中に「問題がなければ」というくだりがありましたが、問題があった場合、それが例外処理にあたります。これを、従来の様式による業務フローチャートで描くと以下のようになります。

図５　従来の様式で例外処理を反映させた場合の業務フローチャート

ただし、これはごくシンプルな例です。（1）例外処理の分岐は1カ所のみ、（2）「誰が」「どうする」のみで「何を」は省略してあります。例外処理が何個所も何パターンもあり、作業のそばに「何を」を配置したら、どうなるでしょうか。描き切れなくなったり、線が絡み合ったりして、見た目も煩雑なものになることが、イメージできるでしょう。

今回は、「誰が」と「何をどうする」とを分離して2つの点から作業を表すという発想の転換により、「たくさんの業務バリエーションを、どのように業務フローチャート上に反映させ、業務プロセスを可視化していくのか」という課題に、1つの答えが出せたと思います。

連載第3回目となる次回は、もう一つの代表的課題である「作業の粒度をどのように統一するのか」について、解説していきます。