業務フローをわかりやすく表現することのできるフローチャートについて、こちらの記事で作成ステップをご紹介しましたが、では次にどうやってその図表を活用すればよいのでしょうか？
この記事では「レストランの電話予約」から「レストランのインターネット予約」へ業務プロセスを見直してみます。
変更されるものは何か？
すでに作成済みのフローチャートを参照します。インターネット予約にすることで、今回変更がありそうなのはどこでしょうか。主な変更点は以下の3点です。
- 顧客はレストランに電話せず、Web上で手続きを行う
- 空き状況の回答は人ではなく、Webシステムで行う
- 予約確認の案内は人ではなく、Webシステムで行う
アクターに追加・変更はあるか？
赤枠で囲った変更点について、それぞれのアクターに追加もしくは変更があるか確認します。①は引き続き顧客が行うプロセスなのでアクターに変更はありません。一方、②、③はレストラン（の人）が行うものではなく、Webシステムで行うものに変更があります。
つまり、フローチャート上のスイムレーンに「システム」というアクターの追加が発生しそうです。このとき、スイムレーンはどこに追加するのが良いでしょうか？おすすめは、顧客とレストランの”間”の位置への追加です。
というのも、この「システム」の役割を考えたとき、それは顧客とレストランとの間のやり取りを代行するものだからです。フローチャートのプロセスを細かくしていく過程で、「システム」が両者の間のハブになりそうだな、両者からシステムに対しフロー（矢印）が往来しそうだな、という想像ができますよね。
このような性質（複数のアクターから矢印が向かう性質）のアクターは、図のわかりやすさという観点でも、スイムレーンの真ん中に配置することでよりフローチャートをよりシンプルで読みやすい見た目にできるメリットもあります。
プロセス自体を見直せるポイントはないか？
プロセスの見直しで最も重要なポイントがこの確認作業です。アクターが変更・追加される、特にその対象がシステムであれば、人でできなかったことが可能だったり、人による実行では必要だった2~3つのプロセスをたった1つのプロセスで代替できる、といったことが容易にあります。（同じ人のアクターであったとしても、A部門はできないけどB部門の権限だとできる、というプロセスもありますよね。）
今回は「希望の日時の確認」~「空きがある？→YES」までのプロセスに見直しができます。具体的には、レストランの空き状況を”何月何日”という特定の対象ずつ確認するサイクルを繰り返すのではなく、複数日時の空き状況を一括で提示する、というプロセスが可能と考えられます。
上記では、空き状況の一括表示期間を「2ヶ月」としています。（「前後1ヶ月の空き状況を表示」というプロセス）期間を具体的にどう設定するかはさておき、どんなに長い期間を表示したとしてもその期間内で顧客が予約したい日時があるとは限りません。ですので、この”予約したい日時が表示されていない場合”については、新たにプロセスの組立てが必要です。
このようにプロセスの見直しというのは、プロセスが単純にA→Bに変化する以上に、その関連するプロセスに影響がないかを注意深く観察することが大事です。
残課題はないか
業務プロセスやシステムプロセス（機能やその使い方・画面のつくり）というのは何通りも考えられ、プロセスを見直している人＝フローチャートを再構築している人が、単独で意思決定できるケースは少ないと思われます。
意思決定のバトンタッチをするのであれば、残課題は図表上に書き込んでおくことをおすすめします。例えば前段で記載した「一括表示する期間は2ヶ月でよいか」も残課題の1つです。また、予約確認と予約プロセスはシステムが担うことになりましたが、レストランは予約が入ったことをどのように知るのでしょうか？予約が入ったタイミングで、即時通知を受ける必要はあるでしょうか？
以下の図では、フローチャート上にこれらの残課題を追記しています。
まとめ
フローチャートを用いた業務プロセスの見直しについて、具体的な過程やポイントについてご紹介しました。これらの内容を口頭ベースで話し合うことももちろん可能ですが、いまどの部分について話をしているのか（議論対象の一致）と、他に変更が発生する部分がないか（影響範囲の特定）において、フローチャートという可視化ツールは非常に有効です。
フクロウの図表ラボ 