1.3業務モデリング

業務モデリングは「決まった図を機械的に描く」作業ではありません。同じ業務を可視化する場合でも、データの流れと処理の関係を明らかにしたいのか、データの構造を明らかにしたいのか、利用者とシステムの相互作用を明らかにしたいのか、業務プロセス全体の分岐・並行・関係者の役割分担を明らかにしたいのかによって、選ぶべき表記法（DFD/E-R図/UML/BPMN）は変わります。目的に合わない表記法を選ぶと、伝えたい情報がうまく可視化できず、ステークホルダとの認識合わせに失敗します。

1.3.1DFDとE-R図

• DFD（Data Flow Diagram・データフローダイアグラム）＝業務やシステムにおけるデータの流れと処理（プロセス）・データストア・外部との入出力の関係を図示する表記法。「どのデータが、どの処理を経て、どこに保存・出力されるか」というデータの流れに着目した現状分析・業務改善の検討に向く。
• E-R図（Entity-Relationship Diagram）＝業務で扱うデータの実体（エンティティ）と実体間の関連（リレーションシップ）を図示する表記法。「どのようなデータ項目が存在し、それらがどう関連するか」というデータ構造の設計・データベース設計の土台に向く。DFDが「データの流れ」に着目するのに対し、E-R図は「データの構造」に着目する点が異なる。

1.3.2UML（ユースケース図）とBPMN

• UML（Unified Modeling Language）のユースケース図＝利用者（アクタ）とシステムが提供する機能（ユースケース）の相互作用を図示する表記法。「システムは誰に対して何ができるようにするのか」というシステムの機能スコープの合意形成に向く。業務プロセスの内部の手順の詳細（誰が何の順で処理するか）までは表現しない。
• BPMN（Business Process Model and Notation）＝業務プロセス全体の手順・分岐（条件分岐）・並行処理・複数の関係者（レーン）間での役割分担を時系列に沿って図示する表記法。「現行の業務手順のどこが非効率か」「理想の業務手順はどうあるべきか」という業務プロセス全体のAs-Is/To-Be対比に向く。DFDがデータの流れに着目するのに対し、BPMNは処理の手順・制御フローに着目する。

あなたは物流会社のシステムアーキテクトで、「出荷指示から配送完了までの業務プロセスが非効率で、部門間の連携で遅延が頻発している」という課題を受け、業務モデリングによる現状分析を任されたとします。ある同僚は「まずE-R図を描いて、扱っているデータ項目をすべて洗い出そう」と提案しました。しかし、この課題の本質はデータ項目の過不足ではなく、出荷指示部門・倉庫部門・配送部門という複数の関係者の間で、どの順序で・どの条件分岐で・誰が何を担当し処理が受け渡されているかにあります。E-R図はデータの構造（実体と関連）を明らかにするのには向いていますが、複数部門にまたがる処理の手順・分岐・並行関係を可視化する目的には向いていません。この場面で選ぶべき表記法はBPMNです。出荷指示部門・倉庫部門・配送部門を別々のレーンとして配置し、各部門の処理を時系列に並べることで、「倉庫部門の在庫確認待ちで配送指示が滞留している」「ある条件分岐（在庫不足時の代替手配）の処理が部門をまたいで往復し遅延の主因になっている」といったAs-Isの非効率箇所を可視化でき、そのままTo-Be（改善後の業務プロセス）の設計にも活用できます。もし後工程でこの業務が扱うデータの詳細設計（データベース設計）に進む段階になれば、そこで初めてE-R図が有効になります。「とりあえず定番の図を描く」のではなく、明らかにしたい対象（データの流れか、データの構造か、機能スコープか、業務プロセス全体の手順・役割分担か）に応じて表記法を選ぶことが、業務モデリングの核心です。

1.3.3この節のまとめ

• DFDはデータの流れ、E-R図はデータの構造（実体と関連）に着目する表記法
• UMLユースケース図は機能スコープの合意、BPMNは業務プロセス全体の手順・分岐・役割分担に向く
• 表記法は明らかにしたい対象（データか、構造か、相互作用か、プロセス全体か）から逆算して選ぶ判断が核心