システム開発や業務改善の現場では、「このデータはどこから来るのか」「誰が入力するのか」「どこに保存されるのか」「どの帳票や画面に使われるのか」がわからなくなることがあります。
たとえば、顧客情報、注文情報、在庫情報、請求情報などは、業務の中で何度も使われます。しかし、データの流れが整理されていないと、二重入力、転記ミス、古い情報の参照、責任の所在不明といった問題が起きやすくなります。
そこで役立つのが、DFDです。
DFDは、Data Flow Diagramの略で、日本語では「データフロー図」と呼ばれます。業務やシステムの中で、データがどこから入り、どこで処理され、どこへ出ていくのかを図で整理するためのフレームワークです。
初心者はまず、「DFDはデータの流れを見える化する図」と理解すれば十分です。
システム開発だけでなく、業務改善、DX推進、RPA導入、データ連携設計、帳票見直しなどでも使える実務的な考え方です。
この記事でわかること
・DFDとは何か
・DFDは何に使うのか
・DFDの基本的な考え方
・DFDの使い方
・DFDの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「DFDはデータの流れを整理するための型だ」とつかめれば十分です。
DFDとは？
DFDとは、Data Flow Diagramの略で、業務やシステムの中でデータがどのように流れるかを表す図です。
日本語では「データフロー図」と呼ばれます。
DFDでは、次のようなことを整理します。
・どこからデータが入ってくるのか
・誰がデータを入力するのか
・どの処理でデータが使われるのか
・どこにデータが保存されるのか
・どこへデータが出力されるのか
・外部の人やシステムとどのようにデータをやり取りするのか
たとえば、受注業務を考えてみましょう。
顧客から注文情報が届きます。その注文情報をもとに、在庫確認を行い、出荷指示を作成し、請求情報を作ります。さらに、注文情報は販売管理システムに保存され、請求情報は経理システムへ送られるかもしれません。
このようなデータの流れを図で整理するのがDFDです。
初心者向けに言い換えると、DFDは「データの通り道を描く地図」です。
業務の中でデータがどこから来て、どこを通って、どこへ行くのかを見える化することで、システム設計や業務改善がしやすくなります。
一言でいうと、DFDは業務やシステムにおけるデータの流れを整理するためのフレームワークです。
DFDは何に使うのか
DFDは、業務やシステムにおけるデータの流れを整理するために使います。
主な用途は次のとおりです。
・業務内のデータの流れを見える化する
・入力、処理、保存、出力の関係を整理する
・二重入力や転記作業を見つける
・システム間のデータ連携を整理する
・帳票や画面で使うデータの出どころを確認する
・業務改善やDX推進の前提を整理する
・システム開発の要件定義に活用する
・RPAや自動化の対象を見つける
・データベース設計の前段階として使う
・外部ベンダーに業務やデータの流れを説明する
DFDは、業務フローを描くための図とは少し違います。
業務フローでは、「誰が、どの順番で、何をするか」に注目します。一方、DFDでは「データがどのように流れるか」に注目します。
たとえば、同じ受注業務でも、業務フローでは「営業担当が注文を受ける」「倉庫担当が在庫を確認する」「経理担当が請求書を発行する」といった作業の順番を見ます。
DFDでは、「注文データ」「在庫データ」「出荷指示データ」「請求データ」がどこから来て、どの処理で使われ、どこに保存されるかを見ます。
この違いを理解すると、DFDの使いどころがわかりやすくなります。
どんな人に向いているか
DFDは、次のような人に向いています。
・システム開発や要件定義に関わる人
・業務改善やDX推進を担当している人
・業務システムの導入を検討している人
・データ連携や帳票設計を整理したい人
・RPAや自動化の対象業務を探している人
・Excelや手作業の転記を減らしたい人
・既存システムのデータの流れを理解したい人
・外部ベンダーに業務内容を説明する人
・データベース設計の前提を整理したい人
・プロジェクトマネージャーや業務担当者
特に、業務部門とIT部門の間に立つ人にとってDFDは有効です。
業務部門は「この帳票がほしい」「この画面にこの情報を出したい」と考えます。一方、IT部門や開発者は「その情報はどこから取得するのか」「どのデータを正とするのか」「どのシステムに保存するのか」を確認する必要があります。
DFDを使えば、業務で使うデータの流れを共通認識として整理できます。
DFDの基本的な考え方
DFDの基本的な考え方は、データの流れをいくつかの要素に分けて表すことです。
代表的な要素は次の4つです。
・外部実体
・プロセス
・データストア
・データフロー
外部実体
外部実体とは、システムや業務の外側にいる人、組織、外部システムなどのことです。
たとえば、次のようなものが外部実体になります。
・顧客
・取引先
・営業担当者
・経理部門
・配送会社
・決済システム
・外部の販売サイト
・金融機関
外部実体は、データの送り手や受け手になります。
たとえば、顧客が注文情報を送る、配送会社に出荷情報を渡す、経理部門に請求情報を渡す、といった形です。
プロセス
プロセスとは、データを処理する作業や機能のことです。
たとえば、次のようなものがプロセスになります。
・注文を受け付ける
・在庫を確認する
・見積を作成する
・請求金額を計算する
・顧客情報を登録する
・承認可否を判定する
・出荷指示を作成する
プロセスでは、入力されたデータをもとに何らかの処理を行い、別のデータを出力します。
たとえば、「注文を受け付ける」というプロセスでは、顧客から注文情報を受け取り、注文データを作成します。
データストア
データストアとは、データを保存しておく場所です。
たとえば、次のようなものがデータストアになります。
・顧客マスタ
・商品マスタ
・在庫データベース
・注文データベース
・請求データベース
・商談履歴
・申請履歴
・問い合わせ履歴
初心者向けに言えば、データストアは「データの保管場所」です。
システムでは、処理の途中や処理後にデータを保存します。DFDでは、どのプロセスがどのデータストアを参照し、どのデータストアに更新するのかを整理します。
データフロー
データフローとは、データの流れを表す矢印です。
たとえば、次のようなデータの流れがあります。
・顧客から注文情報が届く
・注文受付プロセスから注文データベースへ注文情報を保存する
・在庫確認プロセスが在庫データベースを参照する
・請求処理プロセスが請求データを経理システムへ送る
・出荷指示データを倉庫へ送る
DFDでは、矢印に「注文情報」「顧客情報」「在庫データ」「請求データ」のように、流れるデータの名前を書きます。
これにより、単なる作業の流れではなく、どのデータが動いているのかを明確にできます。
DFDの使い方
手順1 対象となる業務やシステムを決める
まず、DFDで整理する対象を決めます。
いきなり会社全体のデータの流れを描こうとすると、範囲が広すぎて整理できません。最初は、1つの業務や1つのシステムに絞るのがおすすめです。
たとえば、次のような単位で考えるとよいでしょう。
・受注管理
・請求処理
・問い合わせ対応
・社内申請
・在庫管理
・顧客管理
・見積作成
・研修申込受付
・経費精算
・採用応募管理
対象を決めるときは、どこからどこまでを範囲にするかも明確にします。
たとえば、受注管理であれば、「顧客から注文を受ける」から「出荷指示と請求データを作る」までを対象にする、といった形です。
範囲が明確になると、図が複雑になりすぎるのを防げます。
手順2 外部実体を洗い出す
次に、その業務やシステムとデータをやり取りする外部実体を洗い出します。
外部実体は、データの出入り口になる存在です。
たとえば、受注管理なら次のような外部実体が考えられます。
・顧客
・営業担当者
・倉庫部門
・経理部門
・配送会社
・外部ECサイト
社内申請なら、次のような外部実体が考えられます。
・申請者
・承認者
・総務部門
・経理部門
・通知システム
外部実体を洗い出すことで、どこからデータが入ってくるのか、どこへデータを渡すのかが見えやすくなります。
手順3 主なプロセスを整理する
次に、対象業務の中で行われる主な処理を整理します。
プロセスは、データを受け取り、何らかの処理をして、別のデータを出力するものです。
受注管理なら、次のようなプロセスが考えられます。
・注文を受け付ける
・顧客情報を確認する
・在庫を確認する
・出荷指示を作成する
・請求情報を作成する
問い合わせ対応なら、次のようなプロセスが考えられます。
・問い合わせを受け付ける
・問い合わせ内容を分類する
・回答担当を割り当てる
・回答を作成する
・対応履歴を保存する
プロセス名は、「名詞」だけではなく、「〜する」という動詞で書くとわかりやすくなります。
たとえば、「注文」ではなく「注文を受け付ける」、「在庫」ではなく「在庫を確認する」と書くと、処理内容が明確になります。
手順4 データストアを整理する
次に、業務で使うデータの保存場所を整理します。
データストアには、マスタデータや履歴データがあります。
たとえば、受注管理なら次のようなデータストアが考えられます。
・顧客マスタ
・商品マスタ
・在庫データベース
・注文データベース
・請求データベース
社内申請なら、次のようなデータストアが考えられます。
・社員マスタ
・承認ルートマスタ
・申請データベース
・承認履歴
・添付ファイル保管場所
ここで大切なのは、「どのデータをどこに保存するのか」を明確にすることです。
同じ顧客情報が複数のExcelや複数のシステムに保存されている場合、どれが正しい情報なのかわからなくなることがあります。DFDでデータストアを整理すると、データ管理上の問題も見つけやすくなります。
手順5 データフローを矢印でつなぐ
外部実体、プロセス、データストアが整理できたら、データの流れを矢印でつなぎます。
矢印には、流れるデータの名前を書きます。
たとえば、受注管理なら次のような流れになります。
・顧客から「注文情報」が注文受付プロセスへ流れる
・注文受付プロセスが「顧客情報」を顧客マスタから参照する
・在庫確認プロセスが「在庫情報」を在庫データベースから参照する
・出荷指示作成プロセスが「出荷指示データ」を倉庫部門へ送る
・請求情報作成プロセスが「請求データ」を経理部門へ送る
・注文データが注文データベースに保存される
このように整理すると、業務の中でどのデータがどこを通っているのかが見えるようになります。
手順6 データの抜け漏れや重複を確認する
最後に、作成したDFDを見ながら、データの抜け漏れや重複を確認します。
確認する観点は次のとおりです。
・必要な入力データが不足していないか
・出力データの元になる情報は明確か
・同じデータを複数回入力していないか
・どのデータが正しい原本なのか明確か
・保存すべきデータが保存されているか
・不要なデータを持ちすぎていないか
・外部システムとの連携が整理されているか
・個人情報や機密情報の流れは適切か
・帳票や画面に表示するデータの出どころは明確か
DFDは、描いて終わりではありません。図を見ながら、データの流れに問題がないかを確認することが重要です。
DFDの具体例
例 受注管理業務を整理する場合
ある会社では、顧客からの注文を営業担当者がメールで受け取り、Excelに転記していました。その後、在庫担当者に在庫確認を依頼し、出荷担当者へ出荷指示を送り、経理部門に請求情報を伝えていました。
この業務では、次のような問題がありました。
・注文情報を複数のExcelに転記している
・在庫確認の結果がメールで埋もれる
・出荷指示の内容にミスが起きる
・請求情報の元データがわかりにくい
・顧客情報が営業担当者ごとに管理されている
・注文履歴を集計しにくい
この場合、DFDを使ってデータの流れを整理します。
外部実体は次のようになります。
・顧客
・営業担当者
・倉庫部門
・経理部門
プロセスは次のように整理できます。
・注文を受け付ける
・顧客情報を確認する
・在庫を確認する
・出荷指示を作成する
・請求情報を作成する
データストアは次のようになります。
・顧客マスタ
・商品マスタ
・在庫データベース
・注文データベース
・請求データベース
データフローは、次のように整理できます。
・顧客から注文情報が届く
・営業担当者が注文情報を注文受付プロセスへ入力する
・注文受付プロセスが顧客マスタを参照する
・在庫確認プロセスが在庫データベースを参照する
・注文データが注文データベースに保存される
・出荷指示データが倉庫部門へ送られる
・請求データが経理部門へ送られる
このようにDFDで整理すると、注文情報がどこから来て、どこへ保存され、どの部門へ渡されるのかが明確になります。
また、複数のExcelへの転記が不要ではないか、在庫情報を直接参照できないか、請求データを自動生成できないかといった改善ポイントも見えてきます。
別の例 社内研修の申込受付を整理する場合
別の例として、社内研修の申込受付業務を考えます。
ある会社では、研修参加希望者がメールで申し込み、担当者がExcelに入力していました。定員を超えた場合は担当者が手作業で調整し、参加者に案内メールを送っていました。研修後は、出席結果とアンケート結果を別々に管理していました。
この場合、次のような問題がありました。
・申込メールの見落としが起きる
・Excelへの転記作業が多い
・定員管理が手作業になっている
・参加者リストの最新版がわかりにくい
・出席データとアンケート結果が分かれている
・過去の研修履歴を集計しにくい
DFDで整理すると、外部実体は次のようになります。
・受講者
・研修担当者
・講師
・上司
・アンケートシステム
プロセスは次のように整理できます。
・研修申込を受け付ける
・定員を確認する
・参加者を確定する
・案内メールを送信する
・出席結果を登録する
・アンケート結果を取り込む
データストアは次のようになります。
・社員マスタ
・研修マスタ
・申込データベース
・参加者データベース
・出席履歴
・アンケート結果
データフローは、次のように考えられます。
・受講者から申込情報が届く
・研修申込受付プロセスが社員マスタと研修マスタを参照する
・申込情報が申込データベースに保存される
・定員確認プロセスが申込データと研修マスタを参照する
・参加者確定データが参加者データベースに保存される
・案内メール送信用データが受講者へ送られる
・出席結果が出席履歴に保存される
・アンケート結果がアンケートシステムから取り込まれる
このようにDFDを使うと、研修申込業務に必要なデータと、その流れを整理できます。
特に、申込データ、参加者データ、出席履歴、アンケート結果をどう関連づけるかが見えやすくなります。これにより、研修効果の分析や受講履歴管理にもつなげやすくなります。
具体例でわかるポイント
具体例から学べるポイントは次のとおりです。
・DFDはデータの入口、処理、保存、出口を整理できる
・業務の中でどのデータが使われているかが見える
・二重入力や転記作業を発見しやすい
・データの正しい保管場所を考えやすい
・システム間連携の整理に役立つ
・帳票や画面に必要なデータの出どころを確認できる
・業務改善や自動化の対象を見つけやすい
・個人情報や機密情報の流れも確認しやすい
DFDは、業務の流れそのものよりも、データの流れに注目するところが特徴です。
DFDを使うメリット
DFDを使うメリットは、業務やシステムの中でデータがどのように動いているかを見える化できることです。
主なメリットは次のとおりです。
・データの流れを直感的に理解できる
・データの入力元と出力先が明確になる
・二重入力や手作業の転記を発見しやすい
・データの保存場所を整理できる
・システム間連携を検討しやすい
・業務改善のポイントを見つけやすい
・帳票や画面設計の前提を整理できる
・データベース設計の前段階として使える
・RPAや自動化対象の発見に役立つ
・外部ベンダーに業務内容を説明しやすい
特に重要なのは、データの「正」を明確にしやすいことです。
実務では、同じ顧客情報が複数のExcel、複数のシステム、複数の担当者の手元に存在していることがあります。その結果、どの情報が最新なのか、どの情報を見ればよいのかがわからなくなります。
DFDを使うと、どこでデータを作り、どこに保存し、どこから参照するのかを整理できます。これは、データ品質の向上や業務効率化に直結します。
DFDを使うときの注意点
DFDは便利ですが、使い方を間違えると、複雑で読みにくい図になってしまいます。
よくある失敗例は次のとおりです。
・業務フロー図と混同してしまう
・作業の順番だけを描いて、データ名を書かない
・図の範囲が広すぎて複雑になる
・外部実体とプロセスの区別が曖昧になる
・データストアを整理せずに描き始める
・データの保存場所が不明確なままになる
・現場に確認せず、想像でデータの流れを描く
・例外処理時のデータの流れを省略する
・個人情報や機密情報の流れを見落とす
・作った図を更新せず、実態とずれてしまう
特に注意したいのは、DFDは「作業手順の図」ではなく「データの流れの図」だという点です。
業務の順番を整理したい場合は、BPMNや業務フロー図のほうが向いています。DFDでは、どのデータがどこから来て、どこで処理され、どこへ保存・出力されるかに注目します。
また、DFDを作るときは、データ名を具体的に書くことが大切です。
単に「情報」と書くのではなく、「注文情報」「顧客情報」「請求データ」「在庫情報」のように、何のデータなのかがわかる名前にしましょう。
関連フレームワークとの違い
DFDと関連するフレームワークには、BPMN、UML、ER図、CRUDマトリクス、要件定義フレームなどがあります。それぞれ目的が異なります。
BPMNとの違い
BPMNは、業務プロセスの流れを図で整理するための記法です。
DFDは、データの流れを図で整理するための記法です。
BPMNが「誰が、どの順番で、何をするか」を見える化するのに対して、DFDは「どのデータが、どこから来て、どこへ行くか」を見える化します。
業務改善では、まずBPMNで業務の流れを整理し、その後にDFDでデータの流れを整理すると理解しやすくなります。
UMLとの違い
UMLは、システムの構造や動きをさまざまな図で表現するための記法です。
UMLには、ユースケース図、クラス図、シーケンス図などがあります。利用者、処理のやり取り、データ構造など、複数の視点からシステムを表せます。
DFDは、その中でも特にデータの流れに注目します。
UMLがシステム全体を多面的に表現する道具だとすれば、DFDはデータの流れを重点的に整理する道具です。
ER図との違い
ER図は、データベースの構造を整理するための図です。
DFDは、データが業務やシステムの中でどのように流れるかを整理します。一方、ER図は、データ同士の関係を整理します。
たとえば、DFDでは「注文情報が注文受付プロセスを通じて注文データベースに保存される」といった流れを見ます。
ER図では、「顧客と注文は1対多の関係」「注文と注文明細は1対多の関係」といったデータ構造を見ます。
DFDが「データの動き」を表すものだとすれば、ER図は「データの構造」を表すものです。
CRUDマトリクスとの違い
CRUDマトリクスは、データに対して作成、参照、更新、削除のどの操作が必要かを整理するための表です。
DFDでは、データがどのプロセスを通じて流れるかを図で整理します。CRUDマトリクスでは、各機能や業務がどのデータにどの操作を行うかを確認します。
DFDでデータの流れを把握し、CRUDマトリクスで操作の抜け漏れを確認すると、より実務的なシステム設計ができます。
要件定義フレームとの違い
要件定義フレームは、業務要件、機能要件、非機能要件を整理するための考え方です。
DFDは、要件定義の中でも特にデータの流れを整理する場面で役立ちます。
たとえば、「注文情報を登録する」「請求情報を作成する」という機能要件がある場合、DFDを使うと、そのデータがどこから来て、どこへ保存され、どこに渡されるのかを確認できます。
要件定義フレームが全体の整理だとすれば、DFDはデータ面を深掘りするための道具です。
DFDはどんな場面で使うと効果的か
DFDは、次のような場面で使うと効果的です。
・新しい業務システムを設計するとき
・既存業務のデータの流れを整理するとき
・Excelやメールで行っている業務をシステム化するとき
・システム間連携を検討するとき
・帳票やレポートの元データを確認するとき
・二重入力や転記作業を減らしたいとき
・RPAや自動化の対象を探すとき
・データベース設計の前提を整理するとき
・個人情報や機密情報の流れを確認するとき
・外部ベンダーにデータの流れを説明するとき
特に、複数のシステムや複数のExcelが混在している業務では、DFDが役立ちます。
たとえば、営業部門がExcelで顧客情報を管理し、経理部門が別システムで請求情報を管理し、倉庫部門が別の在庫システムを使っている場合、データの流れが複雑になりがちです。
DFDを使うと、どこでデータが作られ、どこで更新され、どこへ渡されているのかを整理できます。その結果、システム連携や業務改善の検討がしやすくなります。
まとめ
DFDとは、業務やシステムの中でデータがどのように流れるかを整理するためのフレームワークです。
Data Flow Diagramの略で、日本語ではデータフロー図と呼ばれます。
DFDでは、外部実体、プロセス、データストア、データフローという要素を使って、データの入口、処理、保存、出口を見える化します。
BPMNや業務フロー図が「誰が、どの順番で、何をするか」を整理するのに対して、DFDは「どのデータが、どこから来て、どこへ行くか」を整理します。
DFDを使うと、二重入力、転記作業、データの保存場所の曖昧さ、システム間連携の問題などを見つけやすくなります。また、要件定義、システム設計、業務改善、DX推進、RPA導入にも役立ちます。
最初から完璧な図を描く必要はありません。まずは、身近な業務について「入力されるデータ」「処理されるデータ」「保存されるデータ」「出力されるデータ」を書き出すところから始めてみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
要件定義フレームとは？初心者向けに意味・使い方・具体例をやさしく解説
BPMNとは？初心者向けに意味・使い方・具体例をやさしく解説
CRUDマトリクスとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
IT・システム・業務設計で使うフレームワークまとめ｜初心者向けに種類・使い方・選び方をわかりやすく解説
