【工事中】概念DFD
注：草案中ですが一旦公開します。
頻繁に更新するのでご了承ください。
前提知識
こちらの記事『3つのデータモデルとエンティティ』をご一読ください。
概念DFD
概念DFDとは？
下図のように、概念エンティティとデータの流れを表した図を、私は概念DFD（Data Flow Diagram）と呼んでいます。
なお、主に使う概念エンティティは、そのタイプがイベント型や在庫型が
中心です。他のタイプは基本的には使いません。また、概念DFDは、比較的自由に使えるように考えています。その応用例については後述します。
概念DFDと教科書的なDFDとの違い
ここでいう「教科書的なDFD」とは、情報処理技術者試験などでも採用されている、昔から使われているDFDを指します。名前に「データ」が付いているので誤解しやすいですが、処理（＝プロセス）を表す図です。
概念DFDは、「業務で使うデータの流れ」を重視した図です。そのため、
教科書的なDFDの「データストア」を概念エンティティに置き換え、「プロセス」と「源泉と吸収」は使いません。
【コラム】教科書的なDFDと業務フロー図の関係
私の経験では、教科書的なDFDではなく、業務フロー図を使っていました。具体的には、業務の流れにITシステムとの関連も加えた図です。特に意図していたわけではなく、そのように先輩方から習っていたし、お客様からも求められていたので。
以降は、教科書的なDFDと業務フロー図を区別せずに使います。
概念DFDと業務の関係
コンピュータが普及する前は、業務の流れに合わせて、下図のように紙帳票も流れていました。そのコンピュータ化の過程で生まれたモデル図の一つが「教科書的なDFD」です。データベース（以下、DB）が生まれる前のモデル図なので、「データストア」は「紙帳票の束」なども含めた考え方でした。
コンピュータの普及が進み、DBも活用されるようになりました。「紙帳票の束」ではなく、DBを使ってデータを効果的・効率的に「蓄積および加工」できるよう、データモデリング技術が考え出されました。その過程で3つのデータモデルも生まれました。
それでも、業務面では「紙帳票」の考え方が活かせます。紙をデータに置き換えただけなので。私は、「紙帳票の束」を概念エンティティに置き換えて捉えています。図1と図2を組み合わせると、図3-1のようなイメージになります。
図3-1の一部をデータを登録する画面に変えると、図3-2のようなイメージになります。
さらに、昨今は入出力機能の多様化が進んでいます。たとえば、処理の自動化やEDIの活用した図3-3のようなイメージです。
概念DFDを図3-1～3のように定義すると、概念エンティティの数が増えると煩雑になり、分かりにくくなります。そのため、私は割り切って図1のように簡素化しました。概念エンティティと処理の関係については、詳細DFD（注：別の記事で書きます）などの別のモデル図で対応します。
概念DFDと概念データモデル
概念DFDと概念エンティティ名
イベント型の概念エンティティの名称を決める場合、英語の第3文型「SVO（主語、述語動詞、目的語）」を使うと便利です。例えば、図4のようなイメージです。概念エンティティの名称を「O→V」の順になるようにしています。主語（S）は明らか（＝業務を遂行する企業）なので割愛するのが一般的です。
ただし、慣習的に使い慣れた用語があれば、そちらを優先して構いません。図4でいえば、「注文受領 → 受注」、「債権請求 → 請求」です。図1などは、慣習的な用語を採用しています。以降も同じです。
概念DFDと識別子の関係
図3-2の「出荷指示登録」画面は、概念エンティティ［受注］のデータを参照することを表しています。具体的に参照した受注データが何かを、概念エンティティ［受注］の識別子「受注番号」の値を概念エンティティ［在庫出荷］に記録します。概念エンティティ［請求］も同様です。
図1に識別子の流れも追加したのが、図5です。なお、「識別子」の使い方によって「主キー」や「外部キー」という表現に変えています。
このような「主キー（の値）と外部キー（の値）の関係」を、データモデリングでは「リレーションシップ」と呼んでいます（注1）。図5を理解できれば、図1の概念DFDは図6のような概念DFDに変換できます（注2）。
注1：オブジェクト指向アプローチでは、識別子とは別にインスタンスを
使います。ここでいう「インスタンス」は、コンピュータのメモリ
上のアドレス（いわゆる「ポインタ」）で特定するイメージです。
注2：概念DFDと概念ERDの関係を理解しやすいよう、簡単な例を使いま
した。実践では、単純に変換できないことのほうが多いです。
留意してください。
在庫型の概念エンティティを組み合わせた例
前述したとおり、概念DFDでは主にイベント型の概念エンティティを使います。他の概念エンティティ・タイプを使った例が図7です。概念エンティティ［在庫］のタイプが「在庫型」であることが分かるようにしています。
参考のために、上記のように SVO と紐づけやすいように文章も追加しました。
在庫型の概念エンティティの場合、V（述語動詞）がないことが分かります。コンピュータ上に記録があろうがなかろうが、実物の在庫があるためです。図5のような識別子の流れとは異なるので注意してください。詳しいことは割愛します。
概念DFDと業務フロー図
業務フロー図の利点と欠点
業務フロー図は、業務ユーザーにも分かりやすいという利点があります。しかし、IT技術の進歩により、ITシステム化の視点では業務フロー図の欠点も目立つようになりました。例えば、図3-3のように多様な入出力機能を使う場合です。ITシステムとしては多様な入出力機能があっても、業務ユーザーや（BtoCの）消費者などの個々人の視点では使い分けないのほとんどです。
そのため、業務フロー図も必然的に複数に分かれます。1つの概念エンティティが複数の業務フロー図に表れることになります。システム要求・要件定義の途中では、本当に「1つの概念エンティティ」なのかも不明確です。業務フロー図だけでは、概念データモデルを確定することはできません。
概念DFDは、業務フロー図の欠点を補う
業務フロー図の上記欠点を補うためには、概念エンティティの視点でデータの流れをまとめることが必要です。そのために使うのが概念DFDです。たとえば、業務フロー図Aに出てくる［受注］などの概念エンティティと、別の図Bに出てくる［受注］などの概念エンティティが同じなのか、データの流れ（主に識別子）が同じなのか、概念DFDを使って確認できます。
概念DFDを使って問題がないことが確認できれば、上述どおりに概念データモデルに変換して、具体的なデータモデリングを進められます。
概念DFDと他のモデル図
モデル図の視点と主な種類
システム要求・要件定義や設計で使うモデルは、図8-1の2つの視点によって大きく4つに分類できます。
これらの分類を組み合わせると、実際に使う代表的なモデル図は、図8-2のように位置づけられます。
これらのモデル図を実際に使うと、モデル図間の連携度合いの悪さが気になる時があります。それを補完するため、私は概念DFDを位置づけられると考えています。データモデルと業務フロー図については前述どおりです。他の図については、後日追加します。
概念DFDを使う目的
概念DFDを使う大きな目的は、次の2つです。
システム要求・要件定義および設計の当たり前品質を上げる
プロジェクト内や運用・保守担当者とのコミュニケーションを円滑にする
目的1は、一般的なモデル図の目的と共通です。
より重視したいのは、目的2です。コミュニケーションが円滑になればなるほど、当たり前品質が向上するためです。具体的なことは、次のコツを参考にしてください。
概念DFDを使うコツ
概念DFDを使うコツを、3つだけ挙げます。
概念DFDはA3用紙1枚に収まるように作る
概念DFDをコミュニケーション・ツールとして活用する
概念DFDを納品物にしない
以下に補足します。
コツ1．概念DFDはA3用紙1枚に収まるように作る
上記目的2を果たすためには、システムの全体像を関係者と共有することが欠かせません。概念DFDは「データ」の視点でシステムの全体像を表すのに適しています。
その全体像を概念DFDで表す場合、私の過去の経験でいえば、A3用紙1枚に収まる範囲が適切でした。それで7～8割の概要が伝われば、あとは関係するドキュメントと紐づけることで済みました。
では、A3用紙1枚に収まらない場合はどうするか。
私は、それに対する考え方を、概念DFDの詳細度と日本地図を使って説明することが多いです。例えば、次です。なお、詳細度は、教科書的なDFDで使う「レベル」にあたります。
詳細度 0 ： 日本地図
詳細度 1 ： 都道府県別の地図
詳細度 2 ： 市区町村別の地図
詳細度 3 ： 市街地など別の地図
｜詳細度 n ： 建物内の地図（や設計図）
詳細度が上がれば、教科書的なDFDのように処理（プロセス）を追加しやすくなります。そのような図を私は「詳細DFD」として区別しています。詳細DFDについては別の記事で書きます。
コツ2．概念DFDをコミュニケーション・ツールとして活用する
コミュニケーション円滑化を図る方法として、（1）概念DFDに工夫を加える、（2）概念DFDを使って関係者と会話する、などがあります。
（1）については、次の2つの事例を使って説明します。
・ 大量データを扱うシステム開発プロジェクトで、各概念エンティティに
ついて、データを一度に登録する件数や累計のデータ件数を付記した。
→ 関係者が処理性能の向上を意識しやすくなりました。
・ データ・マネジメントに関するシステム開発プロジェクトで、次の3つが
分かるように列をつけた。
（a）データの取り込み、（b）データ加工、（c）データ表示
→ 概念エンティティの役割が判別しやすくなりました。
（2）について、私が取り組んだのは、印刷した概念DFDを使って会話する
ことでした。たとえば、会話する対象を、概念DFDの該当箇所を指して話すようにしました。
私が意外だったのは、若手技術者が自主的に印刷して活用していたこと。
具体的には、自分がシステムのどの部分を担当しているかを把握する、データフローの前後の担当者と積極的に会話する、必要なことを書きこむ、などの活用をしていました。
以上のようなことから、概念DFDがコミュニケーション・ツールとして活用するのが有用だと考えています。
コツ3．概念DFDを納品物にしない
私の経験では、頻繫に概念DFDを更新していました。コミュニケーション・ツールとして活用していたので、改善点に都度気づいたためです。もちろん、詳細設計工程以降での改善頻度は減りました。
しかし、もし納品物としていたら、変更管理の負担が無視できない大きさだったと思います。コミュニケーションに使える時間も減るので、品質悪化リスクも大きくなります。そのようなリスクを大きくしないため、概念DFDを納品物にしないことが大事です。