DFDの特徴

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

DFD（Data Flow Diagram）は、システムにおけるデータ全体の流れ（flow）を表した図のことです。一般的には要件定義フェイズといったシステム設計の初期段階で作成されます。システムを作る際に、まずは「このシステムがどう動くのか」といったシステム全体の流れとデータ処理のプロセスを図表にすることで、開発内容を文字だけでなく視覚的に捉えることができます。また、DFDはシステム構築以外にも、さまざまな業務フローを分析するためにも用いられている便利な手法です。

具体的に言えば、システムにおける入力（input）と出力（output）が何であるか、またデータの出所・発生元・出力先・データの保管場所などを示します。DFDは処理のタイミングを示すものではなく、順序も関係ありません。また、DFDは依存関係を示すため、相互依存関係がない処理については並列・並行性を表現します。同じ用途で使用するツールとしては、フローチャートがあります。

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

・関係者でシステムイメージを確認し共有する

・既存システムを整理して、全体像を把握する

・機能の漏れや重複がないように機能を整理する

・処理（プロセス）を詳細化していく

DFDを作成する上で理解すべき要素は、「データフロー（流れ）」「データストア（データベース）」「プロセス（処理）」「外部エンティティ」の4つです。非常にシンプルなので、ユーザーにも分かりやすいのが特徴です。下記の表でDFDの4つの要素についてまとめていますので、確認してください。

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

Excelのセルを方眼紙のように使い、Excelに標準で実装されている図形を使います。文字はテキストボックスを利用して記載します。1度作ってしまえばテンプレートにして簡単に作成できるようになります。多くのSEは、DFDを作成する際にExcelを用います。

まずはマイナビIT エージェントに無料登録いただいて、キャリアアドバイザーにキャリアや転職に関する相談をしてみてはいかがでしょうか。

DFDのメリット・デメリット

DFDを使用する前に、メリットとデメリットについて理解しましょう。DFDはシステムの機能や仕組みを可視化することで、ユーザーと開発者の相互理解を深めることが可能です。その一方で、実際のシステムの動きや機能の詳細が把握しにくいなどの欠点もあります。以下で詳しく説明します。

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

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

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

実際の動作をつかみにくい

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

コントロールフローの表現が難しい

DFDでは「条件分岐」といったコントロールフローのマッピングが難しいです。そのため、コントロールフローは記述されないことが多く、別に資料を追加して記載する必要があります。

実際にDFDを作成する

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

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

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

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

DFDはシステムのデータの流れにフォーカスすることで、システム全体を確認するのに適しています。どこでどんなデータが発生するのか、どこでデータが利用されるかを先に把握しておくと書きやすいです。

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

最後に、上記.までで必要な処理を洗い出し、それらを記述すればDFDは完成です。処理は丸で表記し、矢印線で繋ぐと見やすいです。

DFDのルールと注意点

DFDは好き勝手、自由に書いていくものではありません。DFDを書く上で最低限のルールがあります。わかりやすく見やすいDFDを作成するために、ルールに従って記載してください。また、DFDで記載できる内容には限りがあります。DFDを作成する上での注意点も説明しますので、併せてチェックしてください。

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

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

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

DFDは「データフロー（流れ）」「データストア（データベース）」「プロセス（処理）」「外部エンティティ」という4つの要素で構成されています。それぞれの要素には必ず名前をつけてください。特にデータフローの名称は忘れずにつけましょう。

プロセスに名称をつけ忘れても、データフローにそれぞれ名称が付いていればプロセスの内容は推測できます。しかしデータフローに名称がない場合、何のデータがやり取りされているのかがわからなくなるため注意が必要です。

要素ごとに違う記号を使うことで、DFDは各段に見やすくなります。DFDは文字・線・矢印だけでシステム構造を示すため、記号を使い分けることで他の要素との違いを明確にすることが可能です。すべての要素に同じ記号を使うと要素の違いがわかりにくくなるため、丸・四角・三角などの複数のオブジェクトを使い分けましょう。

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

・DFDは業務フローではない

重複しますが、DFDはあくまでもデータの流れを矢印で示したものであり、そこには「順序」「時間の変化」「役割分担」などは表せません。そうした部分を示すのは「業務フロー」です。

ユーザーにとっては「業務フロー」で業務のイメージが掴めますが、システム開発ではデータとプロセスが重要になるので、DFDを用います。DFDと業務フローの両方を用いて要件定義を進めるのが良いでしょう。

・粒度を意識する

DFDには粒度があります。粒度を細かくし過ぎるとシステム全体を把握しにくくなるため注意が必要です。最初は大まかにシステムを把握できるよう、主要な機能や動きのみを書きましょう。

粒度を細かく落とし、レベルをブレークダウンしていくことで、最終的にコンピューターで自動化可能な単位のプロセスとなります。プロセス=プログラムとはなりませんが、プログラムの対象になりうる業務であるということが把握できるようになります。

要件定義のポイント

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

システム概念図もありますが、図表としてよく利用されるものの内、DFD（Data Flow Diagram）、ユースケース図、ER（Entity Relationship）図のそれぞれの役割について確認しましょう。また、DFDと似ているUMLについても補足で説明していますので、参考にしてください。

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

顧客はストーリーの中で主役となるのか、脇役になるのかがDFDでは不明です。それを明らかにするものとして、ユースケース図というものがあります。その他、データベースシステムを構築する場合はER図というものが必須です。*要件定義では、DFDのほかにユースケース図とER図もあると便利です。

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

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

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

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

ER図は主にデータベースシステムで用いられます。会社・社員・商品などの属性を持った管理対象をエンティティと称し、リレーションと呼ぶ線でそのエンティティ同士を繋いで表現します。各エンティティはキー項目を持ち、同一種類のエンティティを識別します。データベース設計に利用すれば、そのまま活かすことが可能です。

UML（Unified Modeling Language）は「統一モデリング言語」と呼ばれるもので、オブジェクト指向のソフトウェアを構築する上で使用されます。UMLはシステムを構成するコンポーネント、構造や動作を視覚化する上で一定のルールを設け、書き方を統一することでわかりやすくする目的があります。DFDがユーザーと開発者両方がシステムを理解できるように作成されるのに対し、UMLは開発者がシステム構造を視覚的に理解するために作成されるといった違いがあります。

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

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

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

ER図とは？詳細・メリット・作成方法についてわかりやすく解説！