データフロー図（DFD）：レベル、シンボル、実践的な例
適切な表記法でデータフロー図を作成する方法を学びましょう。DFDレベル0〜2、Yourdon-DeMarco対Gane-Sarsonシンボル、実際の例を網羅しています。
システムが壊れたり、プロセスが誤った出力を生成したりすると、最初の質問は通常「どこでデータが間違ったのか？」です。データフロー図（DFD）は、データの移動を明示的にすることでこの質問に答えます。データがどこから来て、どこへ行き、どのように変換され、どこに保存されるかを正確に示します。
制御フロー（次に何が起こるか）をモデル化するフローチャートとは異なり、DFDはデータフロー（どのデータがどこに移動するか）をモデル化します。この違いが、システム分析、ソフトウェア設計、複雑なデータ統合のドキュメント化に適切なツールとなります。
データフロー図とは？
データフロー図は、データがシステムを通じてどのように移動するかを視覚的に表現したものです。以下を示します：
- 外部エンティティ — システム外のデータのソースと宛先
- プロセス — 入力データを出力データに変換する変換
- データストア — データが静止して保持される場所
- データフロー — 上記の要素間のデータの移動
DFDはタイミング、判断ロジック、または誰がタスクを実行するかを示しません。データの移動のみを示します。この焦点を絞ったスコープにより、実装の詳細に迷うことなくシステムを理解し設計するのに役立ちます。
DFDのシンボル
2つの表記法が主流です：Yourdon-DeMarcoとGane-Sarson。どちらも異なる形状で同じ概念を表現します。
Yourdon-DeMarco表記法
ソフトウェアエンジニアリングで広く使用されているオリジナルの構造化分析表記法：
| 要素 | シンボル | 説明 |
|---|---|---|
| プロセス | 円（バブル） | データを変換する；動詞句でラベル付け |
| データストア | 開いた端の長方形 | データを格納する；名詞でラベル付け |
| 外部エンティティ | 長方形 | システム外のソースまたは宛先 |
| データフロー | ラベル付き矢印 | 要素間を移動する名前付きデータ |
┌──────────┐ ╭──────────╮ ┌═══════════════╗
│ 顧客 │───────→ │ 注文 │───────→ ║ D1: 注文 ║
└──────────┘ 注文 │ 検証 │ 有効 ╠═══════════════╣
╰──────────╯ 注文 ║ ║
Gane-Sarson表記法
情報システムとビジネス分析で一般的：
| 要素 | シンボル | 説明 |
|---|---|---|
| プロセス | 角丸長方形（分割ヘッダー付き） | IDとプロセス名でラベル付け |
| データストア | 左側が開いた長方形 | D番号と名前でラベル付け |
| 外部エンティティ | 長方形 | システム外のソースまたは宛先 |
| データフロー | ラベル付き矢印 | 要素間を移動する名前付きデータ |
┌──────────┐ ┌────────────────┐ ┌═══╦════════════╗
│ 顧客 │───────→ │ 1.0 │───────→ ║D1 ║ 注文 ║
└──────────┘ 注文 │ 注文検証 │ 有効 ╚═══╩════════════╝
└────────────────┘ 注文
どの表記法を使用するか？
両方とも同じ情報を伝えます。コンテキストに基づいて選択してください：
- Yourdon-DeMarco：ソフトウェアエンジニアリング、学術、構造化分析手法の使用時に推奨
- Gane-Sarson：ビジネス情報システムとエンタープライズコンテキストで一般的
1つを選択し、プロジェクトのすべての図を通じて一貫性を保ちます。
DFDのレベル
DFDは階層的に構成されています。上位レベルの図は概要を提供し、下位レベルの図は詳細を提供します。各レベルは上位レベルの単一プロセスをその内部サブプロセスに分解します。
レベル0：コンテキスト図
コンテキスト図はシステム全体を単一のプロセスとして示し、外部エンティティに囲まれています。システムの境界を定義し、その境界を越えるデータを示します。
顧客注文
┌──────────┐ ─────────────────→ ╭──────────────────────╮
│ 顧客 │ │ │
└──────────┘ ←───────────────── │ 注文管理 │
注文確認 │ システム │
│ │
┌──────────┐ ─────────────────→ ╰──────────────────────╯
│ サプライヤー │ 在庫更新 │
└──────────┘ ↓
┌──────────────┐
│ 決済処理 │
└──────────────┘
コンテキスト図は1ページに収まり、境界を越えるデータフローのみを示すべきです—内部の詳細なし。内部プロセスを追加している場合は、間違ったレベルにいます。
レベル1：概要図
レベル1の図は単一のコンテキストプロセスをその主要なサブプロセスに分解します。これらがシステムの主要な機能領域です。
┌──────────┐ ╭──────────╮ ╭──────────╮
│ 顧客 │───────→ │ 1.0 │───────→ │ 2.0 │───┐
└──────────┘ 注文 │ 注文受付 │検証済み │ 支払処理 │ │
│ │ 注文 │ │ │
╰──────────╯ ╰──────────╯ │
│ ↓
↓ ╭──────────╮
┌════════════════╗ │ 3.0 │
║ D1: 注文 ║────────────→ │ 注文 │
╚════════════════╝ 注文データ │ フルフィル│
╰──────────╯
│
↓
┌──────────┐
│ 配送 │
│ パートナー│
└──────────┘
レベル1の図には通常3〜7つのプロセスがあります。それ以上ある場合は、より少ない高レベルのプロセスにグループ化することを検討してください。
レベル2：詳細図
レベル2は各レベル1のプロセスをそのサブステップに分解します。レベル1の各バブルはそれ自体のレベル2の図を取得します。
例えば、上記のプロセス1.0「注文受付」を展開すると：
┌──────────┐ ╭──────────╮ ╭──────────╮
│ 顧客 │──────────→ │ 1.1 │──────────→ │ 1.2 │
└──────────┘ 生の注文 │ フォーマット│ 有効データ │ 在庫 │
│ 検証 │ │ 確認 │
╰──────────╯ ╰──────────╯
│ │ │
無効 │ 在庫あり
注文 在庫 │
↓ なし ↓
┌──────────┐ ╭──────────╮
│ 顧客 │ │ 1.3 │
└──────────┘ │ 商品 │
│ 確保 │
╰──────────╯
│
↓
┌════════════╗
║ D1: 注文 ║
╚════════════╝
どのくらい深くすべきか？
プロセスが以下の場合に分解を止めます：
- 数文で説明できるほどシンプル
- 1人または原子的なシステム機能によって実装される
- 実装に必要な詳細レベルに達している
ほとんどのシステムはレベル2以上は必要ありません。レベル3は稀で、システムが複雑すぎるか、分解が適切に構造化されていないことを示すことが多いです。
DFD対フローチャート
どちらも箱と矢印を使用するため混同されることがよくあります。しかし、それぞれ異なる質問に答えます。
| 側面 | データフロー図 | フローチャート |
|---|---|---|
| 示すもの | データがシステムを通じてどのように移動するか | 制御がプロセスを通じてどのように流れるか |
| 主な質問 | どのデータがどこへ行くか？ | 次に何が起こるか？ |
| 時間/シーケンス | モデル化されていない（データ変換のみ） | 中心的 — シーケンスが主な構造 |
| 判断ロジック | 表現されていない | 明示的（ひし形の判断ノード） |
| 誰が実行するか | 示されていない | スイムレーン形式で示せる |
| データストレージ | 明示的なデータストアシンボル | 表現されていない |
| 最適用途 | システム分析、データアーキテクチャ | プロセスドキュメント、手順ガイド |
フローチャートはローン承認プロセスのステップを示します。DFDはローン申請システムが受け取るデータ、それがどこに保存されるか、どの出力を生成するかを示します。
システムを分析または設計する際にはDFDを使用します。手順をドキュメント化する際にはフローチャートを使用します。
ステップバイステップ：DFDの作成
ステップ1：システムの境界を定義する
システムの内側と外側を特定します：
- 内側： 制御するプロセス、データストア、データフロー
- 外側： 外部エンティティ — 顧客、パートナー、外部システム
境界の外側のすべては外部エンティティです。境界を越えるデータはコンテキスト図のフローとして表示されます。
ステップ2：コンテキスト図を描く（レベル0）
- システム全体を中央に単一のラベル付き円として配置する
- すべての外部エンティティを特定し、外側に配置する
- 説明的なラベルで境界を越えるデータフローを描く
- 完全性を確認する：システムに入出力するすべてのデータにラベルが付いているか？
ステップ3：主要プロセスを特定する（レベル1）
システムを3〜7つの主要プロセスに分解します：
- 各プロセスに動詞句の名前を付ける（「注文検証」、「支払処理」）
- 番号を付ける（1.0、2.0、3.0）
- どのデータフローがそれらを接続するかを特定する
ステップ4：データストアを追加する
プロセス間でデータが保持される場所を特定します：
- データベース：顧客レコード、注文履歴、在庫
- ファイル：ログファイル、設定
- 外部データ：外部システムとの間で渡されるデータ（多くの場合、内部ストアではなく境界フローとして表現）
各データストアに名詞でラベルを付け、D番号（D1、D2）を割り当てます。
ステップ5：データフローで接続する
要素間にラベル付きの矢印を描きます：
- フローには説明的な名前が必要（「顧客注文」、「検証済みレコード」、「請求書」）
- フローはプロセスからプロセス、プロセスからデータストア、外部エンティティからプロセスを接続する
- データストアは外部エンティティに直接接続しない（データはプロセスを通過する必要がある）
ステップ6：レベル2に分解する
レベル1の各主要プロセスについて、その内部サブプロセスを示す別のレベル2の図を描きます。レベル1のプロセスに入出力するデータフローは、レベル2の図の境界フローになります。
ステップ7：一貫性を検証する
以下を確認します：
- プロセスに入るすべてのデータフローがそのプロセスで使用されているか
- プロセスから出るすべてのデータフローがそのプロセスから発生しているか
- データストアはプロセスを通じてのみアクセスされているか（外部エンティティから直接アクセスされていないか）
- レベル1の境界フローがコンテキスト図のフローと一致しているか
実際の例：Eコマース注文システム
レベル0：コンテキスト図
┌──────────┐ 注文リクエスト ╭──────────────────────╮
│ 顧客 │ ────────────────→ │ │
└──────────┘ │ Eコマース │
↑ 注文ステータス │ 注文システム │
└───────────────────── ─ │ │
╰──────────────────────╯
┌──────────┐ 決済結果 │ ↑
│ 決済 │ ────────────────→ │ │
│ ゲートウェイ│ ←──────────────── │ 出荷
└──────────┘ 請求リクエスト ↓ データ
┌──────────────┐
│ 配送 │
│ パートナー │
└──────────────┘
レベル1：主要プロセス
顧客 ─── 注文リクエスト ──→ ╭──────────╮
│ 1.0 │ ──→ D1: 注文
│ 注文 │
│ 検証 │
╰──────────╯
│
検証済み注文
↓
決済GW ←── 請求 ── ╭──────────╮ ── 決済 ──→ D2: 決済
リクエスト│ 2.0 │ 記録
決済GW ── 結果 ──→ │ 支払 │
│ 処理 │
╰──────────╯
│
確認済み注文
↓
╭──────────╮
D1: 注文 ── 注文データ ───→ │ 3.0 │ ── 出荷リクエスト ──→ 配送
D3: 製品 ─ 在庫データ ───→ │ 注文 │ パートナー
│ フルフィル│
╰──────────╯
│
出荷データ
↓
╭──────────╮
│ 4.0 │ ── ステータス更新 ──→ 顧客
│ 追跡＆ │
│ 通知 │
╰──────────╯
レベル2：プロセス1.0の分解（注文検証）
顧客 ─── 生の注文 ──→ ╭──────────╮
│ 1.1 │ ── 無効 ──→ 顧客（エラー）
│ フォーマット│
│ 確認 │
╰──────────╯
│
フォーマット済み注文
↓
╭──────────╮
D3: 製品 ─ 在庫情報 ─→│ 1.2 │ ── 在庫なし ──→ 顧客
│ 在庫 │
│ 確認 │
╰──────────╯
│
利用可能な注文
↓
╭──────────╮
D4: 顧客 ─ 認証データ ─→│ 1.3 │ ── 未確認 ──→ 顧客
│ 顧客 │
│ 確認 │
╰──────────╯
│
検証済み注文
↓
D1: 注文（保存）
よくあるDFDの誤り
外部エンティティをデータストアに直接接続する。 データストアは内部のものです；外部エンティティは直接アクセスできません。システムの境界を越えるすべてのデータはプロセスを通過する必要があります。
ラベルのないデータフロー。 すべての矢印には説明的な名前が必要です。「データ」や「情報」は説明的ではありません。フローはデータが何を表すかで名付けられるべきです：「顧客注文」、「支払い確認」、「在庫レベル」。
入力または出力のないプロセス。 プロセスには少なくとも1つの入力フローと1つの出力フローが必要です。入ってくるデータがない円は何もないからデータを「作成」しています—それはプロセスではなく外部エンティティです。出ていくデータがない円はすべてを破棄します—それをデータストアへの書き込みとしてモデル化するか、プロセスを削除します。
制御フローとデータフローの混在。 判断、シーケンス、制御ロジックはDFDに属しません。判断のひし形を描いている場合は、DFDではなくフローチャートを作成しています。DFDはデータの移動のみを示します。
レベル1での詳細すぎる内容。 レベル1には3〜7つの主要プロセスがあるべきです。レベル1で15のプロセスを示している場合は、階層的な分解をスキップしています。関連するプロセスを高レベルのバブルにグループ化し、レベル2を使用して詳細を示します。
レベルの不一致。 レベル1の図のプロセス2.0に入るデータフローは、プロセス2.0のレベル2の図の境界フローと一致しなければなりません。不一致は図が同じシステムを表していないことを意味します。
説明なしにサブシステム間で共有されるデータストア。 複数のプロセスが同じデータストアにアクセスする場合、それが意図的であり、アクセスが意味をなすことを確認してください。単一の「メインデータベース」データストアを過剰に使用すると、重要なデータアーキテクチャの決定が隠れます。
FlowavaでDFDを作成する
データフローを手動でマッピングするのは面倒です—すべての境界フローを特定し、プロセスに一貫して番号を付け、レベルを同期させるには多大な労力が必要です。
Flovovaのデータフロー図メーカーは、平易な言語によるシステムの説明からDFD構造を生成します。システムの入力、出力、主要プロセスを説明して、洗練できる下書き図を取得します。これは特にコンテキスト図とレベル1の概要を素早く作成し、その後必要なプロセスのレベル2の詳細に掘り下げるのに役立ちます。
まとめ
DFDは、システムを通じてデータがどのように移動するかを理解または伝達する必要がある場合の適切なツールです—ステップバイステップで何が起こるかではなく、データがどこから来て、何が変換し、どこに保存され、最終的にどこへ行くか。
コンテキスト図から始めてシステムの境界を確立します。レベル1に分解して主要プロセスを特定します。さらなる明確化が必要なプロセスのみレベル2に進みます。データフローに具体的な名前を付け、制御ロジックを図に混在させず、レベル間の一貫性を検証します。
関連リソース
- フローチャートのシンボルと意味 — 標準表記法のリファレンス
- BPMNダイアグラムガイド — ビジネスプロセスモデリング標準
- データフロー図メーカー — AIでDFDを作成
- システムアーキテクチャテンプレート — すぐに使えるアーキテクチャ図テンプレート
