複雑なフローチャートを整理するには、全体像と詳細を分けます。親となる図には主要な段階と重要な結果を残し、一つの段階の内部手順を名前付きのサブプロセスへ移します。その際、サブプロセスが何から始まり、結果がどこへ戻るかを明確にします。
文字を小さくしたり、例外の経路を消したりすることから始めないでください。見た目がすっきりしても、使いにくくなることがあります。主な流れを追いやすくしながら、実務に必要な詳細にもたどり着けることが目標です。
何がフローチャートを読みにくくしているかを見つける
箱を並べ替える前に、原因を見つけます。大きな業務段階と一回のクリック操作が混在していないか、複数の分岐で同じ確認を繰り返していないか、あらゆる例外を主経路に詰め込んでいないかを見ます。Boardmixで全体図と詳細なフローチャートを一緒に編集すれば、両者のつながりを見ながら整理できます。
読む人が答えを知りたい問いを考えましょう。
- 「自分の申請はどう処理される？」には、主要な段階、待機する場所、起こり得る終了状態が必要です。
- 「この段階で何をすればよい？」には、作業、判断、入力、引き継ぎが必要です。
- 「このケースはなぜ失敗した？」には、該当する例外経路と、その分岐を決める情報が必要です。
この三つをすべて同じ粒度で答えようとすると、図が絡まりやすくなります。見せ方を分ければ、同じ業務を説明しながら、全員にすべての手順を読ませずに済みます。
問題が線の引き方だけなら、まず図形をそろえ、交差を減らします。短く一貫した業務を、構造的に見せるためだけに複数の図へ分ける必要はありません。詳細が全体の流れを邪魔していて、意味のある入力と結果を持つ部分を切り出しましょう。
何を省くかより先に、業務の範囲を決める
ASQのフローチャート作成手順は、業務の範囲、始まりと終わり、必要な詳細度を決めることから始まります。図を移動する前に、何が入力され、何をもって完了とするかを書き出します。
この記事の架空の例では、範囲を従業員が経費申請を提出してから、承認・却下を判断し、承認された場合は経理へ引き渡すまでとします。支払いそのものは範囲外です。そのため「経理への引き渡し完了」を「精算済み」に言い換えてはいけません。
整理前の図には、申請を開く、領収書を読む、必要事項を確認する、不足項目を依頼する、回答を読む、承認者へ送る、判断を記録する、従業員へ知らせる、承認済みの資料を転送するといった作業が入っているかもしれません。どれも役立つ作業ですが、すべてを全体図に置く必要はありません。
整理中は元の図を比較用に残します。今回変えるのは業務の説明の仕方であって、会社の承認方針ではありません。業務そのものの変更案は、明確に別の版として扱います。
重要な結果を残した全体図を作る
例を三つの段階にまとめます。後から図形を動かしても詳細を探せるよう、固定の識別子を付けます。
- P1 — 申請の必要書類を確認する。必要な裏付け情報がそろっているかを確認します。結果は「審査に進める」または「取り下げ」です。追加情報を待っている申請はP1の中にとどまります。
- P2 — 申請を審査する。担当の審査者が承認または却下を記録します。却下された申請はそこで終了し、経理へは引き渡しません。
- P3 — 承認済みの資料を経理へ引き渡す。承認された申請と裏付け情報を渡します。この図は引き渡し時点で終わり、支払いまでは扱いません。
全体図の主経路は「申請済み → P1 → P2 → P3 → 経理への引き渡し完了」となります。同時に、P1からの「取り下げ」とP2からの「却下」という二つの重要な出口も残します。どちらも、曖昧な「完了」の箱にまとめません。
珍しい結果だからといって、消してはいけません。次の担当者の対応が変わる結果は、全体図にも必要です。内部の細かな確認は詳細図へ移せますが、承認と却下の違いは残します。
意味を変えずにP1を詳しくする
詳細図の上に、そのサブプロセスが担当する範囲を短く書きます。
- 入口：申請番号と、提出済みの裏付け資料を持つ申請。
- 目的：必要な書類や情報がそろっているかを確認する。
- 返す結果：「審査に進める」または「取り下げ」。
- 待機状態：「情報待ち」。正常な完了とは区別する。
続いて内部の流れを描きます。
- P1.1 — 申請と必要書類を読む。この種類の申請に必要な情報の一覧を使います。
- P1.2 — 必要書類はそろっているか。そろっていれば「審査に進める」としてP2へ渡します。
- P1.3 — 不足する情報を依頼する。理由のない「却下」という連絡ではなく、足りない項目を明示します。
- P1.4 — 従業員の回答を待つ。補足・修正された資料が届けばP1.1へ戻ります。明示的な取り下げがあれば「取り下げ」を返します。回答がない場合は「情報待ち」のままです。別の状態へ移すには、組織のフォローアップ手順で定めた条件を満たす必要があります。
書類がそろっていることと、申請が承認されたことは別です。P1は書類の充足を確認し、P2が申請の可否を判断します。両者を「確認」の一箱にまとめると、元の曖昧さを作り直してしまいます。
待機状態は、同じ依頼を繰り返し送るループとも異なります。外部からの回答を待って止まっている状態です。組織に再連絡や終了のルールがあるなら、その実際の条件を描きます。図の都合で勝手な期限を設けないようにします。
全体図と詳細図の間を迷わず移動できるようにする
全体図の段階を「P1 — 申請の必要書類を確認」、詳細図を「P1の詳細」とします。入口と出口の名称も両方でそろえます。全体図では「審査に進める」、詳細図では「承認済み」と書かれていると、同じ状態なのか分かりません。
共有キャンバスでは詳細を親の近くに置き、別の文書にある場合は明示的な参照先を書きます。ページの端へ消える無名の矢印より、「P1の詳細」と付けた接続の方が分かりやすくなります。作成者に聞かなくても、参照先を見つけられるようにしましょう。
チームの記法に合うなら、定義済み処理の記号も使えます。ただし、装飾的な形よりも名称と接続の方が重要です。BPMNのような正式な記法を使っている場合は、そのサブプロセスの規則に従い、気軽に別の記法を混ぜないようにします。
詳細図の中でも、判断の粒度をそろえます。画面単位の操作説明書を意図しているのでなければ、「申請を審査する」と「添付アイコンをクリックする」を同じ階層に並べません。クリックの説明は補足や別の操作ガイドへ分けます。
三つのケースを両方の図で追う
全体図と詳細図の違いが分かるケースを使います。業務に新しい手順を追加するのではなく、整理後も意味が保たれているかを確認するためのケースです。
| ケース | 詳細図での動き | 全体図に表れる結果 |
|---|---|---|
| 書類がそろっており、申請が承認される | P1.1とP1.2を経て「審査に進める」となる。 | P1 → P2 → P3 → 経理への引き渡し完了。 |
| 領収書が不足し、従業員が提出した後に申請が却下される | P1.3で領収書を依頼。P1.4で受け取り、P1.1へ戻る。 | P1は最終的に「審査に進める」を返す。P2で却下され、P3には進まない。 |
| 情報不足の状態で従業員が取り下げる | P1.4が「取り下げ」を返す。 | 「審査に進める」や「承認済み」ではなく、「取り下げ」で終了する。 |
二つ目のケースは詳細図の中でループしますが、そのループを全体図全域へ引く必要はありません。「書類がそろうか取り下げられるまで、必要書類の確認にとどまる」という業務の意味は、全体図でも保たれています。
実際のケースを追えない場合は、手順を別の場所へ移しただけなのか、誤って消したのかを確認します。元の図、全体図の結果、詳細図の出口を比較し、レイアウトを整える前に食い違いを直します。
一枚の複雑な図を、つながらない多数の図にしない
数個の箱ごとに分割すると、業務を理解するより次の図を探すことに時間がかかるようになります。一まとまりの段階は一緒に保ちます。担当範囲が明確、繰り返し使う処理、内部の判断が多いなど、サブプロセスとして分ける理由が必要です。
同じような確認が複数の場所にある場合も、本当に同じ確認かを先に確かめます。「アカウントへのアクセス権を変更する前に本人確認する」と「申請に顧客識別子があるか確認する」は別の目的です。名前が似ているだけでは、まとめる理由になりません。
この例では、Boardmixのキャンバス上部に全体図、そのすぐ下にP1の詳細を置きます。必要書類の一覧は判断のひし形に詰め込まず、使う場所であるP1.2の横に置きます。却下と取り下げは、文章と見た目の両方で区別し、色だけに頼らないようにします。
Boardmixを開いてフローチャートを整理しましょう。最も分かりにくい段階から始め、その部分だけを詳しくし、すでに読みやすい箇所は変えずに残します。読む人が全体を説明でき、自分が担当する段階の手順を正確に見つけられる状態を目指します。
