公開ファイル提供方式と個別帳票メニュー提供方式
情報検索系システムをユーザに提供する方式は，公開ファイル提供方式と個別帳票メニュー提供方式に大別できます。
- 公開ファイル提供方式
- 公開ファイル提供方式とは，基幹業務系システムで収集蓄積したデータをユーザが取り扱いやすい形式に加工したファイル群を公開し，ユーザが使いやすいツールを提供することによって，ユーザが任意の切り口で検索加工する方式です。データウェアハウスでのＯＬＡＰツールなどがこれにあたります。
情報システム部門としては，公開ファイルの整備とツールの使い方の普及をすれば，それ以降はユーザが自主的に多様な利用をするので，手が省けます。ユーザとしては，公開ファイルの内容やツールの習得が面倒ですが，それができれば，公開されているすべてのデータを望む形式で得ることができます。 - 個別帳票メニュー提供方式
- ところが，ユーザにとっては公開ファイルの内容やツールの習得が壁になって情報検索系システムが普及しないこともあります。また，操作が面倒だと忙しいときには使わないこともあります。それで，情報システム部門が，１をクリックすれば○○集計表，２をクリックすれば△△分析表というようなメニューを作成して提供する方式も多く見られます。
この方式ですと，ユーザは便利ですが，情報システム部門が用意した「おしきせ」の情報しか入手できません。それでメニューの拡充を求めますが，そうなると情報システム部門が多忙になり，情報システム部門の負荷削減の目的とは逆の方向に進んでしまいます。
情報検索系システム普及での悲劇的ドキュメンタリー
この２つの方式は，どちらが優れていてどちらがダメだと決め付けるわけにはいきません。利用者の成熟度や利用環境などにより併用する必要があります。しかし，ややもすると個別処理メニュー提供方式が大勢を占めており，肝心O「必要な人が・・・」や「情報システム部門の負荷低減」などの本来の目的が達成できないでいるのは悲劇です。
しかも，個別処理メニュー提供方式を採用している理由が，全社的な利失を考慮したものであればよいのですが，どうもユーザの過度依存症，それに対する情報システム部門の没我的愛情症に起因しているのでは問題です。
- なぜか情報システム部門が責任者に
- 情報検索系システムは，情報システム部門にも大きな効果がありますが，それにもまして必要な情報をいつでも得られるというユーザの期待が大きいように思われます。ですから，本来ならばユーザが推進者になって情報システム部門に協力を依頼するのがスジのように思われます。少なくとも両者からなる推進チームを編成するのが妥当でしょう。
ところが，なぜか情報システム部門が推進責任者にされてしまうのですね。ですから，講習会を設けたのに参加して「くれない」，利用して「くれない」という表現になるのです。ユーザとしては，自分の本業でないから上司も歓迎してくれないし，成功するかどうかわからないものに首を突っ込みたくないという気持ちがあるのでしょう。それよりも，情報システム部門に文句をいっておけば，連中が何とかやってくれるさという依存観念があるのでしょう。 - ユーザは音声応答・ＡＩつきのコンピュータを持っていた
- ユーザからみれば，コンピュータとは情報システム部門なのですね。必要な情報がほしいときには「おーい木暮，ちっと○○を出してくれ」といえば，私は依頼者の状況を勘案して○○とは何かを判断してプログラムを作成して帳票を出力して送付していました。
ですから，ユーザにとってみれば，いかに便利なツールであっても，業務にも情報技術にも通暁しておりしかも親切な木暮氏以上の効果は期待できません。それで「そんな面倒なことをしなくても今のまでいいよ」というつれない返事になってしまいます。 - 個別処理メニュー提供方式での妥協
- 情報システム部門としては普及責任がありますので，「そこを何とかお願いしますよ」，「ほら，あなたがいっていた帳票がワンタッチで出てきますよ。便利でしょう」と便利さを強調することになります。その結果，操作もより簡単に帳票もより美しくという過剰サービスがエスカレーションします。しかも，情報システム部門内ですら「情報検索系システムは，使われてナンボの世界だ。いかに理想でも使われなければ意味がない」という始末。当然，公開ファイル提供方式のような「お客様にご負担をかける」ような方式は提案すらされません。
- 当初は大成功！
- 紆余曲折はあるものの，なかにはこのようなことが好きなユーザもいます。それを特別待遇の賓客として利用してもらいますと，木暮某のように恩着せがましいこともいわないし，即座に結果が出ると好評です。このような成功例がいくつか現れると，以後は情報検索系システムブームが出現します。
「この１年間でユーザが○○人になりました。メニューは○○個作成しました。利用件数は○○回を突破しました」という報告がトップに提出され，社長賞の候補にすらなります。ユーザと情報システム部門の蜜月時代です。 - 成功は失敗の母
- 成功を喜んでいる間にカタストロフィーが起こります。当初は「販売部門メニュー」で済んでいたのが，「東京支店と札幌支店では規模が違うし仕事の仕方も違う」ので「東京支店販売部メニュー」や「札幌支店総務課メニュー」になり，さらには「東京支店販売１課メニュー」「東京支店販売１課井上メニュー」へと細分化されていきます。あまりにも多くの要求が殺到するので，情報システム部門がそれの開発に忙殺されてしまいます。
その結果は，「作りますが既に１００件のバックログを抱えています。１日平均１件のスピードで対応していますので，半年後にはポンと入れればパッと出るシステムをご提供できます」ということになります。ユーザは「情報システム部門に頼んでもなかなかやってくれない」と文句をいうし，情報システム部門は「こんなに残業してやっているのに，評価してくれない」と欲求不満が高まります。 - いまさら公開ファイル提供方式？
- これを打破するには，公開ファイル提供方式の採用が考えられます。しかし，これまでも経過により，ユーザは「いまさらなんだ。われわれは営業が任務で，コンピュータを覚えるのは仕事ではない。そもそもそのために情報システム部門があるのだ。これは情報システム部門の責任放棄だ」と叱られます。トップも同じような意見です。
情報システム部門内部でも「ユーザに面倒なことはさせられない」「ユーザにジョインを知ってもらうのは困難だ」という意見も強く，なかなか踏み切れません。 - 帳票直前ファイルシンドローム
- その妥協として，個別帳票メニューを提供するのではなく，その元になるデータを提供しようということになるのですが，上記のような理由により，「○○帳票に関する一切の項目を１ファイルに収めて，レコード内の計算はすべておこなっておく。それにより，ユーザは選択と集計のキーだけを指定すればよい」という，正規化とはまったく逆の「帳票直前ファイル」での提供になります。
これでは提供するファイル群があまりにも多くなります。それを基幹業務系システムの一環として作成するのでは，基幹業務系システムはますます複雑になってしまいます。しかも，このような環境ですから個人が勝手に作成してテストなしの本番になります。ファイル間の調整などは行えません。それで「○○ファイルから出したものと△△ファイルからのもので数字が違う。コンピュータなんか信用できない」といわれたりもします。
ユーザに必要な知識とは
「飢えている人に魚を与えても一時の飢えをしのぐだけである。魚の取り方を教えれば一生飢えから解放される」のです。個別処理メニュー提供方式ではいつかカタストロフィーが起こります。それ以前に公開ファイル提供方式を導入する必要があるのです。
カタストロフィーが起こる段階になってからはじめてユーザに技術習得を要求するのは，「うちには財産があるのだから，お前は苦労などしなくていいよ」とスポイルして育てておきながら，ある日突然に「親の会社が倒産して全財産を失った。お前は自分で食っていく手段を考えろ。しかも，親は心労で病気になってしまった。親の世話も頼む」というようなものです。適切な養育方法とはいえません。
「自動車を運転するには免許が必要だ。企業は自動車の運転を期待する」ことを明確にするべき時代になっているのです。ユーザも最小限の情報知識を持つことが要求されるのです。実際に多くの企業が技術普及をしていますが，その方向が不適切なように思います。
何のための表計算ソフトか
表計算ソフトの利用技術を習得する必要性があることは誰でも知っています。しかし，それを個人の生産性向上ツールだと思っていたのでは困ります。たしかに表計算ソフトは縦横集計をするとかグラフを描くのに便利ですが，それだけのことでしたら，企業としては暗算でもソロバンでもできる人を採用すればよいのです。現実には，セルにデータを伝票から拾ったりコンピュータからの出力帳票から再入力したりすることに大部分の時間がかかるのです。それらのデータはコンピュータにあるのですから，そこから選択加工しながら表計算ソフトのスプレッドシートに取り出す能力があってこそ，表計算ソフトの能力が効果的になるのです。
情報検索系システムでは，ユーザは単に情報を得るだけでなく，それを編集加工するニーズを持っています。それを二次加工といいましょう。ユーザが表計算ソフトの知識を持っていれば，情報検索系システムの提供側は，スプレッドシートに取り出すまでの環境を提供すれば，後はユーザに任せることができます。ユーザにその知識がなければ，ユーザは二次加工する処理までも情報検索系システムに求めるでしょう。
二次加工のニーズは多様です。データ取り出しの数倍・数十倍のケースがあります。それを情報システム部門に依頼していたのでは，情報システム部門の負荷は非常に高くなってしまいます。すなわち，ユーザの表計算ソフト知識の有無は，情報検索系システムの成否に影響するのです。
データウェアハウスの利用にも必要
データウェアハウスのＯＬＡＰツールでは，縦横の断面を変えてみたり，奥の断面を表示したりする機能が比較的簡単な操作でできるようになっています。ところが，縦に得意先，横に年月をとった売上高の表でも，縦に商品，横に支店をとった出荷量の表でも，その表示形式はどれも同じ形式になっています。それを表の種類により自動的に異なる形式にしてくれなければ使わないというのでは困ります。
そのような要求に迎合して，ＯＬＡＰツールに個別のシステムをかぶせて個別帳票メニュー方式にして，ユーザにはＯＬＡＰツールを意識させないで使えるようにしているケースが多くあるのです。これでは，せっかくのデータウェアハウスの利点がなくなってしまいます。
正規化とジョインの知識が必要
ＯＬＡＰツールを利用するには，データを多次元データベースの形式で持つことになりますが，それはある程度限定した利用を前提として構築しますので，任意の切り口での検索加工をするのには限界があります。それには，正規化してＲＤＢ（リレーショナル・データベース）の形式で保存しているデータをアクセスする必要があります。
正規化されたファイルから求める情報を得るためには，売上ファイル，得意先マスタファイル，商品マスタファイルを用いること，得意先コードと商品コードをキーとしてそれらのファイルを結合（ジョイン）することといった知識が必要になります。ユーザにこの知識があれば，情報検索系システムの運営は極めて簡素化されるのです。
この知識は情報技術とはほぼ無関係ですし，項目やファイルの定義がユーザにわかりやすい形で整理されていれば，短期間で理解できる内容です。ところが，多くの企業でのユーザへの技術普及の内容を見ると，これをマトモにやっているところは極めて少ないのです。その裏には，ユーザは「表計算ソフトは個人としても使うので習得したいが，そんな企業のことまで苦労して覚える気がしない」という依存症と，「ユーザにそこまでさせてまで情報検索系システムを普及する必要があるか」という情報システム部門の愛情がそうさせているのでしょう。それがかって効果的な普及を妨げているのです。