データ・モデルを維持管理して生かす

業務フローだけでは、ビジネス・ルールもデータの流れもつかみにくい

データ・モデルを見れば、どのようなビジネス活動を行っているのかが、分かり易くなります。このため、データ・モデルは、さまざまな場面で活用できます。例えば、システム構築を推進する情報システム部門とユーザー部門とのコミュニケーションをスムーズにする手段として、非常に有効です。

一般的に、要件定義を行う際には、ユーザーに業務のヒアリングを行い、ヒアリングの内容を仕様に反映します。この仕様をもとに、開発を進めていきます。しかし、ほとんどの場合、開発途中で仕様変更、いわゆる手戻り作業が発生します。仕様変更を発生させる原因の1つは、仕様を固める際のコミュニケーション・ミスです。

情報システム部門とユーザー部門の意思疎通を図る手段には、大きく2つあります。業務フロー図と、ER図（論理データ・モデル）です。いずれも、システム構築には欠かせないドキュメントであり、互いに補完関係にありますが、コミュニケーションを図るという点では大きな違いがあります。

例えば、商品の販売形態として、直接販売と間接販売の両方を手がけている企業があったとします。この企業は、販売力強化のため、直接販売部門と間接販売部門を統合し、販売システムを再構築しようとしています。

直接販売を行っているA事業部では、以下の4つの受注プロセスを行います。その後、業務を出荷部門へ引き継ぎます。

1. 取引先から営業担当に見積依頼
2. 営業担当は見積システムで見積もりを作成し、取引先に提示
3. 取引先は、見積内容を確認して注文
4. 取引先からの注文書情報に基づき、業務担当が受注入力

一方、間接販売を行っているB事業部では、以下の受注プロセスを行います。その後、A事業部と同様に、業務を出荷部門へ引き継ぎます。

1. 取引先からの注文書に基づき、業務担当が受注入力
2. 業務担当が、受注内容を営業担当へ連絡

上記の流れを、業務フロー図を使って表現したものが、図1です。

以上のように、この企業は、同じ受注業務であっても、直接販売と間接販売ではプロセスが異なります。このため、業務フロー図は、それぞれ個別に作成しなければなりません。

また、業務フロー図では、直接販売、間接販売、出荷という個別のプロセスを把握することはできますが、直接販売と間接販売の違いを含めて、受注から出荷までの一連の流れを簡単に確認することができません。さらに、今回のように対象の業務が3部門（直接販売、間接販売、出荷）にまたがってしまうと、各部門が行っている業務の相違点を確認しにくい、というデメリットがあります。

情報システム部門であっても、業務をよく理解しているのであれば、要件定義の段階で、業務面からの指摘や相違点の確認ができます。しかし、業務が分からなければ、ユーザーへのヒアリングに頼りがちとなり、結果として業務とうまく噛み合わないシステムが構築されてしまいます。また、業務フロー図では、データの細かい流れを簡単に把握することができません。

全体像が見えるデータ・モデルでは、新たな問題や改善案を発見できる

ER図（論理データ・モデル）で表した場合、業務フロー図と比べて、コミュニケーションにどのような差が出るでしょうか。先ほどと同じ例を用いて、「業務全体」、「リレーションシップ」、「属性（データ項目）」の視点で解説します。

• 業務全体
• リレーションシップ
• 属性（データ項目）

（1）全体把握

業務フロー図では、単体のプロセスしか把握できません。一方、ER図では、受注から出荷までの一連の業務とデータの流れ、およびそれらの関係性を、全体的に、また細かいところまで把握できます。

まず、ER図を見ると、取引先エンティティがサブタイプ化されていることが分かります。これにより、取引先には顧客と代理店の2種類があることが分かります。業務フロー図の場合は直接販売と間接販売の2つを分けて作成する必要がありましたが、ER図では、それぞれの業務を1つで表現できます。

また、顧客エンティティから見積エンティティに対して定義したリレーションシップと、代理店エンティティから間接受注明細エンティティに対して定義したリレーションシップの2点に注目してください。これらは、「A事業部は、直接販売を行っているため、取引先への見積もり提出が必要」であり、「B事業部は、間接販売であるため、見積もりが不要」であるという、業務の違いを表しています。

さらに、担当者エンティティは、見積、受注、出荷の3つのエンティティに対してリレーションシップを定義しており、それぞれ、営業担当者コード、業務担当者コード、出荷担当者コードと、それぞれの役割担当を明示して定義しています。これにより、見積もりは営業担当、受注は業務担当、出荷は出荷担当が、それぞれの業務を行っていることが分かります。

このように、ER図を使うことによって、業務に関係のないシステム担当者であっても、追加のヒアリングを行うことなく、業務内容全体を簡単に把握することができます。

（2）リレーションシップに着目

先ほどのER図をもう1度、見てみましょう。取引先エンティティと出荷エンティティのリレーションシップが定義されていない点に着目してください。これらが設定されていないということは、出荷先と受注先が同じ、ということを示します。つまり、直接販売の場合は顧客、間接販売の場合は代理店となります。

ER図から読み取れる範囲で、次の仮説が考えられます。

1. 商品によっては、代理店を経由せずに直送されているものがあるのか？
2. 代理店サービスが付随する場合は代理店を経由し、商品単独の場合は直送されるのか？

ER図のメリットは、仮説の検証が可能なだけではありません。「商品によっては、代理店を経由させずに直接納品とすることで、顧客接点を増やすことができる。これにより、直接販売との相乗効果を図ることができる」といったように、新たな改善案を生み出すことが可能です。

また、商品エンティティに着目すると、見積明細エンティティと間接受注明細エンティティにリレーションシップが定義されていることが分かります。この点から、「直接販売の場合は、見積時に商品構成を変更できる。間接販売の場合は、受注時に商品構成を変更できる」ことが分かります。

事業部単位での活動は、ER図を見ても「A事業部では、受注時に、見積時とは異なる商品構成になることがある」といったことは予見できないかも知れません。しかし、ER図を用いて全体を俯瞰（ふかん）し、類似業務や関連業務と比較しながら確認することで、より新たな検討事項を生み出すことができます。

（3）データ項目に着目

リソース系エンティティに従属する項目と思われるものが、イベント系エンティティに含まれる場合があります。

図4の「単価」に着目してください。単価は、商品に関連するので、一般的には商品エンティティに従属します。しかし、図4では、見積エンティティにも含まれています。見積エンティティには取引先コードがフォーリン・キーとして含まれているため、「見積時に、取引先によって単価を変更できるのではないか」という仮説が立てられます。

このように、ER図から読み取れることをユーザー部門に確認することで、より深いコミュニケーションを図ることが可能になります。