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