複雑なシステムの可視化
現代のシステムは、ますます複雑化しています。多くの異なる技術やプラットフォームが相互に作用し、データがリアルタイムで流れる環境では、システムの全体像を把握することが困難になりがちです。現代的なシステムに限らず、古くから利用されてきたシステムは度重なる改修、機能拡張によって、やはり複雑化しがちです。DFDは、そのシンプルな構造と視覚的な表現を通じて、システムのデータフローを直感的に理解するための優れたツールです。とくに新しいメンバーがプロジェクトに参加するときや、異なる専門分野の間でコミュニケーションをとるときにその有用性は顕著です。
ここで、合併とシステム統合で非常に苦しんだことで有名な銀行のお話をしましょう。なかなか完成しないことで有名となった新システムではなく、その前に使用していたシステムでのエピソードです。このシステムは、2011年3月の東日本大震災の発生にともない、テレビ局が番組などを通じて行った「義援金への協力」の呼びかけをきっかけに、振り込みが殺到、取引明細の件数が勘定系システムで処理できる1日の上限値を超えたことから、大規模なシステム障害が発生しました。
長きにわたって使用し続けていたシステムは、機能の追加・改修を繰り返し、肥大化・複雑化していました。また、その規模の大きさ故に、担当も細分化されていました。システムの全体像を把握できる人がおらず、どこの異常がどこに影響するかを把握することが難しい状態で、いわゆる「ITガバナンスの不全」と呼ばれる状態になっていました。
ITガバナンスを立て直すため、このトラブル以降1年にわたり再発防止策に取り組みましたが、この際に力を入れたのが「データフロー図 」を作成することでした。
この取り組み以前においても、システム単位での仕様書、業務の流れを示す資料も作成されていましたが、データの流れに着目してシステム全体を貫くモデルを作成したのは、これがはじめてだったとのことです。役割分担が細分化され、知識が局所的にしか存在しない状態から、「組織全体としての知識」として昇華させることができたのです。
こうして作成したデータフロー図は、障害の原因となった「上限値」の設定箇所の特定や影響範囲の確認、エラー処理の強化といった障害発生予防にも役立っただけでなく、障害発生時の伝達体制においても、影響範囲や規模が速やかに把握できるようになり、関連部署や外部への連絡も円滑になったそうです。
この事例のように、「データフロー」に着目して可視化することができるDFDは、複雑化したシステムを分析して可視化し、システムの改善、障害対応、情報連携の強化につなげることができます。
オブジェクト指向分析・設計およびUMLとの関係
DFD以降、さまざまなモデリング手法、分析・設計手法が登場し、比較して優劣を語られるシーンも多いですが、完全に対立する概念ではなく、それぞれの特徴を理解し、それぞれの長所を活用すべく併用することで相乗効果を得られることもあります。
たとえば、先ほども取り上げたUMLとの関係性について見てみましょう。
UMLは、オブジェクト指向の視点からシステムをモデリングし、クラス図、シーケンス図、ユースケース図など、複数の視点でシステムを表現します。これに対してDFDは、システム全体のデータフローに焦点を当てて、プロセスを経由してデータがどのように移動するかを視覚化します。また、DFDを用いた構造化分析のアプローチは、高次元のモデルから細分化しつつ、その次元を上下しながら整合性を担保していく手法です。
こうした特徴を踏まえて併用する場合、DFDでシステム全体のデータフローを俯瞰し、どのデータがどのプロセスを経由するのかを把握し、さらにプロセスを細分化した後、UMLを使って各プロセスの詳細設計を行うことで、システム全体の理解と詳細設計が統合され、設計の一貫性を向上させることができます。
また、DFDとUMLでそれぞれ異なる視点で分析・設計を行うため、多面的にチェックすることができ、一方の手法だけでは発見しにくい問題の発見につながります。
ユーザーストーリーの整理の段階において、UMLではユースケース図を用います。ユースケース図は、ユーザー（アクタ）とユースケースによって概観を表現するシンプルなモデルであるため、非ITエンジニアとのコミュニケーションに活用できますが、極めてシンプルである半面、動作・振る舞い、データ、依存関係などの表現が困難です。UMLに閉じてこれらの情報を補う場合、シーケンス図や状態遷移図などを併用するのが一般的ですが、これらのモデルは使い慣れていない、読み慣れていない人、さらには非ITエンジニアが理解するにはハードルが高くなります。
ここで、ユースケース図と同じくらいシンプルな構成要素で描くことができるDFDを用いると、非ITエンジニアの理解へのハードルを上げることなく、ユーザーの操作とそれにともなうデータフローを統合的に視覚化することができます。
シンプルな表現技法
業務であったり、顧客体験であったり、すでに実装されているシステムの処理といったものを極度に抽象化すると「何らかの情報を入力として、何らかの処理をして、生まれたものをどこかへ出力する」という構造にたどり着きます。そして、DFDはこれをそのまま表現することができます。それと同時に、出力されたデータが次のプロセスにつながっていない場合、「何のために生み出されたのか？ その処理は本当に必要だったのか？ わたしたちはこの処理やデータについて、正しく理解できているのか？」という疑問に気づくきっかけも与えてくれます。
DFDは「データ」「プロセス（処理）」「外部エンティティ」をデータフローを示す矢印でつなぐという、たった4つの要素で描くことができる、極めてシンプルな表現技法です。そのため、非ITエンジニアであっても読み取ることが容易です。また、自身の業務を「流れ」や「手続き」で覚えている業務担当者にとって、静的断面を表現するモデルよりも受け入れやすいでしょう。
こうした特徴は、コミュニケーションツールとして非常に有用です。システムの発注者やヒアリングに応じた業務担当者は、話をした内容がITエンジニアに正しく伝わったのか、正確に理解してもらえたのか、不安を抱えた状態になります。ITエンジニアが作成する設計書の内容が、ITエンジニアにしか理解できない体裁であった場合「実際に動くもの」が渡されてくるまで、確認する術がありません。こうした状況に対してとれるアプローチは「非ITエンジニアにも理解しやすいモデルを作って見せる」か「質のよいドキュメントを作成するよりも、とにかく動くものを早く作って見せる」か、となります。このうち、前者の手段としてDFDは非常に優れている、と言えるでしょう。後者の代表格がアジャイルであり、設計手法としてはドメイン駆動設計などが該当するでしょう。
多くの関係者、多くの開発者が関わる大規模システムの開発においては、アジャイル的アプローチがとりにくいことも多く、しっかりしたドキュメントを作成し、認識齟齬をなくしたうえで、次のステップに進む必要があります。とくに日本では、自社のシステム開発をシステムインテグレータなどの専門会社に委託することが一般的です。受託した会社も業務を細分化し、二次・三次受託者へ再委託することが多く、いわゆるゼネコン方式がとられています。開発プロセスには、ウォーターフォールモデルが採用されています。このことは長きにわたり賛否の議論が続いていますが、現実問題として、このような開発体制、商習慣が主流として継続しています。こうした体制である限り、各受発注者の間の依頼内容の認識齟齬、作業工程間の情報齟齬は、品質問題や開発遅延に直結する原因となるため、正確に表現されたドキュメントをよりどころとしたコミュニケーションが不可欠です。DFDを使ってモデリングすることで、システム全体を描き、必要とされる機能やデータストアを明確にし、そこから、受託者がそれぞれ担当する範囲を切り出して開発を進めることができます。これにより、担当者間で相互に情報連携する境界線も明確に示すことができます。自身が開発を担当している機能が、どこにどのように影響してくるかを把握することも容易になるのです。
