業務フロー図の書き方｜ムダな工程を特定できるフロー図を作成できる

四角と矢印を並べて、それらしいフロー図は描ける。でも記号の意味も向きも自己流で、気づけば「描いた本人にしか分からない図」になっている——業務の可視化を任された業務設計担当や、自分の担当業務を見直したい実務担当者なら、一度は経験があるのではないでしょうか。担当者間の受け渡しも分岐も読み取れず、肝心の「で、どこにムダがあるの？」にたどり着けない。業務フロー図の書き方を検索しても、記号一覧は出てくるのに、それを使って現状業務を描き、ムダを指し示すところまでは案内してくれません。

この講座でお伝えしたいのは、一つです。業務フロー図は、きれいに整理して見せるための図ではありません。現状の業務を標準化された記号で1枚に描き起こし、その図の上でムダな工程を指差して特定するための道具です。描くこと自体がゴールではなく、ムダを見つけて根拠を示せることがゴールです。

終えると、次の3つができるようになります。業務フロー図が業務の可視化に果たす役割と、代表的な2つの表記法（JIS X 0121 と BPMN）の違いを説明できること。主要な記号と「左から右・上から下」という流れの向きを使い分けて、現状業務のフロー図を作成できること。そして描いた図の上で、ムダな工程を ECRS という視点で特定できることです。覚えて帰る型は、「標準記号で描く → 担当レーンで受け渡し・分岐を見える化 → ECRS でムダを特定」。本講座では、あなたが業務設計担当として、備品購入の申請から承認、発注までの身近な業務（申請者・上長・購買担当の3者が関わります）を1枚のフロー図に段階的に育て、最後にその図でムダを特定する場面を、全章を通して追います。

先にレーンをお伝えします。本講座は「現状業務を記号でフロー図化し、その図でムダを特定する」可視化技術に絞ります。そもそもどんな業務があるかを洗い出す段階は業務棚卸しの進め方、描いたフロー図を文章の手順書に落とす作業は業務手順書(SOP)の書き方、特定したムダを起点に標準の型を決めて展開する計画は業務標準化の進め方が、それぞれの正本です。本講座はそこには踏み込みません。

業務フロー図とは何か——可視化の道具と2つの表記法

フロー図は業務を「誰が読んでも同じ意味」で伝える共通言語

そもそも業務フロー図とは何でしょうか。処理の内容やデータの形式などを記号化し、それらを矢印（流れ線）で結んで、視覚的に分かるように表した図のことです（出典：日本電気技術者協会「フローチャートの作り方」）。文章でだらだら書くより、図式化したほうがはるかに理解しやすい。だからこそフロー図は、ルールに沿って正しく描けば「誰が読んでも同じ意味として伝わる」共通言語として機能します（出典：BPMコンソーシアム「BPMNとは」）。

これは、備品購入業務を思い浮かべると腑に落ちます。申請者・上長・購買担当の3者が関わるこの業務は、口頭で説明すると毎回どこかがズレます。ところが1枚の図にしておけば、全員が同じ流れを同じ意味で共有できます。しかも、処理の手順をフロー図で図式化すると、流れの誤りやムダを簡単に見つけ出せるようになります（出典：日本電気技術者協会・同上）。可視化は、共有のためだけでなく、ムダ発見のための足場でもあるのです。

JIS X 0121 と BPMN——2つの代表的な表記法

フロー図には表記法がいくつもありますが、まず押さえたいのは代表的な2つです。

1つ目が JIS X 0121 です。JIS X 0121:1986「情報処理用流れ図・プログラム網図・システム資源図記号」は、情報処理のための文書化に用いる記号を規定した規格で、26種類の記号が定められています（出典：JIS X 0121:1986 規格本文）。処理・判断・入出力といった記号があり、処理手順やアルゴリズムを共通の記号で表したい場合に向いています（出典：業務可視化ノート「フローチャートの種類一覧」）。なお JIS の正式名称は2019年の法改正で「日本工業規格」から「日本産業規格」に変わりましたが、規格番号と1986年版である点は変わりません。

2つ目が BPMN（Business Process Model and Notation）です。BPMN は OMG（Object Management Group）が維持する国際標準（ISO19510）の業務プロセスモデリング表記です（出典：BPMコンソーシアム・同上）。業務の開始と終了、担当者や部門の役割分担、判断、例外処理、外部組織とのやり取りまで表現でき、部門や関係者をまたぐ業務プロセスの共有・分析に向いています（出典：業務可視化ノート・同上）。

両者の違いは「何を表すのに向くか」です。JIS X 0121 は処理手順やアルゴリズムを共通記号で表すのに向く一方、担当者・部門・顧客との受け渡しまで表したい場合は、BPMN やスイムレーン型の業務フローチャートのほうが適しています（出典：業務可視化ノート・同上）。

「何を可視化したいか」を先に決めてから表記法を選ぶ

ここでつまずきやすいのが、表記法を決めないまま描き始めてしまうことです。用途が定まらないと記号が自己流になり、読み手に伝わらない図になります。フロー図を選ぶときは、最初に「何を可視化したいか」を決め、その後で表記法を選びます（出典：業務可視化ノート・同上）。もう一つのつまずきは、最初から記号を増やしすぎること。初心者は「四角形で処理・ひし形で判断」といった簡単なフローチャートから始めるのが現実的です（出典：業務可視化ノート・同上）。

そこで本講座では、まず入門に向く JIS 系の基本記号で備品購入業務を1本の流れとして描き（第2章）、そのうえで担当ごとの受け渡しをスイムレーンで足していく（第3章）という進め方をとります。なお、フロー図に描く前の段階、つまり「そもそもどんな業務があるのか」を洗い出す作業そのものは、業務棚卸しの進め方が正本です。本講座は、洗い出した業務を図に描く段からスタートします。

この章の確認（演習）

あなたが可視化したい業務を1つ選び、「何を・誰に伝える図か」を1文で書いてみてください。たとえば「備品購入の申請〜発注の流れを、申請者・上長・購買担当が共有するための図」というように。そのうえで、処理手順を中心に表すなら JIS 系、担当ごとの受け渡しを表したいならスイムレーン型、と表記法を1つ選び、選んだ理由を一言添えてみましょう。

主要記号と流れの向き——記号でフロー図を描く

覚えておく主要記号——まずは7つ

記号の意味がバラバラだと図は伝わりません。JIS X 0121 の記号のうち、業務フロー図でよく使う主要な7つを、規格の定義とともに押さえましょう（出典：JIS X 0121:1986 規格本文）。

• 端子：外部環境への出口または入口を表し、プログラム（業務）の流れの開始・終了を示します。業務フローの「開始」と「終了」に置きます。
• 処理：任意の種類の処理機能を表します。「申請書に記入する」「発注する」といった、作業そのものを表す最も基本の記号です。
• 判断：一つの入口と幾つかの択一的な出口をもち、記号中の条件の評価に従って唯一の出口を選ぶ判断機能を表します。「上長が承認するか」のような条件分岐に使います。
• 書類：人間の読める媒体上のデータを表し、媒体には帳票などが含まれます。「申請書」「発注書」といった紙・文書に使います。
• データ：媒体を指定しないデータを表します。
• 定義済み処理：サブルーチンやモジュールなど、別の場所で定義された一つ以上の処理を表します。別のフローに切り出した一連の手続きを1つの箱で示したいときに使います。
• 線（流れ線）：データまたは制御の流れを表します。記号どうしを結び、業務の流れをつくります。

記号は、その形で意味を識別することを目的としており、実際に用いる記号は規格に示された形を手本とすることとされています（出典：JIS X 0121:1986 規格本文）。一般に、処理は長方形、判断はひし形で描く、と覚えておくと入門としては十分です（出典：業務可視化ノート）。本講座では作図ソフトを問わないので、以降は〔端子〕〔処理〕〔判断〕〔書類〕のように擬似記号で表します。

標準的な流れの向きは「左から右・上から下」

記号を並べたら、次は向きです。標準的な流れの方向は、左から右へ、上から下へとすると定められています（出典：JIS X 0121:1986 規格本文）。読み手はこの向きを前提に図を追うので、これに従うだけで「読める図」に近づきます。逆に、下から上や右から左へ流れる場合、あるいは向きを明示したい場合は、線に矢先（矢印）を付けます。流れの向きを明示する必要があるときは矢先を付けなければならない、というのが規格のルールです（出典：JIS X 0121:1986 規格本文）。差し戻しのように流れが逆行する矢印には、必ず矢先を付ける——これを守るだけで、逆流が読めない図がぐっと減ります。

備品購入業務を記号に置き換えて1本にする

では、備品購入業務を記号に置き換えてみましょう。まずは担当を分けず、1本の流れにします。

〔端子：申請開始〕→〔処理：申請書に必要事項を記入〕→〔書類：備品購入申請書〕→〔判断：上長は承認するか〕→（はい）〔処理：購買担当が発注〕→〔書類：発注書〕→〔端子：発注完了〕

判断記号からは、条件によって出口が分かれます。「いいえ（承認しない）」なら、申請者に差し戻す線が伸びます。このとき、想定される評価結果は経路を表す線に近接して書くこととされているので（出典：JIS X 0121:1986 規格本文）、分岐の線のそばに「はい」「いいえ」と添えます。

図を描き始める前に、もう一つやっておくべきことがあります。使う記号とその意味を一覧にした凡例を、最初に決めておくことです。凡例があれば、読み手は記号の解釈で迷いません。

つまずきやすいのは2つ。1つは、記号の使い分けが曖昧で、何でも処理記号にしてしまうこと。申請書は〔書類〕、承認可否は〔判断〕、と意味で選び分けます。もう1つは、矢先を省いて逆流が読めなくなること。差し戻しや例外の線こそ、矢先を忘れないようにしましょう。

この章の確認（演習）

第1章で選んだ業務を、端子・処理・判断・書類の4記号だけを使って、左から右・上から下に1本の流れで描いてみてください。開始と終了は必ず〔端子〕で挟み、条件で分かれるところは〔判断〕にして、分岐の線のそばに「はい／いいえ」を書き添えます。最初に凡例（使った記号の意味）を1行ずつ書いておくと、後で読み返しやすくなります。

担当ごとに分けて描く——受け渡しと分岐を見える化

1本フローだけでは「誰がやるか」が見えない

第2章で描いた1本の流れには、実は大事な情報が抜けています。「どの工程を、誰がやるのか」です。JIS X 0121 は処理手順やアルゴリズムを表すのに向く一方、担当者・部門・顧客との受け渡しまで表したい場合は、BPMN やスイムレーン型の業務フローチャートのほうが適しています（出典：業務可視化ノート）。備品購入業務のように複数人が関わり、「ここで仕事を渡す」ポイントがある業務では、担当の見える化が効いてきます。

担当ごとにレーンを分けると受け渡しが一目で分かる

そこで使うのが、スイムレーン（プールとレーン）です。プールはプロセスの主要な参加者を表し、プール内のスイムレーンは特定の役割・参加者のアクティビティとフローを示して、「プロセスのどの部分に誰が責任を負うか」を定義します（出典：Lucidchart「BPMN」）。横帯を担当ごとに分けて、各工程をその担当のレーンに置けば、誰が何をやり、どこで仕事を引き渡すのかが一目で分かります（出典：業務可視化ノート）。

備品購入フローを、3つのレーンに分けて描き直してみましょう。

• 申請者レーン：〔端子：申請開始〕→〔処理：申請書に記入〕→〔書類：申請書〕→（上長レーンへ受け渡し）
• 上長レーン：〔判断：承認するか〕→（はい／購買レーンへ）／（いいえ／申請者レーンへ差し戻し）
• 購買担当レーン：〔処理：発注〕→〔書類：発注書〕→〔端子：発注完了〕

レーン間を渡る矢印が「受け渡し」です。この受け渡しの線こそ、後でムダを探すときの重要な手がかりになります。担当の境界を越えるところ（＝仕事が人から人へ渡るところ）は、待ちや行き違いが生まれやすい場所だからです。

判断の分岐と、差し戻し・例外の線を描く

判断記号からは複数の出口が出ます。第2章で触れたとおり、想定される評価結果は経路の線の近くに書きます（出典：JIS X 0121:1986 規格本文）。備品購入なら、「承認する（はい）」は購買レーンへ、「承認しない（いいえ）」は申請者レーンへ差し戻し、という2本の線に、それぞれ条件を添えます。金額が一定額を超えたら別の承認者へ回す、といった追加分岐がある場合も同様に書き足します（金額の閾値は各社のルールで変わるため、ここでは「（例）一定額を超えたら」とだけ示します）。

つまずきやすいのは、レーンを分けずに「誰が」を省いてしまうこと、そして分岐条件を線の近くに書かず、後から図を見ても「この分岐は何で分かれるんだっけ」と読めなくなることです。受け渡しと分岐条件は、面倒でも図の上に明記します。

なお、ここで描いた業務フロー図を、今度は文章の手順書（SOP）に落とし込みたくなったら、業務手順書(SOP)の書き方が次のステップの正本です。本講座はフロー図までを射程とします。

この章の確認（演習）

第2章で描いた1本フローに、担当のレーンを2〜3本引いてみてください。各工程を担当のレーンに置き直し、レーンの境界を越える「受け渡し」の矢印を引きます。そのうえで、承認NGのときの差し戻しなど、分岐を1つ以上描き込み、それぞれの分岐の線のそばに条件（はい／いいえ、など）を書き添えましょう。

フロー図でムダを特定する——ECRS で工程を問い直す

可視化の目的は「ムダを見つける」こと

ここまでで、備品購入業務が1枚のフロー図になりました。いよいよ本題です。可視化の目的は、きれいな図をつくることではなく、ムダを見つけること。処理の手順をフロー図で図式化すれば、流れの誤りやムダを簡単に見つけ出せる（出典：日本電気技術者協会）——この「見つけやすさ」を活かします。

図を眺めると、いくつかのサインが目に入ります。判断が多く分岐が複雑に枝分かれしている、同じような処理が別のレーンにも現れている（重複）、差し戻しで前の工程へ戻る線がループになっている（手戻り）、レーンの境界（受け渡し）の前後で流れが滞っている（待ち）。これらは、図にしたからこそ指差せるムダの候補です。ただし「感覚でムダっぽい」で終わらせず、次の型で問い直します。

ECRS——排除→結合→交換→簡素化の順で問い直す

ムダを問い直す型が ECRS（イクルス）です。Eliminate（排除）・Combine（結合と分離）・Rearrange（入替えと代替＝交換）・Simplify（簡素化）の頭文字で、業務改善を実施する上での順番と視点を示します（出典：JMAC 用語集「ECRS（改善の4原則）」）。もともとは生産管理・製造の現場で浸透したフレームワークで、いまは多様な業種・部門で使われています（出典：Asana「ECRSとは」）。

大事なのは、この4つを順番に問うことです。

• Eliminate（排除）：その工程をそもそも無くせないか。業務の成果物や作業レベルを無くせれば、コストも手間もかからず実行も速く、最初に検討すべき最も効果の大きい視点です（出典：JMAC）。
• Combine（結合と分離）：似た工程をまとめられないか、逆に分けたほうがよくないか。類似業務を結合すると手間が減り、投入コストも少なく実施が容易です（出典：JMAC）。
• Rearrange（交換）：作業の順序・場所・担当を入れ替えられないか。順序を変えるだけで効率が上がる場合があります（出典：JMAC）。
• Simplify（簡素化）：残った工程をよりシンプルにできないか。業務実態を分析し、あるべき姿を設計・導入します（出典：JMAC）。

なぜこの順番かというと、改善効果は排除が最も大きく、簡素化に向かうほど小さくなるため、この順で進めると少ない手間で大きな成果を得やすいからです（出典：Asana）。いきなり簡素化（ツール導入）から入りたくなりますが、不要な業務を効率化しても意味は薄い。まず「無くせないか」を問うのが鉄則です。

備品購入フローに ECRS を当てて特定する

備品購入フローに当ててみましょう。上長の承認と購買担当のチェックで似た確認を二重にしているなら、Combine（結合）でまとめられないかを問います。承認NGでの差し戻しが何度もループしているなら、そもそも申請様式が不十分で手戻りを生んでいないか、Eliminate（排除）や Simplify（簡素化）で差し戻しの原因を減らせないかを問います。承認待ちで発注が滞っているなら、Rearrange（交換）で承認と見積取得の順序を入れ替えられないかを問います。

特定したムダは、図のその工程に印を付け、「ここは受け渡しの前で待ちが発生している」「ここは前の工程と重複している」と、図を根拠に指し示します。感覚ではなく図の上の位置で語れることが、可視化の成果です。ここから先、特定したムダを起点に「あるべき標準の型」を決めて全社へ展開していく計画づくりは、業務標準化の進め方が正本です。本講座は「描いて→ムダを特定する」までを見届けます。

この章の確認（演習）

第3章で仕上げたフロー図を見ながら、ECRS の4つの視点から、それぞれ1つずつ工程を挙げてください。「無くせる（排除）」「まとめられる（結合）」「入れ替えられる（交換）」「簡単にできる（簡素化）」に当てはまりそうな工程を、図のどこかを指しながら根拠とともに説明します。排除から順に問うことを忘れずに。1つでも「ここは無くせるかもしれない」と言えたら、可視化がムダ特定につながった証拠です。