DFDとは？ わかりやすく10分で解説

DFD（Data Flow Diagram）とは

DFD（データフロー図）は、「データがどこから来て、どこへ流れ、どの処理で形を変え、どこに保存されるのか」を、図で整理するための設計ツールです。とくに、依頼側（業務側）と開発側（設計・実装側）の認識合わせに強く、システムの全体像を共有しながら、機能の漏れ・重複・前提のズレを早い段階であぶり出すのに役立ちます。

DFDが扱うのは、画面レイアウトやクラス設計といった「作り込みの詳細」ではなく、処理の単位（プロセス）とデータの流れ（データフロー）、データの保管（データストア）、外部とのやり取り（外部エンティティ）です。つまり、仕様の骨格を「データ中心」に捉え直すことで、システムを理解しやすくします。

この記事では、DFDの基本概念、記号の読み方、作成の手順とルール、レイヤリング（階層化）の考え方、データディクショナリやプロセス詳細化ドキュメントとの関係まで、実務で迷いやすいポイントを補強しながら解説します。

DFDの定義

DFD（Data Flow Diagram）は、システム内のデータの移動と、移動の途中で行われる処理、処理結果の保存、および外部との入出力を表す図です。

主要な要素は次の4つです。

• データフロー：データの移動（矢印）
• プロセス：データを変換・判断・集計・更新する処理（丸・角丸など）
• データストア：データを保存する場所（DB、ファイル、キュー、台帳など）
• 外部エンティティ（外部実体）：システム外部の人・組織・別システム（ソース／シンク）

DFDは、構造化分析の代表的な成果物として広く知られ、記法としてはデマルコ（DeMarco）式やゲイン・サーソン（Gane-Sarson）式などが用いられます。どちらを選ぶ場合でも、目的は共通で、「関係者が同じ理解を持てること」が最優先です。

DFDの目的と利用シーン

DFDの目的は、システムのデータの流れを明確にし、設計者・利用者・開発者が“何が起きるか”を同じ地図で語れる状態を作ることです。仕様検討の初期ほど効果が大きく、以下のような場面で活用されます。

• 新規開発：要件定義〜基本設計で全体像を固める
• 既存改修：影響範囲（どのデータがどこで使われるか）を洗い出す
• 業務プロセス改善：データの滞留・二重入力・手戻りポイントを見つける
• データ連携：外部システムとの入出力の境界・責務分担を明確化する

事前にDFDで合意を取っておくと、「そのデータはどこで作られる？」「その更新は誰が責任を持つ？」といった論点が前倒しで整理でき、後工程の手戻りを減らせます。

DFDの起源と歴史

DFDは1970年代に、情報システムの複雑化に対応するための手法として発展しました。構造化分析・構造化設計の文脈で、トム・デマルコやエドワード・ヨードンらによって整理され、実務で使いやすい記法として広まりました。

現在では、UMLなど別のモデリング手法が主流の現場もありますが、DFDは「データ中心で全体像を短時間で共有できる」という強みから、要件の初期整理や現状分析の場面で今も有効です。

DFDと他の設計ツールとの比較

DFDはデータの流れを主役に据えた図です。似た図としてUMLやER図がありますが、焦点が異なります。

• DFD：データがどこから来て、どの処理で変わり、どこへ行くか（流れと変換）
• ER図：データの構造（エンティティ間の関係、属性、正規化）
• UML：ソフトウェアの構造・振る舞い（クラス図、シーケンス図、状態遷移図など）

実務では、DFDで全体の流れを合意 → ER図でデータ構造を確定 → UMLで実装設計を詰めるのように、目的に応じて組み合わせると迷いが減ります。

DFDの構造と記号

DFDには「データフロー」「プロセス」「データストア」「外部エンティティ（外部実体）」という4要素があります。ここを押さえるだけで、DFDの読み書きはかなり安定します。

データフローとは

データフローは、システム内で移動するデータの流れを表します。一般に矢印で描き、矢印の向きがデータの移動方向です。

実務上のコツ：データフローには、できるだけ名詞（例：注文情報、認証要求、更新結果）で名前を付けます。曖昧な「データ」「情報」だけだと、後で読み返したときに意思疎通が崩れがちです。

プロセスとは

プロセスは、入力データを受け取り、何らかの処理を行って出力データへ変換する箱です。丸や角丸などで表現されます。

プロセスの命名：「〜する」「〜を更新する」「〜を照合する」などの動詞句で書くと、役割が明確になります（例：注文を登録する、ユーザーを認証する）。

注意点：プロセスには原則として入力と出力の両方が必要です。入力だけのプロセスは「ブラックホール」、出力だけのプロセスは「ミラクル（魔法）」と呼ばれ、仕様の欠落を疑うサインになります。

データストアとは

データストアは、データが保存される場所（DB、ファイル、台帳、ログ、メッセージキューなど）を表します。一般には二本線などで描きます。

ポイント：データストアは「保管庫」なので、原則としてプロセスを介して読み書きします。つまり、データストア→データストアや外部エンティティ→データストアの直結は避け、間にプロセスを置いて「誰が何の目的で更新するのか」を明確にします。

外部エンティティ（外部実体）の意味

外部エンティティは、システム外部の人・組織・他システムを表します。外部から入力される場合はソース、外部へ出力する場合はシンク（吸収）として扱います。

外部エンティティを置くと、「システムの境界」がはっきりします。どこまでが自システムの責務で、どこからが外部の責務なのかを図の時点で合意できるため、後のトラブル（責任範囲の曖昧さ）を減らせます。

DFDの書き方とルール

DFDは「描けば終わり」ではなく、ルールに沿って描くほど、レビューで不整合を見つけやすくなるのが強みです。ここでは、作成の流れと、実務で頻出するルール・ミスをまとめます。

DFDを始める前に

最初に押さえるべきは、4要素の役割と、図のスコープ（システム境界）です。加えて、詳細化が進むほど重要になるのがデータディクショナリ（データ定義書）です。

DFDは「線と箱」で流れを示しますが、線に書かれた「注文情報」とは具体的に何か、どの項目が含まれるのか、といった情報は図だけでは足りません。そこでデータディクショナリを併用し、言葉のズレを減らします。

デマルコ式とゲイン・サーソン式の違い

どちらも目的は同じで、記号の形が主な違いです。重要なのは「方式の優劣」ではなく、プロジェクト内で混在させないことと、関係者が読める形にすることです。

• デマルコ式：シンプルで直感的。初学者にも説明しやすい。
• ゲイン・サーソン式：プロセスを四角形で表しやすく、図面として整理しやすい。

ステップバイステップでDFDを書く

迷ったら、まずはトップダウンで進めるのが安定です。

1. コンテキスト図（最上位）：システムを1つのプロセスとして描き、外部エンティティとの入出力だけを示す
2. レベル0（Level-0）：主要プロセスに分解し、データストアを含めた全体像を描く
3. レベル1以降：複雑なプロセスをさらに分解して詳細化する

補強ポイント：分解したら必ずバランス（整合）を確認します。上位レベルで出入りしていたデータフローが、下位レベルで突然消えたり増えたりすると、仕様の欠落や過剰設計が起きます。

DFD作成時のエラーとその回避策

DFDのミスは「図としての描き間違い」と「設計としての欠落」の両方が起きます。頻出パターンを押さえておくと、レビューが速くなります。

• ブラックホール：入力はあるが出力がない（処理結果がどこにも行かない）
• ミラクル：出力はあるが入力がない（根拠のないデータ生成）
• グレーホール：入力に対して出力が過大・過小（処理内容が説明不足）
• 直結ミス：外部エンティティ↔データストア、データストア↔データストアを直結してしまう
• 命名の曖昧さ：「データ」「情報」だらけで、何が流れているのか不明

回避策としては、(1) 命名ルール（名詞／動詞）を決める、(2) 上位・下位でバランス確認をする、(3) 第三者レビューを入れる、の3つが効果的です。

DFDとレイヤリング

DFDの強みは、階層化（レイヤリング）で複雑さを制御できる点です。一枚に詰め込みすぎず、理解の単位に分けることで、関係者が「今どの粒度の話をしているか」を揃えられます。

コンテキストダイアグラムとは

コンテキスト図は、システム全体を1つのプロセスとして扱い、外部エンティティとの入出力だけを描く最上位の図です。ここでのゴールは、境界（スコープ）を確定することです。

「どこまでを自システムでやり、どこからが外部か」が曖昧だと、後で要件が膨らみます。まずはコンテキスト図で合意してから詳細に進むと、ブレにくくなります。

システムをレイヤリングする意味

大規模なシステムは、全体像だけでは理解しきれません。レイヤリングにより、一度に見る範囲を限定し、プロセス・データフロー・データストアを「説明可能な単位」に分けます。

レイヤリングは、理解だけでなく、設計・改修の効率にも効きます。たとえば改修案件では、該当プロセスがどのレベルにあり、どのデータストアに影響するかが追いやすくなります。

レイヤリングのテクニック

レイヤリングの基本は「分解（decomposition）」です。分解の粒度はプロジェクトにより異なりますが、目安としては次のように考えると安定します。

• 1プロセスが1〜2文で説明できないなら分解候補
• 入力・出力が多すぎて線が交差しまくるなら分解候補
• 担当チームや責務が異なる処理が同居しているなら分解候補

分解したら、上位レベルと下位レベルの入出力の整合（バランス）を必ず確認します。

DFDとデータディクショナリ

DFDは「流れ」、データディクショナリは「中身」を担当します。両者をセットで運用すると、“同じ単語を使っているのに指しているものが違う”という典型的な事故を減らせます。

データディクショナリとは

データディクショナリは、システム内のデータに関する情報を集約した定義書（リポジトリ）です。代表的には次のような情報を持ちます。

• データ項目名（論理名／物理名）
• 型・桁数・必須/任意・制約（例：NULL不可、コード体系）
• 生成元（どのプロセスで作るか）
• 利用先（どのプロセスで参照するか）
• 保存先（どのデータストアに入るか）

データディクショナリの使用方法

データディクショナリは、DFDのデータフロー名・データストア名と対応づけて使うと効果的です。たとえば「顧客情報」というフローが出てきたら、その構成（顧客ID、氏名、契約状態など）を定義書で参照できるようにします。

また、改修案件では「どの項目がどのプロセスに影響するか」を追跡するのに役立ちます。結果として、テスト観点の漏れや、想定外の副作用を減らせます。

DFDとデータディクショナリの協調

DFDの各要素（フロー／ストア／プロセス）が、データディクショナリやミニ仕様書に参照される状態が理想です。図だけ・文書だけに偏ると、どちらかが更新されずにズレが生まれます。

データディクショナリ作成のヒント

• 命名を統一：DFDと同じ呼称を使う（別名が増えるほど混乱します）
• コード体系を明記：ステータス値、区分値は定義を固定する
• 更新ルールを明確化：いつ・誰が・何を更新するか（責務）を記載する
• 最新版を維持：運用の途中で古くなると、参照されなくなります

プロセスの詳細化

DFDは抽象度が高い分、プロセスの中身は別ドキュメントで補うのが定石です。ここでは代表的な2つのツール、ミニ仕様書とデシジョンテーブルを紹介します。

ミニ仕様書とは

ミニ仕様書は、DFD上の「1プロセス」に対して、処理内容を文章で補足する文書です。最低限、次の観点があると“実装に落ちる仕様”に近づきます。

• 入力（どのフローを受け取るか）
• 前提条件・バリデーション（何を満たす必要があるか）
• 処理（何をどう変換・判断するか）
• 出力（どのフロー／ストアを更新するか）
• 例外・エラー時の扱い（何を返すか、どこに記録するか）

デシジョンテーブルとは

デシジョンテーブルは、条件が多い判断ロジックを整理する表です。とくに「条件の組み合わせ」で結果が変わる処理（割引、権限、状態遷移など）で効果を発揮します。

条件を列、アクション（結果）を行として整理することで、抜け（未定義の組み合わせ）や矛盾（同じ条件で結果が複数）が見つけやすくなります。

ミニ仕様書とデシジョンテーブルの相互関係

ミニ仕様書が「処理の説明書」だとすると、デシジョンテーブルは「判断のルール表」です。両方を組み合わせると、文章の曖昧さを減らし、レビューも実装も進めやすくなります。

効果的なミニ仕様書とデシジョンテーブルの書き方

詳細化では、情報を盛りすぎないことも重要です。目安としては、プロセスを読んだ人が“入出力と判断基準”を再現できるくらいまで書けば十分です。細部（UI、例外の全パターン）は、必要に応じて別資料へ切り出します。

FAQ