連載第2回目の今回は、従来型の業務フローチャートの代表的課題の一つである「たくさんある業務バリエーション(現場で実際に行われている多数の例外処理)をどのように業務フローチャート上に反映させ、業務プロセスを可視化していくのか」について、考えていきましょう。●例外処理がかけないのはなぜか業務フローチャートのそもそもの目的は「業務プロセスの可視化」ですから、業務プロセスを現実に行われているとおりに記述することに意義があります。実際の業務プロセスは、何も問題が起こらずスムーズに進むような理想的なパターン、いわば「本筋」ばかりでは済みません。現実の現場は本筋に収まらない、原因も頻度も多種多様な「例外」に満ちています。現実の業務プロセスが、例外処理というバリエーションに富んでいるのであれば、業務フローチャートも現実を反映したものでなければ、本来は意味がないはずです。それに、実務において、ミスが起こりやすい処理や上司や熟練者の判断を仰ぐ必要のある処理は、往々にして例外処理であり、例外処理こそ、どういうときに起こり得るのか、どう対処するのか、知っておく必要性が高いともいえるでしょう。実際に業務フローチャートを作成すると、例外処理を盛り込む際に困難に直面します。その原因は何でしょうか。原因は、例外処理の存在を知らないことです。当該業務の担当者と業務フローチャート作成者が別の場合は、業務フローチャートを作成する人が知らなかったということも、担当者自身が聞かれたときに忘れていたということもあり得ます。これは業務フローチャート作成の前段階の問題であり、今回の連載では触れません。様式、つまり作成時の技術的な問題は、以下の2点に集約されます。(1)「図が細かくなり過ぎるので描き切れない」(2)「作業間を結ぶ線が複雑に絡み合い、意味が分からなくなる」(1)については「PowerPointを利用しているから」という点に帰着することが多いようです。PowerPointは、スライドとして描くスペースが決まっているために、このようなことが起こります。例外処理を複数の場合分けで表現すると、担当者別のスイムレーンの幅が広がってしまい、ほかのスイムレーンを圧迫して、全体が小さくなり過ぎてしまうことで、結局、描き切れなくなります。(2)は(1)を避けようとして起こる問題です。全体が小さくなるのを防ぐために、作業をぎっしりと配置した結果、線が絡み合ってしまうのです。「担当者や担当部署によって仕切られたスイムレーンに作業を配置する」という従来の発想そのものが、上記の2つの問題を引き起こす根本的な原因なのです。●ケーススタディ:新発想の業務フローチャート連載第1回目では、具体的な例をもとに、従来からの一般的な様式による業務フローチャートを作成してみました。今回は同じ例をもとに、「担当者や担当部署によって仕切られたスイムレーンに作業を記載する」という従来の発想を捨て去って、業務フローチャートの記載ルールを考えてみましょう。前回、業務フローチャートは「要素」と「流れ」によって表現されると説明しましたが、その組み合わせは、従来の様式の業務フローチャート以外にも様々なパターンを考えることができます。紙ドキュメント・情報システムのみを「どうする」のそばに記号として記載ルールに注目してください。前回みた従来の発想をもとにした定義との大きな相違点は、「誰が」と「どうする」のスイムレーンを分けた点にあります。流れを示すのは、従来の定義と同じく「どうする」です。これにより作成される業務フローチャートは以下のようになります。一般的な業務フローチャートに慣れた人にはなじみのない形ですが、業務フローチャートの本来の目的である「業務の流れ、つまり業務プロセスを可視化する」という視点では、目的を果たしていることがわかります。この図において特徴的なことは、従来の様式が、作業の要素である「誰が・何を・どうする」を1つのスイムレーン内に1点で示していたものを、「誰が」と「何をどうする」とに分離して、2つのスイムレーンにプロットされた2つの点から表していることです。●お絵かき的発想からの脱却このように見てくると、業務フローチャートの構成単位である作業を平面上の1点で表すという固定概念から、解放されたのではないでしょうか?業務フローチャートは、「要素」と「流れ」の組み合わせで、どのような様式でも描くことができます。作業を表すために、必ずしも1つのスイムレーン内に1つの点として配置する必要はないのです(図3)。従来の発想にとらわれない業務フローチャートまた、新発想による様式では、バリエーションを表す「流れ」が複数のスイムレーンを行ったり来たりせずにシンプルになっているので、図4のように「例外処理、つまり多数のバリエーションが盛り込める」ことも直感的に理解できるでしょう。例外処理を描き込んだ新発想の業務フローチャート連載一回目のケーススタディで、従来の様式に従って例外処理を盛り込むとどうなるかをイメージしてください。3人の担当者のうち、森山さんと田中さんの話の中に「問題がなければ」というくだりがありましたが、問題があった場合、それが例外処理にあたります。これを、従来の様式による業務フローチャートで描くと以下のようになります。従来の様式で例外処理を反映させた場合の業務フローチャートただし、これはごくシンプルな例です。(1)例外処理の分岐は1カ所のみ、(2)「誰が」「どうする」のみで「何を」は省略してあります。例外処理が何個所も何パターンもあり、作業のそばに「何を」を配置したら、どうなるでしょうか。描き切れなくなったり、線が絡み合ったりして、見た目も煩雑なものになることが、イメージできるでしょう。今回は、「誰が」と「何をどうする」とを分離して2つの点から作業を表すという発想の転換により、「たくさんの業務バリエーションを、どのように業務フローチャート上に反映させ、業務プロセスを可視化していくのか」という課題に、1つの答えが出せたと思います。連載第3回目となる次回は、もう一つの代表的課題である「作業の粒度をどのように統一するのか」について、解説していきます。システム導入・運用の現場における業務改善コンサルティングを手掛ける。業務現場・コンサルティング・アウトソースのそれぞれの経験を通して培った業務プロセスを理解・改善する実践的な手法を開発し、研修・コンサルティングを提供している。様々なビジネスシーンで活用される「業務フローチャート」ですが、業務フローチャートを正しく活用できているでしょうか?作成にばかり手間を取られ、肝心の業務フローチャート活用にはあまり時間を掛けていない。こんな状況ではないでしょうか。本コラムでは真の意味で業務フローチャートを使いこなす方法を松浦剛志氏に解説いただきます。(現三菱東京UFJ銀行)審査部にて企業再建を担当。その後、グロービス(ビジネス教育、ベンチャー・キャピタル、人材事業)にてグループ全体の管理業務、アントレピア(ベンチャー・キャピタル)にて投資先子会社の業務プロセス設計・モニタリング業務に従事する。中心とする管理業務のコンサルティングとアウトソースを提供する会社、ウィルミッツを創業。2006年、業務プロセス・コンサルティング機能をウィルミッツから分社化し、プロセス・ラボを創業。詳しいプロフィールはこちら簡単なケースを使ってフローチャート(プロセスマップ)の書き方を理解し・使いこなせるようにPDFにまとめました。フローチャートの書き方をお探しの方は是非参考にしてください。フローチャートには代表的なものだけでもいくつかの手法、つまり書き方があります。