システム開発を外注する前に、現状（As-Is＝現在の仕事の流れ）と導入後（To-Be＝システム導入後の仕事の流れ）の業務フロー図を作ると、見積もり漏れや認識違いを減らせます。担当者・作業・判断条件・データ・例外を同じ粒度で整理し、重要業務から合意することが成功の要点です。

業務フロー図は、見栄えのよい資料を作ることが目的ではありません。開発対象となる業務を関係者で確認し、何をシステム化し、何を人の判断として残すかを決めるための資料です。本記事では、非エンジニアの発注担当者でも進められる作成手順、必要項目、費用・期間、外注先の見極め方を解説します。

業務フロー図が開発依頼前に必要な理由

業務フロー図とは、業務の開始から終了までについて、誰が、何を、どの順番で行い、どこで判断やデータの受け渡しが発生するかを可視化した図です。システム開発では、要件定義（＝作るものと条件を決める工程）の土台として利用します。

発注者から開発会社への相談では、「受注管理を効率化したい」「申請を電子化したい」といった目的は共有されていても、実際の業務条件が整理されていないことが少なくありません。たとえば、次の条件が後から判明すると、機能追加や見積もり変更につながります。

  • 金額や商品区分によって承認者が変わる
  • 一部の取引先だけ専用の帳票が必要になる
  • 受注後の変更や取消しには別の権限が必要になる
  • Excel、メール、紙の台帳に情報が分散している
  • 月末だけ処理件数が大幅に増える
  • システム障害時には手作業で処理を継続する必要がある

業務フロー図にこれらを記載すると、開発会社は必要な画面、権限、通知、データ連携、履歴管理などを具体的に検討できます。発注者側も、不要な機能や過剰な自動化を見分けやすくなります。

業務フロー図と他の資料の違い

業務フロー図だけですべての仕様を表す必要はありません。資料ごとの役割を分けると、作成や更新がしやすくなります。

資料 主に表す内容 開発依頼での役割
業務フロー図 担当者、作業順序、判断、情報の受け渡し システム化する業務範囲を確認する
機能一覧 検索、登録、承認、通知などの機能 見積もり対象を整理する
画面一覧・画面イメージ 利用者が操作する画面 操作方法や入力項目を確認する
データ項目一覧 顧客名、申請日、金額などの情報 保存・検索・連携するデータを確認する
要件定義書 機能、性能、運用、制約などの合意事項 開発範囲と条件を正式に合意する
操作マニュアル 完成したシステムの利用手順 導入後の教育や運用に利用する

発注者がよく誤解しやすいのは、画面イメージを作れば業務も伝わるという点です。画面だけでは、操作の前後にある確認作業、承認条件、他部署への引き継ぎ、例外時の対応が分かりません。まず業務の流れを整理し、その一部をシステムの画面や機能へ落とし込む順番が基本です。

現状と導入後の両方を作る

業務フロー図は、現状と導入後の2種類を用意するのが理想です。

種類 確認すること 主な用途
As-Is 現在の担当者、作業、使用資料、課題、例外 課題の把握、移行対象の確認、要件の根拠整理
To-Be 導入後の役割分担、自動化範囲、判断、運用 必要機能、権限、通知、導入後の体制の決定

現状を確認せずに導入後の理想像だけを作ると、既存データの移行、取引先とのやり取り、法令・社内規程上の制約などを見落とす可能性があります。一方、現状の作業をそのままシステム化すると、非効率な手順まで固定化しかねません。「現状を理解したうえで、不要な作業をなくしてから導入後を設計する」という順番が重要です。

業務フロー図の作り方5ステップ

業務フロー図は、最初から細部まで描こうとせず、対象範囲を決めてから現状、課題、導入後の順で整理します。小規模な業務であれば社内で作成できますが、複数部署や外部システムが関係する場合は、責任者を決めて計画的に進める必要があります。

ステップ1：目的と対象範囲を決める

最初に、何の意思決定に使う業務フロー図なのかを明確にします。対象範囲が曖昧なままヒアリングを始めると、関連業務が次々に増え、完成時期を見通せなくなります。

最低限、次の項目を決めてください。

  • 解決したい業務課題
  • 対象となる部署、拠点、利用者
  • 業務の開始地点と終了地点
  • 対象に含める商品、取引、申請などの種類
  • 対象外とする業務
  • 業務フロー図を承認する責任者
  • 開発会社へ提示する予定日

たとえば「受注業務」だけでは範囲が広いため、「法人顧客から注文書を受領してから、出荷担当者へ確定情報を渡すまで」のように開始と終了を定義します。請求、入金、返品を今回は対象外とする場合は、それも記載します。

ステップ2：資料収集とヒアリングを行う

次に、現場で実際に使われている資料とシステムを確認します。社内規程に書かれた正式な手順だけでなく、実務で行われている作業を把握することが大切です。

収集する資料の例は次のとおりです。

  • 申請書、注文書、見積書、請求書などの帳票
  • Excelやスプレッドシートの管理表
  • 現行システムの画面や操作マニュアル
  • メールやチャットの定型文
  • 組織図、権限表、承認規程
  • 処理件数、繁忙期、締め時間が分かる資料
  • 過去に発生した差し戻しやエラーの記録

ヒアリングでは「通常はどうしていますか」だけでなく、次の質問まで確認します。

  • 誰から何を受け取ると業務が始まりますか
  • 完了と判断できる状態は何ですか
  • 金額、商品、顧客によって手順は変わりますか
  • 入力内容に誤りがあった場合は誰が修正しますか
  • 担当者が不在のときは誰が代行しますか
  • システムが利用できないときはどうしますか
  • 同じ情報を別の場所へ転記していますか
  • 最も時間がかかる作業やミスが多い作業は何ですか

開発会社の立場から特に確認したいのは、「判断条件」と「例外」です。「上長が承認する」という説明だけでは、誰が上長なのか、金額で承認者が変わるのか、差し戻し後にどこから再開するのかを設計できません。判断に使う条件を可能な限り言語化してください。

ステップ3：現状の業務フローを作る

収集した情報を基に、現状の流れを図にします。スイムレーン（＝部署や担当者ごとに作業欄を分ける表現）を使うと、誰が担当する作業なのかを把握しやすくなります。

業務フロー図で使う要素は、複雑にしすぎる必要はありません。

要素 記載内容 記載例
開始・終了 業務が始まる条件と完了状態 注文書を受領、出荷指示が完了
担当者・部署 作業を行う主体 営業、営業責任者、物流担当
作業 主体が行う具体的な行動 営業が注文内容を登録する
判断・分岐 流れが変わる条件 値引率が10％を超えるか
データ・帳票 入力、参照、出力する情報 注文書、顧客台帳、在庫データ
システム 使用する既存ツール 販売管理システム、メール
例外 通常と異なる処理 在庫不足、注文変更、取消し

作業名は「確認する」「処理する」だけで終わらせず、「営業が顧客台帳と注文書の会社名を照合する」のように、主体、対象、行動が分かる表現にします。

また、1枚にすべてを詰め込まないことも重要です。全体像を表す概要版では主要な業務を5〜10個程度にまとめ、詳細版で承認、差し戻し、取消しなどを展開すると読みやすくなります。この数は厳格な基準ではなく、関係者が全体像を把握できる粒度の目安です。

ステップ4：課題と要件候補を整理する

現状の業務フローができたら、各作業の課題を確認します。この段階では、すぐに機能名へ置き換えるのではなく、課題の原因と改善後の状態を整理してください。

現状の作業・課題 改善後の状態 要件候補
注文内容を複数の台帳へ転記している 同じ情報を一度だけ入力する 受注情報の一元管理、データ連携
承認依頼をメールで送っている 承認状況を一覧で確認できる 承認機能、通知機能、履歴管理
在庫不足が受注後に判明する 登録時に在庫状況を確認できる 在庫照会、警告表示
担当者しか進捗を把握できない 権限のある利用者が状況を確認できる ステータス管理、検索機能

「AIを使う」「すべて自動化する」といった解決方法から入ると、費用に対する効果を判断しにくくなります。まず、何に時間がかかっているか、どのミスを減らしたいか、誰がどの状態を確認できればよいかを明確にします。

課題には優先順位も付けます。「必須」「できれば必要」「将来対応」の3段階程度に分けると、予算超過時に開発範囲を調整しやすくなります。

ステップ5：導入後の業務フローを作り、承認を得る

導入後の業務フローでは、システムが行う処理と、人が判断する作業を分けて記載します。自動化する作業だけでなく、導入後も人が確認する箇所、システム外に残る作業、障害時の代替手順も示してください。

導入後のフローができたら、次の関係者にレビューを依頼します。

  • 業務責任者
  • 日常的に作業する実務担当者
  • 承認者や管理者
  • 前後工程を担当する部署
  • 情報システム、セキュリティ、法務などの関係部署
  • システム開発を担当する会社

レビューでは、図のきれいさではなく「この流れで実際に運用できるか」を確認します。特に、権限、締め時間、代理承認、修正・取消し、障害時対応について合意を取ってください。

完成時には、業務フロー図だけでなく、次の補足資料もまとめると開発会社が見積もりやすくなります。

  • 業務フローの名称、目的、対象範囲
  • 用語集
  • 登場する担当者と権限
  • 使用する帳票とデータ
  • 処理件数、利用者数、繁忙期
  • 例外処理の一覧
  • 課題と要件候補の一覧
  • 未決事項と決定期限
  • 更新日、作成者、承認者

依頼前チェックリストとよくある失敗

業務フロー図は、すべての処理を詳細に描くよりも、開発範囲と業務上の判断を関係者が説明できる状態にすることが重要です。開発会社へ渡す前に、次のチェックリストを確認してください。

業務フロー図の完成チェックリスト

目的・範囲

  • 解決したい課題が記載されている
  • 業務の開始地点と終了地点が明確である
  • 対象部署、利用者、対象外業務が分かる
  • 現状と導入後のフローが区別されている

担当者・作業

  • 各作業の担当者が分かる
  • 部署間や社外との受け渡しが記載されている
  • 手作業とシステム処理が区別されている
  • 同じ作業が重複していないか確認している

判断・例外

  • 承認や分岐の条件が具体的である
  • 差し戻し、修正、取消しの流れがある
  • 担当者不在時の代行方法が分かる
  • 障害時やデータ不備時の対応が分かる

データ・運用

  • 入力、参照、出力するデータが分かる
  • 既存システムや外部サービスとの接点がある
  • 処理件数、利用者数、繁忙期を補足している
  • 個人情報や機密情報を扱う箇所が分かる

合意・更新

  • 実務担当者が内容を確認している
  • 業務責任者が導入後の流れを承認している
  • 未決事項に担当者と期限が設定されている
  • 編集可能な元データが保管されている

よくある失敗と回避策

よくある失敗 問題になる理由 回避策
規程上の流れだけを描く 現場の転記や個別対応が見積もりから漏れる 実務担当者へヒアリングし、実際の帳票や画面を確認する
正常な処理だけを描く 修正、取消し、差し戻しが追加開発になりやすい 例外一覧を別紙で作り、各例外の復帰地点を決める
作業の粒度がばらばら 一部だけ詳細になり、業務量や機能数を比較できない まず概要版を作り、必要な箇所だけ詳細化する
画面や機能から考え始める 現状の非効率な手順をそのまま再現しやすい 課題と改善後の状態を整理してから機能を検討する
判断条件が「必要に応じて」になっている 承認ルールや権限を実装できない 金額、区分、役職など客観的な条件へ置き換える
開発会社だけで作成する 業務上の判断が推測になり、完成後に運用できない 開発会社は進行・作図を支援し、自社の責任者が承認する
全社業務を一度に整理する 関係者と論点が増え、完成まで長期化する 開発対象や優先業務に範囲を絞り、段階的に作成する

発注時に特に注意したいのは、業務フロー図を確定仕様として固定しすぎることです。初期段階では不明点が残るため、確定事項、仮定、未決事項を分けて提示してください。開発会社が未決事項を質問し、要件定義で具体化できる余地を残したほうが、現実的な提案を受けやすくなります。

作成期間・費用の目安と外注先の選び方

業務フロー図の作成期間と費用は、対象業務、部署数、ヒアリング人数、例外処理、既存資料の状態によって変わります。次の金額は、開発費を含まない業務整理・作図支援の一般的な目安です。

依頼方法・規模 費用の目安 期間の目安 向いている状況
自社で作成 外部費用なし 1〜4週間 1部署内で業務が単純、担当者が流れを把握している
作成方法の助言・レビューを依頼 20万〜80万円程度 2〜6週間 下書きは作れるが、抜け漏れや粒度を確認したい
現状調査から導入後設計まで依頼 80万〜300万円程度 1〜3か月 複数部署が関係し、ヒアリングや改善案の整理が必要
全社・複数拠点・複数システムを対象 300万円以上になる場合がある 3か月以上 部門横断で業務標準化や大規模な刷新を行う

費用を左右する主な要因は次のとおりです。

  • 対象となる業務プロセスと部署の数
  • ヒアリング対象者の人数と拠点数
  • 現行資料の有無と正確性
  • 例外処理、承認ルール、権限の複雑さ
  • 現状整理だけか、改善案や導入後設計まで含むか
  • 対面会議や現地調査の必要性
  • 業務フロー図以外の機能一覧、データ一覧も作るか
  • 関係者間の調整や会議進行を外注するか

開発会社へ見積もりを依頼する際は、単に「業務フロー図作成一式」とまとめられていないか確認してください。少なくとも、事前調査、ヒアリング、現状フロー作成、課題整理、導入後フロー作成、レビュー、修正回数、納品物を分けて確認すると比較しやすくなります。

見積もりで確認する項目

  • ヒアリング回数と対象人数
  • ワークショップや会議の回数
  • 作成する業務フロー図の対象範囲と本数
  • 現状と導入後の両方が含まれるか
  • 課題一覧、要件候補、データ一覧などの付属資料
  • 自社と外注先の役割分担
  • レビューと修正の回数
  • 追加費用が発生する条件
  • 納品形式と編集可能な元データの有無
  • 成果物の利用権と保管方法

作図だけを安く依頼しても、ヒアリングや合意形成が対象外であれば、自社側の負担が大きくなることがあります。反対に、業務改善や要件定義まで含まれている見積もりは高く見えても、単純な作図代行とは成果物が異なります。価格を比較する前に、どこまでの支援が含まれるかをそろえてください。

システム開発全体の初期費用、運用費、予備費まで含めた考え方は、システム開発予算の決め方｜発注前の算定手順で詳しく解説しています。

外注先を見極めるポイント

業務フロー作成の外注先は、作図の速さだけでなく、業務を正確に聞き取り、開発要件へつなげられるかで判断します。

  • 現状の課題や開発目的を先に質問しているか
  • 通常処理だけでなく例外、権限、データを確認しているか
  • 自社の業界や類似業務を理解する姿勢があるか
  • 特定の製品や開発方法を最初から押しつけていないか
  • 業務フローから機能一覧や見積もりへつなげられるか
  • 自社側が決める事項と外注先が支援する事項を区別しているか
  • 編集可能な形式で成果物を納品できるか
  • 開発後も更新できる運用方法を提案しているか

初回相談では、完成した業務フロー図がなくても問題ありません。対象業務、現在の課題、関係部署、既存資料、希望時期を伝え、どの範囲から整理すべきか提案してもらいます。開発会社そのものを比較する観点は、システム開発会社の選び方｜発注前の比較ポイントも参考にしてください。

業務整理から要件定義、開発まで一貫して相談したい場合は、開発のご相談はこちらからお問い合わせください。

まとめ

  • 業務フロー図は、誰が、何を、どの順番で行い、どこで判断やデータ連携が発生するかを可視化する資料です
  • 現状のAs-Isを確認してから、導入後のTo-Beを設計する順番が基本です
  • 作成前に業務の開始・終了地点、対象部署、対象外業務、承認者を決めます
  • 通常処理だけでなく、差し戻し、修正、取消し、担当者不在、障害時などの例外を整理します
  • 図だけでなく、処理件数、利用者数、権限、データ、未決事項を補足すると見積もり精度が上がります
  • 外部支援の費用は、レビュー中心なら20万〜80万円程度、現状調査から導入後設計までなら80万〜300万円程度が一般的な目安です
  • 外注先は作図技術だけでなく、ヒアリング力、業務理解、要件定義や開発への接続力で選びます
  • 最終的な業務判断を開発会社へ丸投げせず、自社の業務責任者が承認することが重要です

よくある質問

業務フロー図がないとシステム開発を依頼できませんか？

必須ではありませんが、業務の関係者や例外処理が多い場合は作成をおすすめします。完成版でなくても、現状の担当者、作業、判断条件、使用データを整理した下書きがあれば、開発会社が要件を確認しやすくなります。

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

PowerPoint、Excel、オンラインの作図ツールなど、関係者が閲覧・編集しやすいツールで十分です。ツールの高機能さよりも、記号や粒度を統一し、更新責任者を決めることが重要です。

現状の業務フローと導入後の業務フローはどちらを先に作りますか？

原則として、現状の業務フローを先に作ります。現在の作業、例外、データの流れを把握してから導入後の業務を設計すると、必要な機能や移行対象を根拠を持って判断できます。

業務フロー図は誰が作成するべきですか？

業務責任者を意思決定者とし、実務担当者、情報システム担当者、必要に応じて開発会社が共同で作成するのが理想です。開発会社に作図を任せる場合も、業務上の判断まで丸投げせず、自社が内容を承認してください。