７．１ はじめに
本章では，共生・創生のための情報資源戦略に関して，企業内部において，数値的情報を共有し分析することにより，組織としての創造性の向上を図る分野について考察する。この分野での情報利用形態は，1970年代のＤＳＳ（Decision Support System），1980年代を通して普及したいわゆる情報検索系システム（１），1990年代中頃から発展したデータウェアハウス（Data Warehouse）により代表される。
これらの利用形態は，それを支援する情報技術環境は異なるが，情報共有化・創造性向上の観点ではほぼ同じような位置付けになる。それで本章では，これらを一般論としては情報検索系システムと表現し，データウェアハウス特有の事項に関してはデータウェアハウスと使い分けることにする。
(1)「基幹業務系システム」と「情報検索系システム」は，日本の実務界で慣用的に使われている用語であり，厳密な定義はないが，本章では次のような意味で用いている。基幹業務系システムとは，スコットモートン(Scott Morton)による区分では，ＴＰＳ（Transaction Processing System）およびＩＲＳ（Information Reporting System）に相当するものであり，最近ではＯＬＴＰ（Online Transaction Processing）と呼ばれる分野である。販売システム，生産システム，経理システムなどのように，全社的なデータを定例的・定型的に処理することを目的とした情報システムを指す。情報検索系システムとは，スコットモートンのＥＳＳ（Executive Support System）に似ているが，ＥＳＳは経営者を対象にしたものであり，操作を容易にするために情報システム部門があらかじめ加工したものを提供しているのに対して，基幹業務系システムでは，利用者を一般社員までも対象にして，利用者が自ら検索加工をする形態である。米国の実務界ではＤＳＳと呼ぶことが多いが，それではスコットモートンの（狭義の）ＤＳＳ－現在のパソコンの表計算ソフトが持つゴールシーキング機能のような利用－までも含んでしまうと解釈されることもあるので，あえて情報検索系システムとした。
７．２ 情報共有化・創造性向上と情報検索系システム
7.2.1 情報検索系システムの発展
情報システムの発展を歴史的に概観することにより，情報システムにおける情報検索系システムの重要性が増大してきたこと，そして，情報検索系システムが情報共有化や創造性向上に大きな役割を持つことを示す。
情報検索系システムの発展の推移を図７－１に示す。日本の大企業がコンピュータを本格的に導入しはじめた１９６０年代初頭では，コンピュータは高価でありソフトウェアも貧弱であった。そのために，専門技術集団である情報システム部門が中心になり，給与計算，売上処理，会計処理など，データが大量で定量的効果が大きく，画一的処理で論理が比較的単純な業務処理が対象になった。ここでは，それを基幹業務系システム(1 前出)という。
図７－１ 情報検索系システムの発展
基幹業務系システムの普及により，社内の基本的なデータがコンピュータに集積されるようになると，そのデータを有効に活用することが期待されるようになった。また，経営者や利用部門は，基幹業務系システムから提供される情報が定例的・定型的であることに不満を持ち，アドホックに任意の切り口で検索加工した情報が得られることを希望した。１９７０年代の後半になると，ＴＳＳ（Time Sharing System）技術が普及したことにより，経営者や利用部門に配置された端末から，メインフレームを操作できるようになった。ＥＵＣ（End-user Computing）の環境ができたのである。
この環境になると，基幹業務系システムで収集蓄積したデータをエンドユーザが利用しやすい形式にファイルにして公開し，エンドユーザが比較的簡単な照会言語を利用して公開されたファイルを任意に検索加工する利用体系が出現した。いわゆる情報検索系システムである。
１９８０年代初頭に，マーチン（Martin, J.,1986(訳書),pp.16-23）はインフォメーションエンジニアリング（Information Engineering）を提唱し，情報検索系システムのような利用形態を「プログラマなしのシステム開発」として説明しているが，そこでは情報検索系システムをバックログ解消のための手段としているように，この頃の情報検索系システムは，基幹業務系システムの補助的なものと認識されていた。基幹業務系システムにより多様な情報を提供するのでは，情報システム部門の負荷が増大するし，エンドユーザにとっても個々の帳票出力を情報システム部門に依頼していたのでは情報を得るのに時間がかかるので，簡単な処理はエンドユーザが自分で行えるようにするという位置付けである。
情報検索系システムは，１９８０年代を通して普及した。１９８０年代中頃には，ＲＤＢ（Relational Database）の処理効率の改善（2）とパーソナルコンピュータ（以下「パソコン」という）の普及により，メインフレームから必要なデータを抽出してパソコンにダウンロードし，使いやすいパソコンソフトで多様に編集することが可能になった。さらに，１９８０年代末期から１９９０年代にかけて，ダウンサイジングが進み，ＣＳＳ（Client-server System）が普及すると，必要なデータを利用部門のサーバに置いて，それをクライアントから検索加工する形態へと進んだ。 １９９０年中頃になると，並列技術やディスクアレイなどの発展により，巨大なデータベースを格納して検索することが実用化され，多次元データベース（Multi-dimensional Database）などの高機能で使いやすいツールが出現したことにより，データウェアハウスの概念が普及してきた。
データウェアハウスの提唱者の一人であるインモン（Inmon, W.H.,1995(訳書))は，データウェアハウスを「マネジメントの意思決定を支援するために，subject-oriented, integrated, time-variant, non-volatileの特性を持つデータの集合」であると定義し，その概念自体は新しいものではなく，ＣＳＳとほぼ同じであり，それの発展形態であるとしている。
情報検索系システムとは，情報共有の観点でとらえれば，エンドユーザに公開されたデータベースとそれをアクセスするツールや環境の集合体であり，創造性向上の観点では，エンドユーザがそれらのデータベースやツールを用いて，任意に検索加工することにより問題発見や課題解決に創造力を発揮するのを支援する情報システムである。
(2)ＲＤＢが普及しはじめた頃は，ＲＤＢは，その特徴である動的結合機能により，小回りはきくが処理効率が悪いので，情報検索系システムに適しており，定例的な処理が多い基幹業務系システムには，むしろＮＤＢ（Network Database）が適しているといわれていた。基幹業務系システムにも適用されるようになったのは，１９８０年代中頃である。
７．２．２ 情報検索系システムによる情報共有化・創造性向上
情報共有化や創造性向上の分野では，グループウェアやナレッジマネジメントが取り上げられることが多いが，問題発見や問題解決の分野では，情報検索系システムのように，数値的な情報を共有化して創造的に検索加工することが役立つケースも多い。
たとえば，石油業界で流通コスト削減を検討することを考えよう。これは架空例であるが，おそらく次のようなアプローチをするであろう。
- ローリで配送距離が大きいとコストも高いだろうから，配送距離が長い事例を抽出する。
- それに該当する顧客への売上高や粗利益の推移を調べる。
- 製油所から直接にローリで運ぶのではなく，海岸の油槽所へ船で運び，そこからローリで運んだらコストがどうなるか検討する。
- その油槽所の取扱量が増大してもタンクのやりくりができるかどうか検討する。
- 自社の油槽所ではなく，他社の油槽所を借りたらどうなるか検討する。
- いっそのこと，自社製油所から運ぶのではなく，他社の製油所から出荷したらどうなるかを検討する。
このようなことを，イモづる的に仮説検証を試行錯誤する過程で，改善できる案を発見し実施していくことにより流通コストが削減できるのである。
すなわち，従来から存在するデータを共有化して，従来は気づかなかった切り口で検索加工することが創造的な改善・改革に役立つのである。このようなアプローチは一種の知識の共有化，組織の創造性の向上ともいえよう。そして，これを可能にするのが情報検索系システムでありデータウェアハウスなのである。
７．３ 情報検索系システムと基幹業務系システムの関係
７．３．１ 情報検索系システムと基幹業務系システムの関係の逆転
本節では，情報検索系システムが情報システムの主役であり，情報検索系システムが用いるデータを正確に円滑に供給するのが基幹業務系システムであると考えるほうが適切であること，しかも，情報検索系システムを中心に考えて基幹業務系システムを構築すると，改訂が容易な基幹業務系システムにできることを示す。
前述のように，情報検索系システムが出現した当時では，情報検索系システムは，基幹業務系システムの補助的あるいは付帯的な位置付けであった。しかし，そのような認識では，情報検索系システムに供給されるデータは，基幹業務系システムで必要とするデータに制約されてしまう。石油業界における市区町村マスタファイルの取り扱いを例にしよう。ガソリンスタンドの新設，廃統合，評価などのためには，市区町村における世帯数，自動車保有数，ガソリンスタンドの数などは必須な項目である。ところが，基幹業務系システムでは，市区町村マスタファイルは単なる住所マスタに過ぎないので，これらの項目を収集することすら思いつかないであろう。
情報を活用するには，まず，どのような項目が必要であるかを考え，次に，それらの収集手段を考えるべきである。すなわち，情報システムは情報検索系システムでの用途を先行して構築するべきなのである。また，情報検索系システムのデータの品質が低いと，それから得られる情報の品質が低くなり，意思決定を誤らせることになる。データの品質を高めるには，収集方法と品質管理のルールを定めて，それを強制することが必要になるが，それが基幹業務系システムなのである。すなわち，基幹業務系システムとは情報システムに品質のよいデータを供給する機能なのである（図７－２）。
図７－２ 情報検索系システムの位置付けの変化
７．３．２ 情報検索系システムによる基幹業務系システムの簡素化
（１）入出力部分の分離による簡素化
情報検索系システムを普及する目的は，必要な人が必要なときに必要な情報を容易に得られるようにするだけではない。経営環境の激変に対処するには，基幹業務系システムを環境に応じて改訂する必要があるが，情報検索系システムを普及させることにより，基幹業務系システムを改訂が容易なシステムにすることができるのである。
情報検索系システムを普及すれば，個々の帳票を提供するのではなく，その基になるデータを公開データベースとして提供するだけでよいので，基幹業務系システム全体の規模を小さくできる。また，データ入力の部分も，ある程度はユーザの設計に任せることができる。
入出力部分が少なくなることは，ヒューマンインタフェースに関する部分が少なくなり，処理の大部分がファイル間でのロジックの処理だけになる。そのために，ＣＯＢＯＬのような逐次的言語ではなく簡易言語で記述できるので，同じ規模であっても改訂に必要な作業量を少なくすることができる。また，ヒューマンインタフェースの部分は，組織の改訂や仕事の変更などに伴い改訂しなければならないが，ロジックの部分は環境が変化しても改訂する必要が比較的少ない。そのために，基幹業務系システムの改訂そのものを減少できる。図７－３は，情報検索系システムの普及により，基幹業務系システムの規模が非常に小さくできることを示す。
図７－３ 情報検索系システムによる基幹業務系システムの規模削減
（２）マスタファイルの整備による簡素化
ここでは，得意先マスタや商品マスタのような台帳的なデータを持つファイルをマスタファイルといい，売上ファイルや在庫ファイルのようにイベントが発生するたびに累積・更新されるファイルをイベントファイルという。
情報検索系システムでは，マスタファイルの項目をキーとして，イベントファイルのレコードを選択・分類・集計する処理が大多数である。従って，情報検索系システムを構築するには，まずマスタファイルの体系化を行い，項目の整理をすることが必要になる。
たとえば，いくつかの得意先に例外処理をするとき，
ＩＦ 得意先コード＝○○ ＯＲ ×× ・・・
とするのではなく，得意先マスタファイルに得意先区分という項目を設けて，
ＩＦ 得意先区分＝１ ・・・
とできるようにしておくことが望ましい。このような項目は，基幹業務系システムで検討するよりも情報検索系システムからの要請により気づくことが多いのである。
このように，基幹業務系システムの再構築に先立ち，情報検索系システムを構築することにより，マスタファイルの項目を，処理までも含めて整理できるのである。マスタファイルの体系化ができることにより，基幹業務系システムの構築はイベントファイルだけを対象にすればよいので，その規模をかなり小さく簡素化できる。
７．３．３ データ中心アプローチと情報検索系システム
（１）データ中心アプローチの利点
改訂が容易なシステムにするには，データ中心アプローチ（ＤＯＡ：Data Oriented Approach）によるシステム開発が有効であるといわれている。情報検索系システムを前提とすることにより，基幹業務系システムをデータ中心アプローチで構築しやすくなる。
データ中心アプローチとは，データ構造をシステム構築の基礎とする考え方であり，データ中心アプローチにより構築されたシステムは，次のような利点がある。
- ①システム改訂が容易になる
- 経営環境は激変しており，それに伴い基幹業務系システムへの改訂要求が増大する。しかも競争が激しいので短期間での改訂が要求される。そのため，改訂が容易にできるシステムが優れたシステムであるといえる。
経営環境の変化により，得意先や納入先，取扱商品などは大きく変化するであろうが，得意先と納入先の間に親子の関係があるとか，取扱商品はいくつかの商品系列に区分されるといったデータ構造は，よほどの経営環境が変化しない限り変化しない。また，正規化（normalization）したファイル群では，得意先や商品といった項目は一ヶ所にしか存在しない。そのため，新規の得意先が発生したり，商品を廃棄したりするときもファイルの一ヶ所だけ修正するだけで，全体を整合的に修正することができる。すなわち，データ中心アプローチにより，改訂が容易なシステムにすることができる。 - ②統合したシステムを構築しやすい
- 得意先や商品は，販売システムだけでなく，流通システムや会計システムなどにも関係する。ＥＲ（entity-relationship）モデルを作り，得意先や商品の属性を考えるとき，単に販売システムだけでなく他のシステムでの利用を考えることは比較的容易であるし，そのようにして作成した得意先マスタファイルや商品マスタファイルは，どのシステムでも共通して利用できる。すなわち，データ中心アプローチにより，縦割りのシステムではなく，統合化したシステムにすることが容易である。
（２）情報検索系システムとデータ中心アプローチの関係
情報検索系システムでの公開データベースは，データを部品として多様な用途に利用するのが目的であるから，正規化してあることが望ましい。また，情報検索系システムでは「当社が購入している取引先に，当社商品をどれだけ納入しているか」というような，横串的に分析する処理が多いが，それには各システムが統合化されている必要がある。また，上述のマスタファイルの整備は，必然的に横串的な利用を前提とするものであり，処理も含めた項目の整理は，必然的にデータ中心アプローチを要求する。
すなわち，情報検索系システムでの公開データベースは，データ中心アプローチで基幹業務系システムを構築するときの目標となる。また，データ中心アプローチで基幹業務系システムを構築すると，情報検索系システムの公開データベースも容易に構築できるのである。
７．３．４ ＥＲＰパッケージ導入と情報検索系システム
（１）情報検索系システムによるカスタマイズの減少
最近はＥＲＰ（Enterprise Resource Planning）パッケージが注目されている。ＥＲＰとは，企業全体の経営資源の最適配分を図るものであり，ＥＲＰパッケージはリエンジニアリングを実現するための基盤であるといわれている。
ＥＲＰパッケージの導入にあたっては，情報検索系システムを先に構築するのがよい。少なくとも，情報検索系システムを前提としてＥＲＰパッケージの対象機能を検討すべきである。
ＥＲＰパッケージを成功させるには，カスタマイズ（customize）（3）を少なくすることが重要だといわれている。ところが，現実には多様な出力情報が必要になる。それをＥＲＰパッケージでカバーさせようとすると，ＥＲＰパッケージの規模が大きくなるだけでなく，環境変化に応じたカスタマイズが将来的にも多くなる危険がある。一般的にＥＲＰパッケージでは，入出力部分は企業環境により異なるので仕様が簡素になっている。従来の個別システムと比較して，ヒューマンインタ 8年2月16日号）では，「新発想のデータ・ウェアハウス」の特集をしており，１９件の例をあげて，ライン部門支援型５件，スタッフ部門支援型８件，全社員支援型６件に区分している。全社員支援型の多くとライン部門支援型が個別処理メニュー提供型である。それ以外のものはほとんどが多次元データベース型であり，明記はしていないが，その一部は個別メニューを提供しているように思われる。
（２）多次元データベースとデータマイニング
コッドら（Codd,E.F.，Codd, S.B. & Salley, C.T.,1993(訳書),pp.170-210)は，データウェアハウスのような分析を主体とする利用形態をＯＬＡＰ（Online Analytical Processing）と命名し，ＯＬＡＰに適したデータの持ち方としては，ＲＤＢよりも多次元データベースが適していることを示した。
また，これからのマーケティングでは顧客の購買行動を個人のレベルで把握することが重要で，それには大量のディテールデータをデータマイニングするのが有効だといわれている。とかく，この二つは混同して用いられるが，そのツールにせよ用いられるデータにせよ，これらは違うものだと解釈するべきである。
多次元データベースでの処理は，一般的に単純な集計計算である。そのため，統計学の知識がなくとも，実務的な知識があれば比較的簡単に活用できるし，比較的副作用も少ない。一般に日常業務での問題発見的な用途に用いられべきツールである。
それに対して，データマイニングのツールは，高度な統計手法が用いられ，そのモデル作成や結果の解釈には，高度な統計的な知識も要求される。とかくこのような処理は，無関係の項目が統計的に意味を持つような結果になったりする。統計学の知識がないと，表面的な結果を鵜呑みにする危険がある。分析専門家が利用すべきツールなのである。
７．４．２ データウェアハウス用データベースでの混乱
（１）データウェアハウスでのデータベース
データウェアハウスを構成する要素には，全社的なデータを保管する（狭義の）データウェアハウスと，各部門に設置されるデータマート（Datamart）がある。データマートでのデータの持ち方としては，たしかにＲＤＢよりも多次元データベースが適しているといえるが，データウェアハウスでは，むしろＲＤＢのほうが適している。また，いわゆる「大福帳データベース」が適しているとの風潮があるが，これはデータウェアハウスには不向きである。
エンドユーザの要求は多様であり変化する。データマートのディスク容量は比較的小さいから，すべての要求を満足させるだけのデータを保管できないので，必要に応じてデータウェアハウスからデータマートにデータをダウンロードする必要がある。すなわち，データウェアハウスはデータマートのデータ保管庫であるともいえる。その観点では，データウェアハウスでは，任意の切り口でデータを抽出しやすいデータの持ち方が望まれる。それには正規化したＲＤＢが適している。
そもそも，なぜデータウェアハウスが必要なのだろうか。基幹業務系システムのデータを保持しているメインフレームがあるのだから，メインフレームから直接にデータマートにダウンロードすればよいので，データウェアハウスは不要だとも考えられる。ところが，基幹業務系システムのデータは正確性や効率性の観点から，個別の処理に適したデータ構造にしている。その構造はデータマートで必要とする構造とは一致していない。その変換には基幹業務系システムの知識が必要であり，しかも複雑な処理が必要になる。それでは，データウェアハウス－データマートの運営維持が困難になる。それを解決するために，その間にデータウェアハウスを設置するのである。
基幹業務系システムのデータからデータマートのデータへの変換を容易にする観点からも，データウェアハウスのデータは部品として使えるように正規化しておくことが必要なのである（木暮,1997,pp.103-113)。メインフレームでの基幹業務系システム，データウェアハウスおよびデータマートの関係を図７－４に示す。
図７－４ 基幹業務系システム，データウェアハウス，データマートの関係
（３）いわゆる大福帳データベース
経営情報関連の有力な雑誌である『日経情報ストラテジー』は「大福帳データベース」を提唱している(5)。それにより，データウェアハウスではディテールデータを時系列で持つことから，データウェアハウスでは大福帳データベースで持つのだという表現が実務家の間で流布している。どうも実務者のなかには，「生データ」と「ディテールデータ」を混同している風潮がある。 しかし，データウェアハウスのデータには大福帳データベースは不適切なのである。そもそも大福帳データベースは基幹業務系システムを想定したものであり，データウェアハウスのような情報検索系システムには向いていない。間違ったデータを保存することは，基幹業務系システムでは重要なことであるが，データウェアハウスのような利用では操作を複雑にさせてしまう。
また，大福帳データベースでは正規化を否定しているが，上述のように，むしろ正規化したディテールデータが望ましいのである。よしんば非正規化データで持つにしても，それは「生の」データではなく，いったん正規化した後で，効率を考慮して最適化すべきなのである。
(5) 『日経情報ストラテジー』誌の１９９３年８月号，pp. 34-56, 「老朽化した企業細胞を”大福帳”システムが破壊」では，「大福帳データの４条件」の中で，「企業活動で生じたデータは加工せず，生データに形で記録し，直接アクセスする」としている。１９９４年８月号pp.42-66, 「マルチメディア時代の大福帳システム：誰が，いつ，何をしたかが分かる」では，「入力データはそのまま１件１件再び取り出せるように記録する」「間違ったデータを入力しても消してはならない」としている。また，１９９６年９月号 pp.89-108，「大福帳システムとデータウェアハウス－情報活用は江戸時代に学べ」では，「生データを大福帳の法則で記録すれば･･･このデータをデータウェアハウスに生かすことで、問題点の発見や分析、追跡などがより早く、スムーズに実行でき、対策をすぐに立てられるようになる」といっている。
７．５ 情報検索系システムの普及を阻害する要因
７．５．１ データ公開におけるセクショナリズム
グループウェアの有効活用のためには，組織文化の影響が大きいといわれているが，情報検索系システムにおいても，組織の体質が発展を阻害していることが多い。また，情報検索系システムの活用では，エンドユーザの情報リテラシの向上がいわれているが，ここでは，エンドユーザの過剰趣味や過剰依存の体質が阻害要因になっていることを示す（6）。
情報検索系システムのデータの大部分は基幹業務系システムで収集したものであるから，グループウェアのように「重要な情報は入力しない」という問題は存在しない。しかし，そのデータを公開する段になると，いろいろな意見が出てきて，公開できないとか，公開するにしても複雑な管理をしなければならないことがある。
たとえば，社の方針として値引販売を原則として禁じているのだが，何らかの事情でＡ支店が値引販売をしたとしよう。すると，Ａ支店が値引きしたのを，Ａ支店は公表したくないし，本社営業統括部門は，それを他支店が知ればこぞって値引販売に走るだろうと考える。それで，「販売数量を公開するのはよいが，単価は公開しない」，「サマリーデータはよいがディテールデータでは金額を入れない」，「ディテールデータの単価は該当支店内だけに公開する」というような意見が出てくる。
あるいは，データを公開することにより他部門からとやかく言われるのを嫌って，「データの構造が複雑なので，事情を知らない者が検索加工をすると，誤解を招く結果になる。必要な情報がほしければ当方が出力して渡すから，データの公開はするべきではない」というような意見もでてくる。
部門セクショナリズムの強い組織文化があるときには，データウェアハウスの活用以前に，このような問題を解決しなければならないのである。
(6)ここに掲げるような事象は，所属組織の欠点になるためか，公表されることは少ない。しかし，非公式の場では，情報システム部門の愚痴としてよく話題になることである。
７．５．２ 過剰体裁愛好症と過度依存症
（１）エンドユーザの過剰体裁愛好症
グループウェアではあまり問題にならないことが，情報検索系システムの普及では大きな問題になることがある。たとえば「支店別府県別売上集計表」を得たいとする。データベースが整備されており，適切な汎用的なツールがあれば，ベタ打ちの数表の形式でそれを入手するのは至極簡単である。しかし，エンドユーザは，それでは満足しない。図７－５のように，まず，罫線を引きたがるが，そのデザインは帳票により異なるので，汎用ツールでは対処できず，個別の処理が必要になる。さらに，グラフ化をしたがるが，通常の棒グラフなどでは満足せず，地図に製品の形で大きさを表すような形式にまでしたがる。すなわち，エンドユーザは，情報がほしいのではなく，きれいな帳票がほしいのである。これではエンドユーザの生産性は向上しない。
図７－５ エンドユーザの過剰趣味愛好症
（２）エンドユーザの情報システム部門への過度依存症
そのような風潮が広まると，自分では高度な加工をする技術を持たない者までが，体裁に凝った帳票を求めるようになり，それを情報システム部門に要求する。データウェアハウスのツールは便利であり，多様な機能があるが，エンドユーザはそれを習得しようとせずに，情報システム部門にグラフまで加工するのをワンタッチでできるようなマクロ機能を組み込むことを要求するようになる。これでは，情報システム部門が硬直化してしまう。
データウェアハウス発足当時は，ともかく使わせることが目的になり，個別処理メニュー提供型のサービスをしがちである。これは受け入れやすいが，いつまでもこれを続けていると，エンドユーザの要求が多くなったときに，情報システム部門が対応できなくなり，カタストロフィが起こる危険がある。また，エンドユーザはメニューでの運用に慣れてしまい，多次元データベース型やデータマイニング型に移行することができなくなり，イモづる的な利用，すなわち，問題発見や創造性の向上が阻害される危険がある。
７．６ これからのデータウェアハウス
７．６．１ データウェアハウスとメタデータ
（１）エンドユーザのためのメタデータ（エンドユーザ用辞書）
データウェアハウスは組織の創造性を向上させるために重要なツールである。その目的をより効果的にするには，単に操作性を改善するとか，多様な処理ができるようにするだけではなく，データ管理の機能を強化する必要がある。
エンドユーザへの講習会を開催しても，なかなか利用にまで至らないといわれる。その理由は，利用技術ばかりを教育して肝心のデータ構造などの説明が不十分だからである。エンドユーザにとって困難なのは，パソコンの操作やツールの理解などよりも，どのようなファイルがあるのか，どのような項目名があるのか，その項目の内容はどうなっているのかなどがわからないのである。それで，講習会では理解しても，実務で使えないし，実務で使わないから習得できないのである。
データウェアハウスではメタデータが重要なことは，従来から指摘されている。しかし，現実にほしいのはエンドユーザのための辞書に相当するものがほしいのいであるが，商用ソフトウェアでは，まだ満足する状況になっていない。
次に二つの例を示すが，いずれも現在の技術で比較的容易に実現できるであろうし，これらが実現すれば，あまり手をかけないで個別処理メニュー型の環境が構築できる。
その第１の例がエンドユーザのためのメタデータ（エンドユーザ用辞書）である。たとえば「得意先別商品別売上集計表」を求めるプロセスで考えよう。
- 得意先が「得意先」なのか「顧客」なのかわからない。また，得意先とは代金の請求先なのか商品の納入先なのか不明である。
- おそらく売上ファイルは数種類あるであろう。ディテールデータで持っているのかサマリしているのか，保管しているデータはいつからいつまでのデータなのかなどがわからないと使えない。あるいは，売上のなかでも例外処理のデータが入っていないかも知れない。
- 売上の個数も不明である。たとえば３月に１００個出荷したものが４月に１０個返品になったとき，３月のデータが１００で４月が－１０（あるいは＋１０）となっているのか。あるいは３月を９０に修正してあるのだろうかがわからないと，結果を正しく理解することができない。
エンドユーザにとっては，そのような疑問に答えるオンライン辞書がほしいのである。その例を図７－６に示す。
図７－６ エンドユーザ用辞書の体系図例
逆に，このような機能が整備されていれば，エンドユーザが「得意先別商品別売上集計表」と入力すれば，ナビゲータが「対象期間はいつからいつまでですか」とか「月別集計でよいですか」というような質問をして，条件を対話的に明確にするシステムにもできよう。また，過去の利用を学習することにより，「ガソリンが対象ですか」とか「大阪支店管轄ですね」などと，利用者によって省略時解釈を変えることもできよう。
（２）メタデータの引継ぎとテンプレート
第２の例がメタデータの引継とテンプレートである。元ファイルＡを加工して新ファイルＢを作成したとき，Ａのメタデータ情報をＢに引き継ぐ機能がほしい。当然このとき，大阪支店のデータを抽出したのであれば，得意先や売上個数の辞書には「大阪支店の」という語句も組み入れてほしいのである。
また，エンドユーザは同じような処理をすることが多い。たとえば売上ファイルを主入力ファイルとして指定したとき，過去にそれを主入力として処理をした内容の一覧表を表示して，そのどれかを指示して，一部を変更すれば実行できるようなテンプレート機能があると便利である。
７．６．２ データウェアハウスとオブジェクト指向
（１）メタデータとオブジェクト指向
オブジェクト指向アプローチが普及してきた。既にＲＤＢもオブジェクト指向データベースの機能を取り込んでいる。データウェアハウスにもオブジェクト指向の考え方が次第に取り入れられることが期待される。
現状のデータウェアハウスでは，データの部品化や再利用の面には有効であるが，処理も含めた部品化・再利用に関してはあまり注目していない。上述のメタデータの引継ぎは，クラス間でのインヘリタンスであり，テンプレートはオブジェクト（クラス）のエクステンションであるともいえる。オブジェクト指向の考え方を採用することにより，体系化が容易にできるのではなかろうか。
（２）データウェアハウスとグループウェアの統合
情報共有化の観点では，データウェアハウスもグループウェアも同じような目的である。ところが，前者ではフォーマットされたレコードの加工を対象とし，後者はファイル単位での加工をしないマルチメディア情報を対象とすることで，独自に発展してきている。
これを統一した環境で利用することができると便利である。データウェアハウスにより，急速に売上を伸ばしたガソリンスタンドを発見したら，その写真や地図を見たり，そこでの自社担当者との商談記録なども調べたりしたいであろう。また，ガソリンスタンドが業界協会で表彰されたとの電子メールを見たら，そこの売上高の推移などを調べたいであろう。
オブジェクト指向データベースでは，抽象データ型という属性があり，項目に不定長の文章や図形が使えたり，他のファイルのアドレスを指定して，そのファイルを表示したりするような機能を取り入れている。これを利用することにより，データウェアハウスからグループウェアの情報をアクセスすることは比較的容易である。既に一部の商用データベースではこのような機能を提供しているが，まだデータウェアハウスとしての位置付けにはなっていない。
（３）グループウェアとの統合とデータウェアハウスの構築
オブジェクト指向とは無関係であるが，このような統合が円滑にできるようになると，データウェアハウスの構築・運用が容易になる。
データウェアハウスの構築では，とかく多様な項目を入れたがる。ガソリンスタンドの例でいえば，経営者のやる気だとか，外観がきれいかどうかなどの項目も入れようとする。ところが運用する段になると，コード化するのが無理であったり，実際に何にしてよいかわからず，ほとんどが「その他」になっていたり，何年経っても更新されないままになり，結果として使えないデータになってしまう。
無理にコード化するのではなく，当初はグループウェア的な自由形式での文章ファイルにしておき，それとのリンクだけをデータウェアハウスに登録しておくだけで，かなり実用になる。そして，それらの更新が円滑にできるようになった段階で，あらためてコード化を考えればよいのである。
７．７ おわりに
本章では，情報検索系システムやデータウェアハウスが情報共有化や創造性向上に効果的であり，それらを健全かつ円滑に発展させるためには，次のような認識が必要であることを論じた。
- 情報検索系システムは基幹業務系システムの付帯的な存在ではない。むしろ情報検索系システムを情報システムの中心的存在であるとして，それに正確なデータを提供するのが基幹業務系システムであると考えるべきである。
- 情報検索系システムの検討が大切である。データ中心アプローチやＥＲＰパッケージによるシステム開発にあたっては，情報検索系システムを検討することが大切である。データウェアハウスをよりよく運営するために，データウェアハウスの形態，データの持ち方，組織文化や利用者の心構えなどについて論じた。
- これからのデータウェアハウスでは，エンドユーザ辞書の機能が重要であることと，グループウェアとの統合化が望まれることを示した。すなわち，情報検索系システムやデータウェアハウスを論じることは，情報システム全体のありかたを論じることになるのである。