データフロー図（DFD）の書き方｜レベル分けの考え方と記号
システムの資料にDFDが出てきたものの、フローチャートとの違いが分からない。あるいは自分で描こうとして、どこまで細かく分ければよいか迷う。DFDは記号が4つしかない単純な図ですが、レベル分けという独特の考え方があります。この記事では、記号の意味とレベル分けの原則を整理します。
DFD（Data Flow Diagram、データフロー図）は、システムの中をデータがどう流れるかを表した図です。どこからデータが入り、何によって加工され、どこに保管され、どこへ出ていくかを示します。
フローチャートとの決定的な違いは、時間の概念がないことです。フローチャートが「次に何をするか」という順序を表すのに対し、DFDは「データがどこへ動くか」という関係だけを表します。分岐や繰り返しは描きません。
主な用途は、システムの全体像を関係者で共有することです。特に、既存のシステムを刷新するときや、複数のシステムをつなぐときに効果があります。
「この情報はどこから来ているのか」「なぜ2箇所で同じデータを持っているのか」といった疑問は、DFDを描くと見えてきます。データの重複や、誰も使っていない出力に気づく機会にもなります。
DFDの構成要素は4つだけです。記号の形は流儀によって多少違いますが、意味は共通しています。
データに何らかの加工を加える処理を表します。「受注を登録する」「請求金額を計算する」といった、動詞で終わる形で書きます。
重要な原則が1つあります。プロセスには必ず入力と出力の両方があることです。入力だけで出力がないプロセス、出力だけで入力がないプロセスは、描き間違いです。
データが保管される場所です。データベースのテーブル、ファイル、紙の台帳などが該当します。上下を線で挟んだ形か、右端の開いた長方形で描きます。
データストアは自分では何もしません。プロセスが書き込み、プロセスが読み出すだけです。データストアから直接別のデータストアへ矢印を引くことはできません。
システムの外側にいて、データをやり取りする相手です。顧客、取引先、他部署、外部サービスなどが入ります。
ここを決めることが、実はDFDを描く上で最も重要な判断になります。どこまでを自分たちのシステムとみなすかが、図の範囲を決めるからです。
データが動く向きを表します。矢印の上には、何のデータが流れているかを必ず書きます。「注文データ」「顧客情報」「在庫数」といった名詞です。
名前のない矢印は、DFDでは意味を持ちません。何が流れているか書けない矢印は、そもそも必要ない可能性があります。
DFDの特徴であり、最も分かりにくい部分です。1枚の図にすべてを詰め込まず、粗い図から細かい図へと段階的に展開していきます。
最も粗い、1枚目の図です。システム全体を1つのプロセスとして描き、その周りに外部エンティティを配置します。
この図で示すのは、システムの境界だけです。誰とデータをやり取りするのか、何が入って何が出ていくのか。データストアは描きません。
単純すぎて省略したくなりますが、ここを飛ばすと範囲が曖昧なまま細部に入ることになります。
コンテキストダイアグラムの中身を開いた図です。1つだったプロセスを、主要な機能に分解します。ここで初めてデータストアが登場します。
プロセスの数は、5から7個程度が目安です。10を超えると読みにくくなり、3以下だと分解の意味が薄くなります。
レベル0の各プロセスを、さらに開いた図です。プロセス番号1を開いた図がレベル1の図となり、必要ならさらにレベル2へと進みます。
どこまで展開するかの基準は、それ以上分解しても意味がなくなったところです。実務では、レベル1か2で止まることがほとんどです。
レベル分けで最も重要な決まりごとです。上位の図と下位の図で、出入りするデータが一致していなければなりません。
具体的には、レベル0のプロセス1に3本の矢印が出入りしているなら、それを開いたレベル1の図でも、外側との矢印は同じ3本でなければなりません。
下位の図を描いているうちに新しいデータのやり取りが必要だと気づくことがあります。そのときは、上位の図も直してください。片方だけ直した状態が、DFDが信用されなくなる典型的な原因です。
5つ目が実務的なポイントです。複雑な部分だけレベル2まで展開し、単純な部分はレベル0で止める。均等に展開しようとすると、労力の割に得るものが少なくなります。
4つ目が最も多い間違いです。フローチャートに慣れていると、つい判断のひし形を描きたくなります。DFDでは、条件によって流れが変わる場合も、単に複数の矢印として描きます。
見たいものが違います。データがどこにあり、どう動くかを整理したいならDFD。作業の順番と分岐を示したいならフローチャートです。システム開発では両方作ることも珍しくありません。
補完関係にあります。ER図がデータの構造を示すのに対し、DFDはそのデータがどう動くかを示します。DFDのデータストアが、ER図のエンティティに対応することが多くなります。
描ける必要はありませんが、読めると役に立ちます。特にコンテキストダイアグラムは、システムの範囲を確認する資料として有効です。「この相手とのやり取りが抜けている」といった指摘は、発注者側でないとできません。
描けます。新規構築の場合は、あるべき姿としてのDFDを描きます。既存システムがある場合は、現状のDFDと新しいDFDを両方作り、差分を確認する進め方が有効です。
DFDが示すのは、データの流れという構造だけです。それをいつまでに、誰が実装するのかは表せません。設計が固まったら、次はそれを日程と担当に落とす作業が残ります。
Xtrategyでは、施策のスケジュールと予算・KPIを同一画面で管理できます。
DFDは記号が少なく、覚えることはわずかです。難しく感じるのはレベル分けの部分ですが、これも「粗い図から始めて、必要なところだけ開く」と考えれば単純です。まずは外部エンティティを挙げて、コンテキストダイアグラムを1枚描くところから始めてみてください。
Googleで、当サイトの記事を見つけやすくする
