なぜ「使わない」のか？ なぜ「使わなくなった」のか？
「昔、使ったことがある」人たちは、なぜ最近は使わなくなってしまったのでしょうか。「知らない、聞いたことがない」人は、かつてDFDで設計していたような作業をどうしているのでしょうか。
実態としては、技術・開発手法の進化とともに、新しいモデリング手法とツールが登場し、とって代わられています。
近年のシステム開発においては、Javaに代表される「オブジェクト指向」のプログラム言語によって開発を行うケースが大半となっています。そして、このオブジェクト指向で開発するための分析・設計のためのモデリング手法として、UML（Unified Modeling Language：統一モデリング言語）が使用されます。UMLには、静的な構造、動的な振る舞い、相互作用といったものを表現するさまざまなダイアグラムが含まれており、その目的に併せて使い分けることができます。とくにクラス図やシーケンス図は、オブジェクト指向の開発言語の実装をほぼそのまま表現することができ、設計ツールからソースコードへ、ソースコードから設計ツール上のモデルへ、といった相互の自動生成機能が進化し、ドキュメンテーションの負担を軽減することに寄与してきました。
また、システム開発プロセスにも変化がありました。
システム全体の大きな枠組みを要件定義、設計、開発、テスト、リリースと一方向に向かって進める「ウォーターフォールモデル」は、いまも多くの現場で用いられてはいますが、「アジャイル開発」を採用する現場が増えています。アジャイル開発では、開発対象を細分化して、この開発プロセスを「サイクル」としてすばやく回し、リリースされた機能について、実際に使用したユーザーからの意見要望といったフィードバックも取り込みながら進化させていきます。
アジャイル開発において重要な価値観を示した「アジャイルソフトウェア開発宣言 」に「包括的なドキュメントよりも動くソフトウェアを」という文言があります。これはドキュメント作成を不要とする話では決してないものの、要件定義や設計におけるドキュメンテーションに時間、コストを投入することを忌避する理由の一つになっており、「より少ないドキュメンテーション作業」「ソースコードとの乖離が少ないドキュメンテーション」を重視するようになっています。
本編でも解説しますが、DFDは「構造化分析」とセットで用いられ、システム全体像からトップダウンで論理整合性をとりながら表現し、かつ、モデルだけでは表現できない部分は文章で仕様書を書き起こす、というのが伝統的な手法とされています。
これに対しUMLは、モデルだけでソースコードと乖離が比較的少ない表現が可能であり、必ずしもトップダウンで段階的に詳細化する必要がなく、いま焦点を当てたい部分だけに絞って詳細に記述できるといった理由から、アジャイルな進め方と相性がよいとされています。
このような経緯から次第にDFDが使われなくなり、UMLでのモデリングが主流となってきていると考えられます。
すでにUMLを使用することが当たり前の時代になってからITエンジニアになった方も多くなってきているかと思います。そうした方には、DFDというモデリング手法を使ったことはなく、DFDという名前すら知らない、という状況であっても不思議ではありません。
まだまだ活かせるDFD
ここまで、DFDの衰退の経緯を語ってきました。読み返してみても、「アジャイルとUMLで、もうDFDは要らないじゃないか」と思える内容になっています。しかし、それでもあえていまDFDを取り上げるのは、次のようなDFDのよさを知っていただき、活かしてほしいからです。
- 複雑なシステムの可視化において、有用なモデリング手法であること
- DFDのエッセンスは、決して最近の手法と対立概念にはならないこと
- 非ITエンジニアにとっても、DFD自体は比較的理解しやすいモデルであるため、コミュニケーションツールとして導入ハードルが低いこと
ここからは、これらについてもう少し触れていきたいと思います。
