---
title: "業務フローのシステム化とは？システム化業務フロー図の書き方と対象工程の選び方"
url: "https://www.issoh.co.jp/column/details/15783/"
published: 2026-07-27
updated: 2026-10-11
categories: ["受託開発・システム発注"]
publisher: "株式会社一創"
---

# 業務フローのシステム化とは？システム化業務フロー図の書き方と対象工程の選び方

業務フローのシステム化は、フロー図を描いた時点で終わる作業ではありません。現場の手順を書き起こし、どの工程をシステムに渡し、どの工程を人手に残すかを線引きするところまでが本体です。この記事では、IPA（情報処理推進機構）の定義に沿って業務フロー図・システム化業務フロー図・システムフロー図の違いを整理し、現行業務フローの書き起こし、対象工程の選び方、システム化業務フロー図の描き分け、要件定義への渡し方を発注側の作業として順に説明します。補助金の「プロセス」の読み違いにも触れます。

## まとめ：業務フローのシステム化で成果を分ける対象選定と図の描き分け

成果を分けるのは、フロー図の精緻さではなく対象工程の選び方です。例外の割合が高い工程を無理にシステムへ載せると、稼働後に「システムに入らない案件」が手作業の抜け道になり、二重運用が残ります。判断が人に依存する工程は、判断自体を人に残し、申請・資料提示・判断結果の記録をシステム化する範囲と分けてください。

進め方は、現行業務の整理、候補工程の絞り込み、システム化業務フロー図の作成、機能一覧・画面一覧への展開、実現手段の選定の5段階です。システム化業務フロー図はIPAの定義では「業務フローにおいてシステム化する部分を識別したもの」で、人の作業・システムの機能・人がシステムを使う作業を記号で区別し、システム化の内と外が一目で分かるように描きます。

費用面では、削減できる年間工数を金額に換算して回収年数で範囲を決めます。デジタル化・AI導入補助金2026の「4プロセス以上」は業務フローの工程数ではなく、導入するITツールが持つ機能の区分の数です。読み違えると範囲設計を誤ります。

## 業務フローのシステム化とは？業務フロー図・システムフロー図との違い

### IPAの定義にみるシステム化業務フローの位置づけ

業務フローのシステム化とは、部門をまたいで流れる一連の業務手順を図に書き起こし、そのうちシステムに任せる工程を機能へ置き換える取り組みです。「システム化業務フロー」という用語は、IPAが2010年3月31日に公開した[機能要件の合意形成ガイド ver.1.0 システム振舞い編](https://www.ipa.go.jp/archive/files/000004525.pdf)に定義があります。同ガイドは、システム化業務フローを「業務全体を俯瞰する業務フローにおいて、システム化する部分を識別したもの」と定め、役割を「業務全体において、システム化する範囲を明示的に表す」こと、複数部門が関わる場合に「相互の役割分担を明示的に表す」ことと書いています。

同ガイドは業務を3つに分けて呼び分けます。人手で行う「作業」、システムが自動で行う「機能」、人がシステムを使って行う「システム利用作業」（ユースケースと同義）です。機能とシステム利用作業をまとめて「システム化業務」と呼び、その範囲と作業の境界が分かる業務フローがシステム化業務フローです。要件定義で作った発注者視点の業務フローを土台にして、外部設計の段階でシステム化の範囲を発注者と開発者が合意するための図、という位置づけになります。

### 業務フロー図・システム化業務フロー図・システムフロー図の違い

| 図           | 描く対象         | 主な読み手        | 作る段階      |
| ----------- | ------------ | ------------ | --------- |
| 業務フロー図      | 人と部門の仕事の流れ   | 現場・発注側       | 現状分析・要件定義 |
| システム化業務フロー図 | 業務の中のシステム化範囲 | 発注側と開発側      | 要件定義〜外部設計 |
| システムフロー図    | データと処理・媒体の流れ | 開発側・情報システム部門 | 設計        |

業務フロー図は「誰が何をするか」を描き、システムが出てこなくても成立します。システムフロー図は、どのデータがどの処理を通ってどの媒体に出力されるかを描く図で、JIS X 0121が記号を定める図の1つ「システム流れ図」がこれにあたります。システム化業務フロー図はその中間にあり、業務の流れを保ったまま、どこからがシステムの仕事かを示します。発注側が責任を持って描くのは前の2つで、システムフロー図は開発側の成果物として受け取るのが通常の分担です。

### 業務効率化・ワークフロー電子化との範囲の違い

業務効率化は目的の側にある言葉で、システム化はその手段のひとつです。[業務効率化とは？意味と進め方・成果を出す手法をわかりやすく解説](/column/details/12821/)で扱うECRSのような改善手法は、システムを入れなくても成立します。まず手順そのものを削れないか検討し、削れない工程だけをシステム化の候補に残す。この順番を逆にすると、要らない作業を高い費用で自動化することになります。

ワークフローは、日本の実務では稟議・申請・承認の回付を指すことが多く、業務フロー全般より範囲が狭い言葉です。図の上で承認の関門を囲み、そこは既存のワークフロー製品、前後の見積管理や検収は業務システム側と色分けしておくと、見積もりの範囲が争点になりにくくなります。

## 現行業務フロー（As-Is）の書き起こし手順と記法の選び方

### 例外処理・差し戻し・手作業を漏らさないヒアリング手順

管理職には業務の目的と統制上のルールを確認し、実際の手順や例外は担当者への聞き取りと実案件の記録で確かめます。正常系の流れは短時間で描けますが、時間がかかるのは正常系から外れたときの分岐で、次の順に進めると抜けが減ります。

1. 担当者に直近1か月の実案件を3〜5件挙げてもらい、実際にどう流れたかを1件ずつ追う
2. 各工程で「この通りに進まなかったことは何回ありましたか」と回数で聞く
3. 差し戻しが起きる条件と、差し戻し後にどこへ戻るかを矢印で書き足す
4. システム外の作業（Excel集計、メール依頼、電話確認、紙への転記）を別の記号で示す
5. 担当者が代わると引き継げない判断（値引きの可否、納期調整）に印を付ける

回数を聞くのは、例外の多さを感覚ではなく数字で残すためです。「たまにあります」を「月3回」に置き換えておくと、次の対象選定の議論が短く終わります。IPAの[ユーザのための要件定義ガイド 第2版](https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf)も、業務フローの分岐ごとに発生頻度を確かめておくと「システム化対象に取り込むかどうかを決める際に役立つ」とし、担当部署は具体的な組織名ではなく役割（ロール）で書くよう勧めています。

### スイムレーン・BPMN・JIS X 0121・産能大式の使い分け

記法は「誰に読ませるか」で選びます。

| 記法         | 主な読み手     | 向く場面        | 注意点          |
| ---------- | --------- | ----------- | ------------ |
| スイムレーン     | 業務担当と発注側  | 部門をまたぐ受け渡し  | 分岐が増えると崩れる   |
| BPMN       | 開発者と業務分析者 | 自動化を前提にした設計 | 記号が多く習得が要る   |
| JIS X 0121 | 情報システム部門  | 処理と媒体の対応付け  | 組織間の受け渡しに弱い  |
| 産能大式       | 経理・管理部門   | 帳票と証憑の流れの追跡 | 作図ツールの選択肢が狭い |

現場確認用には役割別のレーンで描き、開発側と記号の意味を統一する必要がある場合にBPMNを選びます。BPMNにもレーンがあるため、最初から共通の記法で作成する方法もあります。BPMNはOMG（Object Management Group）が策定した表記法で、現行の[BPMN 2.0.2](https://www.omg.org/spec/BPMN/2.0.2/About-BPMN)は2014年1月に正式公開されました。ISO/IEC 19510:2013として国際規格になっているのは1つ前の2.0.1です。[JIS X 0121](https://webdesk.jsa.or.jp/books/W11M0090/?bunsyo%5Fid=JIS+X+0121%3A1986)は情報処理の文書化に使う流れ図記号の規格で、1970年に制定、1986年に改正され、2026年6月22日に内容変更なしで確認されています。既存の設計書がこの記法で残っているなら、そちらに合わせたほうが読み替えの手間が要りません。テキストで図を管理したいなら[マーメイド記法の書き方｜フローチャート・シーケンス図・ER図をテキスト管理する手順](/tech/details/17351/)も選択肢になります。

### プロセスマイニングに切り替える条件

工程間の分岐が多い、拠点が複数ある、部署ごとにやり方が違う。こうした場合は聞き取りで全体を捉えにくくなります。代わりに、システムのログから実際の流れを復元するのが[プロセスマイニングとは？仕組み・3つの分析とタスクマイニングとの違い、導入判断](/column/details/13375/)で扱う手法です。[MicrosoftのPower Automateの解説](https://learn.microsoft.com/en-us/power-automate/process-mining-processes-and-data)が示すとおり、案件ID・処理名・発生日時を対応付けたイベントログが必要です。担当者情報は追加属性であり、Excelの記録でも必要な履歴をそろえてCSVなどに整形できれば分析できます。導入判断では、ログの取得・統合にかかる費用と、分析によって得たい改善効果を比較します。聞き取りで把握できる範囲は手作業で整理し、必要な箇所に分析を絞ります。

## システム化する工程の選び方と人手に残す工程の条件

### 頻度・工数・例外率・判断介在度による候補工程の選定

書き起こした工程は、次の4軸で数値化して上位から候補に残します。

- 頻度：月間の発生件数
- 工数：1件あたりの所要時間（月間件数との積は月間工数。年間削減見込み時間は、1件あたりの削減時間×月間件数×12で算出）
- 例外率：手順どおりに進まなかった件数の割合
- 判断介在度：担当者の裁量で結果が変わる度合い（基準を文章化できるかで判定）

優先度が最も高いのは、頻度と工数の積が大きく、例外率と判断介在度が低い工程です。例えば月120件・1件15分の作業をすべて削減できると仮定すると、削減時間は月30時間・年360時間です。時間単価を3,000円と置けば、工数換算で年間108万円分になります。開発対象にするかは、この工数換算額に品質・統制面の効果も加え、導入費と運用費に照らして判断します。まず積で上位5工程を並べ、そこから例外率が高いものを落とす。この二段階で候補が決まります。

### システム化を見送り、手順書と人手に残す工程の3条件

次の条件に当てはまる工程は、システム化しないほうが結果的に安く済みます。

第一に、例外の種類と対応方法を整理できていない工程です。例外を発生頻度だけでなく種類ごとに数え、すべての分岐を実装しようとすると、開発費は正常系だけの場合より大きく膨らみます。手順書とチェックリストで運用し、例外の発生条件が安定してから改めて検討します。

第二に、判断基準を文章にできない工程です。「取引先との関係を見て納期を調整する」といった工程は、条件分岐として書き下せません。無理にルール化すると、現場が例外申請の抜け道を使い始め、システムの記録が実態と合わなくなります。

第三に、近いうちに業務そのものが変わる工程です。組織再編や制度改正が控えているなら、変更後の手順が固まってから着手します。見送った工程はフロー図に「対象外」と明記して残してください。消すと、次の検討時に同じ議論をやり直すことになります。

## システム化業務フロー図（To-Be）の書き方とIPAの作図指針

現行フローに機能名を書き足すだけでは、開発側が範囲を読み取れません。IPAのシステム振舞い編は、システム化業務フローの書き方のコツを02D201〜02D211の11項目にまとめており、そのうち発注側が描く段階で効くものを使います。

### 区画・記号・線種によるシステム化範囲の描き分け

同ガイドがシステム化業務フローの構成要素として挙げるのは、業務・作業・システム化業務・システム利用作業・機能・区画・開始点・終了点・業務データ・処理の流れ・データの流れ・条件分岐・並行分岐など14項目です。発注側で特に押さえたいのは次の4つのコツです。

- 各業務を部門などの役割ごとの区画（レーン）に置く（02D203）
- システム化する部分を専用の記号で描くか、システムを1本の区画にして境界で内と外を分ける（02D204・02D205）
- 処理の流れとデータの流れの矢印は線の種類を変える（02D206）
- 既存システムや別プロジェクトが担う部分は、開発対象外として破線など別の記号で描く（02D209）

実務では、担当部門のレーンの下に「システム」のレーンを1本足すやり方（02D205の形）が単純で確実です。人が画面から操作するシステム利用作業は担当者のレーンに専用の記号で置き、自動で動く機能はシステムのレーンに置きます。他システム本体のうち今回改修しない部分は開発対象外として描きます。連携処理は今回の開発対象かを別途明示し、矢印にデータの種類と発生タイミング（都度・日次・月次）を書き添えます。画面数と連携本数は概算見積もりの材料になります。金額を具体化するには、各機能の処理内容、非機能要件、移行・テスト範囲も詰める必要があります。

### システム化業務フロー図の階層化と説明文の付記

図が複雑になったら、接続子で紙を分けるのではなく業務を階層化します。同ガイドは、1印刷ページを1つの完結した業務として描き、密接に関連する業務を流れの途中で分断しないこと（02D208）を挙げています。粒度の目安は、機能一覧の中機能の単位でシステム化業務フローを1枚描き、小機能の単位は文章の「システム化業務説明」に回す、という対応づけです（02D501）。

図には説明文も付けます（02D210）。「(1)発注書作成：仕入れ担当が製品名・数量・発注先を入力する」のように、記号の番号ごとに1文を添えておくと、記法に慣れていない決裁者でも流れを読めます。

### 機能一覧・画面一覧・業務ルール一覧への展開手順

図の要素は、次の手順で要件定義の成果物の項目へ置き換えます。

1. システムのレーンに置いた機能を1行ずつ書き出し、機能一覧の機能名にする
2. 担当者レーンから伸びるシステム利用作業を、画面と操作の組に置き換えて画面一覧を作る
3. 画面間の遷移と条件は、業務フローの矢印から機械的に写さず別途設計する
4. 矢印に添えたデータの種類を、項目名・桁数・必須有無の一覧に展開する
5. 分岐の条件を業務ルール一覧として切り出し、判断者と根拠資料を併記する

システム利用作業ごとに、正常に終わる流れだけでなく、代わりの流れと例外の流れを書き出しておくと（同ガイドの02D303は基本・代替・例外の3種類のシナリオを考えるよう求めています）、稼働後に例外が溢れる失敗を前倒しで潰せます。業務の側の記載項目は[業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説](/column/details/16307/)、画面遷移図やER図の作り分けは[要件定義と設計で作る7つの図｜画面遷移図・ER図とデザイナーの担当範囲](/column/details/2860/)で扱っています。機能一覧と業務ルール一覧まで発注側で作れていれば、以降はベンダーと共同で詰められます。

## パッケージ・ノーコード・スクラッチ・RPAの選び分けと内製・外注の線引き

### フローの標準度と例外の多さで決める実現手段

標準的な手順に寄せられる業務ほどパッケージが効き、自社固有の商流が絡むほど個別開発の比重が上がります。

| 手段    | 向く条件            | 向かない条件             |
| ----- | --------------- | ------------------ |
| パッケージ | 標準手順に寄せられる      | 独自の商流が収益源          |
| ノーコード | 必要な連携と処理量が製品仕様内 | 処理量・実行時間が製品の上限を超える |
| スクラッチ | 競争力の源泉になる工程     | 汎用の管理業務            |
| RPA   | 既存画面を残す前提       | 画面変更が頻繁な業務         |

判定の順序は、まずパッケージで賄えるかを見て、賄えない部分だけを個別開発に回すのが費用面で有利です。標準機能で満たせない要件を洗い出し、必須要件への影響と、追加開発・連携・保守を含む総費用でパッケージ主体かスクラッチ主体かを判断します。既存画面を変えずに転記だけを減らしたいならRPAが候補ですが、連携先の画面変更で操作対象を識別できなくなると、設定の修正や再テストが必要になります（適用範囲は[RPAとは？仕組み・できること・主要ツールと導入判断をわかりやすく解説](/column/details/12869/)）。

### 内製で持つ範囲と外部委託に出す範囲

フローの書き起こしと対象選定は、外に出さず自社で持つ範囲です。外部に作成を支援してもらう場合も、社内の実務担当者が例外処理を確認し、業務責任者が対象範囲を承認する体制を残してください。一方、システム化業務フロー図の詳細化以降、特に画面設計とデータ移行は外部の経験が効く領域です。判断の分かれ目は[内製化とは？外注との違い・メリットとデメリット・進め方を解説](/column/details/12823/)で扱っています。社内に最低限必要なのは、業務側の意思決定者1名とフロー図を維持する担当者1名です。決裁者が不在だと、例外を残すか切るかの判断が現場に戻され、要件が膨らみます。

書き起こしたフローを受発注・在庫・生産などの基幹業務のシステムとして作る段階では、業務要件と既存システムとの連携設計を同時に扱える体制が要ります。当社は[基幹システム開発](/service/business%5Fsystem/core%5Fbusiness/)として、要件定義から連携設計まで一貫して対応しています。

## 業務フローのシステム化が失敗する3つの型と着手前の潰し方

### 現行業務をそのまま写し、稼働後に例外処理が溢れる型

現行フローを見直さずにシステムに置き換えると、現場が回避策として使っていた手作業まで機能として実装され、開発費が膨らみます。稼働後は想定外の分岐が「システムに入らないので別管理」として残ります。To-Be図を描く前に「この工程は無くせないか」を1工程ずつ確認する時間を、正式な作業として日程に入れてください。

### 部門横断のフローを部門単位で発注し、連携仕様が抜ける型

部門別に発注する場合、連携仕様の責任者を決めないと、受注・在庫引当・請求の間で仕様が抜けます。IPAの02T004は、データ授受のタイミング・方法・期限・媒体の事前合意を求めています。稼働後に、営業側が入力した情報の粒度が経理側の必要に足りない、といった食い違いが見つかります。着手前に、レーンをまたぐ矢印を数え、1本ずつに「誰が仕様を決めるか」を記入してください。担当が空欄の矢印が残る状態で見積もり依頼に進まないことです。

### 旧手順が並走して定着しない型

新システムを入れても旧来のExcel台帳が生き残ると、二重入力で削減したはずの工数が戻ってきます。切り替え前に決めるのは、旧手順を止める日付、その日以降に旧手順で処理された案件の扱い、例外を認める権限者の3点です。日付だけ決めて例外の扱いを決めないと、現場の判断で例外が積み上がります。止める日付は、必要な業務周期（月次締めを含むなら1回以上）での処理確認、データ照合、障害時の復旧手順の確認を終えられる時点に置きます。

## 投資回収の試算とデジタル化・AI導入補助金の「プロセス」の読み方

### 削減工数の金額換算と回収年数による対象範囲の設定

対象工程ごとに年間削減見込み時間を人件費単価で金額に換算し、合計から初期費用と年間運用費の回収年数を出します。初期費用500万円・年間削減額200万円・運用費年50万円なら、正味の削減額は年150万円で、回収は約3.3年です。社内基準の設定例として、3年以内で回収できる範囲を第1弾とし、5年を超える工程は再評価する方法があります。実際の基準は、資金計画と品質・統制面の要件を踏まえて決めてください。対象の広げすぎに加え、削減時間の過大評価や運用費の見落としも、回収年数を延ばす要因になります。入力ミスの削減件数や月次締めの短縮日数など、時間以外の効果も併記してください。

### 補助金のプロセス数と業務フローの工程数の違い

旧IT導入補助金にあたるデジタル化・AI導入補助金2026の通常枠は、補助額を「プロセス数」で区切っています。[第7回公募以降の通常枠公募要領](https://it-shien.smrj.go.jp/pdf/it2026%5Fkaitei%5Fkoubo%5Ftsujyo.pdf)では、5万円〜150万円未満が1プロセス以上、150万円〜450万円以下が4プロセス以上で、補助率は1/2以内です。令和7年10月〜令和8年9月の間に、当該期間の地域別最低賃金以上、かつ令和8年度改定の地域別最低賃金未満で雇用する従業員が全従業員の30%以上である月が3か月以上ある場合は2/3以内になります。

ここでいう「プロセス」は、業務フローの工程の数ではありません。公募要領が定めるのは、導入するITツールが持つ機能の区分で、共Ｐ-０１「顧客対応・販売支援」、共Ｐ-０２「決済・債権債務・資金回収」、共Ｐ-０３「供給・在庫・物流」、共Ｐ-０４「会計・財務・経営」、共Ｐ-０５「総務・人事・給与・労務・教育訓練・法務・情シス・統合業務」、各業種Ｐ-０６「業種固有プロセス」、汎Ｐ-０７「汎用・自動化・分析ツール」の7つです。受注から出荷までの工程を4つ書き出しても、すべて同じ機能区分なら1プロセスです。なお、汎Ｐ-０７だけでは申請できず、共Ｐ-０１〜各業種Ｐ-０６のいずれかと組み合わせる必要があります。

もう1つの前提は、補助の対象が「事務局に登録されたＩＴツール」の導入費用に限られることです。業務フローに合わせてゼロから作るスクラッチ開発は、この枠組みに乗りません。補助金を使うなら、実現手段の選定でパッケージやクラウドサービスを選んだ部分に充てる、という順序で考えます。2026年10月11日時点の[事業スケジュール](https://it-shien.smrj.go.jp/schedule/)では、通常枠の6次締切が2026年10月30日（金）17:00、交付決定日が2026年12月10日（木）予定で、7次以降の日程は未公表です。2026年10月9日には第7次公募回以降の要件変更（1人当たり給与支給総額に係る申請要件の追加など）も公表されているため、申請前に最新の公募要領で確認してください。枠ごとの違いは[デジタル化・AI導入補助金とは？旧IT導入補助金の枠・補助額とAIツールの対象範囲](/column/details/13781/)にまとめています。

## 業務フローのシステム化についてよくある質問

### 業務フロー図はどのツールで作ればよいですか？

現場確認用の1枚目は、PowerPointやExcelなど社内で誰でも開けるツールで構いません。開発ベンダーとは記号と粒度を合意し、BPMNを採用する場合に対応ツールを選びます。既存の図で意味を共有できるなら、ツールを変更する必要はありません。維持する担当者を決めずに高機能なツールを入れると、更新が止まって実態と離れていきます。

### システム化業務フロー図と現行業務フロー図は何が違いますか？

現行業務フロー図（As-Is）は、いま動いている手順を良し悪しの判断をせずに写したものです。システム化業務フロー図は、業務の流れの中でシステム化の範囲を識別した図です。本記事では、改善後の業務を表すTo-Be図として作成します。両方を残すと、差分がそのまま「何が変わるか」の説明資料になり、稼働後の効果検証にも使えます。

### 業務フローの可視化にはどれくらいの期間がかかりますか？

可視化の期間は、工程数だけでなく、担当者の日程、確認する例外の数、部門間の合意に必要な時間を積み上げて見積もります。工程ごとにヒアリング、実案件の追跡、例外分岐の確認を予定に組み込みます。複数部門にまたがる場合は、受け渡す情報と担当範囲を合意する時間も確保してください。

### 業務フローを整理せずにシステムを発注してもよいですか？

お勧めしません。フロー図が無いまま見積もりを依頼すると、ベンダーが置いた前提が要件定義の途中で崩れ、追加費用の交渉になります。対象業務のスイムレーン図と例外一覧を出発点に、対象範囲、処理量、連携、移行、非機能要件も確認して見積もりの前提をそろえます。準備が難しければ、[要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説](/column/details/12848/)で扱う要件定義そのものを工程として切り出して発注する手もあります。その場合も、対象工程の選定だけは自社で判断してください。

### 小規模な会社でも業務フローのシステム化に取り組む価値はありますか？

担当者1名しか手順を知らない業務がある会社では、その人の不在時にも処理できるよう、手順と判断基準を共有することが先決です。書き起こして手順書にするところまでは、システムを入れなくても効果があります。そのうえで年間の削減見込みと導入・運用費を比較し、自社の回収基準を満たす工程から着手します。法令対応や誤処理防止が必要な工程は、工数削減とは別に評価してください。

## 関連記事

- [業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説](/column/details/16307/)
- [要件定義と設計で作る7つの図｜画面遷移図・ER図とデザイナーの担当範囲](/column/details/2860/)
- [ワークフローとは？承認フローの仕組み・システム化の判断基準と選び方を解説](/column/details/12893/)
- [購買管理の業務フローとは？見積・発注・検収・支払の流れとシステム化の判断を解説](/column/details/15539/)
- [プロセスマイニングとは？仕組み・3つの分析とタスクマイニングとの違い、導入判断](/column/details/13375/)

---

出典: [業務フローのシステム化とは？システム化業務フロー図の書き方と対象工程の選び方](<https://www.issoh.co.jp/column/details/15783/>)（株式会社一創）