DFD（データフロー図）は、システム内のデータの流れを視覚的に整理するための設計図です。要件定義から業務分析、データガバナンスまで幅広い場面で活用されており、エンジニアと業務担当者が共通の認識をつくるためのコミュニケーションツールとしても機能します。
本記事では、DFDの基本概念から書き方・記号・よくある失敗パターンまで、実務で役立つ知識を体系的に解説します。
目次
DFD（データフロー図）とは
DFD（データフロー図）がどのようなものか、まず基本的な定義とシステム設計における役割を押さえましょう。DFDで表現できることとできないこと、活用される主なシーンについて詳しく解説します。
DFDの定義とシステム設計における役割
DFD（データフロー図）とは、システムを通じてデータがどのように流れ、処理され、保管されるかを図示した設計ドキュメントです。「Data Flow Diagram」の略称で、1970年代にエドワード・ヨードンとトム・デマルコが体系化した構造化分析手法の中核として確立されました。
システム設計においてDFDが担う主な役割は、「データの流れの可視化」と「業務プロセスの整理」の2点です。複雑なシステムでも、データの入出力・処理・保管という観点で整理することで、関係者が共通認識を持つための基盤となります。エンジニアだけでなく、業務担当者や経営層との議論にも使えるシンプルさが、DFDの強みのひとつといえます。
DFDで表現できること・できないこと
DFDが表現できることは、主にデータの流れと処理の関係性です。どこからデータが入力され、何のプロセスを経て、どこに出力・保管されるかを明確に示せます。システムの全体像を俯瞰したり、業務の境界を整理したりする際に特に効果的です。
一方、DFDには表現できない領域があります。処理の順序・時間的な流れ・条件分岐といった「ロジック」は対象外であり、データの構造や属性の詳細も記述できません。DFDは「何を処理するか」を把握するためのツールであり、「どう処理するか」を記述するフローチャートや、「何のデータか」を定義するER図とは役割が異なります。目的に応じた使い分けが重要です。
DFDが活用される主なシーン
DFDは、システムの要件定義フェーズや業務分析において特に効果を発揮します。業務担当者とシステム開発者が共通の図をもとに議論できるため、認識のズレを防ぐコミュニケーションツールとして機能します。
既存システムのリプレイス時には、現行のデータフローを整理する手段としても重宝されます。さらに近年では、データガバナンスやデータリネージの可視化、セキュリティ設計における脅威分析にもDFDの考え方が応用されるケースが増えており、要件定義から運用管理まで幅広い文脈で活躍します。
DFDの基本構成要素と記号の見方
DFDは、4種類の基本要素によって構成されます。記法によって記号の形に若干の違いはありますが、意味と役割は共通です。各要素の特徴と実務での注意点について詳しく解説します。
プロセス（データを処理する機能）
プロセスは、入力データを何らかの処理によって出力データに変換する機能を表します。Yourdon記法では丸（円）、Gane-Sarson記法では角丸四角形で描かれます。プロセスには必ず入力と出力のデータフローが存在し、片方だけしかない状態は設計上のエラーです。
現場では「入力だけあって出力がない」状態を「ブラックホール」、「出力だけあって入力がない」状態を「ミラクルソース」と呼び、レビュー時の確認ポイントとして知られています。プロセス名は「注文を検証する」「在庫を更新する」のように動詞と目的語を組み合わせた具体的な表現にすると、図の可読性が高まります。
データフロー（データの流れと方向）
データフローは、プロセス・データストア・外部エンティティの間を流れるデータを矢印で表します。矢印の方向がデータの流れる向きを示し、ラベルにはデータ名を記述します。
データフローの名前は、「顧客情報」「注文データ」のように内容が具体的にわかるものにすることが重要です。「データ1」「情報A」のような抽象的な名称では可読性が著しく低下します。実務では、データフローの名称をデータ辞書と連携させて管理することで、設計書全体の整合性を高めることができます。
データストア（データの保管場所）
データストアは、データが一時的または永続的に保存される場所を表します。データベースのテーブルやファイル、帳票などがこれに該当し、Yourdon記法では開いた長方形、Gane-Sarson記法では両端が閉じた形で描かれます。
データストアは、プロセスとの間にのみデータフローで接続され、外部エンティティと直接つながることはありません。この原則を守ることで、データの入出口が明確になり、不正なデータアクセスの検知にも役立ちます。設計レビューの際には、この接続ルールが守られているかを必ず確認しましょう。
外部エンティティ（システムの外部との接点）
外部エンティティは、対象システムの外側に存在してデータをやり取りする主体を指します。顧客や担当者などの人物、他のシステム、外部組織などが該当し、四角形の記号で表されます。外部エンティティはデータの発生源または吸収先であり、DFDのスコープ外の存在です。
外部エンティティの洗い出し不足は、システム境界の曖昧さに直結します。「このシステムにデータを送る人・組織・システムは何か」「このシステムからデータを受け取るのは何か」という2つの問いを軸に整理すると、見落としを減らせます。要件定義の段階で丁寧に確認しておくことが、後工程の手戻り防止につながります。
DFDの種類と階層構造
DFDは、システムの全体像から詳細な処理まで、階層的に表現できることが大きな特徴です。一般的にはレベル0から始まり、段階的に詳細化していきます。各レベルの特徴と使い分けのポイントを解説します。
コンテキスト図（レベル0）：システム全体の俯瞰図
コンテキスト図（レベル0 DFD）は、システム全体を1つのプロセスとして表し、外部エンティティとのデータのやり取りだけを示した最上位の図です。対象システムの全体像と、外部とのインターフェースを一目で把握できます。
コンテキスト図の主な目的は、システムのスコープを明確にすることです。ステークホルダーへの説明資料として、またシステム間連携の検討の出発点として活用されます。まずコンテキスト図を作成してスコープを合意してから詳細設計に進む流れが、現場では定番のアプローチです。
レベル1 DFD：主要プロセスの分解
レベル1 DFDは、コンテキスト図の1つのプロセスを複数のサブプロセスに分解したものです。システムの主要な機能単位とデータストアが初めて登場するレベルであり、業務の大まかな流れを把握するのに適しています。
レベル1では、通常3〜7程度のプロセスに分解するのが適切とされています。多すぎると図が複雑になり、少なすぎると詳細が伝わりません。チームでのレビューを行う際には、まずレベル1の図をベースに議論を進めることが多く、業務と技術の共通言語として機能します。
レベル2以降：詳細プロセスへの展開
レベル2以降は、レベル1の各プロセスをさらに詳細に分解したDFDです。複雑な処理ロジックが含まれるプロセスや、データの流れが多岐にわたる機能を詳細化する際に作成します。
すべてのプロセスをレベル2以降まで展開する必要はなく、複雑さに応じて選択的に詳細化するのが実務では一般的です。「そのプロセスが複数の工程で構成されているか」「担当者や部門をまたぐかどうか」などを目安にすると、詳細化の判断がしやすくなります。
階層を分けて描く理由と使い分けのポイント
DFDを階層に分けて描く理由は、複雑なシステムを段階的に理解しやすくするためです。一度にすべての詳細を1枚の図に詰め込もうとすると、可読性が大きく低下します。読み手と目的に合わせてレベルを選ぶことが、使い分けの基本です。
経営層やビジネスオーナーへの説明にはコンテキスト図、開発チームとの詳細設計にはレベル1〜2が適しています。プロジェクト開始時に「どのレベルまで作成・管理するか」を合意しておくと、後工程でのドキュメント不整合を防ぐことができます。
DFDの書き方・作成手順
DFDは、手順に沿って段階的に作成することで、品質の高い成果物を効率よく仕上げられます。実務で活用できる6つのステップを順番に解説します。
STEP1．対象システムのスコープと目的を明確にする
DFD作成の出発点は、対象システムの範囲（スコープ）と作成目的の明確化です。何のためにDFDを作るのか、どのシステム・業務が対象なのかをチームで共有しておかないと、作業が途中で迷走するリスクがあります。
特に大規模システムでは、最初に「今回のDFDはどの機能領域を扱うか」を決めてから着手することが重要です。スコープが曖昧なままだと、プロセスや外部エンティティの洗い出しが不完全になり、後の工程で手戻りが発生しやすくなります。
STEP2．外部エンティティとコンテキスト図を描く
スコープが決まったら、まず対象システムと接する外部エンティティを洗い出し、コンテキスト図を作成します。「このシステムにデータを送る人・組織・システムは何か」「このシステムからデータを受け取るのは何か」という観点で整理すると、見落としが減ります。
コンテキスト図が完成することでシステムの境界線が明確になり、後続の詳細設計の土台が整います。この段階でステークホルダーに確認を取ることで、スコープの認識齟齬を早期に解消できます。
STEP3．主要プロセスとデータフローを整理する
コンテキスト図をもとに、システム内の主要プロセスとそれらをつなぐデータフローをレベル1 DFDとして展開します。プロセスは動詞＋目的語（「注文を検証する」「在庫を更新する」）で命名すると、内容が明確になります。
データフローは、実際の業務フローや画面・帳票のデータ項目を参照しながら定義すると、より実態に即した図になります。この段階では完璧を目指すより、チームでのレビューを前提に素早く作成し、フィードバックを反映させるサイクルを回すことが実務では効果的です。
STEP4．データストアを定義して関係を結ぶ
主要プロセスが整理できたら、各プロセスが参照・更新するデータストアを定義します。データストアは、システムが保持する情報の塊（顧客マスタ、注文テーブル、ログファイルなど）に対応します。
プロセスとデータストアを矢印で結ぶ際は、「読み込み（参照）」か「書き込み（更新）」かを矢印の方向で明示することが重要です。データストアとプロセスの関係が整理されると、データの依存関係が可視化され、後のテーブル設計や正規化作業にも活用できます。
STEP5．階層を展開して詳細を追加する
レベル1 DFDで定義したプロセスのうち、複雑な処理を含むものをレベル2以降に詳細化します。詳細化の際は、上位レベルのデータフローと整合が取れているかを常に確認しながら進めることが必要です。
この一貫性の確保は「バランスチェック」と呼ばれ、DFDの品質管理における重要なプロセスです。上位レベルのプロセスへの入力データと出力データの種類・量が、展開後の下位レベルでも保たれているかを確認することで、設計の矛盾を早期に発見できます。
STEP6．レビューと整合性チェックを行う
DFD完成後は、必ずレビューと整合性チェックを実施します。確認項目は、すべてのプロセスに入力と出力が存在するか、データフローのラベルが具体的かつ意味がわかるか、外部エンティティとデータストアが直接つながっていないかなどです。
レビューは業務担当者とシステム担当者の両方が参加する形式が理想です。業務の観点と技術の観点を掛け合わせることで、片方だけでは見落とすような問題点を拾い上げることができます。レビューで得たフィードバックを反映させることで、DFDの精度が大きく高まります。
DFDと他のシステム設計図との違い
DFDは、他のシステム設計図と使う場面や表現できる内容が異なります。それぞれの違いを理解した上で使い分けることが、設計ドキュメント全体の品質向上につながります。代表的な図との違いを解説します。
ER図（エンティティ関連図）との違いと使い分け
ER図はデータの構造と関連性（エンティティ・属性・リレーション）を表現する図であり、DFDとは目的が異なります。DFDが「データがどこをどう流れるか」を示すのに対し、ER図は「データがどんな構造で存在するか」を定義します。
設計の現場では、DFDとER図を補完的に使うことが一般的です。まずDFDでデータの流れを整理し、データストアの内容が固まったらER図でテーブル構造を詳細化するという手順が有効です。双方を組み合わせることで、システムの構造と振る舞いを包括的に把握できます。
フローチャートとDFDの違い
フローチャートは処理の手順や条件分岐といった「ロジックの流れ」を表現するための図です。DFDはデータの流れと処理の関係を表すものであり、処理の順序や条件は対象外となります。
混同しやすいポイントは、どちらも「矢印で流れを表す」という視覚的な類似性です。フローチャートが「どの順序でどんな処理をするか」を示すのに対し、DFDは「どこからどこへデータが流れるか」を示す点で根本的に異なります。設計の目的に応じて適切な図を選択することが重要です。
UMLのユースケース図・シーケンス図との違い
UMLのユースケース図はアクターとシステムの相互作用を、シーケンス図はオブジェクト間のメッセージのやり取りを時系列で表現します。DFDが「データ中心」の設計に向いているのに対し、UML図は「オブジェクト中心」や「処理中心」の設計に対応しています。
オブジェクト指向開発のプロジェクトではUMLが主流ですが、業務分析やレガシーシステムの設計整理においては、DFDのシンプルな記法が有効な場面も多くあります。プロジェクトの特性や目的に合わせて、使う図を選択することが設計品質の向上につながります。
DFDの活用シーン
DFDは、システム設計の初期段階だけでなく、データ管理やセキュリティ設計など幅広い文脈で活用できます。具体的な活用シーンとそれぞれのポイントについて詳しく解説します。
要件定義・業務分析におけるDFDの活用
要件定義フェーズでは、業務担当者の業務フローをDFDで可視化することで、業務とシステムの境界や、システムが扱うべきデータを明確化できます。業務担当者とエンジニアが協業するワークショップの場でDFDをホワイトボードに描きながら議論するアプローチは、認識のズレを早期に解消する効果があります。
業務分析においても、現状（As-Is）と将来（To-Be）のデータフローをDFDで比較することで、改善すべきプロセスの特定やシステム要件の導出が行いやすくなります。DFDは業務とシステムをつなぐ共通言語として機能します。
システムリプレイス・データ移行時のデータフロー整理
既存システムのリプレイスやデータ移行プロジェクトでは、現行システムのデータの流れをDFDで整理することが有効です。長年運用されてきたシステムでは設計書が存在しないか古くなっていることが多く、現状のデータフローを再整理する必要が生じます。
DFDを使って現行システムのプロセスとデータストアを可視化することで、移行対象データの洗い出し、移行前後のデータフローの比較、移行計画の策定が体系的に進められます。「現行の仕様が誰もわからない」という状況を解消する手段としても有効です。
データガバナンス・データリネージの可視化
データガバナンスの強化においては、データがどこで生まれ、どのように加工・移動し、どこに格納されるかを追跡する「データリネージ」の可視化が求められています。DFDの考え方はこのデータリネージの整理に直接応用でき、データウェアハウスやデータレイクの設計においても活用されます。
上流から下流へのデータの流れをDFDで整理することで、データの出どころや加工の経路が明確になります。品質管理やコンプライアンス対応においても、データの来歴を可視化したDFDは重要な役割を果たします。
セキュリティ設計・脅威分析（DFDを使ったリスク把握）
セキュリティ設計の分野では、DFDを活用した脅威分析手法「STRIDE」が活用されています。DFDを描いてデータの流れと信頼境界を可視化した上で、プロセスやデータフロー・データストアごとに脅威を分類・分析するアプローチです。
DFDで可視化されたデータの流れをもとに、「どこでデータが改ざんされるリスクがあるか」「どこで不正アクセスが起きやすいか」といった観点でリスクを特定できます。開発初期の段階でセキュリティリスクを把握することで、設計への組み込みコストを大幅に下げることが可能です。
DFD作成でよくある失敗パターンと改善策
DFDの作成においては、経験の少ないうちに陥りやすいパターンがあります。代表的な失敗事例と改善策をまとめました。
プロセスとデータフローの粒度がばらばらになる
DFD作成で最も多い失敗のひとつが、プロセスやデータフローの粒度（詳細さのレベル）がレベル間でバラバラになることです。同じレベル1に「顧客管理全般」という大きなプロセスと「パスワードを更新する」という細粒度のプロセスが混在すると、図全体の可読性が大きく低下します。
改善策は、各レベルで粒度の基準を明確に定めることです。「レベル1は業務機能単位」「レベル2は画面・帳票単位」といった基準を設けることで、複数人で作業する場合でも一貫した品質のDFDを作成できます。チームで基準を合意してから着手することが重要です。
外部エンティティとデータストアを混同して描いてしまう
外部エンティティとデータストアはどちらも「データのやり取り先」として扱われがちですが、本質的に異なります。外部エンティティはシステムの外側に存在する主体であり、データストアはシステムの内側にある保存領域です。
「顧客データベース」を外部システムとして扱うか、内部のデータストアとして扱うかはスコープの定義次第で変わります。設計の最初にシステム境界を明確に定め、その境界の内側にあるものをデータストア、外側にあるものを外部エンティティとして統一することで、混同を防ぐことができます。
階層が深くなりすぎて全体像が見えなくなる
DFDの階層化は便利な反面、詳細化しすぎるとレベル3・4・5と際限なく深くなり、全体像の把握が困難になります。その結果、ドキュメントの管理コストが高まり、更新も滞りがちになります。
現場での改善策は、「詳細化は最大でもレベル2〜3まで」と事前にルール化することです。それ以上の詳細はフローチャートや擬似コードといった別の記述方式に切り替えることで、DFDをシステムの全体像把握に特化した役割に絞り込めます。ドキュメントの目的と役割を明確に定めることが大切です。
作成して終わりで更新・管理されない
DFDをはじめとする設計ドキュメントの共通課題として、作成時点では精緻に作られても、システム変更に追随して更新されない問題があります。「古くなったDFDが残り、誰も信頼しなくなる」という状態は多くの現場で発生しています。
対策としては、DFDの更新タイミングをプロセスに組み込むことが有効です。仕様変更の際には必ず関連するDFDを見直す、リリース後に定期的なドキュメントレビューを実施するといったルールを設けることで、DFDを「生きたドキュメント」として維持できます。
まとめ：DFDをシステム設計・データ管理に活かすために
DFDは、データの流れを視覚化してシステムの複雑さを整理するために、今日も多くの現場で活用されている設計手法です。4つの記号という最小限の語彙でシステムを表現できるシンプルさが、業務担当者とエンジニアをつなぐコミュニケーションツールとして機能します。要件定義から業務分析、データガバナンス、セキュリティ設計まで、幅広い用途に対応できることも大きな強みです。
本記事で紹介した書き方のステップと失敗パターンを参考に、ぜひ実際のプロジェクトでDFDを活用してみてください。作成・管理のルールをチームで合意しておくことで、DFDは設計の質を継続的に高めるための有力なツールになります。
「これからデータ領域に関する取り組みを実施したいけれど、何から手をつけたらいいかわからない」「データ専門家の知見を取り入れたい」という方は、データ領域の実績豊富な弊社、データビズラボにお気軽にご相談ください。
貴社の課題や状況に合わせて、データの取り組みをご提案させていただきます。
