DFDとは?システムエンジニアを目指す方に必修の図法を習得しよう!
DFD
DFDとは?システムエンジニアを目指す方に必修の図法を習得しよう!
アンドエンジニア編集部
2021.10.13
この記事でわかること
DFDはシステム開発の要件定義フェイズでデータの流れを確認するために作られる図である
DFDには4つの要素があり、 ルールに従って、ユーザーと確認し合いながら作成する
DFDだけではすべてを表現できないため、別途業務フロー図やユースケース図、ER図なども用いる

DFDの特徴(概要、メリット・デメリット、要素など)を解説

DFDの特徴など

DFDというIT用語について、SE(システムエンジニア)やPM(プロジェクトマネージャー)の方、システム開発を勉強中の方はよくご存じだと思います。ITパスポート試験でもこのDFDについて出題がされています。この記事では、SEを目指しているプログラマーや他の職種の方を対象に解説しますので、ご存知のところは読み飛ばしてください。

DFDとは

DFD(Data Flow Diagramの略称)は、システムにおけるデータ全体の流れ(flow)を表した図のことです。

システムを作る際に、まずは「このシステムがどう動くのか」といったシステム全体の流れとデータ処理のプロセスを図表にすることで、開発内容を文字だけでなく視覚的に捉えることができます。また、DFDはシステム構築以外にも、さまざまな業務フローを分析するためにも用いられている便利な手法です。

一般的には要件定義フェイズなど、システム設計の初期段階で作成されます。

具体的に言えば、システムにおける入力(input)と出力(output)が何であるか、またデータの出所・発生元・出力先・データの保管場所などを示します。DFDは処理のタイミングを示すものではなく、順序も関係ありません。

同じ用途で使用するツールとしては、フローチャートなどがあります。また、DFDは依存関係を示すため、相互依存関係がない処理については並列・並行性を表現します。

DFDの目的

DFDでは、「システム機能」と「データ」の流れを表す図ですが、DFDには次のような目的があります。

・関係者でシステムイメージを確認し共有する ・既存システムを整理して、全体像を把握する ・機能の漏れや重複がないように機能を整理する ・処理(プロセス)を詳細化していく

では続いて、DFDのメリットとデメリットについて見ていきましょう。

DFDのメリット

DFDのメリットは、なんと言っても視覚的でわかりやすい点です。システムの構成要素を分割し、図形でデータの流れを記述するため、業務全体を把握しやすくなります。これにより、「あいまい」な部分を排除でき、さらにシステムの「抜け」を防ぐことができます。

DFDを1枚に書ききれない場合は、レベル分けして書きます。まず全体像を書き、レベルを下げた形でそれぞれの内部プロセスを細かく記載していきます。

データベース設計との関係を見るとすれば、データストア(ファイルやデータベース)がエンティティ候補になります。また、データの発生元や入力元・出力先(外部実体)もエンティティの候補となります。

DFDのデメリット

DFDのデメリットは以下のようなものが挙げられます。

1.実際の動作をつかみにくい DFDのレベルでは、各プロセス間の依存関係や処理の順序が実態とは一致しないことがあり、実際の動きは後から決定されます。そのため、実際にプロセスを動作させた際に、DFDと同じレベルで可視化することが難しいという問題があります。

2.コントロールフローの表現が難しい DFDの要素として「条件分岐」などのコントロールフローのマッピングが難しいため、記述されないことが多いのですが、要素としては追加していくことが必要です。

DFDの4つの要素

DFDの作成については、「データフロー(流れ)」「データストア(データベース)」「プロセス(処理)」「外部エンティティ」の4つの要素があります。非常にシンプルなので、ユーザーにも分かりやすいのが特徴です。下にDFDの4つの要素について表にしたので、確認してみましょう。

DFDの要素

DFDとExcel

DFDを作成する際、ホワイトボードなどに書いていく方法もありますが、ドキュメントとして残すためには電子的に保管可能な形式にした方が良いでしょう。DFD作成専用ツールなどを利用するのも手ですが、汎用的で誰でも使えるExcelがおすすめです。

Excelのセルを方眼紙のように使い、Excelに標準で実装されている図形を使います。文字はテキストボックスを利用して記載します。

1度作ってしまえば、それをテンプレートにして簡単に作成できるようになります。多くのSEは、DFDを作成する際にExcelを用います。

実際にDFDを作成する

DFDを作成する

DFDはあくまでも、データ中心の機能関連図です。インプット・アウトプット・処理・データの保管の流れを表すだけです。そこには「誰が」「いつ」「どのように」という情報は記述されません。それらを示すのは別の図です。

例えば、受発注在庫管理システムをDFDで表すと、以下のような図になります。ここでは外部エンティティは「顧客」と「物流倉庫」です。インプットは商品注文データ、アウトプットは顧客に届けられる商品です。

 

DFDの例

1.全体ストーリーを確認

DFDは、要件定義においてユーザー(クライアント)とのヒアリングを通じて作成していきますが、いきなりDFDの作成に入っても、直ぐに書けるものではなく、無理に書き進めても齟齬が生じる可能性があります。

まずは現状を確認し、そこからどんなシステムにしたいのかストーリーを描いてみるとよいでしょう。そのストーリーから両者共通のシナリオが生まれれば、DFDの目的は半ば達成したといえます。

2.データの発生場所と利用を把握

DFDは仕組みの中でのデータの流れにフォーカスすることで、業務の全体を確認する図です。どこでどんなデータが発生するのか、どこでデータが利用されるかを先に把握しておくと書きやすくなります。

3.データの蓄積を把握

続いて「受注データ」や「在庫データ」のような、常時もしくは一時的にデータが蓄積されるものを洗い出します。DFDでは、データを蓄積する場合は上下に線を引きます。

4.処理を列挙する

最後に、1.〜3.までで必要な処理を洗い出し、それらを記述していけばDFDは完成します。処理は丸で表記し、矢印線で繋いでいきます。

DFDだけでは足らないものがある

DFDではデータの流れや処理は分かりますが、「誰が何をする」という役割までは曖昧です。例えば、顧客は商品を注文しますが、具体的に注文行為で何をするのかが分かりません。電話で注文するのか、PCやスマホから注文するのかによってシステムの中での役割が異なります。

顧客はストーリーの中で主役となるのか、脇役になるのかがDFDでは不明です。それを明らかにするものとして、ユースケース図というものがあります。

その他、データベースシステムを構築する場合はER図というものが必須です。つまり、要件定義において登場するフロー図はDFD以外にもあるということを覚えておいてください。

DFDのルールと注意点

DFDのルール

データフロー図は好き勝手、自由に書いていくものではありません。データフロー図を書く上でも最低限のルールがありますので、ルールに従って書いていきましょう。

1.プロセスには入力と出力がかならずある

DFDに記されるプロセスは人やコンピューターによって実行されることを示し、他から受け取ったモノやデータを加工する働きをします。

したがって、プロセスには必ず「入力(input)」と「出力(output)」が必要です。逆に言えば、「入力」と「出力」がないプロセスは存在できません。これは、すべての業務は「input」→「process」→「output」で構成されていることを示しています。

2.データストア間は直接データフローで結ばない

データフロー図を書いている際に、いきなりデータストアから他のデータストアにデータフロー(線)を結んでしまう人がいますが、必ずデータストア間にはプロセスが入ります。例えば「受注管理簿」から「出荷管理簿」を作成する場合、必ず両者の間には「出荷指示」というプロセスが入ります。

3.各要素には名前を付ける

データフロー図の要素は「データフロー(流れ)」「データストア(データベース)」「プロセス(処理)」「外部エンティティ」でしたが、それぞれの要素には必ず名称を付けます。特にデータフローには必ず名称を付けなければなりません。

プロセスに名称をつけ忘れても、データフローにそれぞれ名称が付いていればプロセスの内容は推測できますが、データフローに名称が記されていないと、一体何のデータがやり取りされているのかが分からなくなります。

DFDの注意点

DFDはあくまでもデータの流れを中心とした図であり、表せるものには限りがあります。DFDの特徴を踏まえ、有効活用することが重要です。

1.DFDは業務フローではない 重複しますが、DFDはあくまでもデータの流れを矢印で示したものであり、そこには「順序」「時間の変化」「役割分担」などは表せません。そうした部分を示すのは「業務フロー」です。 ユーザーにとっては「業務フロー」で業務のイメージが掴めますが、システム開発ではデータとプロセスが重要になるので、DFDを用います。システム開発においてはDFDと業務フローの両方を用いて要件定義を進めていくのがよいでしょう。

2.粒度を意識する DFDには粒度があります。あまり粒度を細かくし過ぎると、全体を俯瞰できる大きさに収まらず、全体像を把握しづらくなるため、最初は大きなレベルで書きます。 粒度を細かく落とし、レベルをブレークダウンしていくことで、最終的にコンピューターで自動化可能な単位のプロセスとなります。プロセス=プログラムとはなりませんが、プログラムの対象になりうる業務であるという事が分かっていきます。

要件定義のポイント

要件定義のポイント

要件定義においては、システム開発側とユーザー側が互いに確認しあうドキュメントを作成していきます。文章だけでは確認がとりづらい、全体が見えにくいものなどは図表で表現します。

システム概念図などもありますが、図表としてよく利用されるものの内、DFD(Data Flow Diagram)ユースケース図ER(Entity Relationship)図のそれぞれの役割について確認しましょう。

DFDは、データの流れに着目

DFDについて、改めて整理しましょう。DFDはデータの流れを表す記法で、「データフロー(流れ)」「データストア(データベース)」「プロセス(処理)」「外部エンティティ」という4つの要素を用いて、データを中心に処理や機能の関連性を記述していきます。

DFDにおける矢印はデータの流れを表しており、処理の順序とは無関係である点に注意が必要です。DFDにおいては、時系列は考慮しません。また、DFDには階層があり、処理の全体を表すレベル1、レベル2はそれをブレークダウンしたもの、というようにレベル(階層)が上がるにつれて詳細になっていきます。

ユースケース図は、操作や機能に着目

DFDでは表現できないユーザーとシステム機能の関係に着目した図法が、ユースケース図です。DFDとは逆にユーザーの操作を中心にしてシステム機能をメインに書きます。

アクター」と称されるシステムとの間でやり取りを行うユーザーや他システム、「ユースケース」というシステム機能、「アクター間とユースケース間の関連」という3つの要素を用いて、システム機能とシステムを利用するユーザーや他システムとの相関関係を記述します。

ER図は、データのグループ同士の関係に着目

ER図は主にデータベースシステムで用いられます。会社・社員・商品などの属性を持った管理対象をエンティティと称し、リレーションと呼ぶ線でそのエンティティ同士を繋いで表現します。

各エンティティはキー項目を持ち、同一種類のエンティティを識別します。データベース設計に利用すれば、そのまま活かすことが可能です。

DFDを習得してシステム開発に役立てよう

当記事では、システムの中でデータフローを表現するための図として「DFD」を解説しました。DFDは、システムにおける入力や出力が何か、データの出所・発生元・出力先・データの保管場所などを示します。

DFDによってシステムのイメージの確認・共有ができたり、プロセスを詳細化したりできます。DFDを作成する際はルールに沿った書き方が必要なため、この記事を1つの参考してシステム開発に役立ててください。

ER図とは?詳細・メリット・作成方法についてわかりやすく解説!
Twitterをフォローしよう!
この記事をシェア
Twitter
Facebook
LINE
Hatena
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!

編集部オススメコンテンツ

eyecatch_visual_coder
Adobe製品を使わない"デザイナー"?「ビジュアルコーダー」が考える、自己満足で終わらないWebデザインとは
三角
2020.06.16

アンドエンジニアへの取材依頼、情報提供などはこちらから

お問い合わせ・情報提供
この記事をシェア
Twitter
Facebook
LINE
Hatena
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!

編集部おすすめコンテンツ

アンドエンジニアへの取材依頼、情報提供などはこちらから