情報システム利用形態の体系に関する考察

１　はじめに

情報システム(ここではビジネス用途のコンピュータシステムに限定する)の全体像を理解するには，情報システムをいくつかの利用形態に分類して，その位置づけと相互の関連を把握するのが適切である。従来は情報システムの歴史的な発展の順序に従って体系化してきた。それを歴史的体系という。

また，情報システムの開発や運用で多くの問題が指摘されている。私は，そのいくつかは情報システムを歴史的体系で認識していることに起因すると考えた。そして，それを回避するには，歴史的発展順序とは逆の観点から情報システムを体系化することが適切だと考えた。これを逆歴史的体系という。

本論文では，逆歴史的体系の概要とそれによるシステム開発の方法論，逆歴史的体系の利点について考察する[1]。

[1]本論文は，私が日本経営システム学会全国研究発表大会で発表した次の２編をベースにしている。「情報システム利用形態の体系に関する考察」第２２回講演論文集，1999, pp.89-94，「同（第２報）」第２４回講演論文集，2000, pp.31-34.

２　歴史的体系と逆歴史的体系

２．１　歴史的体系

情報システムの利用形態は，基幹業務系システム→情報検索系システム→パソコンの利用→コミュニケーション系システムの順で出現してきた。

（１）基幹業務系システム

コンピュータがわが国でもビジネスに活用されはじめた１９６０年代では，コンピュータは高価であり，プログラム技術も未発達な状態であった。それで，売上業務や会計業務のような，全社的な大量データを迅速・正確に画一的な処理することが対象になった。いわゆる基幹業務系システムである。

（２）情報検索系システム

１９７０年代末になると，ＴＳＳ(time sharing system)技術の発展やＤＳＳ(decision support system)の概念の普及と共に，エンドユーザが自らコンピュータを利用するＥＵＣ(end-user computing)の利用形態が出現した。

エンドユーザが求める情報は多様であるが，それを提供する情報システム部門は多忙であるし，必要とするたびに情報システム部門に依頼していたのでは，情報を得るまでに時間がかかってしまう。それを回避するには，基幹業務系システムで収集・蓄積したデータをエンドユーザが使いやすい形式のファイルにして公開し，エンドユーザが簡易言語を用いて，任意の切り口で検索加工するのが適切である。

これが情報検索系システムの概念であり，情報検索系システムを基幹業務系システムの補助的な位置づけとして認識されてきたのである[2]。この利用形態は，１９８０年代を通して普及し１９９０年代にはデータウェアハウス（data warehouse)へと発展してきたが，補助的な位置づけであるとの認識はあまり変化していない。

[2]例えば，J.Martin,"An Information Systems Manifesto",成田光彰訳，『管理者のための情報戦略』，日経マグロウヒル社，1986, pp.16-25 では，エンドユーザが必要とする情報をプログラマなしで得るためのシステムであるとしている。また，W.H.Inmon, R.D.Hackathon,"Using the Data Warehouse",藤本康秀監訳，『よくわかるデータウェアハウス活用法』，インターナショナル・トムソン・パブリッシング・ジャパン，1996でも，データウェアハウスはＤＳＳの発展形態であり，基幹業務系システムのデータをエンドユーザが使いやすいように加工したものだと位置付けている。

（３）パソコンの利用

１９８０年代になると，パソコン(personal computer)の発展やＯＡ(office automation)の概念の普及により，部門や個人レベルでのコンピュータ利用が進んだ。パソコンとメインフレームの連携技術は急速に進んだが，ＯＡでのパソコン利用業務と従来からのメインフレームでの基幹業務系システムとの融合はあまり進まなかった。

（４）コミュニケーション系システム

１９８０年代末から１９９０年代にかけて，メインフレームによる集中処理からＣＳＳ(client-server system)環境へのダウンサイジングが進行した。しかし，わが国では頃は基幹業務系システムのＣＳＳ環境への移行はあまり進まず，ＣＳＳ環境での利用形態として，グループウェアによる電子メールや電子掲示板の利用が普及した。いわゆるコミュニケーション系システムである。このような利用は，インターネット／イントラネットの普及により急速に拡大している。しかし，コンピュータとしての利用とコミュニケータとしての利用は互いに異なる分野であるという認識が現在でも強く残っている。

２．２　逆歴史的体系

１９９０年代後半での情報技術の発展は，利用形態にも大きな影響を与えている。それをふまえて，情報システム全体の体系を再整理することが考えられる。私は，インターネットに接続されたパソコンの利用→特定の組織内に限定した情報伝達・共有化に特化したコミュニケーション系システム→コード化されたデータに特化したデータウェアハウスのような情報検索系システム→情報検索系システムで用いるデータの収集と品質保証をする基幹業務系システムの順で情報システムを認識するのが適切であると考える。これは逆歴史的発展とはほぼ逆な順序であるので，逆歴史的体系と名づける。

（１）インターネット接続パソコン利用の位置づけ

インターネットに接続されたパソコンの利用は社会的常識のレベルに近づいてきた。これを情報システムの基本的な利用形態とすることは自然な発想である。しかも，情報システムの基盤が，特定の機種，ＯＳ，アプリケーションに限定しないオープン環境になるので望ましい。既に，多くの情報システムが，クライアント環境をＷｅｂブラウザで統一したり，情報交換にＨＴＭＬやＸＭＬを利用したりする動向にある。

（２）コミュニケーション系システムの位置づけ

インターネットは不特定多数者との情報の伝達と共有化の手段である。しかし，企業内などの限定された空間では，伝達・共有すべき情報の量や質が非常に高くなるし，会議室予約などの特殊な利用も必要になり，特定のグループウェアのようなツールを利用する必要がある。このように，組織内の用途でのコミュニケーション系システムは，インターネットを組織環境に特化した形態であると考える。

（３）情報検索系システムの位置づけ

コミュニケーション系システムでは，文書や画像など加工を前提としない情報を取り扱う。ところが，企業では数値を計算加工した情報も重要である。

情報検索系システムとは，コミュニケーション系システムと同様に情報の伝達および共有化を目的とするものであるが，取り扱うデータがフォーマット化されたデータであり，利用者が何らかの加工をすることを前提としたシステムである。すなわち，逆歴史的体系では，情報検索系システムとはコミュニケーション系システムの対象を特化した利用形態として認識するのである。

（４）基幹業務系システムの位置づけ

情報検索系システムで利用するデータの収集を容易に確実にし，データの品質を保証するには，データの収集や加工のルールを定めて，それに特化したコンピュータシステムを構築するのが効果的である。それが基幹業務系システムである。すなわち，歴史的体系では，情報検索系システムは基幹業務系システムの補助的存在であ歴史的体系では，基幹業務系システムは情報検索系システムを維持するための入力システムであると認識するのである。

当然ながら，基幹業務系システムには，業務をルール化することにより，仕事の仕方そのものを変革する役割がある。しかし，そのような戦略的利用でも，分析を主体とする分野が重視されている。

３　逆歴史的体系によるシステム構築

逆歴史的体系に基づくシステム構築の方法論の概要を，情報検索系システムと基幹業務系システムの関係を中心に示す。

３．１　情報検索系システムを前提とした基幹業務系システムの構築

（１）マスタファイルの先行構築

検索加工処理は極端にいえば，売上ファイルのようなイベントファイルを，得意先マスタや商品マスタなどのマスタファイルの項目をキーにして，選択・分類・集計をする処理だといえる。すなわち，マスタファイルの項目を設定することが情報システム設計の基本なのである。

システム設計では，販売システムや会計システムなど個別のシステムを検討する以前に，全体のシステム計画を立案し，そこで項目名称やコード体系を統一することが重視される。それにはデータ中心アプローチが効果的であるが，当初からイベントファイルまでも含む全体のＤＦＤ(data flow diagram)やＥＲ(entity-relationship)図などを作成するのは困難である。

それを回避するために，当面はイベントファイルを考えずに，マスタファイルに必要な項目だけを対象に設計するのである。マスタファイルが先行していれば，個別システムの構築では，次のような効果がある。
・イベントファイル関係だけを対象にすればよいのであるから，システム全体が簡素化できる。
・先に項目名やコード体系が確立しているので，自然に統合化されたシステムになる。

（２）コミュニケーション系システムとの連携

マスタファイルの項目には，コード化しにくい項目もある（後述）。それを無理にコード化するのではなく，コミュニケーション系システムで構築している文書のファイル名などを項目として入れておき，それを参照するようにする。そして，利用している過程で分類が可能になった時点で，あらためてコード化すればよいのである。

（３）基幹業務系システムの設計

必要となるデータのうち，外部情報の入力など単に入力しさえすればよいものは，入力担当者や入力時のルール化を行なうだけでよく，基幹業務系システムとして構築する対象は，販売データなど業務プロセスに密着しているデータだけとなる。

個別システムの構築では，帳票出力を目的とするのではなく，情報検索系システムのファイル群すなわちデータウェアハウスへのデータ供給を中心に設計する。請求書や財務諸表の作成など，正確性が重要で大量に出力するものは基幹業務系システムで作成するが，出力帳票の大部分を占める管理資料は，基幹業務系システムで設計するのではなく，その元になるデータを整理して提供することにする。また，入力処理の部分は，できるだけワークフロー管理システムなどにより対処することにして，基幹業務系システムから外すことにする。

３．２　基幹業務系システムの改訂

現実には既に基幹業務系システムが構築されている場合が多い。これを逆歴史的体系に変換するには，次のような順序が考えられる。

（１）マスタファイルの整備

多くの現行システムでは，たとえば得意先マスタにしても多様な種類の得意先マスタが存在している，項目名でのホモニム・シノニムが多い，得意先と購入先が異なるコード体系になっている，正規化が不十分であるなどの欠点がある。

このような状態の現行システムでのマスタファイルの整理をすることが大切である。このとき，既存のマスタと整理後のマスタの相互変換システムを作る必要があるが，これは比較的容易である。

（２）保管データのデータウェアハウス化

基幹業務系システムでの結果として保管すべきデータを決定して，コード変換や正規化をしてデータウェアハウスに格納する適切な変換システムを構築する。これにより，改訂要求の多くはデータウェアハウスからの出力処理でカバーできるので，基幹業務系システムにまで影響することが少なくなる。

（３）個別システムの分離

全体のシステムを一挙に改訂することは理想ではあるが，費用や労力の都合により実施が困難であり，適当な部分に分割して個別に逐次改訂をすることが多い。ところが，マスタファイルは多くのシステムにまたがっているので，その分割をするのを困難にしている。このとき，（１）での既存のマスタと整理後のマスタの相互変換システムが有効になる。

また，システムの目的が（２）でのデータウェアハウスの正規化されたデータの更新となる。これにより，個々のシステム内部を他のシステムと独立になりので，個別部分に分割することが比較的容易になる。

以上のようなプロセスにより，分割した個別システムを逐次改訂すればよい。

４　歴史的体系での問題点と逆歴史的体系による効果

従来の情報システムの構築や運営には，多くの深刻な問題点がある。私は，それらのいくつかは歴史的体系による認識により発生したものであり，逆歴史的体系の認識をすることにより回避できると考える。その例をいくつか列挙する。

４．１　グループウェア導入の容易化

多大な費用を投じてグループウェアを購入し，多様なアプリケーションを構築したのに，あまり利用されていないことがある。これは，自社で経験がない利用形態を直接に導入したからである。

グループウェア購入の前に，インターネットでの電子メールを社内での情報交換手段として利用していれば，何を便利にすればよいかを検討するのも容易であるし，その利用状況を見てから，グループウェアを導入するほうが安全でもある。しかも，インターネットメールの段階でモバイル・コンピューティングの必要性の検討もできる。

最近の情報システムは，クライアント環境をＷｅｂブラウザで統一する動向にある。エンドユーザがブラウザの操作に習熟していれば，その後の展開を円滑に行うことができる。

４．２　データウェアハウス（情報検索系システム）運営の容易化

情報検索系システムあるいはデータウェアハウスを構築したのに，エンドユーザが活用しないとか，情報システム部門がかえって多忙になったなどの問題がある。

（１）操作方法

一般に情報検索系システムは，「１をクリックすれば○○集計表，２をクリックすれば○○分析表」のように個別帳票メニューを提供する方式と，公開ファイルと簡易ツールを提供する方式がある。前者ではエンドユーザはコンピュータの知識も必要としないし操作も容易であるが，メニューで与えられた情報しか入手できないし，情報システム部門では多様なメニューを開発・提供するために，かえって多忙になってしまう。情報検索系システムを基幹業務系システムの補助と考えると，コンピュータ知識を持たないエンドユーザにも利用してもらう必要があるので，このような方式をとらざるをえない。

それに対して，パソコン操作知識を前提とするならば，後者の方式を採用することが容易である。データウェアハウスから必要なデータをパソコンにダウンロードする手順は比較的容易であるし，ダウンロードしたデータをパソコンの表計算ソフトなどで多様な編集加工もできる。情報システム部門としては，データウェアハウスのデータの整備だけをすればよい。

（２）項目の設定

エンドユーザが利用しない原因は，操作方法を習得するのが面倒なことよりも，データが不備なために適切な情報が得られないとか，得られた情報が現実と違うなどのために使わないことが多いのである。それは，マスタファイルの項目が不適切なことに起因する。

石油販売企業の市区町村マスタを例にすれば，情報検索系システムとしては，世帯数，自動車台数，ガソリンスタンド数などの項目が必要なのはいうまでもない。ところが基幹業務系システムでは，請求書の宛先程度にしか利用しないので，コードと地名があれば十分であるし，効率を考えれば不要な項目は持ちたくない。このように，基幹業務系システムのデータをデータウェアハウスに変換したのでは，必要な項目が不足してしまう。このようなことは逆歴史的体系で認識すれば回避できることである。

また逆に，データウェアハウスを構築するにあたって，極端に多様な項目を入れたがることもある。ガソリンスタンドのマスタを例にすれば，前面道路の通行量，スタンドの美観，店長の積極性などもコード化して入れようとする。それが正確にコード化でき登録更新されれば効果的な活用ができるであろうが，それを調べて入力する現場の担当者の作業量は大変である。そのために適当な数値を入れるとか，大部分を「その他」に分類したりする。そして，その後の更新がなされずに放置されることが多い。

これは，無理にコード化しようとするために起こるのであり，前述したように，まずコミュニケーション系システムの文書との連携を考え，利用している間に分類ができるようになってからコード化すればよいのである。

４．３　基幹業務系システム構築・改訂の容易化

経営環境は激変しており，企業間競争は激しくなっている。それに対処するには，基幹業務系システムの構築および改訂を容易にすることが必要であり，情報検索系システムを前提にして基幹業務系システムを構築することが効果的である。

(１)基幹業務系システムが簡素化される

システムの構築や改訂を容易にするためには，システムの規模を小さく簡素化することが有効である。情報検索系システムを前提とすることにより，基幹業務系システムの出力系の大部分および入力系の一部分をエンドユーザに移すことができるので規模を縮小できる。また，入出力系を減らすことはヒューマンインタフェースに関する部分を少なくすることである。それにより，システムはファイル間処理になるので，プログラム言語にＣＯＢＯＬのような逐次処理言語ではなくＳＱＬやユーティリティのような非逐次処理言語を利用できる部分が増加する。これは同じ処理ではあっても，プログラムの改訂はかなり容易になる。

(２)データ中心アプローチを採用しやすい

保守に柔軟なシステムにするには，データ中心アプローチが有効であることはよく知られている。情報検索系システムのデータベースを維持することが基幹業務系システムの目的とすることにより，自然にデータ中心アプローチを採用できる。

情報検索系システムを整備すると，販売システムや購買システムなどの個別のアプリケーションを開発する以前に，商品マスタや得意先マスタなどのマスタファイルが台帳的に整備される。これができていれば，基幹業務系システムで個別のアプリケーションを構築するにしても，売上データなどのトランザクションデータだけのシステムを構築するだけでよい。また，事前のマスタファイル整備により，他のシステムと整合的なコード体系ができるので，「仕入先にどれだけ納入しているか」のような各システムを横串的に処理するのが容易な統合したシステムになる。

４．４　ワークフロー管理システムの高度化

ワークフロー管理システムの利用は盛んであるが，その適用は電子稟議や旅費精算など比較的ローカルな業務に限られている。これは，ワークフロー管理システムをグループウェアの延長と考え，基幹業務系システムとは別途な対象と認識しているからである。

しかし，ワークフロー管理システムは，基幹業務系システムの入力システムとして，もっと一般的に活用できるものである。逆歴史的体系では，まずワークフロー管理システムでシステムを構築し，バックオフィスとしての大量データ処理を効率的に行なうために基幹業務系システムを構築するというアプローチになる。

４．５　ＥＲＰパッケージ導入の円滑化

ＥＲＰパッケージの導入を成功させるにはカスタマイズを少なくすることが重要なことがよく指摘される。利用部門からのカスタマイズ要求は，入出力でのヒューマンインタフェースに関することが多い。ところが，一般的にＥＲＰパッケージでは，入力の操作性は悪いし，必要とする多様な帳票は提供されないのが現実である。それをそのまま利用部門に強いることはできない。

ＥＲＰパッケージ導入以前にグループウェアの発展としてワークフロー管理システムを整備することにより，入力部分をそれらに任せることができる。また，データウェアハウスを整備することによって，多様な出力をそれに任せることができる。すなわち，ＥＲＰパッケージを円滑に導入するには，逆歴史的体系によるアプローチが効果的なのである。

４．６　フロントオフィス系システムの容易化

基幹業務系システムでは，戦略的な企業間システムやインターネットによる商取引分野を他の分野と区分することもある。これらのシステムは短期間に構築・改訂する必要があるが，その変更を従来の基幹業務系システムに及ぼさないことが必要になる。その観点では，基幹業務系システムと情報検索系システムとは別にフロントオフィス系システムという利用形態を設定する必要があるかもしれない。

フロントオフィス系システムでは，インターネット接続パソコン環境をベースとしたシステムであり，コミュニケーション系システムもベースにしている。また，コールセンターのようなシステムでは，情報検索系システムが整備を必要とする。この観点では，フロントオフィス系システムは逆歴史的体系によったシステムであるともいえる。

５　おわりに

利用形態を情報システムの歴史的な発展に従った体系よりも，それとは逆の体系により認識するほうが適切であることを示した。

このような体系に関する文献を私は知らない。この体系による開発方法論に触れたが，私自身，現在は大規模システムを構築する立場にない。しかし，私は１９８０年代からこのような認識でシステムを構築して，有効な方法だと考えている[3]。

[3]その初期の方法論は，木暮　仁「エンドユーザコンピューティング　−その構築と運営−」『日経コンピュータ』1992年3月9日号, 1992年4月20日号にある。しかし体系的に論じたものではない。

また，コミュニケーション系システムと情報検索系システムとの連携に関しては不十分であると思う。それを明確にするには，オブジェクト指向データベース，ワークフロー管理システム，ＸＭＬなどの技術的側面の発展を待つ必要がある。