タイトルは言いすぎかもしれないけど、最近のソフトウェア開発においてDFDを書くことはあまり合理的ではないという話（例外はある）。最近DFDについて相談されたので調べたり考えたりしたことを書く。
データフローダイアグラム（DFD）について
構造化分析モデルの一つで（調べていてびっくりしたのだけれども）トム・デマルコが1979年に書いた「構造化分析とシステム仕様<新装版>」が初出のようだ。えっ、まじか。この本は読んでません。
要件定義の信頼できるテキストである「ソフトウェア要求 第3版」の説明を引用するとこんな感じ。
DFDは、システムの変換プロセス、システムが操作するデータや物理的なモノの集合（ストア）、プロセスとストアと外界の間のデータやモノのフローを明らかにする。データフローモデリングは、システム分析に対して機能分解アプローチをとり、複雑な問題を段階的に詳細化していく。これは、トランザクション処理システムや他の機能集約型のアプリケーションに有効である。
（「ソフトウェア要求 第3版」 12.4 データフローダイアグラム より引用）
すでにここでも注目すべき記載がある。「トランザクション処理システムや他の機能集約型のアプリケーションに有効である」である。つまり、そうではないアプリケーションの分析には向いていないということだ。
DFDの問題点
（この本もちゃんと読んでいないのだけど）「ユースケース導入ガイド―成功する要求収集テクニック」ではDFDには以下の問題があると指摘している。まあユースケースを推奨する本に書かれていることではあるのだけど。
- DFDは技術者にとっては便利だが、ユーザを混乱させる傾向がある
- システムとユーザーの責任の境界線があいまい
- ユーザーが読みこなすのに十分な量以上の情報が含まれる
要求リストと同様に、DFDは要求分析者の道具箱から取り除くことをお勧めします。DFDは、この時点では必要ない多くの技術的要素を要求ダイアグラムに導入してしまう。DFDは、ユースケースや、UML（Unified Modeling Language）のクラス図、シーケンス図、ステートチャート図、アクティビティ図に置き換えることができます。
（ユースケース導入ガイド―成功する要求収集テクニック）
まあ実際にDFDを扱ったことのある人であれば、わりと同意できる内容だと思う。DFDはある種の問題に対しては有効な分析手法だが、一般的なソフトウェアの要件定義には極めて不向きなのである。しかしそれに気づくのは往々にして大量のDFDを書いた後なのだが。
現代的な要件定義ガイドのモデル成果物にはDFDは掲載されていない
無料で入手できる要件定義ガイドとしては、IPAが公開しているものがある（PDFがIPAのサイトからダウンロード可能である）
このガイドが取り扱っている要件定義ドキュメントの体系にもDFDが存在しないことを確認すべきである（なお正確には業務フローを表現する手法としては紹介されている）。
というわけで、現代の一般的なソフトウェア開発の要件定義においては、DFDを書くというのは悪手であると言えるだろう。
DFDを書くべきケースはあるのか？
冒頭で紹介した「ソフトウェア要求 第3版」では「トランザクション処理システムや他の機能集約型のアプリケーションに有効である」とあったので、ある種のシステムにおいてはDFDが有効な場合も存在する。自分の経験では、以下のようなシステムの検討においては有効だと考える。
- ユーザーのユースケースがほとんど存在しない自動化システム
- データウェアハウスに類する、ETLのようなデータパイプラインが主たる機能である
そんなシステムばっかりではないので、やっぱり基本的にはDFDは書かない前提にしたほうが良さそう
