https://t.co/Y1dhM7EzlQ DFDの本がでる！いろんな図があったけど、DFDが1番役にたつ気がする
— 渋川よしき (@shibu_jp) March 13, 2025
1月半前にツイートしたところ、プチバズりしまして、献本をいただきました。ありがとうございます。自分でもポチっていたのですが、そちらは会社の本棚にでも入れておこうと思います。
データフローダイアグラムは1970年代に構造化分析の手法と一緒に考案された技法です。1990年代にはオブジェクト指向がさかんに取り上げられ、次世代のスタンダードとして喧伝されました。1997年代にはUMLが登場しました。UMLは無料やら有償のツールも開発されたり、ISOになったりかなり大きなムーブメントを起こし「図といえばこれ」という状況になっていたと思います。UMLは多種多様な図が含まれています。プログラムの構造を記述する図と、プログラムの動きを記述する図に分かれています。ERDもクラス図を使って表現する記法とかも一般化し、オブジェクト指向のコードの可視化もデータ設計も全部UML、みたいな感じでした。
ただ、UMLはモデル駆動アーキテクチャ(MDA)という図を書けばシステム作れるよね、的な流れに傾倒し（結局実現しなかった）、その後アジャイルブームのおりには反動としてシンプルな図を、という流れも出て、多種多様な図の中ではシーケンス図ぐらいしか最近は周りではみないな、というのが僕の実感です。UMLの軽量版としてはC4モデルというのもありますが、日本ではそこまで話題になっていなそうです。
オブジェクト指向中心に構成されたUMLを構成する多種多様な図の中には、構造化プログラミングでもお馴染みのステートチャート図はありましたが、DFDなどのデータの流れを表現する図は含まれていませんでした。本書のサブタイトルも「いにしえの技術」と入っていますし、前書きにも「DFDは過去の遺物として扱われることもあった」という背景はこんなあたりですね。
しかし古いからこそ逆にDFDは役に立つ
DFDはオブジェクト指向の前の時代からあった素朴な手法なので、かえって現代でも応用が効いて役に立つ、というのは最近実感しているところです。フューチャー社内にはオンラインの教育コースもあり、現場でも活用されています。
この技術ブログの中でも、Reactの状態管理の表現で使って見たこともあります。
本書でも4章ではデータレイクとかデータウェアハウスの話題も書かれていますし、5章ではセキュリティの分析での活用ということが触れられています。
僕自身、「もっとDFDは知られてもいいのにな」と思っていたところだったので、本書の登場は待望というか、むしろ僕が書きたかったのにくやしい、ぐらいの気持ちがないかというと嘘になる感じです。僕はオリジナルの1970年の原著などは読む機会がなかったのですが、本書はそのオリジナルを参照して、図の書き方の原則や、業務分析で活用する流れなどが書かれている貴重な本になっています。コンパクトにまとまった本ですし、最初の2章ぐらいを読むだけでもエッセンスは十分学べるので社内で軽く勉強会するにも良さそうです。
ソフトウェアのアーキテクチャはマイクロサービスにすべき、という論もここ数年ずっと見かけますが（僕はあんまりマイクロサービス好きではないが）、マイクロサービス分割を考えている人にもDFDはよく効くと思います。国内で実践している会社の事案で、データベースのテーブルが1つ生えると「サービスの追加が必要ですね」という会話が出てサービスが生えるみたいな噂話を聞いたりもしますが、DFDを見ると、「このテーブルとこのテーブルは同時に1つのトランザクション内で同時に読み書きが必要」ということがよくわかります。分散トランザクションなるおかしなものを考えなくても、「ここで切ったら安全」という箇所が見つかりやすくなります。ここはERDだけを書いていてもわからないDFDのメリットだと思います。
おや？これは普段の業務で見るDFDと違うぞ？
フューチャー以外にもDFDを活用していた会社はそれなりにあるんじゃないかな、という気はしていますが、1990年のUML登場ごろからアングラ化して一般の目には触れない状態で業務で活用されてきたということで、フューチャーに限らず、それぞれの会社の中で独自進化を遂げていてもおかしくはないです。実際に僕も本書を読んでいて「あれ？だいぶ違うかも」と思うなどしました。逆にそこが新鮮というか、まだまだDFDそのものの伸び代だったり、別のものへ進化するのりしろなんじゃないかな、と思っています。
DFDだけで図が必要な図が全部そろうことはないのでシーケンス図とかフローチャートといった動きを表す図、システム俯瞰図、インフラ構成図などの構成要素の図などさまざまな図と組み合わせて使うはずですが、どの図と組み合わせるかによってDFDそのものに課される役割は変わってきます。
本書のサンプルだと、UMLでいうところのユースケース図的な役割も持っていそうです。確かに当時はユースケース図はなかったと思いますし「なるほどそういう活用法があるのか」というところが新鮮でした。フューチャーで書くDFDの図だとそこはないので、そもそも外部エンティティが表現されることはあまりないですし、あったとしても一番末端で積極的にインタラクションする図は見たことがなかったです。人はシステムの外の存在ではなく「画面でデータを見て意思決定をするプロセス」扱いですね。
あと、L0、L1、L2といったレベルによって抽象度が異なる図を書くというのは、DFDを解説するウェブサイトにはありますし、本書でも説明されていますが、フューチャーの中では見ません。全員がコードを書けるコンサルという立場で触れるので（サブシステムごとなど分割はするが）そこそこの詳細度でいきなりズバッと書くというところも、たぶん、オリジナルのDFDとフューチャースタイルは違いがあるんだろうな、と読んでいて思いました。
本書はおそらくオリジナルのDFDに忠実な説明がされていると思うので各社の発展を相対化するための物差しとして、重要な文献として後世に語り継がれるのではないかと思います。
まとめ
本書を読んだことで、フューチャー社内のDFDが何を工夫してどのように活用してきたのか、というのを相対的に見れるようになりました。フューチャースタイルも有志で公開しているガイドライン集にいつか入れられたらいいな、ということを思いました。そして、いつか他社のDFD図の発展がどのようになっているのかとかも世の中に出てきて、50年分の図の進化が行われると良いな、という気持ちを新たにしました。
そのためにも、まだDFDに慣れ親しんでいない人たちもぜひ本書を通じてDFDというものを知って欲しいですし、知って活用している人も「自社のオリジナル要素」を知り、今後議論できる土台ができると良いなと思いました。