» 【第105号】孤島システム対策

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第105号】孤島システム対策

DRI通信105号「孤島システム対策」        2005.6.1
大型のゴールデンウイークも終わり、本年度も軌道に乗ってきた頃かと思
われます。全般に「景気は良い」とのことですが、皆様のところはいかがで
しょうか。5月30日のDOA+コンソーシアム第1分科会は、データモデル
の標準化に関して3件すなわち、堀内先生から「メタデータとメタモデルの
動向−IRDSからMMFIまで」、大林さん(管理工学研究所)から「MOFに
関する2件」、岡部さん(東京電力)から「Metamodel for Ontology Registration」
のプレゼンがありました。内容に比し時間が足りなかったので、質疑は次回
6月27日(月)に行うことになりました。
■ 孤島システムとは
英語ではSilo Systemといわれますが、他システムとのデータの流通がう
まく行かないため、システムが孤立してしまう孤島システム問題は、1990
年代半ば頃から盛んに論ぜられるようになりました。ユーザの要求を汲み
取って、QCD(Quality, Cost, Delivery)の満たされたシステムが出来上が
っても、その後で他システムとのデータのやり取りを行うために、変換など
を含むインターフェースを用意する必要があるというのでは困る。このような
システムがひとつ二つなら対応できるとしても、これが10,20となってくると、
保守コスト、信頼性など、行き詰まり状態となってきます。


ユーザ部門が、そのニーズに基づいて要件定義を行い、これをSIerに発注
するというだけでは、この孤島問題を発生しやすく、1990年代のC/Sによ
るダウンサイジング化とともに話題となっていったことが分かります。始めに
これを問題視し、「システム間に活断層がある。これを解消するのだ」と訴え
ていったのがERPベンダーでした。少し遅れてEAIベンダーが「レガシーを
生かしながら接続しましょう」と登場しました。確かにこれらによって解決した
部分はあるのですが、多くの場合、未解決部分を残しています。
孤島システムの問題は、A2A(Application to Application)のインターフェー
ス問題、インターフェースを構成するデータ、とくにリソースデータ(マスター
データ)の標準化問題に帰着します。ERPで解決するといってもそこで使わ
れるリソースデータを一元化することが解決となっています。EAIの場合も
リソースデータの標準化なくしては接続できません。
SIerへの発注は、通常、アプリケーション単位で行われますので、SIerとし
てはアプリケーション内の標準化はできますが、A2Aの標準化はできません。
これは発注者側が行うべきものといえます。発注者が発注前に個々のアプ
リケーションのインターフェースを確定しておけば、納品と同時に各アプリケ
ーションは円滑に接続していくはずです。
そのアプリケーションの上流工程以前にインターフェースを確定する、と言う
ことですから、多くの場合、プロジェクト発足以前になるかもしれません。
したがってEA(Enterprise Architecture)のような戦略プロジェクトで取り組む
のが、最もスムーズと言えますが、鍵はA2Aにおけるリソースデータの標準
化ですから、大き目のプロジェクトならば、上流工程を補強して対応すること
も可能であると考えます。
■ リソースデータの標準化
社員、顧客、商品を、私はビジネスのための3大リソースと言っています。さら
に、組織、設備、サプライヤー、原材料、勘定科目、その他と、これらの分類
コードがリソースデータを構成します。企業で発生する各種出来事/Factは
イベントレコード(トランザクションレコード)として、これらのリソースデータ/
Termを用いて記述されます。したがってリソースデータを収録したリソースDB
は、「システム広辞苑」という位置づけになります。これが1個のアプリケーション
内でなく、A2Aで共有されなくては困るわけです。このためにリソースデータの
標準化を行います。
この標準化は、組立加工製造業での部品の標準化とよく似ています。種々の
製品を分解すると各種部品が出てきますが、もし標準化ができていなかったと
すると、同じ部品で間に合うのに少しずつ違った部品が使われていたりするで
しょう。これを統一して部品点数を減らすことができます。この作業は分解した
部品を分類整理して統一すると言う、本質的にボトムアップの作業になります。
リソースデータの場合は、データモデリングを通じて、各種イベントレコードに
含まれる、リソースデータを整理し、統合・一元化することになります。このとき
データの形式と同時に意味を判断しなければなりませんので、イベントにおい
てこれがどのように使われているかを把握する必要があります。「データモデ
リングはRDB設計のため」とする、一般の考え方では、ToBeのトップダウン
設計が行われるわけですが、いずれもテーブル設計に変りはないとして、リソ\nースとイベントを分離独立する必要性が、あまり感じられないかと思われます。
しかしここに、「データ標準化によりデータの広域流通を図るため」が付加され
ると、「A2AにおけるAsIsのボトムアップ分析を先行させ、システム広辞苑の
ためにリソースデータを分離独立させること」の重要性がわかってくるのでは
ないかと思われます。
■ DBアーキテクチャの認識
A2Aを考えるということは、n個のアプリケーションDBとこれらが共用す
るリソースDBを想定するわけで、必然的にDBアーキテクチャを考えること
になります。生産、販売、経理、人事などを1個のDBで処理している企業は
見当たりません。これらは個別のDBとしているわけですが、事業部なども絡
み、これらをどう設定すべきか、あまり本格的な指針は見当たりません。これ
までは、持っている予算に応じてDBのスコープが決まっていたケースもある
でしょう。「DBのスコープはどうあるべきか」は、今後の課題といえますが、
「n個のDBがある。リソースはこれらに共通に1個あるべきである。メタデー
タを管理するリポジトリも存在する」などは、すでにはっきりしたことであり、
今やデータモデラーは、スコープを広げて、自ら担当するDBがどのように位
置づけられるべきかを、はっきり課題として認識すべき時代にあると考えます。
■ 意識改革のために
人は自然、与えられた課題の範囲のスコープで思考します。初めてプログラ
ム開発を担当すると、その範囲で考えますので、まずPOA(Program Oriented
Approach)となります。しかしこれではワークファイル経由のスパゲッティ・
インターフェース−DBMSありきから、システムにかかわった若い人は実態
を理解できないかもしれませんが−が発生しますので、次にDOAにより、デ
ータベースという共通の通信場を作り、そこでコミュニケーションする方式を
採用することになります。その前提としてデータ/インターフェースの標準化
が行われ、それまで暗黙知だったファイル形式などが、DDLとして形式知化・
共有化されます。
自分のProgramを中心としたPOAの見方から、DBを中心としたDOAの見方
へ転換することになりますが、これは、自分/地球を中心にした天動説から、
太陽を中心とした地動説に転換する、コペルニクス的転換のように、自分の見
方を相対化する必要があり、人によってはかなり大きなハードルになります。
朝東から出た太陽が夕方西に沈む天動説の実感はなかなか捨てがたいもの
があり、ガリレオの苦労が分かります。しかし、われわれ現代人は地動説を抵
抗なく受け入れています。「地球は丸い。自転しているから昼夜がある。季節は
公転による。月食や日食がある」など事前の教育によって刷り込まれた結果だ
と思います。
P2P(Program to Program)のスパゲッティ・コミュニケーションがDB通信場に
よって解決できたわけですから、A2Aのスパゲッティ・コミュニケーションも、自
分のアプリケーションを相対化して−DBというよりDWHの−通信場の標準化・
共有によって解決できるはずです。この通信場の標準を規定するものとして、
リソースデータとメタデータがあるわけです。太陽系の外側に銀河系を考える
ようなものでしょう。このように自分の今の課題を越えた範囲にスコープを広げ
て考えることによって、正しいアーキテクチャが理解されるものと考えます。
■ まとめ
部分・短期最適と全体・長期最適は本質的にトレードオフします。したがって、
対照的な典型的アプローチ、「RDB設計のためのトップダウン・データモデリン
グ」と「リソースデータ標準化のためのボトムアップ・データモデリング」は、その
特徴を捉えて適宜活用しなければなりません。しかし一般に成熟度の低い段階
では、部分・短期最適が求められますので、多くの孤島システムができてしまい、
次にこれを解消しようと全体・長期最適が求められることになりますが、多くの場
合手遅れになって、多大の時間とコストを損失する結果となっているように思わ
れます。
われわれはデータモデリングのコンサルティングを始めてから20年以上になり
ますが、当初から「リソースは分離独立」を前提として進めており、これを実現し
た会社からは「A2Aのデータ流通に困ったことがない。ERP導入のニーズがわ
からない」との声を聞いております。
システム間に通信場を用意するDBは、用語を共有するある文化圏を形成します
から、そこでの用語を規定するシステム広辞苑となるリソースとリポジトリは、企
業が環境変化に俊敏に対応するための必須要件として、今後ますます重要な課
題になると思われます。より広いスコープで考え、ただしいアーキテクチャを構築
していく必要が求められていると考えます。
(注)資金回転率最大化、在庫最小化などを図るためのトップダウン設計は、現状
分析により現状の可視化・問題点整理などが終わった後で行い、これを反映した
画面・帳票を反映して新規DBが作られる。したがって、経営課題を解決するため
のトップダウン設計は現状IO→現状DB、また新規IO→新規DBのデータモデリン
グの最中ではなく、その中間(データモデリング工程外)で行われるものと考えます。