情報システム学会 メールマガジン 2014.1.25 No.08-10
連載 企業および社会における情報システムの意味を考える
第 16 回 DFD の正しい書き方と使い方

連載
第 16 回企業および社会における情報システムの意味を考える
ＤＦＤの正しい書き方と使い方
大島

正善（MBC:Method Based Consulting）

１．はじめに
先日、「物質のすべては光―現代物理学が明かす、力と質量の起源―」（フランク・ウィル

チェック著、吉田三知世訳、早川書房出版）という本を読んでいたら、面白い文章を見つけたので、少し長くなるが紹介したい。
【そもそもわたしたち人間というものは、奇妙な原材料を使って自分たちの世界の模型を作っている。その原材料を収集しているのが、情報に溢れた宇宙にフィルターをかけて、数種類の入力データの流れに変えられるように、進化によって「設計」された信号処理ツールだ。
「データの流れ」といっても、ぴんとこないかもしれない。もっと馴染みの深い呼び名で言えば視覚、聴覚、嗅覚などのことだ。現代では、視覚とは、目の小さな穴を通過する電磁輻射の幅広いスペクトラムのなかで、虹の七色に当たる狭い範囲だけを取り上げて標本抽出するもの、と捉えられている。聴覚は、鼓膜にかかる空気の圧力をモニターし、臭覚は、鼻粘膜に作用する空気の化学分析を提供するが、その分析は不安定なこともある。…… 感覚系統のおかげで、人類の祖先は世界についてダイナミックで豊かな模型を作り、世界に対して効果的に反応することができた。
】
前号で、DFDの正しい書き方について触れたが、もう少し書くべきことがあることに気が付いたら、この文章に出会った。この本の著者は、2004年のノーベル物理学賞の受賞者であるが、宇宙物理学者も、“データの流れ”によって、人という生命活動がなされていると解釈しているのを知って大いに驚いた。データフローをもとに“世界の模型（モデル）”を作ることができると言っているのである。
さて、DFDはビジネス活動のモデルを表現するダイアグラムであるが、正しい表記をするた
めには、前回触れたこと以外にも重要なことがある。以下にその点について記述する。
２．データストアを中心に書く
一般にDFDの枚数は多くなる。1枚のDFDにはプロセス・ボックスが、７つ程度示されるのが良いとされる。2階層では、全部で50程度のプロセスを表現できる。3階層では、およそ350のプロセスを示すことになる。したがって、通常は３階層までブレークダウンすれば、大抵の業務では、すべてのビジネス・プロセスを表現できる。それ以上ブレークダウンすると、プロセスではなく、アクティビティ・レベルのなってしまうので避けるべきである。
先月号では、DFDの基本的な書き方について触れた。プロセス・ボックスの名称は、アウトプットとインップトの対応付けが終了したあとで、最適な名称を付けて決めるべきものだということを書いた。「決める」というのは、「決まる」というのとは異なり、人が意思を持って付けるべきということである。既存の名称に拘ることなく、そのプロセスの中身にふさわしい名- 1 / 5 -

情報システム学会 メールマガジン 2014.1.25 No.08-10
連載 企業および社会における情報システムの意味を考える
第 16 回 DFD の正しい書き方と使い方称を付与する。そうすると、従来の発想に縛られないプロセス・イノベーションが見えてくることがある。とはいっても、AsIsのプロセスを表現するときには、プロセスが先に決まるのは致し方ない。
そうではあるが、ToBeモデルへ変換するときに、その手順から抜け出せないと、ToBeモデルとAsIsモデルに違いが出にくい。たいした改善がでデータストアA

データストアB

外部エン
ティティA
データストアCきないということになる。だからDFDはあまり役に立たないと勘違いされる。

外部エンティティB

データストアD

プロセスA

データストアE

DFDには、アウトプットから先に書くということの他、もうひとつ重要な原則がある。それは、データスト

外部エン
ティティC

データストアF

データストアGアの周りにプロセスを配置する、ということである。それはどういうこ

図1となのか、例を示そう。

最初に図１を見てほしい。図１には、プロセス・ボックスが一つだけ示されている。アウト
プットのデータフローは３つあり、いずれもデータストアに書き出している。そのアウトプッ
トを作成するのに、3種類の外部エンテ
ィティからのインプットと、４つのデデータストアA

データストアB

外部エン
ティティA

ータストアの情報を用いていることが示されている。このDFDは、一つのププロセスA-1

データストアDロセスで表現するには、データフローの数が多すぎるので下位に展開できる。

データストアAそうやって、下位に展開したのが図２
データストアCである。図1と図2は、同じ処理の上位モデルと下位モデルである。

外部エンティティB

プロセスA-2

データストアE

図2では、3つのプロセスに分割して、DFDを展開した。プロセスA-1は、外データストアF部エンティティＡのデータを入力のトデータストアBリガーとしてデータストアAとBのマスター情報を参照しながら、データスデータストアCトアDを作成（登録あるいは更新）しデータストアD

プロセスA-3ている。
プロセスA-2およびプロセスA-3の

外部エンティティC

データストアG

解釈はここでは書かないが、このよう
図2- 2 / 5 -

情報システム学会 メールマガジン 2014.1.25 No.08-10
連載 企業および社会における情報システムの意味を考える
第 16 回 DFD の正しい書き方と使い方に3つのプロセスで上位のプロセスA全体が成り立っていることを示している。外部エンティテ
ィとのデータフロー、あるいはデータストアへのデータフローは、上位の図と全く同じであることを確認してほしい。
さて、この図は、上位のDFDの正しい展開図といえるであろうか？実は、否である。
図3は図2を見直したものである。見直しの観点は、データストアを可能な限り一か所にまとめるということである。図2では、データストアB,C,Dが複数回あらわれるが、図3では、一度しか現れないように書き直した。こうすることにより、データストアB、データストアC、データストアDが、複数のプロセス（機能）で使われていることが一目瞭然となる（参照なのか更新系なのかも含めて）。このように書き直すと、データの流れが見えるようになり、DFDらしくなる。
しかし、この図3も最終形ではない。さらに洗練できる。次にそれを見てみよう。
データストアA

外部エン
ティティA

プロセスA-1

データストアD

外部エン
ティティB

データストアF

データストアC

データストアB

プロセスA-2

データストアE

プロセスA-3
外部エン
ティティC
データストアG

図3

３．機能の重複を見つけ洗練する
図3を見ると、プロセスA-1とプロセスA-3では、同一データストアに対する処理があるので、そこには共通機能がある”可能性”があることが分かる。（図4）言い方を変えれば、プロセスA-1とプロセスA-3は、データストアAプロセスの責任範囲が重複している可能性があることを示し

外部エンティティA

プロセスA-1

外部エンティティB

データストアFている。
データストアD

実際に業務上の機

データストアB

データストアC

プロセスA-2能の重複があるかどうかは、もちろん確かデータストアEプロセスA-3める必要がある。意図
外部エンティティC- 3 / 5 データストアG

図4

情報システム学会 メールマガジン 2014.1.25 No.08-10
連載 企業および社会における情報システムの意味を考える
第 16 回 DFD の正しい書き方と使い方的にそうしているのかもしれないということも確認する必要はある。そういった検討の後に、重複が意図的ではなく、慣習的にそういった重複した仕事をしていたのだとわかれば、改善したほうがよいということになるかもしれない。
そうやって、さらに洗練したのが、図5である。このように、DFDをデータストアを中心に書くと、プロセス間での重複機能の存在の可能性が見えてくる。業務分析においてDFDをこのように使うことで、業務プロセスのイノベーションが可能になる。
データストアA
データストアB

データストアF

外部エンティティA

プロセスA-1&3’

外部エンティティB

プロセスA-2

外部エンティティC
データストアD

データストアC
データストアE

外部エンティティC

プロセスA-3’

データストアG

図5

４．DFD は論理的なビジネス・プロセスを示すにとどめる
DFDは、かつてプロセス分析の手法をして、ずいぶん使われた。ただ、必ずしも適切に使われたとは限らない。DFDを展開しすぎるとフローチャートのようになってしまうのが理由の一つ。フローチャートという意味は、ビジネス・プロセスを書いているつもりで、システムの処理の詳細なロジックの流れを書いてしまう、という意味である。構造化が上手にできずに、一枚にあまりに多くのプロセス・ボックスやデータストアを書きすぎて、煩雑なものにしてしまいがちなのが、第二の理由である。半導体の基盤の配線図のようなDFDを見たことがある。そして、組織構造に縛られて、描いた図が現状を示しはするが、抜本的改善につながらないというのが、第三の理由である。特に第三の理由は、抽象化をうまくできないとそうなりがちである。
経験から言えば、DFDは、組織構造に縛られず、あるべきビジネス・プロセス・モデルを描くときに、最も威力を発揮するようである。
基本的に、プロセスはインプットをもとに付加

図 6 ビジネス・プロセスの構造- 4 / 5 -

情報システム学会 メールマガジン 2014.1.25 No.08-10
連載 企業および社会における情報システムの意味を考える
第 16 回 DFD の正しい書き方と使い方価値をつけて何らかのアウトプットを生み出す活動であるので、プロセス・イノベーションを考えるときに、現状の組織構造に基づくアウトプット生成活動に縛られると、良い結論を得ることが難しくなる。
このことは、DFDと業務フローとは違うことを語っている。業務フローは、組織を考えて作成する物理的な活動や作業の流れである。
昨年の1月号でも書いたが、ビジネス・プロセスには、図6のような構造がある。DFDは、プロセス・レベルの工程を表現するために使い、アクティビティ・レベルやタスク・レベルの活動を表現するのには、業務フローを使うのがよいであろう。筆者自身はそのような使い分けをしているが、それにより、業務の全体も示すことができ、かつ、全体と詳細の関係も付けられ、わかりやすいビジネス・プロセス・モデルを描くことができる。是非、参考にしていただきたい。
以上- 5 / 5 -