データフロー図の書き方｜5ステップで要件にする

申請フォームの項目は決まった。画面遷移も描いた。それでもレビューで「この数字はどこから来るのか」「承認後のデータはどこに残るのか」と問われ、設計が止まる。

こうした手戻りは、画面ではなくデータの流れが決まっていないときに起きる。そこで役立つのがDFD（データフロー図）だ。

データフロー図は、情報の発生元、処理、保管先、出力先を矢印でつなぐ。見た目は単純だが、きれいに描くことが目的ではない。すべての入力に対応する出力を定め、機能要件、データ要件、権限、テストへ展開できる状態にすることが目的である。

ここからは、データフロー図の書き方を5ステップで整理する。題材は「経費申請」にする。

データフロー図で表す4つの要素

DFDには主に4つの要素がある。IBMの解説でも、外部エンティティ、プロセス、データストア、データフローを基本要素としている。

ここで注意したいのは、矢印に「申請する」「確認する」といった動作を書かないことだ。矢印が表すのは処理ではなく、移動するデータである。「経費申請データ」「承認結果」のように名詞で書く。

業務フロー図との違いも押さえておきたい。業務フロー図は、誰がどの順番で作業するかを見る。データフロー図は、何の情報がどこから来て、どの処理で変わり、どこへ行くかを見る。時系列や担当者の動きを確認したいなら業務フロー図、入出力や保存先を確認したいならDFDが向いている。

両方は競合しない。むしろ、業務フローをAIで描くときの注意点で整理した通常系・例外系の流れに、DFDでデータの入出力を重ねると、仕様の抜けを見つけやすい。

データフロー図の書き方：5ステップ

ステップ1：システム境界と外部エンティティを決める

最初から細かな処理を並べると、図がすぐに迷路になる。先に「どこまでを今回のシステムとして扱うか」を決める。

経費申請なら、対象を次のように置ける。

• システム内：申請登録、承認、差戻し、仕訳データ作成
• システム外：申請者、承認者、会計システム、通知サービス

外部エンティティは、単なる登場人物一覧ではない。データの発生元か、出力先になるものだけを書く。総務部が図に登場しても、情報を送受信しないならDFDには置かない。

最初の1枚はコンテキスト図にする。システム全体を1つのプロセスとして置き、外部との入出力だけを描く。

配置すると、次のような1枚になる。角括弧は外部エンティティ、丸括弧はプロセスを表す。

[申請者] ── 経費申請データ ──> (経費申請システム)

[申請者] <── 受付結果・差戻し理由 ── (経費申請システム)

[承認者] <── 承認依頼・申請内容 ── (経費申請システム)

[承認者] ── 承認結果 ──> (経費申請システム)

[会計システム] <── 仕訳データ ── (経費申請システム)

[会計システム] ── 取込結果 ──> (経費申請システム)

この表を埋めると、境界の曖昧さが見える。「領収書のOCRは申請システム内か」「会計システム側で仕訳を作るのか」といった責任分界が、図を描く前に議題になる。

FigmaのDFD作成ガイドも、要素を洗い出し、システム全体を示す高いレベルから詳細化する流れを示している。いきなり詳細図へ飛ばないことが、最初のコツだ。

ステップ2：入力を出力へ変えるプロセスを書く

次に、システム内のプロセスを分解する。プロセス名は「申請」「承認」のような名詞だけにせず、「申請を登録する」「承認結果を反映する」のように、何を変換するか分かる動詞で書く。

経費申請なら、たとえば次の5つに分けられる。

1. 申請内容を検証する
2. 申請を登録する
3. 承認依頼を作成する
4. 承認結果を反映する
5. 仕訳データを作成する

各プロセスには、入力と出力の両方が必要だ。入力なしで突然データを生む処理や、出力のない処理があれば、説明が欠けている可能性が高い。

たとえば「承認結果を反映する」なら、入力は承認結果と対象申請ID、出力は更新済み申請データと承認履歴になる。ここまで書くと、実装側は必要なAPIや更新対象を考えられる。

コンテキスト図を1段階だけ分解すると、主要な処理とデータストアの関係が見える。二重線はデータストアを表す。

[申請者] ─ 申請内容 ─> (1.申請内容を検証する)

(1.申請内容を検証する) ─ 検証済み申請 ─> (2.申請を登録する)

(2.申請を登録する) ─ 申請データ ─> ||申請データ||

||申請データ|| ─ 承認対象申請 ─> (3.承認依頼を作成する)

[承認者] ─ 承認結果 ─> (4.承認結果を反映する)

(4.承認結果を反映する) ─ 承認履歴 ─> ||承認履歴||

||申請データ|| ─ 承認済み申請 ─> (5.仕訳データを作成する)

(5.仕訳データを作成する) ─ 仕訳データ ─> [会計システム]

プロセスを細かくしすぎる必要はない。1枚に15個も並ぶなら、レビューする側は全体を追えない。まず主要な5〜7処理に絞り、必要な箇所だけ次のレベルで分解する。

ステップ3：データフローに具体的な名前を付ける

DFDで最も情報量が多いのは矢印だ。「データ」「情報」「結果」だけでは、何が流れているか分からない。

次のように具体化する。

• 「データ」ではなく「経費申請データ」
• 「結果」ではなく「承認結果」
• 「通知」ではなく「承認依頼通知」
• 「マスタ」ではなく「勘定科目マスタ」

さらに、主要なデータは項目の粒度まで別表に落とす。

この別表があると、DFDは単なる説明図ではなく、API仕様やデータ定義へつながる。逆に、矢印の名前だけで終わると、実装時に項目の解釈が再び始まる。

個人情報や機密情報もここで確認する。誰の情報か、どこへ送られるか、どこに保管されるかが見えるため、アクセス権やマスキングの議論を前倒しできる。

ステップ4：データストアと更新条件を結ぶ

データストアは、データベース名を並べる場所ではない。業務上、何を記録として残すかを表す。

経費申請なら、少なくとも次の2つが考えられる。

• 申請データ：現在の申請状態と申請内容
• 承認履歴：誰が、いつ、どの判定をしたか

同じテーブルに実装するか、別テーブルに分けるかは後で決めてもよい。要件定義の段階では、「現在値」と「履歴」を別の情報として保持する必要があるかを合意する。

データストアへの矢印も、ラベルは「申請データ」のようなデータ名にする。読み取りか書き込みかは矢印の向きで区別する。誰が作成・参照・更新できるかまで管理するなら、DFDとは別にCRUD表を添えるとよい。

ここで次の4点を確認する。

• どのプロセスが新規登録するか
• どのプロセスが更新できるか
• 削除ではなく履歴化が必要か
• 保存期間と参照権限をどうするか

ER図はデータの構造と関係を表す。一方、DFDはそのデータがどの処理で読み書きされるかを表す。ER図を業務ルールから作る手順と組み合わせると、「箱はあるが更新者が分からない」「処理はあるが保存先がない」という不整合を見つけられる。

ステップ5：例外・権限・受け入れ条件へ変換する

図を描き終えたら、矢印を眺めて終わりにしない。各プロセスを、実装とテストで確認できる条件へ変換する。

通常系だけを描くと、DFDはきれいに見える。だが、実運用で詰まるのは例外系だ。

たとえば会計システムへの送信が失敗したとき、仕訳データはどこに残るのか。再送は自動か手動か。二重送信をどう防ぐのか。DFD上の「仕訳データ」という1本の矢印から、再試行、エラー保管、運用通知を決められる。あわせて、同じデータを再送しても重複登録されない仕組みも要件にする。

AIに仕様書や実装案を作らせる場合も、この段階が効く。図だけを渡すより、データ項目、権限、例外、受け入れ条件を一緒に渡した方が、例外系が抜け落ちるのを防ぎやすい。AIが読める仕様書の書き方で扱った構造化は、DFDからAPI仕様やテストケースへ展開するときにも同じである。

レビューで確認する7項目

最後に、発注者と開発側で次の7項目を確認する。

• システム境界の内外が合意されている
• 外部エンティティごとの入力と出力がある
• 各プロセスに入力と出力がある
• データフローが具体的な名詞で書かれている
• 保管するデータと参照するデータが区別されている
• 個人情報・機密情報の送信先と保存先が分かる
• 例外時の保管、再処理、通知が決まっている

IPAの超上流から攻めるIT化の事例集では、要件定義の成果物と役割分担を整理している。DFDも、作成者だけが分かる図では不十分だ。誰が業務上の正しさを確認し、誰が技術上の実現性を確認するかまで決めておく。

発注者は、データの意味、発生条件、保存の必要性を確認する。SIerや開発チームは、処理の分割、連携方式、整合性、障害時の扱いを確認する。両者が同じ図を見ても、確認する責任は同じではない。

データフロー図は次の成果物への中継点

データフロー図の価値は、1枚の図が完成することではない。

外部エンティティはシステム境界と連携要件へ、プロセスは機能要件へ、データストアはデータ設計へ、データフローはAPIやファイル連携の仕様へつながる。さらに、例外と権限を足せば、受け入れテストと運用設計へ進められる。

つまりDFDは、業務の話を実装可能な仕様へ渡す中継点である。

もし図はあるのに設計が進まないなら、矢印の名前を見直してほしい。「データ」「結果」「連携」としか書かれていない矢印が、未決定の要件そのものかもしれない。

Atsumellは、業務フロー、データ、例外、権限、受け入れ条件をつなぎ、AIと人が同じ前提で読める仕様づくりを支援している。図を作るところで止まらず、開発とテストへ渡せる要件にしたい場合は、お問い合わせから相談してほしい。

関連記事

• ER図の書き方｜業務ルールから作る5ステップ
• AIが業務フローを描く時代
• AIが読める仕様書を書く技術