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

連載 :

2010年10月28日(木)

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

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

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

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

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

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

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

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

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

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

図1: 受注プロセスと出荷プロセスの業務フロー図（クリックで拡大）

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

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

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

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

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

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

（1）全体把握

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

図2: ER図で全体を把握する（クリックで拡大）

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

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

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

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

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

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

図3: リレーションシップから読み取る（クリックで拡大）

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

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

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

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

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

（3）データ項目に着目

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

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

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

図4: データ項目から読み取る

外部委託先とのコミュニケーション・ツールとして使う

データ・モデルは、社内だけでなく、対象業務を複数の委託会社に分けて開発を行う場合など、外部委託先とのコミュニケーションを図る際にも有効です。

受注プロセスはA社、出荷プロセスはB社、といったように、業務プロセスごとに別の委託先に開発を依頼する場合を考えてみましょう。受注プロセスにも、出荷プロセスにも、同じデータ（商品や取引先）があります。しかし、委託先の会社では、それぞれが請け負ったプロセスしか見えません。このため、最終的に納品されたシステム間で、不整合が生じます。

データ・モデルは、全体最適を考慮したものです。しかし、外部の委託会社は、自社の開発生産性を主眼に置くため、データ整理後の「論理データ・モデル」ではなく、処理効率などを考慮した「物理データ・モデル」をベースに考えます。

複数の委託先が、それぞれの効率を考えた物理データ・モデルをベースとしている以上、全体最適にはなりません。このため、納品後に、システム間の差異を埋める連携プログラムを別途用意することになり、システムの保守が大変になってしまうのです。

この問題を解決するためには、全体最適を考慮する論理データ・モデルは、委託先ではなく可能な限り自社で作成すべきです。そして、自社の論理データ・モデルと、納品された物理データ・モデルを比較し、違和感を感じる場合には「なぜ、このようなデータ構造になったのか」を説明させます。こうして、説明に納得できないものについては再検討を促す、といった品質基準を作ることで、トラブルを未然に回避できます。

データ・モデルの活用は発想しだい

データ・モデルは、コミュニケーション以外の、どのような局面で有効でしょうか。

（1）システム統合時

企業合併や工場統合などにより、システムを統合しなければならないケースがあります。このケースでは、業務フローの統合もさることながら、データの統合も必須です。データ統合の際に、主に問題となるのは、「データ構造の違い」、「用語の違い」、「コードの違い」です。

アプリケーションの改修に大きくかかわることになるので、先に物理データ・モデルから統合するという方法はとれません。まずは、論理データ・モデルを用いて、システム同士にどの程度の差異があるのかを確認する必要があります。

最初に、各工場や企業の論理データ・モデルを作成し、それぞれのフィット・アンド・ギャップ分析を行います。次に、統合された、現状の論理データ・モデルを作成します。具体的な統合の手順は、前回の記事で説明した「最適化」を参考にしてください。

さらに、統合後の、あるべき姿となる論理データ・モデルを作成します。これを、現状の論理データ・モデルと比較することで、理想と現実（運用）がうまく噛み合った、理想的なデータ・モデルが完成します。

図5: 理想形となる共通データ・モデルの作成

（2）ERPパッケージの導入時

ERP（統合業務）パッケージを導入する最大のメリットは、システム構築の短納期化です。多くの企業では、対象業務の体系化を行った上で、ERPパッケージが提供する機能と比較し、充足していると判断したら、導入を検討します。

しかし、ERP導入の真の問題は、導入後にあります。「必要なデータが取得できない」といった問題が発生するのです。筆者が支援したユーザー企業では、ERPパッケージのテーブルからデータを取得して他のデータと連携させるブリッジ・プログラムを新規に作成したり、取得できないデータを投入する画面を新たに作成したりする、といったケースが多く見受けられました。

こうした問題は、ERPパッケージの導入前に、データの観点では分析していなかったことが原因です。

自社の論理データ・モデルを作成してあれば、ERPパッケージ導入の際に、データの観点でのフィット・アンド・ギャップ分析が可能となります。

自社の論理データ・モデル × 機能要件
機能要件 × パッケージ機能
パッケージのデータ・モデル × 自社の論理データ・モデル

以上のような多面的な検証によって、ERPパッケージの適合性評価の精度を上げ、ブリッジ・プログラムの作成やデータ投入用画面の作成といったような後手後手の対応が不要になります。

このように、「システム部門でも業務を細かく把握できる」、「コミュニケーション・ツールとして利用する」、「システム統合やERPパッケージ導入時の検証に利用する」など、データ・モデルの活用範囲は、幅広く存在します。

データ・モデルは、作りっぱなしにしない

多方面にわたって活用可能なデータ・モデルですが、せっかく手間暇かけて作成しても、作りっぱなしの状態にしていては、システム変更時に迅速な対応ができません。当然、コミュニケーション・ツールとしても、浸透しないでしょう。

ここで、データ・モデリングとITコストの関係に、注目してください（図6）。

まず、図6の中の、2本の実線に注目してください。右に行くほど上に向かう線は、従来型のファイル設計技法（POA^*1: プログラム中心アプローチ）を採用した場合のコストを示しています。一方、もう一方の、下側にある線は、データ・モデリングを採用した場合のコストを示しています。

[*1] POA: プログラムを中心としているため、最適化されたデータがプログラムごとに複数存在する。データに重複があるため、システムのムダも複数存在する。また、システム統合時には、どれが正しいデータなのか、どれが最新なのかが判断できず、データ統合に難点あり。

データ・モデリングの初動時は、データの意味や内容を確認する時間がかかるため、従来型と比べてコスト曲線は大幅に高くなります。しかし、システムがカット・オーバー（稼働開始）するあたりから、従来型のファイル設計技法のコストが急速に上昇し、データ・モデリングの曲線を越えてしまいます。

ケースごとに曲線の角度に違いはあるものの、データ・モデリングは「仕様変更の影響を受けにくいデータに注目して設計する」という特徴があるため、従来型に比べて冗長性が低く安定性が高いデータ構造を構築できます。仕様変更への対応コストを抑制する効果があります。

とはいえ、ここで注目して欲しいのは、従来型のファイル設計技法との違いではなく、データ・モデリングを採用した場合の、実線とカット・オーバー以降の点線です。この点線が意味しているのは、「一度作成したデータ・モデルを保守していかなければ、データ・モデリングを採用しても、コスト削減効果は薄い」ということです。

図6: データ・モデリングとITコスト（クリックで拡大）

せっかく手間暇かけて作成したデータ・モデルなのですから、その後も維持していかなければ、意味がありません。また、データ・モデリングで得た知識や経験が企業内に蓄積され、変化への対応力の糧となることで初めて、データが企業の経営資源となるのです。逆にいえば、ヒト・モノ・カネは企業で管理されています。企業で管理されていないのは、データぐらいのものです。

人的管理と物的管理の両方でデータ・モデルを維持、管理する

上記の問題は、管理体制（マネジメント・システム）によって解決するしかありません。マネジメント・システムとは、リポジトリと呼ぶデータベースでデータ・モデルを一元管理し、人的管理と物的管理の2つの面から維持、管理していく仕組みのことです。

図7: データ・モデルのマネジメント・システム

（1）人的管理

管理すべき対象は、ER図、データ定義、コード設計書、用語辞書、の4つです。

データ定義には、「アトリビュート」や「カラム」の意味、内容、属性、データ例なども含まれます。コード設計書には、取引先コードや注文番号など、企業で管理しているコード体系や付番ルールが含まれます。用語辞書には、標準化されたデータ名称が含まれる辞書と、名称の標準化ルールが含まれます。データベース・セキュリティに関する定義を包含する場合もあります。

これらの管理対象は、メタデータ（データのデータという意味。例えば、データの属性を示すデータなどが該当）としてリポジトリで一元管理します。複数の関係者が、データ・モデルを同時に参照、更新できる状態が理想です。また、維持管理にあたっては、Oracle Databaseなどを管理するデータベース管理者（DBA）ではなく、全社のデータを管理するデータ管理者（DA）の設置が必要です。