すべてのデータフローダイアグラムに必要な5つの基本構成要素（例付き）

データフローダイアグラム（DFD）は、情報がシステム内でどのように移動するかを視覚的に表現したものです。システムの外観ではなく、データがどのように処理され、保存され、送信されるかに焦点を当てます。アナリストやアーキテクトにとって、この表記法を習得することは、技術的な実装の詳細に巻き込まれることなく、複雑なワークフローを理解する上で不可欠です。

このガイドでは、DFDの構造を分解します。これらの図を構成する5つの核心要素を検討し、それらがどのように相互作用するかを調べ、実用的な例を提示します。最終的に、明確で実行可能なシステムマップを作成するために必要な構造的整合性を理解できるようになります。

🧩 データフローダイアグラムとは何か？

データフローダイアグラムは、情報システム内を流れるデータの流れを図式化したものである。フローチャートとは異なり、制御論理や決定ポイントに注目するのではなく、データの移動に焦点を当てる。物理的な実装を抽象化し、情報の論理的な流れを示す。

DFDは階層的である。高レベルの視点から始まり、具体的な詳細へと掘り下げていく。このレイヤードアプローチにより、ステークホルダーはシステムを一目で理解できる一方で、開発者は具体的なデータ要件を把握できる。

• 視覚的明確性：複雑な論理を単純な形状に簡素化する。
• コミュニケーション：技術チームとビジネス関係者との間のギャップを埋める。
• 分析：ボトルネック、重複、または欠落しているデータ経路を特定するのを助ける。

🏗️ すべてのデータフローダイアグラムに必要な5つの基本構成要素

有効なDFDを構築するには、5つの特定の要素を組み込む必要がある。最初の4つは図式的な記号であるが、5つ目は正確性に不可欠な概念的な要件である。

1. プロセス（変換） 🔄

プロセスは、入力データを出力データに変換する機能を表す。システムのエンジンである。DFDでは、表記スタイル（Yourdon/DeMarco と Gane/Sarson）に応じて、通常は丸みを帯びた長方形または円で表現される。

主な特徴：

• 変換：プロセスは、データの形式または内容を変更しなければならない。データが入力と出力で変化しない場合、それはプロセスではなく、単なる流れである。
• 番号付け：プロセスは階層を明確にするために番号が付けられる（例：1.0、1.1、1.2）。
• 動詞名：名前は動詞から始めるべきである（例：「Total Calculation」ではなく「Calculate Total」）。

例：電子商取引システムを考えてみよう。プロセスの例として「支払いの検証」がある。これはクレジットカードデータ（入力）を受け取り、承認または拒否コード（出力）を返す。

2. データストア（リポジトリ） 🗄️

データストアとは、後で使用するために情報を保持する場所である。データベース、ファイル、紙のファイルボックス、または任意の永続化メカニズムを表す。重要なのは、データストアはデータを処理しないということ。単にデータを保持するだけである。

主な特徴：

• オープン対クローズド：データはストアの内外を流れることができます。ブラックホールではない。
• 命名：名前は内容を示す複数形の名詞にするべきです（例：「顧客記録」、単数の「顧客記録」ではない）。
• 処理のないもの：データストアとプロセスを混同してはならない。データが変更されている場合は、それはプロセスに属する。

例： ライブラリシステムにおいて、「書籍在庫」データストアは利用可能な書籍の詳細を保持する。書籍が貸出または返却されたときに更新される。

3. 外部エンティティ（インタラクター） 👥

外部エンティティは、モデル化されているシステムの境界外にあるデータの発生源または目的地である。これらは、主システムとやり取りするが、その内部論理の一部ではない人物、組織、または他のシステムを表す。

主な特徴：

• 境界：これらはシステムの範囲を定義する。ボックスの外にあるものはすべて外部エンティティである。
• 種類：人間のユーザー（例：「顧客」）、他のシステム（例：「銀行API」）、政府機関（例：「税務当局」）などがある。
• 役割：入力を提供するか、出力を受信する。システムのデータを保存しない。

例： 給与システムにおいて、「従業員」は、勤務時間の提供と給与の受領を行う外部エンティティである。

4. データフロー（移動） 🚚

データフローはプロセス、データストア、外部エンティティを結ぶ矢印である。これらはデータの移動を表す。データフローには、転送されるデータの内容を説明する名前が必要である。

主な特徴：

• 方向：フローは単一の方向を持つ。データが双方向に移動する場合は、2本の矢印が必要である。
• 内容：ラベルは具体的でなければならない（例：単に「インボイス」ではなく「検証済みインボイス」など）。
• 保守:データは消えることはできません。すべての出力には、対応する入力またはソースが必要です。

例: 「ログイン」プロセスから「ユーザーDBデータストアを結ぶ矢印は「認証リクエスト」.

5. データ辞書（定義） 📚

図面上には描かれていないが、データ辞書は完全なDFD仕様の5つの必須要素の一つである。これは、図で使用されるすべてのデータ要素の構造、型、フォーマットを定義する中央集積型リポジトリである。これがないと、図は曖昧になってしまう。

主な特徴:

• 標準化:1つのプロセスにおける「顧客ID」と別のプロセスにおける「顧客ID」が同一であることを保証する。
• メタデータ:データ型（整数、文字列、日付）、長さ、許可される値を定義する。
• 参照:特定のデータフローを、その詳細な定義にリンクする。

例: 辞書は「生年月日」を「YYYY-MM-DD」と定義し、null値を許可しない。これにより、プロセス内の論理エラーを防ぐことができる。

📋 コンポーネント比較表

設計段階で各コンポーネントの特性をすばやく参照するために、この表を使用してください。

コンポーネント	記号の形状	機能	例のラベル	文法ルール
プロセス	角丸長方形／円	データを変換する	税金を計算する	動詞＋名詞
データストア	開かれた長方形／平行線	データを保存する	注文履歴	名詞（複数形）
外部エンティティ	正方形／長方形	ソース／シンク	銀行システム	名詞（単数形）
データフロー	矢印	データを移動する	支払い詳細	名詞句
データ辞書	文書／リスト	データを定義する	データ定義	技術的スキーマ

📉 DFDの詳細レベル

DFDはほとんど孤立して描かれない。それらは、異なる抽象レベルを許す階層構造の中に存在する。これらのレベルを理解することで、各段階で5つの構成要素が正しく適用されることを保証できる。

コンテキスト図（レベル0）

これは最高レベルのビューです。システム全体を単一のプロセスとして表示します。外部エンティティと、システムに入出する主要なデータフローを特定します。

• 注目点：範囲と境界。
• 構成要素：1つのプロセス、3つ以上の外部エンティティ、複数のデータフロー。
• 詳細：データストアやサブプロセスは表示されません。

レベル0図（基本モデル）

この図では、コンテキスト図の単一プロセスを主要なサブプロセスに分解します。内部データストアおよびプロセスの最初のレイヤーを導入します。

• 注目点：主要な機能領域。
• 構成要素：すべての5つの構成要素がここに表示されます。
• 詳細：システムの主要な部分がどのように相互作用するかを示します。

レベル1図（詳細ビュー）

このレベルでは、レベル0のプロセスをその構成要素となる機能に分解します。詳細設計および開発に使用されます。

• 注目点：特定の論理およびデータ処理。
• 構成要素：細分化されたデータフローおよび特定のデータストア。
• 詳細：高精度。開発者によって使用されます。

🛠️ 効果的な図の設計

DFDを作成することは反復的なプロセスです。図が有用かつ正確なまま保つために、以下の構造ルールに従ってください。

1. バランス

プロセスを低レベルに分解する際、入力と出力は一貫性を保たなければなりません。親プロセスが「注文データ」を受け取る場合、子プロセスはその同じ「注文データ」を総合的に処理しなければなりません。データをゼロから創出したり、破壊したりすることはできません。

2. 名前付け規則

一貫性が鍵です。すべての構成要素に対して標準化された名前付け規則を使用してください。組織内で普遍的に理解されている場合を除き、略語を避けてください。ある図で「Invoice」とラベル付けされたデータフローが、別の図で「Bill」とラベル付けされないことを確認してください。

3. コントロールフローの回避

一般的な誤りは、制御論理（if/else）をDFDに混入することです。DFDはデータの移動を示すものであり、意思決定の論理ではありません。制御論理には決定表やフローチャートを使用してください。DFDでは、決定ポイントは入力に基づいて異なるデータフローを出力するプロセスとして表現されます。

4. データストアの接続性

データストアは、新規作成またはアーカイブでない限り、入力と出力の両方を持つ必要があります。データを受け入れるだけのストアはブラックホールです。データを提供するだけのストアは奇跡（何もないところからの創造）です。両方ともシステム論理に反します。

🚧 避けるべき一般的な誤り

経験豊富なモデラーでさえ誤りを犯します。これらの一般的な落とし穴を確認することで、分析フェーズでの時間を節約できます。

• ゴーストフロー：データ辞書に定義のない矢印を描くこと。
• エンティティ同士の直接接続：外部エンティティは他の外部エンティティに直接接続してはいけません。すべての相互作用はシステムプロセスを経由しなければなりません。
• プロセス間のループ：データストアや外部エンティティが介在しない限り、プロセスAがプロセスBにデータを供給し、プロセスBがプロセスAにデータを供給する無限ループを避けてください。
• 過密化：図に7～9個以上のプロセスがある場合、それはおそらく複雑すぎるでしょう。ビューを分割するために、より低いレベルの図を使用してください。
• 辞書の無視：データ辞書を更新せずに図を作成すると、後で実装エラーが発生します。

🌐 実践例：オンライン注文システム

5つの要素を現実のシナリオに適用してみましょう。簡略化されたオンライン注文システムを想像してください。

外部エンティティ

• 👤 顧客
• 🏦 支払いゲートウェイ

プロセス

• 1.0 注文受領
• 2.0 支払い処理
• 3.0 在庫更新

データストア

• 🗄️ 注文データベース
• 📦 在庫記録

データフロー

• 🚚 注文詳細（顧客 → プロセス 1.0）
• 🚚 支払い確認（プロセス 2.0 → 支払いゲートウェイ）
• 🚚 在庫確認（プロセス 3.0 → 在庫記録）

データ辞書エントリ

• 注文詳細： {注文ID、日付、顧客名、商品リスト、合計金額}

🔗 他のモデルとの統合

DFDは孤立して存在するものではない。しばしば他のモデリング手法と補完し合う。

• エンティティ関係図（ERD）： ERDはDFDに示されるデータストアの構造を定義する。
• 状態遷移図： DFDはデータの流れを示すが、状態図はオブジェクトが時間とともに状態をどのように変化させるかを示す。
• ユースケース図： ユースケースはユーザーとのインタラクションを記述するが、DFDはそのインタラクションの裏にあるデータを記述する。

🎯 最良の実践方法の要約

データフローダイアグラムが価値を提供することを確実にするため、以下の原則を心に留めておくこと。

1. シンプルから始める：境界を明確にするために、コンテキスト図から始めること。
2. データをまず定義する：フローを描く前に、データ辞書を更新すること。
3. 一貫性を確認する：親図と子図のデータ入出力が一致していることを確認する。
4. 簡潔に保つ：線が交差しないようにし、スペースの配置を一貫性を持たせる。
5. ステークホルダーとレビューする：論理的なフローがビジネスの期待に合致していることを確認する。

これらの5つの要素を厳密に適用し、構造的なルールに従うことで、システム開発の堅実なブループリントが作成される。この明確さにより、曖昧さが減少し、再作業が最小限に抑えられ、最終的な実装が意図されたデータアーキテクチャと一致することを保証する。

思い出してください。DFDは生きている文書である。要件が変化するたびに、図はシステムの新しい現実を反映するために進化しなければならない。図と併せてデータ辞書を定期的にメンテナンスすることは、成熟した分析プロセスの特徴である。