「業務フローを可視化しろと言われたが、何から手をつければいいかわからない」——DX推進の現場で、最初にぶつかる壁がこれです。
業務改善の第一歩は 現状（As-Is）を正確に描き、あるべき姿（To-Be）との差分を見える化すること です。しかし、記号の選び方や粒度の決め方を間違えると、せっかく作ったフロー図が「誰も読まない資料」になりかねません。
本記事では、As-Is/To-Beフロー図の書き方を基本記号の選び方から実務テンプレートまで体系的に解説します。ツール比較やフロー図からシステム化へ進む際の費用感もまとめていますので、DX推進担当の方はぜひ最後までご覧ください。
目次
- As-Is/To-Beフロー図とは？DX推進で不可欠な理由
- フロー図の基本記号と記法ルール
- As-Is（現状）フロー図の書き方 5ステップ
- To-Be（あるべき姿）フロー図の設計手法
- フロー図作成ツール比較と選定ポイント
- フロー図からシステム化へ：費用感と進め方
1. As-Is/To-Beフロー図とは？DX推進で不可欠な理由
As-Is/To-Beフロー図とは、業務プロセスの「現状（As-Is）」と「改善後の理想像（To-Be）」を図式化し、両者のギャップを明確にする手法です。
なぜフロー図が必要なのか
業務改善やDX推進プロジェクトが頓挫する原因の多くは、「現状認識のズレ」にあります。経営層・現場・IT部門がそれぞれ異なる業務イメージを持ったまま要件定義に入ると、開発後に「思っていたのと違う」という手戻りが発生します。
フロー図による可視化が解決するのは、以下の3つの課題です。
- 認識の統一：部門間で業務プロセスの共通理解をつくる
- ボトルネックの発見：手作業・重複作業・承認待ちなどの非効率を特定する
- 改善効果の定量化：As-IsとTo-Beの差分から、削減できる工数やコストを試算できる
As-Is/To-Be分析の全体像
分析は以下のフローで進めます。
- As-Is調査：現行業務のヒアリング・観察・ドキュメント収集
- As-Isフロー図作成：現状プロセスの可視化
- 課題抽出：ムダ・ムラ・ムリの洗い出し
- To-Be設計：改善後のプロセス設計
- ギャップ分析：As-Is→To-Beの移行に必要な施策を整理
- 実行計画策定：優先順位づけとロードマップ作成
経済産業省「DXレポート2.1」では、DX推進においてまず「業務プロセスの可視化」を行うことが推奨されています（出典：経済産業省「DXレポート2.1」2021年）。フロー図作成はDXの土台づくりそのものです。
章末サマリー：As-Is/To-Beフロー図は、業務改善・DX推進の「共通言語」。現状を正確に可視化し、理想像とのギャップを明確にすることで、手戻りのないプロジェクト推進が可能になります。
2. フロー図の基本記号と記法ルール
フロー図を描く前に、記号の意味と使い分けルールを押さえておきましょう。ここを曖昧にすると、読み手によって解釈が分かれる図になってしまいます。
基本フローチャート記号
| 記号 | 名称 | 用途 | 使用例 |
|---|---|---|---|
| 角丸長方形 | 開始/終了 | プロセスの開始点と終了点 | 「受注開始」「処理完了」 |
| 長方形 | 処理 | 具体的な作業・処理ステップ | 「見積書作成」「在庫確認」 |
| ひし形 | 判断/分岐 | Yes/Noの条件分岐 | 「在庫あり？」「承認済み？」 |
| 平行四辺形 | データ入出力 | データの入力・出力・帳票 | 「注文データ入力」「請求書出力」 |
| 矢印 | フロー | 処理の流れ・順序 | 各記号間の接続 |
BPMN記法を採用すべきケース
業務プロセスを詳細に記述する場合は、BPMN（Business Process Model and Notation）の採用を推奨します。BPMNはISO 19510として国際標準化されており、以下のメリットがあります。
- 部門横断のプロセスを「スイムレーン」で表現できる
- イベント（トリガー）を明示でき、業務の開始条件が明確になる
- システム連携部分をサービスタスクとして区別でき、開発要件に直結する
一方、社内の小規模な改善であれば、基本フローチャートで十分です。目的に応じて記法を選びましょう。
粒度の決め方：3つのレベル
| レベル | 粒度 | 用途 | 記述量の目安 |
|---|---|---|---|
| L1：概要フロー | 部門間の業務の流れ | 経営層への報告・全体俯瞰 | 1枚に10〜15ステップ |
| L2：業務フロー | 担当者レベルの作業手順 | 業務改善の分析・要件定義 | 1枚に15〜30ステップ |
| L3：詳細フロー | システム操作レベルの手順 | 画面設計・テスト仕様 | 1枚に30ステップ以上 |
章末サマリー：基本記号は5種類を押さえれば十分。粒度はL2（担当者レベル）から始め、部門横断プロセスにはBPMN記法の採用を検討しましょう。
3. As-Is（現状）フロー図の書き方 5ステップ
As-Isフロー図は「現実を正確に映す鏡」です。理想を混ぜず、ありのままを描くことが最も重要なポイントです。
ステップ1：対象業務のスコープを決める
最初にやるべきは、対象業務の「始まり」と「終わり」を明確にすることです。
悪い例：「受注業務をフロー図にする」（範囲が曖昧） 良い例：「顧客からの注文メール受信〜出荷指示書の発行まで」（始点と終点が明確）
スコープが広すぎると作成に時間がかかりすぎ、狭すぎると改善ポイントが見えません。1つのフロー図で扱う範囲は「1つの業務目的が達成されるまで」を基準にしましょう。
ステップ2：関係者ヒアリング
現場の担当者に業務手順をヒアリングします。ポイントは以下の3つです。
- 複数人にヒアリングする：同じ業務でも担当者によって手順が異なる場合がある（これ自体が課題）
- 例外処理も聞く：「通常はこうだが、○○の場合は△△する」という分岐を漏らさない
- 実際の画面・帳票を見せてもらう：口頭説明だけでは抜け漏れが生じる
ステップ3：ラフスケッチ（手書きでOK）
ヒアリング内容をもとに、まず手書きやホワイトボードでラフに描きます。この段階では記号の正確さにこだわる必要はありません。
ラフスケッチのコツ：
- 付箋を使い、1ステップ=1枚で並べ替えられるようにする
- 分岐点（判断）を明確にマークする
- 「誰が」「何を使って」行うかをメモしておく
ステップ4：清書とレビュー
ラフスケッチをツール（後述）で清書し、関係者にレビューしてもらいます。
レビューで確認すべき項目は以下の通りです。
- 漏れ：「この作業が抜けている」がないか
- 順序：「実際にはAの前にBをやっている」がないか
- 担当者：「この作業は別の人がやっている」がないか
- 所要時間：各ステップにおおよその所要時間を付記する（To-Beとの比較に使う）
ステップ5：課題の可視化
完成したAs-Isフロー図に、課題箇所をマークします。
| マーク | 意味 | 改善の方向性 |
|---|---|---|
| 赤マーク | ボトルネック（待ち時間・滞留） | 自動化・並列化 |
| 黄マーク | 手作業・属人化 | システム化・マニュアル整備 |
| 青マーク | 重複作業 | 統合・削除 |
章末サマリー：As-Isフロー図は「スコープ定義→ヒアリング→ラフスケッチ→清書レビュー→課題可視化」の5ステップで作成。現実をありのまま描くことが最重要です。
4. To-Be（あるべき姿）フロー図の設計手法
As-Isで洗い出した課題をもとに、To-Beフロー図を設計します。ここが業務改善・DX推進の「腕の見せどころ」です。
改善パターン4分類
課題に応じて、以下の改善パターンを適用します。
| パターン | 内容 | 具体例 | 期待効果 |
|---|---|---|---|
| 排除（Eliminate） | 不要な作業を削除 | 形骸化した二重チェックの廃止 | 工数削減 |
| 統合（Combine） | 複数作業を1つにまとめる | 別々の入力画面を統合 | 時間短縮・ミス削減 |
| 順序変更（Rearrange） | 作業順序を最適化 | 承認を後工程から前工程へ移動 | 手戻り削減 |
| 自動化（Automate） | システム化・RPA・AI活用 | 手入力→OCR+自動データ連携 | 大幅な工数削減 |
To-Beフロー図の設計ポイント
1. As-Isと同じ粒度で描く As-IsがL2レベルならTo-BeもL2で。粒度を揃えないと正確な比較ができません。
2. 定量的な改善目標を付記する 各改善ポイントに「現状：月40時間 → 目標：月10時間」のように数値目標を記載します。これが後のROI算出の根拠になります。
3. 段階的な移行を想定する 一気にTo-Beへ移行するのは現実的ではありません。「Phase 1：紙帳票のデジタル化」「Phase 2：承認ワークフロー自動化」「Phase 3：AIによる判断支援」のように段階を設計します。
As-Is/To-Be比較テンプレート
以下の比較表をフロー図と合わせて作成すると、改善効果が一目でわかります。
| 業務ステップ | As-Is（現状） | To-Be（改善後） | 改善内容 | 削減効果 |
|---|---|---|---|---|
| 受注データ入力 | メールからExcelに手入力（30分/件） | 受注フォーム→DB自動連携（5分/件） | 自動化 | 月20時間削減 |
| 在庫確認 | 倉庫に電話確認（10分/件） | 在庫管理システムで即時確認（1分/件） | システム化 | 月8時間削減 |
| 見積承認 | 紙の稟議書で回覧（平均2日） | ワークフローシステムで承認（平均2時間） | デジタル化 | リードタイム短縮 |
章末サマリー：To-Be設計は「排除・統合・順序変更・自動化」の4パターンで課題を分類。As-Isと同じ粒度で描き、定量目標を付記することで、ROI算出と段階的移行の計画につなげましょう。
＼ 業務フロー可視化、何から始めればいい？ ／
As-Is/To-Beフロー図の作成から改善施策の優先順位づけまで、DX推進のプロが壁打ち相手になります。
※ 営業電話はしません ｜ オンライン対応可 ｜ 相談だけでもOK
5. フロー図作成ツール比較と選定ポイント
フロー図作成ツールは無料から有料まで数多くありますが、業務用途では「チーム共有」「バージョン管理」「BPMN対応」の3点が選定基準になります。
主要ツール比較表
| ツール | 費用 | BPMN対応 | 共同編集 | 特徴 |
|---|---|---|---|---|
| Lucidchart | 月額約1,000〜2,000円/人 | ○ | ○ | 直感的UI、テンプレート豊富 |
| Miro | 月額約1,000〜2,000円/人 | △（プラグイン） | ○ | ホワイトボード型、ワークショップ向き |
| draw.io（diagrams.net） | 無料 | ○ | ○（Google Drive連携） | 無料でBPMN対応、中小企業に最適 |
| Microsoft Visio | 月額約600〜1,200円/人 | ○ | ○（Microsoft 365連携） | Office環境との親和性が高い |
| Cacoo | 月額約600〜1,800円/人 | ○ | ○ | 国産ツール、日本語サポート充実 |
選定フローチャート
以下の基準で選ぶと失敗しません。
- 予算がない → draw.io（無料、十分な機能）
- Microsoft 365を導入済み → Visio（追加コスト小、環境統一）
- 複数部門でワークショップ形式で使いたい → Miro（リアルタイム共同編集が強い）
- 本格的なBPMN図を継続的に管理したい → Lucidchart（バージョン管理・権限管理が充実）
ツール選定の落とし穴
よくある失敗は「ツールにこだわりすぎて、肝心のフロー図作成が進まない」ことです。まずはdraw.ioやPowerPointで素早くプロトタイプを作り、運用が定着してから有料ツールへ移行する段階的アプローチがおすすめです。
章末サマリー：無料ならdraw.io、Office環境ならVisio、チームワークショップならMiro。ツール選定に時間をかけすぎず、まず描き始めることが最優先です。
6. フロー図からシステム化へ：費用感と進め方
As-Is/To-Beフロー図が完成したら、次はTo-Beを実現するためのシステム化です。ここでは費用感と進め方を解説します。
業務フロー可視化→システム化の費用目安
| 段階 | 内容 | 費用目安 |
|---|---|---|
| フロー図作成支援 | 外部コンサルによるAs-Is/To-Be作成 | 50万〜150万円 |
| 要件定義 | To-Beフロー図をもとにした機能要件整理 | 100万〜300万円 |
| システム開発（小規模） | 受発注管理・ワークフロー等の単機能 | 300万〜800万円 |
| システム開発（中規模） | 複数業務を統合した基幹システム | 800万〜2,000万円 |
| 保守・運用（年間） | 障害対応・機能追加・サーバー費用 | 開発費の15〜20%/年 |
中小企業のシステム開発費用の詳細は「中小企業のシステム開発費用ガイド」をご参照ください。また、Excelベースの業務を受発注システムに移行する具体的な手順は「Excel→受発注システム移行ステップ」で解説しています。
コストを抑える3つのアプローチ
1. 段階的開発（フェーズ分け） 一括開発ではなく、効果の大きい業務から順にシステム化。初期投資を抑えつつ、早期にROIを実感できます。
2. ノーコード・ローコードの活用 定型的なワークフロー承認やデータ入力画面は、kintoneやPower Appsで構築可能。開発費を3〜5割削減できるケースもあります。
3. 既存SaaSとの組み合わせ すべてをスクラッチ開発する必要はありません。SaaS＋カスタム開発のハイブリッド構成で、コストと柔軟性を両立します。
製造業での受発注システム構築の費用詳細は「製造業の受発注システム費用（2026年版）」でまとめています。
開発パートナー選定のポイント
業務フロー可視化の段階から開発パートナーに相談すると、To-Be設計の段階で技術的な実現可能性を確認でき、手戻りを防げます。以下のチェックリストを参考にしてください。
- 業務ヒアリングから参画してくれるか（コード書きだけの会社は避ける）
- 類似業務のシステム化実績があるか → GXOの開発事例はこちら
- 要件定義フェーズだけでも依頼できるか
- 保守・運用体制が明確か
GXO株式会社では、業務フロー可視化からシステム開発・保守運用まで一貫して対応しています。会社概要はこちらをご覧ください。
章末サマリー：フロー図からシステム化へ進む際の費用は、小規模で300万〜800万円、中規模で800万〜2,000万円が目安。段階的開発・ノーコード活用・SaaS併用でコスト最適化を図りましょう。
まとめ
As-Is/To-Beフロー図は、業務改善・DX推進のすべての起点になるドキュメントです。
本記事のポイントを整理します。
- As-Is/To-Beフロー図はDX推進の「共通言語」。関係者間の認識統一と課題の定量化に不可欠
- 基本記号は5種類で十分。部門横断プロセスにはBPMN記法を検討
- As-Is作成は5ステップ：スコープ定義→ヒアリング→ラフスケッチ→清書レビュー→課題可視化
- To-Be設計は4パターン：排除・統合・順序変更・自動化で分類し、定量目標を付記
- ツールはdraw.io（無料）から始めてOK。まず描くことが最優先
- システム化の費用は小規模300万〜800万円。段階的開発でリスクとコストを抑制
フロー図を描いて終わりではなく、To-Beの実現まで見据えた計画を立てることが成功の鍵です。
＼ フロー図作成→システム化まで、まるごと相談できます ／
GXO株式会社は、業務ヒアリング・As-Is/To-Be可視化・要件定義・システム開発をワンストップで支援します。
「まずはフロー図の壁打ちだけしたい」という段階からお気軽にご相談ください。
→ 無料で見積シミュレーションを試す → 30分のDX無料相談を予約する
※ 営業電話はしません ｜ オンライン対応可 ｜ 相談だけでもOK
よくある質問（FAQ）
Q1. As-Is/To-Beフロー図の作成にどのくらい時間がかかりますか？
対象業務の規模によりますが、1つの業務プロセスであれば、ヒアリングからAs-Is完成まで1〜2週間、To-Be設計まで含めると2〜4週間が目安です。外部コンサルに依頼する場合は、業務理解のためのヒアリング期間を含めて1〜2か月程度を見込んでおくとよいでしょう。
Q2. フロー図作成は社内でやるべきですか、外部に依頼すべきですか？
理想は「社内主導＋外部ファシリテーション」です。業務知識は社内にありますが、客観的な視点やフロー図作成のノウハウは外部の方が豊富です。初回は外部の支援を受けながら作成し、2回目以降は社内で回せる体制を目指すのがコストパフォーマンスの高い進め方です。
Q3. ExcelやPowerPointでフロー図を作っても問題ありませんか？
初期段階ではまったく問題ありません。むしろ、ツール選定に時間をかけるよりも、手元のツールで素早く描き始める方が重要です。ただし、継続的に更新・共有する場合は、バージョン管理や共同編集が可能な専用ツール（draw.ioなど）への移行をおすすめします。
Q4. フロー図からシステム化する際、最初に手をつけるべき業務は？
「作業頻度が高く、手順が定型化されている業務」から着手するのが鉄則です。たとえば、日次で発生する受発注データの入力や、月次で繰り返す請求処理などが典型例です。成功体験を早期に得ることで、社内のDX推進への理解と協力を得やすくなります。
Q5. As-Isフロー図を作ったら、現状の問題点が山ほど出てきました。どう優先順位をつければよいですか？
「影響度（業務への影響の大きさ）× 改善難易度（コスト・時間・技術的ハードル）」の2軸マトリクスで整理しましょう。影響度が高く改善難易度が低い課題（=クイックウィン）から着手するのが定石です。GXOでは無料のDX診断でこの優先順位づけもサポートしています。
参考資料
- 経済産業省「DXレポート2.1（DXレポート2 追補版）」（2021年）
- 経済産業省「デジタルガバナンス・コード2.0」（2022年）
- ISO 19510:2013「Information technology — Object Management Group Business Process Model and Notation」
- 総務省「令和5年版 情報通信白書」
- IPA「DX実践手引書 ITシステム構築編」（2023年）