DFDの深さ：コンテキスト図からレベル1図へと詳細化する方法

データフローダイアグラム（DFD）は、システム分析と設計における基本的なツールです。情報がシステム内でどのように移動するかを視覚的に表現します。DFDの深さを理解することは、要件を正確に捉えるために不可欠です。このガイドでは、高レベルのコンテキスト図から詳細なレベル1図へと移行するプロセスを検討します。特定のソフトウェアツールに依存せずに、分解の原則、データ保存の原則、構造的整合性について検討します。

DFDの階層構造を理解する 🏗️

DFDは平坦な文書ではなく、階層構造を持っています。この構造により、アナリストはシステムを異なる詳細度で見ることができます。各レベルで、プロセスとデータフローの詳細が追加されます。

• コンテキスト図（レベル0）： 最上位のレベル。システムを外部エンティティと相互作用する単一のプロセスとして示します。
• レベル1図： 最初の分解。単一のプロセスを主要なサブプロセスに分割します。
• レベル2図： 必要に応じて、レベル1プロセスのさらなる分解。

コンテキスト図からレベル1図への移行は、新規のアナリストにとってしばしば最も困難なステップです。明確さと詳細さのバランスを取る必要があります。図が高すぎると、実行可能な情報が不足します。逆に低すぎると、ごちゃごちゃして全体像が見えにくくなります。

コンテキスト図：システムの境界 🚧

コンテキスト図は、すべてのDFDの基盤となります。研究対象のシステムの境界を定義します。円の内側にあるものはすべてシステムの一部であり、外側にあるものは外部です。

主要な構成要素

• 中心プロセス： 単一の円または角が丸い長方形で表されます。これは全体のシステムを表します。
• 外部エンティティ： データの発生源または到着先です。これらは人、部門、または他のシステムです。
• データフロー： エンティティとプロセスを結ぶ矢印です。これらは入力または出力を表します。

境界の定義

境界を明確にすることは非常に重要です。現在のプロジェクトの範囲外にあるエンティティは外部とみなされます。たとえば、給与システムでは税務当局は外部エンティティである可能性がありますが、財務部門は内部である可能性があります。境界の誤認は範囲の拡大と混乱を招きます。

コンテキスト図のベストプラクティス

• シンプルに保つ： 中心プロセスは1つだけであるべきです。
• エンティティを制限する： エンティティが多すぎると図がごちゃごちゃになります。システムと直接やり取りするものに注目してください。
• フローの名前を明確に： データフローは名詞（例：「請求書」）で名前を付けるべきです。動詞（例：「請求書を送信する」）ではないです。
• データストアを含めない： コンテキスト図では一般的にデータストアを含まない。すべてのデータは外部エンティティから来たり、外部エンティティへ行く必要がある。

分解：ドリルダウンの芸術 📉

分解とは、複雑なプロセスをより小さく、管理しやすいサブプロセスに分割するプロセスである。これはレベル1図を作成するための核心的なメカニズムである。タスクを分割することだけではなく、システムの内部論理を明らかにすることである。

分解の原則

レベル0からレベル1に移行する際には、論理的一貫性を保つためにいくつかのルールを守らなければならない。

• データの保存則： 親プロセスの入力と出力は、子プロセスの入力と出力の合計と一致しなければならない。何物も突然消えたり、突然現れたりしてはならない。
• 論理的グループ化： サブプロセスは機能ごとにグループ化すべきである。たとえば、「注文の検証」と「在庫の更新」は異なる機能である。
• プロセスの数： 硬い制限はないが、レベル1図には通常5～9つのプロセスが含まれるべきである。それ以上ある場合は、より上位のレベル1にグループ化するか、図を分割することを検討するべきである。
• 意味のある名前： プロセス名は動詞＋名詞の形式（例：「税金を計算する」）に従うべきである。これにより、データフローと明確に区別できる。

バランスの取り方

最も重要な技術的要件の一つが、データフローのバランスである。レベル0プロセスに入力されるデータは、レベル1プロセスに入力されるデータと等しくなければならない。同様に、レベル0プロセスから出力されるデータは、レベル1プロセスから出力されるデータと等しくなければならない。

コンテキスト図で「注文フォーム」がシステムに入力されている場合、レベル1図ではその同じ「注文フォーム」がサブプロセスのいずれかに入力されていることを示さなければならない。もしレベル1図で「顧客ID」が内部で渡されている場合、それがレベル0図で外部入力または出力であることはできない。ただし、そのIDがレベル0図にすでに存在していた場合は除く。

レベル1図の構築 🛠️

分解計画が整うと、実際に構築が開始される。これには、システムの主要な機能領域を特定することが含まれる。

ステップ1：主要プロセスの特定

コンテキスト図の単一のプロセスを確認する。問うべきは：システムの目的を達成するために必要な主な活動は何か？これらがレベル1図のバブルまたは円として表れる。

• 明確なデータ入力フェーズがあるか？
• 明確な処理または計算フェーズがあるか？
• 明確なレポート作成または出力フェーズがあるか？

ステップ2：フローのマッピング

プロセスを矢印でつなぐ。これらの矢印は、内部プロセス間のデータの移動を表す。また、外部エンティティとこれらの新しいサブプロセスをつなぐ矢印も描くことができる。

• 直接フロー： 一つのプロセスから別のプロセスへ移動するデータ。
• エンティティフロー： 外部エンティティからプロセスへ移動するデータ。
• ストアフロー： プロセスからデータストアへ、またはその逆にデータが移動する状態。

ステップ3：データストアの導入

コンテキスト図ではそれらを除外するが、レベル1図では頻繁にデータストアを含む。データストアとは、データが静止状態で保持される場所である。データベース、ファイル、または物理的なファイルボックスである可能性がある。

データストアを描画する際は：

• 開口型の長方形または、あなたの手法で定義された特定の記号を使用する。
• すべてのデータストアに、少なくとも1つの書き込みプロセスと1つの読み込みプロセスがあることを確認する。
• データがストアに入り込むが決して出ていかない「ブラックホール」や、データがストアから出ていくが元々入っていなかった「ミラクル」を作らないようにする。

よくある誤りと修正方法 ⚠️

経験豊富なアナリストですら、DFDを作成する際に誤りに遭遇することがある。これらのパターンを早期に認識することで、検証段階での時間を節約できる。

1. ブラックホール

ブラックホールとは、入力はあるが出力がないプロセスを指す。これは、データが結果を生まないまま消費されていることを意味する。機能的なシステムでは、すべての入力は何かしらの出力またはデータ保存に結びついていなければならない。

2. ミラクル

ミラクルとは、出力はあるが入力がないプロセスを指す。これは、データが何もないところから生成されていることを意味する。すべての出力は、何らかの入力データから導かれるべきである。

3. コントロールフロー

DFDはコントロールフローではなく、データフローを追跡する。コントロールフローとは、プロセスの開始または停止を示す信号（例：「スタートボタンが押された」）を表す。コントロール信号のように見えるフローが見られたら、それは実際にはデータ（例：「スタートリクエスト」）である可能性が高い。DFDはタイミングや論理制御を明示的に扱わない。

4. バランスの取れていないフロー

レベル1図の入力がコンテキスト図の入力と一致しないときに発生する。レベル1図を描いた後は、常にデータの保存（保存則）を確認する。

DFDレベルの比較 📊

以下の表は、どのレベルをいつ使うべきかを理解するのに役立つように、各レベルの違いを要約したものである。

検証と精練 🔍

初期ドラフトの後、図は検証されなければならない。これは一度きりの確認ではなく、見直しと精練のサイクルである。

• 同僚レビュー：別のアナリストに図を見てもらう。あなたには明らかだったフローが文書に記載されていないことに気づくかもしれない。
• ステークホルダーの検証：ビジネスユーザーと一緒に図を確認する。フローが日々の業務と一致しているか確認する。
• 完全性の確認：すべての外部エンティティが接続されていることを確認する。すべてのデータストアにアクセスがあることを確認する。
• 一貫性の確認：命名規則を確認する。「注文」という用語が一つの場所では「発注依頼」と別の場所では異なる名前にならないようにする。

深さに関する高度な考慮事項 🧠

DFD構造をさらに深く掘り進めるにつれて、粒度に関する意思決定に直面する。どのくらい深くまで掘り下げるべきか？

粒度の閾値

普遍的なルールはないが、一般的なガイドラインは存在する：

• 機能的完全性：プロセスは、完全なビジネス機能を表すべきである。
• 管理可能性：図はスクロールなしで標準のページまたは画面に収まるべきである。
• 複雑さ：レベル1のプロセスに7つ以上のサブプロセスがある場合、独自のレベル2図が必要になる可能性がある。

データストアの取り扱い

データストアは視覚的な流れを複雑にする可能性がある。論理的に配置されていることを確認する。プロセスを貫く線を引かないでください。線がプロセスを横切らなければならない場合は、通過していることを示すために接続点またはジャンクション記号を使用する。

外部エンティティと内部アクター

システム内のアクターと外部のアクターを区別してください。人間のオペレーターがシステムのワークフローの一部である場合（例：データを入力する事務員）、内部のアクターである可能性がありますが、多くの場合、ソフトウェアの境界外にあるため外部エンティティとして表現されます。この定義の整合性が鍵となります。

ドキュメント作成のベストプラクティス 📝

図は物語の一部にすぎません。論理を説明するために文章による記述が必要です。

• プロセス辞書：各プロセスを説明する文書を作成してください。入力、出力、および使用される具体的な論理（例：「残高 < 0 の場合、遅延としてマークする」）を含めてください。
• データ辞書：すべてのデータ要素を定義してください。データ型、長さ、許可される値を指定してください。
• 凡例：カスタム記号を使用する場合は、その意味を説明する凡例を提供してください。

ドリルダウンプロセスの要約 🔄

コンテキストからレベル1へと成功裏に移行するには、厳密なアプローチが必要です。より多くのボックスを描くことではなく、システムの真実を明らかにすることです。

• 境界を明確に定義する明確なコンテキスト図から始めましょう。
• システムを構成する主要な機能領域を特定してください。
• データ保存の原則を適用して、バランスを確保してください。
• 情報が保持される場所にデータストアを追加してください。
• ステークホルダーと照合して正確性を確認してください。

これらの構造化されたステップに従うことで、システム設計の堅固な基盤が築かれます。レベル1図は開発者のための設計図となり、ビジネス関係者とのコミュニケーションツールにもなります。抽象的な要件と具体的な実装の間のギャップを埋めます。