川村渇真の「知性の泉」

情報資源管理:自社開発の減少で利点を生かせず


処理よりもデータの安定度が大きい点に着目

 大きな企業では、いろいろな業務にコンピュータを利用するため、情報システム全体が複雑になりがちだ。各業務のシステムは順番に作ってきたので、最初のほうに作ったシステムは、かなり古くて作り直しが求められている。ところが、どの業務も他の業務と関係があり、別な業務システムに影響を受けるので、対象システムだけを単独で作り直すことはできない。企業全体で見ると、情報システム全体が込み入ってボロボロになっている。
 このような状況は、多くの企業で発生した。その反省から、もっと違うアプローチでシステムを設計しなければならないと気付いた。いろいろな方法論が出てきた中で、注目を集めたのが「情報資源管理」だ。
 基礎となったのは、「処理内容に比べてデータ構造は安定している」との考え方だ。企業の業務形態がかなり変わったとしても、同じデータを扱うなら、データ構造自体はあまり変化しない。変化が大きいのは、業務と密接に関係ある処理内容や表示レイアウトだと気が付いた。そこで、扱うデータをきちんと分析して、データ構造を最初に規定しようとした。そのうえでデータと処理を分離し、処理だけを作り直せば済むように、システムを構築する。このようにデータを中心として設計するため、「データ中心アプローチ」と呼ぶ人もいる。
 データベースに入れるデータ定義が重要となるので、データ・ディクショナリのツールを用いて管理する。すべてのデータ項目にユニークな名前を付けて、どの処理でも決められた名前を用いる。どの処理がどのデータ項目を使っているかも、細かく管理する。まさに、情報を資源として管理する手法だ。

最初のデータ分析工程が非常に大変

 情報資源管理の考え方はかなり注目され、雑誌などでも取り上げられた。情報システム構築の危機を回避する救世主として、とくに上級システムエンジニアが大きな期待をかけた。
 しかし、実際に試すと簡単ではなかった。通常のシステム構築では、対象となる業務だけを考えればよい。データ定義に必要なデータ分析も、対象業務の範囲だけを調べれば済む。ところが、情報資源管理では、特定の業務に依存しないようにデータ構造を構築しなければならない。そうなると、そのデータを使う全部の業務がデータ分析の範囲となる。どんなデータ項目があるかによって、データ構造が変わるからだ。たとえば、従業員データを調査するなら、給与システムに必要なデータ項目だけでなく、人材活用システムなどで使われるデータ項目も含まれる。商品データなら、かなりの業務に関係する。これでは大変だ。
 仕方がないので、データ構造に依存しない構築方法を採用する。データへアクセスする部分だけの処理を用意し、それを経由したアクセスしか許さない。データを利用する業務システムから見て、データ構造を隠蔽してしまうわけだ。この方法なら、データ構造が少しぐらい変わっても、アクセス部分の処理と一緒に更新することで、変更の影響は最小限に抑えられる。
 どんな形で構築するにしても、情報資源管理でもっとも重要なのは、業務で扱うデータをきちんと分析することである。システム化の対象業務を深く理解し、データ構造を整理できるシステムアナリストが必要だ。システムの開発やメンテナンスなど、ある程度の経験が求められるだけに、残念ながら、できる人は多くない。

オブジェクト指向技術を取り入れて発展

 情報資源管理の実現に苦労している間に、オブジェクト指向の波がやってきた。実際に使える開発ツールも増えて、ようやく実用期に入った。
 オブジェクト指向の特徴の1つは、データと処理のカプセル化である。情報資源管理はデータ中心の設計術だが、前述のように、アクセス部分の処理はデータ側に持たせたほうが構造はスッキリする。つまり、オブジェクト指向と相性が良いわけだ。さらに、オブジェクト指向の継承を利用することで、様々なアクセス処理を簡単に追加できる。
 ただし、実現するためには、RDBMSのような既存のツールではほとんど不可能で、新しいツールが必要となる。オブジェクト指向に対応しただけのデータベースではなく、クラス定義を管理するクラス・ディクショナリを持ち、クラス内のデータとメソッドを柔軟に組み合わせられる、まったく新しいタイプのデータベースだ。それをサポートするために、オブジェクト指向プログラミング言語の仕様変更も必要だろう。これらのツールが揃えば、オブジェクト指向技術を利用した情報資源管理が可能になる。
 オブジェクト指向技術との組み合わせで力を得るのは良いが、実際に使うとなると問題もある。まず、情報資源管理自体が、設計の面で高いセンスを要求する。データを利用する業務システムが複数あると、利用する側での共通処理も出てくる。すると、データ側で持つ処理、データ利用側で持つ共通処理、それ以外の利用側処理の3つに切り分けなければならない。それを判断するためには、利用する側の全業務の知識を求められる。
 もう1つのオブジェクト指向技術も、これまた高い設計センスを要求する。構造をスッキリさせるには、何をオブジェクトに設定するかが重要だ。また、継承機能を広く生かすには、オブジェクトとメソッドの構成が良くないとダメだ。結果として、情報資源管理とオブジェクト指向の組み合わせは、さらに高い設計センスを求める。そんな人材は、残念ながら非常に少ない。
 この問題を解決するには、新しいツールが必要だろう。高度なウイザード機能を持ち、設計を手助けするようなツールが。それが無理なら、上手に設計したサンプルを数多く集め、設計のポイントを相当に詳しく説明し、参考にしてもらうしかない。こうして地道に啓蒙し、設計できる人を増やすしかなさそうだ。

パッケージソフトへのシフトで難しい状況に

 日本では、情報システムを自社開発する傾向が強かった。ところが、最近はその傾向が弱まりつつある。背景にあるのは、開発コストだ。構築する情報システムが複雑化するにつれ、自社開発ではコストが無視できないほど大きくなった。また、ERP(Enterprise Resource Planning)のような、会社全体の業務をサポートしながら、カスタマイズ性の高いパッケージソフトも登場した。だんだんとだが、パッケージソフトを利用する流れが強まっている。
 自社で開発しなければ、情報資源管理の特長を生かすことは難しい。それでも、ERPパッケージと連携する小さなシステムは自社開発があり得る。その際には、ERPパッケージ側のインターフェース部分が重要になる。情報資源管理の考え方に沿ったフレームワークを持つ、オブジェクト指向のERPパッケージが、1つの現実的な到達点であろう。その意味で、情報資源管理の推進者は、ERPパッケージの開発元に強くアピールすべきである。
 情報資源管理の目的をさらに進展させると、データを自由に扱えるシステムへと向かう。既存のデータベースのように形式が固まった形態ではなく、好きなようにデータ項目を組み合わせて使え、整合性などの問題解決を支援するようなシステムだ。それを基礎に持つERPを作れば、自由度の高いシステムになるだろう。もちろん、実現するのは相当に難しい。

(1998年4月10日)


下の飾り