» 【第52号】統合化戦略

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第52号】統合化戦略

DRI通信52号「統合化戦略」2001.1.1
いよいよ21世紀になりました。数字の魔術でしょうか、これからの1年あ
るいは10年というより、100年、1000年をどう生きていくべきか考
えさせられます。人口、環境、エネルギー、教育、赤字国債、問題は山積しま
すが、どこまでも流通範囲の広げられる高品質のデータについても考えたいも
のです。
先月は「因数分解の発想」として正規化やシステムのアーキテクチャに関する
考察をしましたが、TISの堀越さんからは「『共有と固有の分割』としてシス
テム構造、データ構造、組織構造など『全てのものの構造』を考えるときに適
用しています。」とのコメントをいただきました。
爬虫類と哺乳類は動物としてのアーキテクチャが違うものかと思われます。猿
と人間の違いもアーキテクチャの違いなのでしょう。システムやITのライフ
も修正・改善では対応できない限界がそのアーキテクチャによって決まってく
るように思われます。これは優れたアーキテクトの抽象的なひらめきに依存す
るもの、「因数分解の発想」はそのような局面で活用されるべきかと思われました。
さて今月は「統合化戦略」について考えます。拙著で恐縮ですが、「データ
中心システム入門」でDOA第2の原理として “One fact to all users” を挙
げました。エントロピー増大の熱力学の第2法則を念頭に、情報世界の自然
の方向を示したかったわけですが、情報流通は、部門内から、企業全体に、さ
らにSCM、CRMと企業の壁を越えての要求が、ますます明らかになってま
いりました。部分最適化は全体最適化に勝てない。全体最適化のために、デー
タの流通/統合が必要とされているわけです。


データの流通のためには、最低限何が必要なのでしょうか。かつては「同じ
メーカーの同じOS、同じDBMSのもとに作るべき」と言った錯覚があった
ようですが、今ではメインフレームのDB2、UNIXのORACLE、NT
のSQLサーバー間のデータ流通に支障があると考える人は例外的でしょう。
結局データの意味、セマンティクスが同じならデータは流通します。ここま
では大方の賛同が得られるかと思いますが、「セマンティクスが同じとは」
の条件については、いろいろな認識があるかに見えます。一番素朴なのは画
面帳票上のデータ項目名が同じなら同じセマンティクスだとするものです。
タグ名を統一すればよいと言った楽観的XML信奉者もこれとあまり変わら
ないように思われます。
自然言語の世界でのアナロジーを考えてみます。「手」と言う言葉は多くの
場合「HAND」と対応できるでしょう。しかし「METHOD」を意味す
る場合があります。また「やり手」というときは「PERSON」の意味に
なります。このように文化が違うと語と意味の対応に違いが発生します。部
門や会社によるデータ項目名と意味の対応の違いも、同じ現象と考えられます。
われわれは原則として、同じエンティティタイプ(顧客、受注など)で同じ
役割(・・が、とか・・をなど、ROLEともいう)をもつデータ項目(厳
密にはATTRIBUTE/属性)は同じセマンティクスだと考えます(た
だし、ここでサブタイプがあればサブタイプごとに考えます)。たとえば
「受注品番」と呼んでも「受注商品コード」と呼んでも「PARTS−NO」
と呼んでも、「受注」の中の「・・を」を示すものとして同じセマンティクス
と考えます。
データタイプや桁数が同じであることは望ましいとは考えますが、1対1の
変換が可能な限りデータ流通上は問題ないと考えます。もちろん物理/論理
レコード上の位置や順序は関係ありません。要するに実装独立のビジネス世
界でのデータの仕様が同じか違うかだけを問題にするわけです。これが同じ
なら「データは流通できる」し、「システムは統合できる」のです。
B2Bにおいて流通するのは主に発注や請求などのイベントデータですが、
そこに含まれる主要なデータは、いつ、誰が、誰に、何を、どれだけと言っ
たデータです。そして誰が、誰に、何を、を表すコードデータ(THモデル
ではリソース系のデータのKEYという)が、部門により、会社により、業
界により、また国によりまちまちな仕様になっているのが、データ流通を妨
げる最大の原因になっています。
たとえば品番と言っても、ある会社では設計図面と対応させ、荷姿を含めな
い。別の会社では荷姿を含め、範囲も事務用品やサービス、特許まで品番と
して扱うなどであると、簡単にデータを接続することができません。同じ仕
様になっている部分をつきとめて接続することになります。データを扱うと
きの最も厄介な作業となりますが、避けて通ることができません。
そしてその仕様は、システム担当者の頭の中にあって、文書や電子化された
データとして形式知化されていない場合が多々あります。これは本来メタデ
ータとして、リポジトリに登録すべきものであり、DOA先進的企業では整
備されつつありますが、無政府状態の企業もまだ少なくありません。健全な
リポジトリにデータ項目定義があるならば、これを比較することによって、
流通可能なデータか否かの判定が容易に進められます。
こうしてデータが流通し、整合性の保証される範囲が、システムの範囲を
決めると考えられます。ポイントはやはり「誰が、誰に、何を」を規定す
る社内外組織と品物のコードデータの、論理的仕様の標準化です。標準化
の範囲はできるだけ広げたいわけですが、限界がありますから、場合(厳
密にはサブタイプという)ごとの変換テーブルを用意して接続を図ること
になります。
このような統合化/データ流通範囲の拡大の作業は、部門システムの統合、
レガシーシステムとERPの接続、企業合併でのシステム統合、B2Bでの
データ流通において必須となります。基礎はデータのセマンティクスを捉え
ることですが、そのスキルを磨くには、手前味噌となりますが、やはり画
面・帳票をTHモデルをもとに分析するボトムアップの作業が最も有効の
ように思われます。