【連載：モデリング修行 入門編】

第2回
オブジェクトモデリングの基礎としてのデータモデリング

篠原光太郎
2003/4/8

---

「第1回 モデリングなしで開発はできない」は、モデリングという概念の説明と、いかにシステム構築においてモデリングが重要な役割を果たすかというポイントを解説しました。今回は、範囲をシステム構築に狭め、システム構築において利用されるモデリング手法を解説し、その中で、データモデルの果たすべき役割を明確にしていきます

---

システム構築におけるさまざまなモデリング手法

　システムを構築する際に必要になるモデルには数多くのものが挙げられますが、大きく分けるとすれば、「システム化をする対象領域」を抽象化したモデルと、「システムそのもの」を抽象化したモデルの2つに分けることができます。

　企業で利用する業務システムの場合には、「システム化をする対象領域」とは業務領域ということになり、業務モデルが必要になります。例えば、受注システムの場合には、システムが支援する対象となる受注業務とはどのような業務なのか、その中でシステムが支援する業務は、どの業務なのか、という点を明確にするためのツールが必要になります。システム構築における業務モデルは、主に業務分析フェイズで作成され、システムの要件定義のインプットとする場合が多いのですが、構築されたシステムが想定する業務モデルに合致しているかをシステムテストフェイズで確認する場合にも利用されます。業務モデルのこのような目的を聞いたときに、業務フローなどを思い浮かべた人も多いでしょうね。業務フローも1つの業務モデルなのです。

　「システムそのもの」で、対象となるシステムの構成要素ごとにモデルが必要になります。例えば、取り扱うデータをモデル化したデータモデル、実装する機能をモデル化した機能モデル、システム構成をモデル化した構成モデルなどがシステムそのもののモデルです。

　それぞれのモデルには、モデル化の手順と図式化のフォーマットなどを規定したさまざまな手法が存在します。例えば、業務モデルにおいては業務をアクティビティという単位で細分化し分析するビジネスプロセスモデル、データモデルにおいてはデータモデルの対象を、エンティティとそのエンティティ間の関連に分けて定義を行うエンティティ・リレーションシップモデルなどが有名です。

　では、システム構築におけるモデリング手法について、その分析対象となる単位をまとめておきましょう。

■業務モデリング手法

　1990年代初頭の業務用統合パッケージ（ERP）の普及が、業務モデリングの普及を促進しました。ERPは、多くの企業で使用されている各業務エリアの業務プロセスを分析し、その標準ともいえる「ベストプラクティス」をベースに業務をモデル化し、そのモデルに従った業務アプリケーションを提供しています。ERPを採用する際は、企業固有の業務プロセスとERPが採用した標準モデルとの間のギャップを「カスタマイズ」や「アドオン」として実装する必要がありますが、ERPの導入を成功させるためには、このカスタマイズの量を最小限に抑えることが必須とされています。このため、企業の業務プロセスを分析し、パッケージの持つ標準モデルとのギャップを明らかにし、なるべく多くのギャップの解消をERPのカスタマイズで行うのではなく、業務プロセスの変更でカバーするように設計する必要があります。

　企業の業務プロセスの最適化を図る手法として「ビジネスプロセスリエンジニアリング（BPR）」が1990年代初頭に発表され、付加価値を生まない業務プロセスを削減し、付加価値を生む業務プロセスに集中することを提唱しました。これは、先ほどのERP導入における業務プロセス変更の必然性とマッチし、ERPの普及と併せて非常に一般的な手法となりました。

　BPRは、業務プロセスをモデル化し、As-Is（現状）からTo-Be（将来）の業務プロセスを導出する手法です。BPRにおける業務プロセスとは、ある情報をインプットとし付加価値のあるアウトプットを出力するアクティビティ（活動）の集合と定義されます。そして、すべてのプロセスは、後の情報システムへの適用を容易にするため、何らかのイベントを機に開始され、一連のアクティビティが終了した時点で完了します。例えば、顧客情報登録プロセスは、コールセンターによる電話受付をイベントとしてスタートし、既存顧客か否かの確認、顧客情報項目の聴取、顧客情報の保存、などのアクティビティによって構成されます。

　また、プロセスモデリングにはIDEF0と呼ばれる規格があります。これは、別名機能モデリングとも呼ばれており、BPRと同様、企業における業務をアクティビティというレベルに分割し、それぞれのアクティビティに対しインプットとアウトプット、制約と機構という4つの情報を定義する手法です。米国商務省の標準化機関であるNIST（National Institute of Standards and Technology）によって1990年代初頭に標準化され、現在でも多くの企業において採用されています。

　もう1つ、プロセスモデリングの手法として押さえておかなくてはならないのが、データ・フロー・ダイアグラム（Data Flow Diagra：DFD）です。DFDは、1970年代に、Tom Demarcoによって提案された構造化分析手法の一部です。DFDは、データの流れを中心に、プロセスを分解し定義していきます。当初は、このDFDのみですべての分析が完結する手法として提案されましたが、現在では、ほかの手法との併用により利用されることが多い手法です。

　また、業務のモデリングは、業務のプロセスと併せて、組織や役割、業務機能階層のモデルも必要になります。実組織ではなく、抽象化したモデル組織を定義し、それぞれの業務プロセスとのマッピングを行う手法がBPR手法の中でも紹介されています。これらに関しては、また機会を改めてご紹介したいと思います。

■データモデリング手法

　情報システムの構築では、機能をベースにした設計手法に限界が訪れ、データそのものを中心に据えた設計手法が提唱されるようになりました。これは、データ・オリエンテッド・アプローチ（DOA）と呼ばれ、現在、多くの企業において採用されているシステム構築方法論です。DOAにおいては、「One fact in one place」を目指しており、データこそが普遍である、というポリシーを持っています。よって、業務も情報システムもデータを中心に設計を行うため、データのモデル化は必須です。

　データモデルに関しては、ERモデル（エンティティ・リレーションシップ・モデル）が有名ですが、このモデルは、1976年にPeter Chainによって提案され、1990年代初頭に、NISTによってIDEF1およびIDEF1xとして規格化されました。また、同時期に、James MartinのInformation Engineering（IE）方法論において、データモデリング技法にERモデルが採用され非常に普及したため、ERモデルには現在でも、IDEF1xとIEの2方式が混在している状況です。

　ERモデルは、「世の中に存在するあらゆるものは、実体（Entity）と関連（Relationship）という2つの概念で表現できる」という簡潔で強力な考え方を持っており、非常に直感的で分かりやすいERダイヤグラムによるモデルの表現方法を持っていたことと、爆発的に普及したリレーショナル・データベースと親和性が高かったことが、現在のデータモデルといえばERモデル、という状態にまで普及を促進させたと考えられます。

　DOAによるER図を利用したシステム構築に関しては、後ほど詳細を解説します。

■オブジェクトモデリング手法

　近年のオブジェクト指向プログラミング言語の台頭とともに、普及しつつある手法です。データモデリング手法では、データそのものの汎用化は可能でしたが、ビジネスプロセスの実装の汎用化がしづらく、また、プロセスがデータに依存するため、データストラクチャの変更が情報システムの非常に多くの範囲に影響を及ぼすため、情報システムの規模が拡大した現在においては限界が見え始めました。

　オブジェクトモデリングでは、現実の社会における物体の特性とその物体にかかわるプロセスを「オブジェクト」として定義し、オブジェクトの特性や業務プロセスの変更の影響範囲を限定することで、複雑で規模の大きなシステムに対する設計や運用の容易性を提供し、DOAの限界を超えることにチャレンジします。

オブジェクトモデリングは、1980年代後半より、数多くの手法が生み出されてきました。中でも代表的だった3人の賢者が1995年にRational Software社に加わったことにより、現在主流となっている統一モデル言語「UML」と統一プロセス「RUP」が生み出されることになりました。

　現在の情報システム構築手法のトレンドとしては、OOA（オブジェクト・オリエンテッド・アプローチ）とDOAは一長一短があり、協調して進展を遂げていくだろうと一般には考えられています。異論はあるかと思いますが、分かりやすさを目指したOOAは、現実の世界からのイメージはしやすいのですが、実際のシステムアーキテクチャとのギャップが大きくなりすぎたため、逆に学術的で取り付きにくい方法論になってしまっています。表計算ソフトがパーソナルコンピュータの火付け役になったのも、RDBがオープンシステムの火付け役になったのも、直感的に効用が分かる、という大きな特徴があったからだと思います。よって、私は、情報システムアーキテクチャが、現在の逐次命令処理型からバイオやニューラル型に移行しない限りは、OOAとDOAは協調して発展していくと思いますし、OOAの入門としてDOAが位置付けられないかとも考えています。

DOAによるモデル作成のステップ

　非常に抽象的な話ばかりになってしまいましたので、DOA手法を例に取って、データモデルを中心としたシステム構築を行う方法を解説したいと思います。今回は、DOA手法でのシステム構築の主なステップと、使用するモデルの記述方法を中心に解説し、次回から数回に分けて実例に基づいたシステム構築を解説していきたいと思います。

　DOA手法でデータモデルを作成するためには、大きく分けて「トップダウン」方式と「ボトムアップ」方式があります。まず、この2種類をご説明しましょう。

　トップダウン方式（トップダウン・アプローチ）：業務分析などのハイレベルな分析を実施し、そこからデータ項目を抽出して、その構造を定義していく手法です。情報システムの構築ステップが進むごとに、その定義を詳細化していきます。現在の情報システムや業務プロセスはいったんご破算にし、スクラップ＆ビルドで情報システムを構築する際に特に有効な手法です。

　ボトムアップ方式（ボトムアップ・アプローチ）：現在利用されている伝票や帳票、帳簿、情報システムなどからデータ項目を抽出し、その構造を分析していく手法です。現在複数ある情報システムを統合し、データ項目に重複がない新規情報システムを構築する際に、有効な手法です。

　トップダウン・アプローチとボトムアップ・アプローチはそれぞれ長所短所があり、実際の構築現場ではこの2つのアプローチをうまく使い分けることになります。例えば、新規システムの構築を行う場合は、大きく2つの目的が存在すると考えられます。1つ目は、現在の部門ごとに分散している情報システムを1つの情報システムに統合すること、もう1つは、今後提供予定の新サービスへの対応です。既存システムの統合にはボトムアップは有効ですが、新サービスへの対応に関しては、現在の帳票も情報システムも存在しないので、ボトムアップでは設計できません。このため、新サービスに関してはトップダウンで実装する必要があります。情報システム構築の現場では、上流フェイズではトップダウンでモデル化を進め、モデルの詳細化をしていく段階で、ボトムアップで分析された詳細情報を当てはめていくことが多いと思います。
　
　ここでは、トップダウン・アプローチで情報システム構築ステップを見ていきましょう。トップダウン・アプローチでは、主に次のようなステップで構築が進められます。

1. プロセス分析
   
   　情報システムの対象領域を明確にするために、業務プロセスを分析します。同時に、組織や役割のモデル化、業務機能のモデル化が必要になることもありますが、今回はプロセス分析を主に取り上げます。
   
   
2. エンティティの抽出
   
   　情報システムの対象領域の分析から、情報システムが管理すべき項目を抽出します。データモデルの世界では、この情報システムが管理すべき項目をエンティティと呼びます。エンティティは、リレーショナル・データベースのテーブルに相当します。今回はプロセス分析の結果から、エンティティを抽出します。
   
   
3. エンティティの関連付け
   
   　抽出されたエンティティの定義を明確にするために、エンティティ同士の関連を明らかにします。エンティティの定義を明確にする手法としては、このほかに、エンティティそのものの定義を構造化言語で記述したデータディクショナリ手法などがあります。今回は、エンティティの関連を定義するために、ER図を作成します。
   
   
4. アトリビュートの抽出
   
   　エンティティによって管理すべき情報項目を抽出します。リレーショナル・データベースのカラムに相当します。
   
   
5. データ生成タイミングの定義
   
   　ERモデルは、情報の静的な定義しか表すことができないため、いつどのようなタイミングでデータが生成されるのかを明確にするためには、別のモデリング手法が必要になります。今回は、データの生成・参照・更新・削除のタイミングを規定するCRUD技法を利用します。
   

<<プロセス分析>>

　ハイレベルの業務プロセス分析です。ここでは、IDEF0を用いることもできますし、いきなりDFDの作成に取り掛かることもできます。情報システム構築の現場は、IDEF0とDFDのどちらかを利用することが多いのではないでしょうか。IDEF0は情報システム化を前提とはせずに業務プロセス分析を汎用化している点、規格化がされている点が特徴です。一方DFDは、システム構築における構造化分析の中で提唱がされた背景を持つ、情報システム化を前提とした業務プロセス分析手法です。よって、最上流はIDEF0で業務プロセス分析を実施した後、データモデリングの一環としてDFDが利用される、というのがフルスペックのモデリングということになります。情報システムの規模に応じて、どのようなステップでどのような手法を適用していくかを、プロジェクト計画の段階で取り決めることが重要です。

　今回は、IDEF0とDFDの両方をご紹介します。

【IDEF0】

　IDEF0では、業務プロセスをアクティビティという単位に分割し、それぞれのインプットとアウトプット、およびコントロールとメカニズムで特徴づけします。図の描き方は次のとおりです。

図1 IDEF0によるプロセス分析

　アクティビティは、インプットの情報を基に、メカニズムによって処理を行い、アウトプットを生成します。メカニズムの処理を行う際の条件が、コントロールです。それぞれ、四角の記号で描かれたアクティビティの上下左右に矢印が描かれていますが、この上下左右のどこに描かれている情報かで、インプット、アウトプット、コントロール、メカニズムを区別します。例えば、「見積もり」というアクティビティは、下記のとおり表現できます。

図2 「見積もり」のアクティビティ

　見積もりというアクティビティは、見積もり構成（提案書）を基に積算され、見積書を生成します。このアクティビティを実行するのはリセラーであり、得意先に応じた割引率やリセラー自身の仕切り率を勘案して、見積もり金額が計算され、見積書となります。

　ここで、インプットとコントロールの見分け方は次のとおりです。

インプット	アクティビティによって「変化」が加えられ、アウトプットを導き出す情報
コントロール	アクティビティが処理をするときに参照する情報

　見積もり処理のフローチャートを描いたときに、いくつかの条件分岐が出てくることを想像し、その分岐の条件式に入っている項目がコントロールと考えると分かりやすいでしょう。

　また、メカニズムは「機能」と訳せますが、アクティビティを実施する組織や役割、人などが対象となります。

【DFD】

　では同様に、これをDFDとして記述するとどのようになるでしょうか。図の描き方は次の図のとおりです。

図3 DFDでの記述

　DFDは、処理を行うアクティビティを丸で囲んで、データの流れを表すデータフローを矢印で表現します。また、情報システムにデータが格納されるファイル名（図4の「リセラー仕切り」のように）にはアンダーラインを引きます。また、それらの情報の源泉となる情報源を、四角で囲んで示します。例えば、先ほどのIDEF0の例は、DFDでは次のように記述できます（DFDの使用方法を明確にするために、一部先ほどの例から拡張しています）。

図4 IDEF0の例をDFDで記述

　DFDでは、アクティビティに出入りする矢印の位置に、特に意味はありません。また、IDEF0のように、コントロールやメカニズムを明確に定義する方法もありませんので、このようなアクティビティの詳細仕様は、アクティビティごとにミニ仕様書を書くことで解決する方法を取ります。

　ミニ仕様書は、データを処理するロジックを明確にします。これを表現する手段として、構造化言語やデシジョンツリー、デシジョンマトリックスなどを利用します。

<<エンティティの洗い出し>>

　さて、プロセスの分析ができたら、今度はデータ構造の定義に移ります。このために、まず、エンティティの洗い出しを実施します。

　エンティティとは、情報項目のことです。例えば、上記の例では、IDEF0のインプットやアウトプット、もしくはコントロールやメカニズムに現れる「名詞」は、すべて候補となります。実際に上記の例から洗い出してみましょう。

• 見積書
  
• 見積もり仕様
  
• 顧客値引き
  
• リセラー仕切り
  
• 顧客
  
• リセラー
  

　何をエンティティとして洗い出すべきかは、まさに経験によるところが大きいですが、エンティティに成り得るカテゴリとしては、下記のような項目が挙げられますので、参考にしてください。

人	社員、役員、取引先、得意先、調達先
物	商品、製品、部品、設備（生産ライン、トラックなど）
場所	国、県、地域
出来事	受注、発注、売上、契約
組織	事業本部、本部、部、課、支店
概念	勘定科目、受注計画、売上計画、予算

<<エンティティの関連付け>>

　前のステップの1つ1つのエンティティは、単なる情報項目の候補でしかありません。これらのエンティティ1つ1つに対しての「定義づけ」が必要になります。エンティティの定義をするにも、数々の方法がありますが、ここではまず、エンティティ間の関連を明らかにするために、ER図を描いてみましょう。

図5 エンティティ間の関連を明らかにするためにER図を描く

　ER図は、エンティティ間の関連を「リレーションシップ」によって表します。エンティティのボックス間を結んでいる線が、リレーションシップです。エンティティ間の関連にも、いくつかの種類があります。リレーションシップの線の両端の形状で、リレーションシップの種類を表します。次に、リレーションシップの代表的な例を挙げておきます。

図6 リレーションシップの代表的な例

◆

　今回は、ER図作成までのステップを図の解説を中心にしてきました。次回から数回に分けて、実例に基づいたモデリングのステップを追うことで、さらにモデリングのキモに近づきたいと考えています。

IT Architect 連載記事一覧