» 【132号】データモデリングの課題−その1

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【132号】データモデリングの課題−その1

■ビジネス系システムの課題
私は、今日のビジネス系システムの4大課題は
・過不足のない要件定義 ・保守工数削減
・全体最適 ・迅速対応
であると考えています。

その実現手段としては、(1)新規開発/再構築(MAKE)、(2)パッケージ/
SaaS活用(BUY)、(3)レガシー活用、があると考えられます。OO(オブジェクト
指向)は、アプリケーション横断のデータ流通問題への取り組みが遅れており、
また実装独立モデルというより実装部品の再利用に重点があるなど、まだ焦点
は(1)の下流のソリューションの段階ですから、上流にかかわるDOAの果たすべ
き役割がきわめて大きいと考えます。
■DOAの役割
DOAはデータモデリングをベースに、
・IOおよびこれを構成するデータ項目を確定する
・データモデル図によりデータ項目を可視化・共有する
・データ項目間の整合性を確保し、円滑なデータの流通を実現する
・データ項目の積み上げにより独立性の高い各種粒度の部品−エンティ
ティタイプ、データベースタイプ、IO、業務プロセス、システムなど−を
定義するを実現すべきもの、すなわちデータ設計・管理およびシステム
アーキテクチャ構築を担当するものと考えます。
DOAの方法論は種々提案されていますが、その動機・目的などによってその
成果物形式や手順が異なります。ChenのERモデルの提案、リレーショナ
ルDBMSの実用化、ERWinなどのツールの登場が、欧米/欧米系の方法
論に大きな影響を与えました。方法論は種々の問題に適用しながら修正改善さ
れてきたわけですが、適用が得意領域に偏ること、また使用者の慣れによって
独自の進化をしてきたもののように見えます。したがって、上記の課題につい
て解決不十分のものも多々残されています。
■個別アプリケーションへの適用が主
DOA方法論も30−20年の歴史をもつわけですが、最大の問題は、ほとん
どが個別アプリケーションへの適用であって、これらを横断した全社アプリケー
ション(A2A:Application to Application)問題への取り組みが極めて少
ないことです。これまでは目先のDBシステムをいかに作るかが課題であり、
これらをいかに連携するかまでは考えていられなかったからかと思われます。
いや「これまでは個別アプリケーションしか課題でなかった。アプリケーショ
ン横断の課題でも同様に解決できるはず」といった楽観論があったのかもしれ
ません。
データモデリングとはデータの標準化による通信場の設計作業ですが、個別
アプリケーションならば、範囲が狭いため、
・経験者は過去の経験をトップダウンに適用できる
・同質の文化−使用するデータ/用語やその意味−を持ったメンバーによる
同質の文化の中のデータ標準化作業であり、調整は比較的やさしく、成果物
における個人差が許容される
・整合性チェックの範囲が狭い
・実装環境が同一なので実装独立の要求が厳しくない
などにより、若干の方法論の不備は障害にならず、その修正改善が遅れました。
■リソース統合が遅れた
今になって欧米で、MDM(Master Data Management)やCDI(Customer
Data Integration)が課題として大きく取り上げられています。これは取引先
や製品/部品など、われわれの言うリソースデータ統合を行おうというもので
すが、これまでは個別アプリケーションの開発しかやってこなかったことの証
左といえます。「孤島システムによる部分最適化では戦えない、ERP、SC
M、CRM、BPM、SOAが必要」となってきたわけですが、そのいずれに
おいてもアプリケーション横断のデータ連携が必要になってきます。しかし多
くの従来のDOA方法論は、リソース統合をはじめ、このための配慮を十分提
供してこなかったわけです。
受注、出荷、請求などのビジネスにおける出来事の記録をわれわれはイベント
データと呼びますが、この中で、顧客、届先、商品などを記述するために使わ
れるのが、リソースデータです。イベントデータを文章とすれば、リソースデー
タはこれを記述するための用語と言うことになります。イベントとリソースは
まったく性質を異にするデータですが、RDBでテーブルとして同様に実装さ
れるからでしょうか、この差を峻別させない方法論が大部分です。この用語相
当のリソースデータは、広辞苑相当のデータインフラとして位置づけられる、
全社データ流通のための最も重要な要です。このためには、リソースデータを
個別アプリケーションから分離し、全社レベルで一元管理しなければならない
はずです。
このリソースとイベントの分離を指導しない方法論が、いま話題の孤島システ
ムの乱立を招いたと思われます。この方法論の不備は個別アプリケーション開
発においては顕在化しませんでした。A2Aのデータ流通が必要になって、顕
在化し騒がれているわけです。
■アプリケーション横断のDOA
A2Aにおいては、生産、販売、経理、人事など多岐にわたるアプリケーショ
ンを対象にしなければなりません。生産といっても家電と重電など商品によっ
て文化が違います。販売も商品の違いや国によって文化が違います。一般に、
文化に対応してDB、したがってアプリケーションが作られます。
特定の個別アプリケーションに通じていても、横断的にすべてに通じている人
は例外的です。このためA2A通信場を、個別アプリケーションのときのよう
にトップダウンに設計できる人はほとんどいません。モノリシックな従来法で
無理にトライすれば、これらを連結した低品質の思い込みモデルを造る結果に
なります。やはり画面・帳票をベースにしたユーザニーズ主導の着実な方法論
を基本とせざるを得ないと考えます。
また最近はSVOT(Single Version Of Truth)−出所が違っても同じデー
タは同じ値を持つべき−の要求を耳にすることが多くなって来ました。これは
個別アプリケーションだけ扱っている時は出るはずもありません。アプリケー
ション間でデータの定義が違っていることから発生します。従来の個別アプリ
ケーション対応のDOA方法論あるいはその適用技術の未熟に起因するものと
いえます。
一方、ITの進化は多くの人の予想を超えるものでした。このため開発タイミ
ングが異なれば、そのIT環境は変わってきます。開発の方法には、先に述べ
た(1)新規開発/再構築、(2)パッケージ/SaaS活用、(3)レガシー活用が
ありますが、既存システムとのデータ流通は不可欠です。またM&Aなど大き
なビジネス変化も頻発します。このためA2A通信場の実装独立への要求は、
個別アプリケーションの場合を超えた厳しいものとなります。
したがって、DOA方法論もそれなりに解決して来た個別アプリケーションへ
の適用と、これまで未着手だったアプリケーション横断への適用とは分けて考
えるべきと思われます。個別アプリケーションにはパッケージやSaaSの解
決もあります。レガシーの改造ならばベテランが手馴れた従来方法で解決した
方が良いということもあるでしょう。しかしアプリケーション横断への−いわ
ばハイレベルデータハブを前提とする−DOAは異質の文化を繋ぐための、実
装独立でユーザニーズ主導かつデータインフラを意識したものでなければなら
ないと考えます。
ただしこのアプリケーション横断のハイレベルデータは、個別アプリケーショ
ンのデータに比べ数が少なく、かつ初めにしっかり設計してあれば、技術やビ
ジネス変化の影響を受けることが少なく、またこれによって個別アプリケーシ
ョンの独立性が確保されるので、以後の保守は非常に合理化されるものと期待
されます。
■記法の統一を超えて
OOはUMLによって記法を統一したので、DOAもこれにならって記法を統
一すべきという声を聞きます。これもひとつの課題ですが、個別アプリケーシ
ョンに対してはすでに方法論を身に付けた人々が大勢いて、問題解決が行われ、
資産もたくさん残されています。したがって、表面的な記法の統一は混乱を招
くだけで得策でなく、むしろアプリケーション横断のDOA方法論の確立を優
先すべきと考えます。またUMLの統一もアイコンの統一の段階であり、多種
類の成果物にはメタデータの重複もあり、人によって使う使わないや、同じア
プリケーションの表現にも個人差が出て、種々提案はあるものの、設計方法論
としては未完成な段階といえます。したがってDOA方法論は、UMLが実装
をカバーしている特長を活かすべく、これとの連携を図りながら、完成を目指
していくのが今後の方向と思われますが、いかがでしょうか。