» 【第84号】DOA第2ラウンド

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

DRI通信84号「DOA第2ラウンド」       2003.9.1
東京電力には良かったのでしょうが、大変涼しい夏でした。結局、海水浴はせず、ジョギングやサイクリングで体力維持を図ることになりましたが、皆様はいかがでしたか。
8月26日(火)第13回K2W勉強会は、「企業情報システムの役割、これまでと今後」というテーマで、8名の講師、45名の参加をいただき、やや発散気味の感もありましたが、熱心な討議が行われました。「業務システムは各部門の責任で開発・運用すべし」「システム部門は人的を含めたインフラ整備により全体最適をはかり、事業競争力のある先進的IT企業を実現すべき」などが指摘されました。
■DOA第1ラウンド
東京国際大学の堀内一先生(当時日立製作所)の命名されたDOA(Data Oriented Approach)が日経コンピュータ誌上で紹介されたのが1985年、その年の10月に弊社DRIは創立しました。ほぼ18年前になります。80年代は結構受けて、大企業の情報システム部門に対し、DOAによるシステム開発方法論「PLAN−DB」の教育・コンサルテーションを行うことができました。開発/再構築の手ごろなアプリケーションを選んで、3ヶ月くらいで概念DBを設計し、その中で人を養成します。従来のPOA(Process Oriented Approach)を脱し、DOA的考え方を身につけるには、どうしても3ヶ月くらいは必要でした。


この考えで基幹系のいくつかのアプリケーションを整理すると、全社で共用できるリソースDB(マスターDB)ができてきます。人が育ってくれば、はじめ3ヶ月かかっても次第に短期間で、しかも自社だけでできるようになります。まだメインフレーム時代で、情報システム部門も力をもっており、1人1台のパソコン時代以前に、標準の開発方法論・フォーマット・コンテンツが用意でき、つづく分散化時代もこれを活用し、大きな混乱もなく今日を迎えておられる会社が多々あります。データの流通に問題が発生しないため、ERP導入の理由が見当たらず、入れるとしても会計だけといった、アプリケーション機能の利用を目的としたものになっているケースがほとんどです。
■DOA潜伏時代
バブルのはじけた90年代は、C/Sの分散コンピューティング時代で、DOAは潜伏を強いられた時代といえます。ハードが安くなり、ベンダーと組んでユーザ部門主導で情報化することが可能になり、ばらばらシステムが乱立し、ITガバナンスは低下しました。ERPの登場、Y2K、Web化と課題は登場しますが、解決の主役はDOAではありません。DBはベースとしてはあるわけですが、パッケージとして用意されていたり、レガシーを手直しする程度で間に合わせることができました。こうしてデータモデル図を読む技術が伝承されず、人が途切れてしまいました。しかもリストラ、アウトソーシングなどが進行し、情報システム部門の人数が減り、システムの企画・調達部門に変質したケースもすくなくありません。
一方、GUIの発達やSmalltalkなどオブジェクト指向言語・プログラミングの発達から、オブジェクト指向(OO)技術が進歩し、MDA(Model Driven Approach)が指向され、これを分析・設計、すなわち上流工程に展開しようという動きが生まれました。そのためにフレームワークが必要と、J2EE、.NETなどが話題となっていますが、大規模業務アプリでの成功事例はまだ発表されていないようです。
■DOA再登場
Y2Kが終わって、中国が台頭し、企業競争が国際化したからでしょうか、B2B、SCM、連結会計などデータ流通が企業内にとどまらず、企業、国境を超えて要求される時代となってきました。データが流通するには、データの形式と意味が一致しなければなりません。そしてn個のシステム間の流通がスパゲッティ化しないためには、Hub & Spoke型の(概念)データベースによるコミュニケーションの場(DB通信場)を用意しなければなりません。ただし、このDB通信場は、バーチャルなものですから、物理的にひとつのものである必要はありません。
元となる個々のデータベースは、販売、購買、生産、人事、会計など業務が違うばかりでなく、事業部、企業、国すら違うわけですから、ヘテロな環境にあるシステム/データベース間の情報流通が課題です。新規自作を一挙に進めることはできませんから、レガシーやパッケージも対象としなければなりません。情報は、引合い・見積・発注・出荷・請求・入金など、ハイレベルのトランザクション/メッセージの形式をとります。そこには、顧客#・組織#・品#など、コードや番号が含まれますが、その形式や意味は、各アプリごとに独自に設定されたものですから、情報流通のためには、調整が必要になります。そのコードや番号としてはシステム間をまたがるハイレベルメッセージに含まれるものがまず対象となります。
すなわち新規自作・パッケージ・レガシーシステムに含まれる
    ・ハイレベルメッセージの形式と意味
    ・ハイレベルコード/番号の形式と意味
の調整・標準化が今回のDOAの課題となります。したがってパッケージやレガシーを生かす場合は、これからハイレベルメッセージを抽出し、これを素材にデータモデリングを行うことになります。しかし、かつての画面・帳票から行った個別システムレベルのデータモデリング技術が、健全なものである限り、そのまま応用できます。そして調整後のメッセージと調整前のメッセージの変換機構を用意することになります。パッケージやレガシーシステムはカプセル化して見ますので、オブジェクト指向的あるいはSOA(Service Oriented Architecture)的扱いといえるでしょう。こうして使える既存資産はフル活用しますが、これはIBMの言うオンデマンドを実現する方向とも言えるでしょう。
■新規自作には従来のDOA
また新規自作の場合は、従来の個別システムレベルのデータモデリングを行うのが自然なやり方になるはずです。この中のハイレベルメッセージは変換機構なしで、そのままアプリケーション間を流通させることができます。実装がWebだ、Javaだといっても、RDBを使うとなれば、実装独立の世界で確立された画面・帳票ベースのデータモデリング手法が有効です。敢えてReinvent the Wheelを行い、OO独自の手法を用いる理由は希薄だと考えます。OOはやはりプロセス中心に考えますから、リソースデータ、DWH、メタデータなどプロセスをまたがるデータインフラを位置づけにくく、孤島システム指向になり勝ちです。DOA手法によって、これを未然に避けるのは賢いやり方と言えるでしょう。
画面・帳票ベースのデータモデリング手法は、ボトムアップなので、相互に矛盾する仕様を調整しながら、標準化する作業が含まれます。このためこの手法を繰り返し適用すると、データ標準化のスキルが自然に身についてきます。業務分野や企業をまたがるハイレベルメッセージを素材とするデータモデリングにおいては、データ仕様の矛盾はより大きくなり勝ちですが、それまでのボトムアップ手法でのスキルが、そのまま活用できます。ボトムアップ手法は、現行にとらわれるとして嫌う人がいますが、業務データの骨格は、商売変えでもしないかぎり、BPRくらいで変わるものではありません。
私は、トップダウン手法は、データモデリングより、プロセスモデリング、それもTo-Beのプロセスモデリングに適した方法ではないかと考えています。われわれは500件以上のデータモデリングの経験がありますので、ある程度のトップダウンデータモデリングも可能ですが、精度には限界を感じています。個々の業務の強みが、使い込まれた画面・帳票の中に埋め込まれており、これをトップダウンに発見するのは容易ではないと感ずることがあるからです。
私は、大まかに次のような対応から、システムアプリケーションにはOOが、一方業務アプリケーションにはDOAが主役とならざるを得ないと考えます。
担当  ベンダー       ユーザ企業
アプリ システムアプリ    業務アプリ
成果物 ツール/プログラム  コンテンツ/データ
手法  トップダウン/OO  ボトムアップ/DOA
一見「この対応はおかしい」と思われる方があるかもしれません。ベンダーが業務アプリやERPを提供しているからです。しかし、それはこれらが未完成品であることを考えると納得できるのではないかと思います。ERPとして提供されるのは、プログラムだけで、核となるコンテンツ、すなわちその企業でデータを指定するときに用いる用語、リソースデータ(マスターデータ)は空のまま提供されていて、そのまま使えるものではありません。ERPを入れたが、使えるリソースデータがない。そこでこれを作るために1年以上かけた、こんな会社は珍しくありません。「業務アプリ=プログラム+リソースデータ」です。リソースデータはDOAによる標準化を通じてユーザが作るものです。DOA再登場はこの要請から起動されたもののように思われます。
その意味ではDOA第1ラウンドに、全社リソースDBを構築した企業は、すでに実質第2ラウンドをも先取り実行してしまっていたと言えるようです。逆にDOA第1ラウンドに取り組んだが、アプリケーションごとに取り組んだため、アプリケーションの「偏見」を持ったリソースデータをベースに、孤島システムを作って終わった企業が多々あるわけですが、今度こそ健全な方法論によって、再度DOAに取り組まなければならないでしょう。
■データ管理はユーザの責任で
ベンダーは、コンテンツはユーザ責任として、ツールを作り売り込みをかけてきます。最近では、Webサービスが話題になっています。ヘテロな環境同士が簡便につながるというわけですが、データを抑えていないと、結局スパゲッティ通信になる危険性があります。Webサービスも、アプリケーション間のハイレベルメッセージの通信の、ひとつの物理的手段としてとらえ、通信すべきデータについてはデータとして管理する必要があるでしょう。
DOAも最初のものは、プログラム間をバケツリレー的に、ファイル経由でつなぐものを進化させ、論理DBを設計しこの上で個別アプリを動かそうというものでしたが、今回のものは、ヘテロなアプリケーションをまたがって、HUB通信場経由、柔軟なコミュニケーションを実現しようと言うものです。リポジトリ、リソースDB、オペレーショナルDW(Data Warehouse)/リアルタイムDWと言ったデータインフラをベースとするものになっていますので、データインフラとこれを活用できる人が、ユーザ企業の宝です。ソフトウエアはアウトソースしてもよいでしょう。しかしこの宝は、是非各企業で育て充実させていっていただきたいと思うものです。