基幹システム・ERPの導入前に現状業務(As-Is)を整理するとき、関係者ごとに「誰が何をしているか」の認識がずれていると、課題や必要な確認事項も定まりません。業務フロー図は、処理の順序、担当、判断、主要な引き渡しを同じ見取り図で確認するための資料です。
最初から全社業務を描く必要はありません。優先度の高い1業務を選び、関係者が事実を確認できる形にすることから始めます。1業務のAs-Isを図にし、課題候補・データ確認事項・要件確認事項を分けて次工程へ渡せるようになります。

業務フロー図は現状の事実を確認する見取り図です。課題候補、要件確認事項、将来案は図と分けて管理します。
01Section業務フロー図で整理すること、整理しないこと
業務フロー図の役割は、開始から終了までの「順序」「担当」「判断」「主要な入出力・引き渡し」を追えるようにすることです。業務プロセスを文書化する際に、開始・終了、担当、判断、前に進むタスクを明確にし、関係者と確認・承認する考え方は、英国教育省の業務プロセス表記標準でも示されています。
一方で、画面操作の細部や改善案までを図に詰め込むと、現状を確認するための図として読みにくくなります。資料ごとの役割をあらかじめ分けておくと、どこに何を記録するかで迷いにくくなります。
| 資料 | 主な役割・記載内容 | 別資料で扱う内容 |
|---|---|---|
| 業務フロー図 | 処理順、担当、判断、主要な引き渡し、主要例外 | 詳細操作、課題の優先度、将来案 |
| 業務手順書 | 画面操作、入力項目、注意点 | 部門横断の全体経路 |
| 業務一覧 | 業務名、担当、頻度、概要 | 個別の判断・例外・復帰先 |
| データ整理表 | 正本・参照元、更新担当、連携、差異対応 | すべての処理順 |
| 課題一覧 | 現象、影響、頻度、優先度、確認責任者 | 現状フローの事実そのもの |
| 要件確認事項一覧 | 機能、連携、権限、保存、期限などの確認事項 | 未合意の将来像を現状として書くこと |
最初に描く1業務を選ぶ
初回のAs-Is整理では、全社業務を一度に対象にせず、次の観点で優先度が高い1業務を選びます。
- 導入対象の候補になっている
- 複数部門・複数担当者をまたぐ
- 手入力、転記、承認待ちが多い
- 例外や差し戻しが頻繁に起きる
- 停止や誤りが受注・出荷・請求などに影響する
業務フロー図は業務棚卸しの一部です。対象部門、帳票、データ、権限などの確認観点は、基幹システム導入前の社内チェックリストも併せて確認すると、導入準備全体とのつながりを整理しやすくなります。
対象範囲を一文で定義する
描き始める前に、開始条件・終了条件・対象外を含む一文を作ります。対象外を明記することで、「今回はどこまで確認済みか」が関係者間でそろいます。
[開始条件]から[終了条件]までを対象に、[部門・役割]が行う[主要な処理・判断]、[利用システム・帳票]、[主要例外]を確認し、[対象外]は含めない。たとえば受注業務なら、次のように置けます。
注文受領から請求データ確定までを対象に、営業・受注管理・出荷・経理が行う受注確認、在庫確認、出荷、請求処理、主要なデータ受け渡しと在庫不足時の顧客確認を確認し、入金消込とマスタ保守は含めない。この一文は、図の基本情報欄、レビュー依頼、承認記録で共通して使います。
02Section最小記法を決める:記号・実線・破線の使い分け

初回のAs-Is整理では、記号を増やすよりも、作業順とデータ送受信を区別する最小ルールをそろえることが重要です。
フロー図の記号には複数の体系があります。ISO 5807(対応する国内規格はJIS X 0121)は、データ・プログラム・システムのフローチャートに用いる記号と利用慣行を扱っています。ただし、初回のAs-Is整理で多くの記号を覚える必要はありません。ここでは、関係者が意味を共有するための実務上の最小ルールを示します。社内標準がある場合はそちらを優先し、この表との対応を凡例で示してください。
| 要素 | 図上の表し方 | 書く内容・例 | 運用ルール |
|---|---|---|---|
| 開始・終了 | 角丸長方形または楕円 | 注文を受領、請求データを確定 | 作業名ではなく、始まる・終わる状態を書く |
| 処理 | 長方形 | 注文内容を確認する | 「対象+動詞」で簡潔に書く |
| 判断 | ひし形 | 在庫を確保可能か? | 質問文にし、すべての出口に条件を付ける |
| 文書・データ | 文書形状、平行四辺形、注記 | 注文書、受注データ | 入力・出力、または渡す情報を表す |
| システム注記 | 処理箱内または近接した注記 | [販売管理] | 部門レーンに混在させず、利用・参照先として書く |
| 実線矢印 | 実線 | 処理順、出荷を依頼 | 次の作業を開始・依頼する流れに使う |
| 破線矢印 | 破線 | 受注データ、出荷実績 | データ送受信、CSV授受、メール添付、連携に使う |
| 例外復帰 | 条件付き矢印 | 内容変更あり→[2]へ戻る | 確認主体、復帰条件、戻り先の処理番号を書く |
実線は作業順、破線はデータ送受信
実線と破線を混ぜると、責任の引き渡しに問題があるのか、データ連携に問題があるのかを区別しにくくなります。実線は「誰が次に何をするか」、破線は「どのデータ・帳票がどこへ渡るか」に限定します。
たとえば、受注管理から出荷へ進む実線に書くのは出荷を依頼です。受注データのようなデータ名は、破線、文書・データ記号、または処理箱の入力:・出力:注記に置きます。データ名を実線上に置かないと決めるだけでも、作業と情報の流れを分けて確認できます。
活動の順序を示す要素とデータ・注記を示す要素を分けて扱う考え方は、OMGのSequence Flow Rulesにも見られます。ここでの線種ルールはBPMN準拠を示すものではなく、現状整理での誤読を避けるための簡易な運用です。
判断と例外は「戻り先」まで書く
判断は在庫を確保可能か?のような質問にし、出口にははい・いいえまたは具体的な業務条件を付けます。例外は注記だけで終わらせず、次の4点をそろえます。
- 誰が確認するか
- 何を確認するか
- どの条件なら通常フローへ戻るか
- どの処理番号へ戻るか
戻り先が複数ある場合は、選択肢を並記せず条件ごとに分けます。たとえば「受注内容を変更するなら受注登録へ戻る」「受注内容は変えず在庫確認だけを再実施するなら在庫確認へ戻る」と書けば、再処理の経路を一意に追えます。
03Sectionスイムレーンの基準と作図の進め方

正常系を先に置き、判断・データ・主要例外を追加してから実務担当者とレビューします。確認後は現状の事実と次の検討事項を分けて管理します。
スイムレーンは、誰がどの処理を担うか、どこで引き渡しが起きるかを見えるようにする表現です。Laneを役割や組織機能に関連する活動の整理に使う基本概念は、OMGのBPMN入門資料でも確認できます。
レーンは一つの基準に統一する
レーンは、部門・役割・システムのいずれか一つを基準にします。同じ階層に営業部、承認者、販売管理システムを並べると、責任分担とシステム境界が混在します。
初回のAs-Is整理では、部門または役割をレーンにし、システム名は処理箱の注記やデータ整理表に置く方法が扱いやすいでしょう。システム連携や二重入力そのものが主な確認対象なら、システム基準の補助図を別に作る方法もあります。
作成者・事実確認者・承認者を分ける
作成者はヒアリング内容を構造化して図のたたき台を作り、事実確認者は各レーンの実務担当者として作業・例外・データ授受を確認します。承認者は、業務責任者または組織で定められた責任者として、対象範囲、主要な現状事実、未確定事項の扱いを確認します。
同じ人が複数の役割を担う場合でも、確認した事実と承認した範囲は記録上で分けます。技術選定前から業務の範囲を整理する参考としては、Microsoft Learnの業務プロセス最適化ガイドも参照できます。
1業務のAs-Isをスイムレーン図にする手順
- Step01
1. 目的と対象範囲を決める
主担当:整理担当または業務責任者。開始条件、終了条件、対象外、レーン基準を一文で定義し、関係部門責任者と対象業務を固定する。
- Step02
2. 既存資料と実務の情報を集める
主担当:整理担当。帳票、一覧、手順書、メール・表計算ファイルの利用を確認し、各レーンの実務担当者と未確認事項を棚卸しシートに残す。
- Step03
3. 正常系を棚卸しして配置する
主担当:整理担当。通常経路を時系列に並べ、部門または役割のレーンに「対象+動詞」の処理箱を置く。担当、判断、主要な入力・出力を確認し、開始から終了まで追える状態にする。
- Step04
4. 判断・データ・主要例外を加える
主担当:整理担当。判断の出口条件、実線による引き渡し、破線または注記によるデータ送受信を追加する。例外は確認主体、復帰条件、戻り先の処理番号を記載する。
- Step05
5. レビューして確定し、別管理へ渡す
主担当:各レーンの実務担当者と整理担当。図にない紙、メール、口頭連絡、代替担当、例外を確認し、版数・確認日・未確定事項を記録する。現状事実は図に残し、課題候補・要件確認事項・将来案は別一覧で管理する。
計画は、対象範囲、関係部門数、例外、既存資料、利用システム、連携・移行論点、関係者のレビュー予定によって変わります。これらの条件を先に確認して計画します。
04Section粒度をそろえ、As-Isのデータ確認を補助資料で行う
As-Is図は、細かい操作説明ではなく、導入検討に必要な現状の構造を確認するための図です。処理の区切り方を統一し、図だけでは確認しにくいデータ論点を補助資料へ分けます。
処理箱を分ける粒度の判断フロー
処理の途中で、担当・判断・システム・データ引き渡し・承認・例外のいずれかが変わるか?
├─ はい:原則として処理箱を分ける
└─ いいえ:同一担当・同一画面・同一判断基準の連続操作なら、1つにまとめる
その詳細操作は教育・日常運用で必要か?
├─ はい:手順書へ分ける
└─ いいえ:As-Isフローでは中位粒度にとどめるたとえば、受注管理担当者が同じ画面で複数項目を確認する操作は、判断や引き渡しが変わらない限り受注内容を確認するという一つの処理箱にまとめられます。一方、販売管理へ登録する、在庫を判定する、出荷を依頼する、といった地点では担当・システム・判断が変わるため、処理を分けます。
業務プロセスの要素と、各工程で必要になる情報要件・情報フローを結び付けて検討する考え方は、NISTのプロセス仕様における情報要件資料でも扱われています。図の読みやすさを保つため、正本や連携条件までをすべて図上に置くのではなく、補助資料で確認します。
図に詰め込まない情報を分けて管理する
As-Isフロー図と別に管理する補助資料
データ整理表
データ・帳票の用途、正本または参照元、更新担当、更新・連携タイミング、未連携時の手作業、差異時の確認者を記録する。
課題一覧
現在起きている現象と影響を、関連工程、頻度・対象件数、依存関係、確認責任者とともに記録する。
要件確認事項一覧
将来の仕組みで何を満たす必要があるかを、機能、連携、権限、帳票、保存などの確認する問いとして記録する。
未確定事項一覧
事実確認が終わっていない点、確認責任者、確認条件を記録する。曖昧な注記のまま図に残さない。
As-Is、課題、要件、To-Beを混在させない
フロー図には「現状、受注情報を表計算ファイルと販売管理へ二重入力している」のような事実を置きます。その事実から考えられる「転記差異が起きる可能性がある」は課題候補です。「どのデータ源を基準に、どのタイミングで連携するか」は要件確認事項であり、「受注登録を起点に連携する」はTo-Be案です。
現状の事実と、課題・要件・改善案を同じ図に混在させないことが重要です。混在すると、未合意の改善案が現行運用であるように見えたり、現場レビューで何を確認すべきかが曖昧になったりします。
05Sectionテンプレートで棚卸しから図へ移す
作図を始める前に基本情報欄と棚卸しシートを作ると、ヒアリング内容をそのまま図形に移すよりも抜け漏れを見つけやすくなります。テンプレートは特定のソフトに依存しない構成で、専用の作図ソフトがなくても、ExcelやPowerPointの図形機能で基本情報欄・棚卸しシート・凡例を再現できます。また、フローの整理を通じてExcelによる在庫・販売管理が確認対象になった場合は、在庫管理をエクセルで行う方法や販売管理をエクセルで行う方法も現状把握の参考になります。
図の基本情報欄
業務名:
目的:
対象範囲:[開始条件]から[終了条件]まで
対象外:
レーン基準:部門/役割/システムのいずれか一つ
対象システム・帳票:
作成日・版数:
更新担当:
レビュー担当:
凡例:実線=処理順・作業上の引き渡し/破線=データ送受信レーンの向きと時系列の向きも最初に決めます。たとえば、横方向を時間の流れ、縦方向を部門にする、と決めれば、後から工程を追加しても読み方をそろえやすくなります。
8列の圧縮棚卸しシート
データの詳細を独立した表にするとしても、作図前の棚卸しでは、データ確認に必要な要点を同じ行で把握できるようにします。
| No. | 担当部門・役割 | 開始条件・入力 | 処理・判断者 | 出力・引き渡し先 | 利用システム・帳票 | 例外・復帰 | データ確認補足 |
|---|---|---|---|---|---|---|---|
| 1 | 正本・更新担当、更新・連携時点、手作業、差異時の確認者、未確定事項・確認責任者 | ||||||
| 2 | |||||||
| 3 |
処理・判断者には、処理名と判断を行う担当を記入します。出力・引き渡し先には、次工程を開始・依頼する行為を書きます。データ名はこの列の実線ラベルに置かず、入力欄、データ確認補足、または図上の破線・文書記号へ移します。
受注業務の最小サンプルと転記順

部門ごとの担当と通常経路を先に配置し、在庫不足や不備などの例外は、確認主体と戻り先が分かるように追加します。
次は、営業・受注管理・出荷・経理の部門レーンを使った説明用モデルです。実際の責任分担、データ正本、システム構成、連携方法は組織ごとに異なるため、必ず関係者に確認してください。
営業レーン
(開始) 注文を受領
→ [1] 注文内容を確認する
入力:注文書・顧客メール
├─ 不備あり → 顧客へ確認を依頼する
│ → 顧客回答を受領する → [1]へ戻る
└─ 不備なし → 受注管理へ受注登録を依頼する
受注管理レーン
[2] 受注を登録・更新する[販売管理]
→ [3] 在庫を確保可能か?[在庫管理を参照]
├─ はい → 出荷へ出荷を依頼する
└─ いいえ → 営業へ顧客確認を依頼する
営業レーン(在庫不足時)
[4] 顧客へ納期・数量を確認する
├─ 商品・数量・納期などの受注内容が変わる
│ → 受注管理の [2] 受注を登録・更新する へ戻る
└─ 受注内容は変わらず、在庫確認だけをやり直す
→ 受注管理の [3] 在庫を確保可能か? へ戻る
出荷レーン
[5] 出荷を手配する → [6] 出荷実績を登録する[出荷管理]
→ 経理へ請求作成を依頼する
経理レーン
[7] 請求データを作成する[会計]
→ (終了) 請求データを確定するこの例で破線を追加する場合は、[1] ⇢ 受注データ ⇢ [2]、[6] ⇢ 出荷実績 ⇢ [7]のように、データ名を破線上に置きます。データ送受信が主な論点ではない場合は、破線を増やさず、処理箱の入力・出力注記とデータ整理表で確認しても構いません。
棚卸しシートから図へ転記する順番は、次の5段階です。
- 基本情報欄に対象範囲、対象外、レーン基準、凡例、版数、更新担当を記入する。
- 棚卸し行を時系列に並べ、正常系だけを開始から終了まで確認する。
- 担当に応じてレーンを作り、
処理を処理箱、判断をひし形へ移し、出口条件を付ける。 - 次工程の開始・依頼を実線で結び、入力・出力・データ名は注記、文書・データ記号、または破線へ置く。
- 例外ごとに確認主体、復帰条件、戻り先の処理番号を追加し、未確定事項は別一覧へ移す。
06Section課題候補と要件確認事項を分けて次の検討へ渡す
As-Isフロー図は、導入する機能や製品を直接決める資料ではありません。現状の対象業務、責任分担、判断、情報の受け渡し、例外をそろえ、次の要件検討で何を確認すべきかを明らかにする土台です。
課題候補は現象と影響、要件確認事項は問いとして書く
課題候補には、「どの工程で何が起きているか」と「どのような影響があるか」を書きます。例として、受注内容を二重入力しているため、転記差異が発生する可能性があるのように記録します。
要件確認事項は、解決策ではなく確認する問いです。たとえば、受注情報をどのデータ源で管理し、どのシステムへいつ連携するかとします。これにより、「連携する」というTo-Be案を先に固定せず、正本、更新権限、連携時点、訂正時の扱いを関係者と確認できます。
優先順位は五つの観点で付ける
課題候補は、業務停止・誤請求・出荷遅延などの影響、発生頻度や対象件数、統制・法令・契約上の重要性、他業務・システム・データ移行との依存関係、確認責任者の五つの観点で確認します。
統制や保存、承認の扱いは業界・組織ごとに異なります。重要性は主管部門と社内規程で確認してください。As-Isが確定した後に要件検討や導入計画へ進む流れは、システム導入の進め方で確認できます。
要件検討へ渡す前の確認
- ✓
対象業務の目的、開始条件、終了条件、対象外が明記され、正常系を担当・処理・判断に沿って開始から終了まで追える。
- ✓
主要な例外、差し戻し、復帰地点、確認先と、主要な帳票・データ、利用システム、判断者が確認されている。
- ✓
データの正本・参照元、更新担当、更新・連携時点、手作業、差異時の確認者が確認済みまたは未確定事項として記録されている。
- ✓
As-Isの事実、課題候補、要件確認事項、To-Be案が別管理になっている。
- ✓
実務担当者と責任者が対象範囲・主要事実を確認し、未確定事項と課題には確認責任者・確認条件・優先度が記録されている。
未確定事項は解決済みとして扱わない。
07Sectionレビュー・更新管理で使えるAs-Isに仕上げる
フロー図は、各レーンの担当者が実際の作業をたどり、主要な事実と例外、残る不明点を確認して初めて要件検討に使える状態になります。
現場レビューでは「図にない仕事」を探す
各レーンの実務担当者に開始から終了まで図をたどってもらい、開始条件・担当・判断者、引き渡す帳票やデータ、不備や繁忙時の例外、連携失敗や入力差異の確認方法、図にないメール・紙・表計算ファイル・口頭連絡を確認します。
代替担当、手作業の転記、例外時の連絡は既存資料だけでは見つからないことがあります。確認した内容は、現状事実なら図または棚卸し表へ、課題なら課題一覧へ、将来確認が必要な点なら要件確認事項一覧へ分けます。
承認記録と更新契機を決める
承認記録には、対象業務、対象範囲、版数、確認日、確認者、承認者、未確定事項の扱いを残します。更新担当とレビュー担当も基本情報欄に記載します。
承認ルール・判断条件、帳票や入力項目、システム・連携・データ更新、部門や責任分担、例外運用に変更や問題が生じたときは、見直しを始める契機として定めておくとよいでしょう。
外部共有前に確認すること
現状調査や支援相談で資料を共有する場合は、個人情報、認証情報、単価、契約情報、社外秘の運用詳細を除外または匿名化できるか確認します。共有する対象範囲、未確定事項、期待する支援範囲も明記し、共有可否は自社の情報管理規程と相談先の条件に従ってください。
フロー図は、支援会社へ現状調査を相談する際にも、対象範囲と支援範囲の認識をそろえる資料になります。図に加えてデータ・帳票一覧、課題一覧、未確定事項を共有できれば、確認すべき前提を整理しやすくなります。対象範囲、関係部門、未確定事項、期待する支援範囲をそろえて共有することは、見積もりの前提をそろえ、見積もり精度を高めるための認識合わせに役立ちます。費用や導入期間は、連携、データ移行、権限、対象範囲、支援内容などでも変わるため、フロー図だけで判断せず個別に確認します。
業務フロー図の作成でよくある疑問
データ送受信を示す破線は、すべてのフロー図に必要ですか?+
必須ではありません。連携、CSV授受、メール添付、二重入力、データ正本が主な確認論点なら破線を使います。図が複雑になる場合は、処理箱の入力・出力注記とデータ整理表で補います。
例外処理が多く、1枚の図が読みにくい場合はどうしますか?+
正常系と例外系を分ける、または業務段階ごとに図を分けます。例外図でも、確認主体、復帰条件、戻り先の処理番号を明記し、正常系との接続を追えるようにします。
権限や承認条件は、フロー図と別に管理すべきですか?+
誰が判断・承認するかは図で示しますが、詳細な権限範囲、金額条件、証跡、保存要件は補助資料や要件確認事項一覧で扱う方法が実務的です。必要な管理方法は主管部門と社内規程で確認してください。
ERP導入に向けた現状業務の整理を相談する
業務フロー図、データ・帳票一覧、課題一覧、未確定事項をそろえると、対象範囲や支援範囲を相談しやすくなります。連携、データ移行、権限、対象部門などの条件も含めて、導入の進め方を確認しましょう。
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。




