ＥＵＣと情報システム部門の組織

ＥＵＣの形態には、パソコン単体での利用、グループウェアなどのコミュニケーション系システム、情報検索系システムがありますが、ここでは情報検索系システムを中心に取り扱います。

情報技術の発展は、コンピュータ利用の大衆化の歴史、すなわち、ＥＵＣの発展の歴史であるといえます。もはや、現在ではＥＵＣこそがコンピュータ利用の中心的なものになっています。

情報検索系システムは、狭義には仮説検証のツールとしての利用が重要でですが、広義には、基幹業務系システムの簡素化など、情報システム全体を合理化する意義を持っており、その観点から情報検索系システムをとらえることが重要です。

ＥＵＣの普及により、情報システム部門の任務や組織が変化してきました。昔はプログラムを書き、システムを構築し、コンピュータの運用をすることが任務でしたが、現在では、経営戦略と情報技術の統合やＥＵＣを支援などが重要な任務となっています。また、ＥＵＣの推進では、情報システム部門ＩＣ（推進組織）、各利用部門でのＩＣ、業務統括部門ＩＣが任務を分担しつつ協力することが重要です。

１　ＥＵＣの概要

本節ではＥＵＣの諸形態を、パソコンの利用、コミュニケーション系システム、情報検索系システムの３つに区分します。前の２つは他章で取り扱っていますので、ここではＥＵＣは情報検索系システムのことであるとして、その概要を記述します。

（１）ＥＵＣの諸形態と本章でのＥＵＣ

ＥＵＣの定義は人により異なりますが、本章では、ＥＵＣとは、「エンドユーザ（情報システム部門以外の人）が、自主的にコンピュータを直接に利用して、自分あるいは自部門の業務に役立てること」とします。

基幹業務系システムでも、要求定義では利用者が中心的な立場になりますし、その実施では利用者が画面からデータを入力したり帳票を出力したりします。しかしそれは、「自主的」というよりも、プロジェクトの一環としての任務ですから、ここではＥＵＣには入れないことにします。

図１４−１　ＥＵＣの利用形態

ＥＵＣの形態は、図１４−１のように３つに分類できます。

�@　パソコンの利用

個人の生産性向上や創造性の向上のために、パソコンのワープロや表計算ソフトを利用する形態。

�A　コミュニケーション系システム

社内利用を対象とした電子メールや電子掲示板などのグループウェアのような利用形態。

�B　情報検索系システム

基幹業務系システムで収集蓄積したデータを、利用者が任意な切り口で検索加工して情報を取り出すような利用形態。

これらの利用形態のうち、�@は「第１１章　パーソナル情報システム」、�Aは「第１０章　グループ情報システム」で取り扱いましたので、ここでは�Bを中心に取り扱います。そのために、ＥＵＣと情報検索系システムとを同義語として扱います。

また、ＥＵＣと似た概念にＥＵＤ（エンドユーザ・デベロップメント）があります。これは、利用者が他の利用者のために小規模なシステムを開発することです。しかし、これを取り上げると、情報システム部門との関係があいまいになりますので、ここでは重視しないことにします。

（２）ＥＵＣ普及の背景

�@経営環境からの要請

情報システムは企業のあらよる業務に浸透しており、経営環境は激変していますので、情報システムへの変更要求は激増しています。また、消費経済の成熟化に伴い、企業は顧客消費動向の把握やさらなるコストダウンが重要になります。そのためには、日常業務で収集蓄積したデータを多様に分析することが必要になります。

�A情報システム部門の多忙化

ところが情報システム部門は、巨大化・複雑化した情報システムの運営、ネットワーク環境の運営、ＥＵＣ推進などのために硬直化しており、それらの要求に応え切れません。それで、利用者自身が自らコンピュータを操作して情報を得ることが必要になります。

�B情報技術の発展

以前はコンピュータは高価で使いにくいものでしたが、パソコンを中心に、急速に価格性能比がよくなり、利用者にも使いやすい環境になってきました。また、時代の発展により、昔のようなコンピュータアレルギが急速に解消されました。

２　ＥＵＣの発展

ＥＵＣの発展を歴史的に振り返ってみます。ＴＳＳ、ＤＳＳ、ＣＳＳ、データウェアハウス、グループウェア、イントラネットなど、コンピュータの発展の歴史は、コンピュータ利用の大衆化の歴史、すなわち、ＥＵＣの発展の歴史であるといってもいいすぎではありません。そして現在では、むしろ、ＥＵＣのほうがコンピュータ利用の通常の形態であり、情報システム部門が開発運用する基幹業務系のほうが特殊な形態であるとすらいえるようになってきたのです。

（１）オープン・プログラマ

日本の大企業が本格的にコンピュータを導入し始めたのは１９６０年代でした。導入当時には、早急に多くの業務をシステム化する必要がありましたが、情報システム部門の人員が少なく、利用部門の人もシステム開発に参加しました。特に技術計算の分野では専門的知識が必要ですので、利用部門が開発し運用することが多かったのです。

そのような人をオープン・プログラマといいました。これは未だ情報システム部門と利用部門の未分離の状況ですので、ＥＵＣとはいえないかもしれませんが、ＥＵＣとは決して新しい概念なのではないことを理解してほしいのです。

（２）ＴＳＳとＤＳＳ

１９７０年代の後半になると、ＴＳＳ（タイムシェアリング・システム：時分割処理方式）が普及してきました。利用者の机に端末を置き、それからメインフレームを共同利用する方式です。

それと共に、ＤＳＳ（デシジョン・サポート・システム：意思決定支援システム）の概念が出てきました。これには２つの形態があります。その一つは、狭義のＤＳＳであり、企業モデルとか予想財務モデルを作り、「もし、売上が○○％あがったら」「もし、○○円の投資をしたら」「その結果はどうなるか」というような問題を机上実験するものです。もう一つはＥＳＳ（エクゼクティブ・サポート・システム：経営者支援システム）ともいい、基幹業務系システムで収集したデータを整理して、簡単な操作で多様な情報を入手できるようにしたシステムです。

このような利用は、１９８０年代を通して急速に発展しました。ＲＤＢ（リレーショナル・データベース）や４ＧＬ（第４世代言語）などの発展により、情報検索系システム用に公開したファイルを、利用者が簡単な言語を用いて、多様な検索加工ができるようになりました。

（３）ＯＡの概念とパソコンの利用

１９８０年代になると、「１９６８年から１９７８年までの１０年間で、生産部門の生産性は９０％向上したが、オフィス業務の生産性は５％向上したにすぎない」との米国での調査報告が発表されたり、パソコンが急速に普及するようになり、パソコンの利用によりホワイトカラーの生産性を向上させることが重視されました。それがＯＡ（オフィス・オートメーション）です。

当初は、ＢＡＳＩＣ言語を使ってプログラムを書くことがＯＡであるかのような奇妙な風潮もありましたが、すぐにワープロや表計算のソフトが普及するようになりました。これは利用部門でのコンピュータ・アレルギを解消するのに大きな意義がありました。一般のホワイトカラーがコンピュータ技術を習得しないと生き残れないというムードを醸成したのです。なお、パソコンの活用については「第１１章　パーソナル情報システム」で詳述しています。

パソコンの普及は、ＴＳＳの利用にも影響を与えました。ＴＳＳの端末がパソコンになり、メインフレームのデータをパソコンにダウンロードして、使いやすいパソコンの表計算ソフトなどで多様な編集をする利用形態になってきたのです。このような動向により、メインフレームとパソコンとの連携が進んだのです。

（４）ＣＳＳとデータウェアハウス

１９８０年代末から１９９０年代にかけて、ＣＳＳ（クライアント・サーバ・システム）が普及してきました。従来の大型メインフレームでの集中処理から、利用部門に分散設置したＵＮＩＸワークステーションやパソコンをＬＡＮで接続した環境で、分散処理をする形態です。これによって、情報システム部門よりも利用部門に、より多くのコンピュータ資源が置かれるようになったのです。

こうなると、メインフレームのデータをＣＳＳのサーバにダウンロードして、クライアントとサーバの間で検索加工することができるようになりました。これは、利用者にとって使いやすい環境であり、ＥＵＣはさらに発展しました。

１９９０年代中頃になると、データウェアハウスの概念が普及してきました。インモンはデータウェアハウスを「目的別に、統合化された、時系列に持つ、更新をしないという特徴を持つ、マネジメントの意思決定を支援するためのデータの集合である」と定義しています。この概念は、情報検索系システムでの公開ファイルなどと同じようなものだとも解釈されますが、超並列プロセサや高速なＵＮＩＸプロセッサの出現、多次元データベースの出現などにより、従来とは格段の利用環境になりました。なお、データウェアハウスについては、「第６章　販売情報システム」で詳述しています。

（５）グループウェアとインターネット

コンピュータ利用での画期的な変化は、電子メールや電子掲示板などのグループウェアの出現です。従来のコンピュータ利用は、数値情報を分類集計するというコンピュータ（計算機）としての利用でした。それが、文書や画像などのマルチメディア情報の伝達や共有化という、コミュニケータとしての利用になってきたのです。なお、グループウェアについては「第１０章　グループ情報システム」で詳述しています。

１９９０年代中頃から、インターネットが急速に発展しました。その技術を社内ネットワークに応用したのがイントラネットです。ＣＳＳの環境と比較して、イントラネット環境では、クライアントにはＷＷＷブラウザだけを置けばよく、運用費用も引き下げられますし、利用者もＷＷＷブラウザの知識があれば、かなり広範囲の利用ができますので、その利用が広まってきました。また、多くのアプリケーションが、ＷＷＷブラウザで使えるようになってきました。なお、ＣＳＳとイントラネットについては「第１６章　ＬＡＮとイントラネット」で詳述しています。

３　ＥＵＣの意義と問題点

情報検索系システムの目的は、「必要な人が、必要なときに、必要な情報を入手できるようにすること」にありますが、それが最も効果を示すのは、仮説検証のツールとしての利用です。情報検索系システムが普及すると、基幹業務系システムの規模を小さく簡素化することができます。このように、情報システム全体を合理化する観点から情報検索系システムをとらえることも重要です。また、ＥＵＣにも、利用者が目的と手段を混同したり、全社的な統制が困難になるなどの問題点があります。ＥＵＣの推進にあたっては、光の部分を伸ばし、影の部分を回避することが大切です。

（１）仮説検証

たとえば石油会社でローリの輸送コストを下げることを考えましょう。目的は明確ですが、どのような帳票を出せばよいかはわからないでしょう。わかっていれば、既に解決しているはずです。それで、次のようなアプローチをするでしょう。

• 遠方に輸送しているケースを取り出してみる。
• 近くの海岸にある油槽所まで船で運び、そこからローリで運べばコストはどうなるか調べる。
• 油槽所の取扱量が増大しつぁらどうなるかを調べる・・・

このように、仮説提起−結果入手−検証−問題発見−仮説提起−のプロセスを繰り返すうちに、問題の解決に近づくのです。このような業務は、多くの分野、多くのレベルで必要になります。

このようなアプローチでは、結果を入手して新たな問題が提起されるのですから、前もって準備しておくことはできません。また、問題を提起してから結果を得るまでの時間が短かいことが必要です。これを円滑に行うには、利用者が自らデータベースを多様な切り口で検索加工できるようにしておく必要があります。

（２）ＥＵＣが基幹系システムに与える影響

経営環境の激変に対処するには、基幹業務系システムを改訂しやすくすることが重要であることは、「第１２章　情報システムの開発と運用」で示しました。また、情報検索系システムを普及することにより、基幹業務系システムが簡素化することも述べました。

一般に、情報システムは、次の３つの処理に分割できます。

�@入力処理

画面によりデータを入力して、データをチェックをして、正しいデータをコンピュータに取り込むまでの処理

�A中核処理

昨日までの累積ファイルを今日の更新ファイルにより更新したり、関連する多様な処理をする。

�B　出力処理

中核処理により更新されたファイルから、多様な帳票類を出力する処理。

下記の例（図１４−２）は架空例ですが、通常の基幹業務系システム典型的なものと考えられます。

図１４−２　ＥＵＣによる基幹業務系システムの規模縮小の例

ＥＵＣがほとんど行われていない状況では、これら３つの処理の全体を基幹業務系システムとして開発運用する必要があります。入力処理が３０，中核処理が２０，出力処理が５０で、全体が１００の規模でした。

ＥＵＣが進んだ段階では次のようになります。出力処理のうち、請求書や財務諸表のような正確性を重視するものは基幹業務系システムとして出力しますが、管理や分析に用いる帳票は、その基となるファイルを提供するだけでＥＵＣに任せるとします。それが全帳票の８０％でしたので、基幹業務系システムの出力処理は０.２×５０＝１０の規模になりました。入力処理は、利用者が表計算ソフトなどにより、入力画面をカスタマイズしたり、ある程度は自作したりできます。それで基幹業務系システムの規模は３０から１０に減少しました。中核処理は、利用者が関与しないので、内容としては変化はありません。しかし、入出力などのヒューマン・インタフェース部分がなくなり、ファイル間だけの処理となりますから、簡易言語の利用ができ、開発や改訂に要する労力は２０から１０に減少しました。すなわち、基幹業務系システム全体としては、１０＋１０＋１０＝３０の規模となりました。

（３）ＥＵＣでの問題点

ＥＵＣには多くの危険があります。そのいくつかを列挙します。

�@　目的と手段の混同

利用者はとかく、必要以上に凝った帳票を作ってみたり、些細なことにことにコンピュータを使うという、過剰体裁愛好症やコンピュータ依存症に罹りがちです。過剰体裁愛好症は伝染しやすく、全社員総コピーライタ化になったり、過剰なハードウェアを要求したり、ソフトウェアの標準化を妨げたりすることにもなる危険があります。さらには、営業マンがコンピュータを使うことは、あくまでも手段であり目的ではありません。コンピュータにのめり込んで、肝心の営業活動がおろそかになるようでは困りますし、さらに、それがよいことだと本人や周囲が信じるようになっては本末転倒です。

�A　情報システム部門の多忙化

利用者に使いやすいシステムにすることは重要なことです。しかし、それを過大に重視すると、多様な帳票をボタン一つで得られるような、個別帳票メニュー提供方式にしがちです。これは便利なので要求が殺到します。すると情報システム部門は、メニュー追加作業で麻痺してしまいます。利用部門の情報システム部門過剰依存症と情報システム部門の利用部門趣味崇拝症は危険です。ある程度は、利用部門に苦労をかけても公開したデータベースから任意に検索加工できる手段を習得させる必要があります。魚を与えるよりも漁の技術を与えるほうが、情報システム部門にとっても利用部門にとってもよいことなのです。しかも、漁の技術はますます易しくなってきています。

�B　スーパーユーザの反乱

利用部門で高い情報技術を持つユーパーユーザは、ＥＵＣの推進において非常に価値のある人材です。しかし、技術が高いということと、ＥＵＣのリーダとしての適任とは違います。過剰画面愛好症のように業務にあまり関係のないテクニックに走ったり、自分の趣味で標準化に逆らうようでは困るのです。スーパーユーザはＥＵＣだけでなく業務でも強い影響力を持っていますので、それが情報システム部門批判に走ると、情報システムの無政府状態を現出する危険すらあります。

�C　セキュリティの確保

パソコンの普及やインターネットへの接続が多くなると、違法コピー対策、ウイルス対策、ハッカー（クラッカー）対策など、従来とは異なったセキュリティの脅威が起こり、しかもその経営に与える影響が非常に大きくなっています。ところが利用者は、セキュリティ対策よりも使いやすさのほうを重視します。自由と責任の関係を認識させることが重要になります。

４　情報システム部門の任務と組織

コンピュータが高価で取り扱いが難しかった頃は、情報システム部門の主な任務は、プログラムを書き、システムを構築し、コンピュータの運用をすることでした。しかし、ＳＩＳなどの概念が普及した頃から、情報システム部門の任務は、経営戦略と情報技術の統合のような企画的な任務が重視されるようになりました。また、ＥＵＣの発展により、プログラムを書くようなことは、情報システム部門のアイデンティティではなくなり、ＥＵＣを支援するためのインフラの整備とか教育普及などの環境整備が重要な任務となっています。

（１）ＤＰ部門としての情報システム部門

日本の大企業にコンピュータが本格的に導入され始めた１９６０年代頃のコンピュータは、アセンブラ言語という暗号のような言語でプログラムを作るのですから、正確で効率的なプログラムを作るには、それなりの訓練が必要でした。また、非常に高価な機械ですし、運用ソフトも不完全なものでしたから、訓練された専門家が運用管理する必要がありました。逆にいえば、当時はプログラムが作れるとかコンピュータの操作ができることが、それだけで専門家としてのアイデンティティがあり、企業のなかで主要な業務として認知されていたのです。

それで、企業組織のなかに専門家を養成し、それをまとめて情報システム部門（当時は電子計算機室などの名称でしたが）という組織にして、プログラム作成やコンピュータ運用に従事させたのです。すなわち、ＤＰ（データ・プロセシング：データ処理）部門だったのです。

当時の情報システム部門の組織は、次のようなものでした。

�@　運用グループ

大きく３つのグループに細分されます。(a)データ入力グループ：昔はパンチャという、伝票や紙に書かれたプログラムをカードにパンチする職種がいました。オンライン入力は普及するに伴い、姿を消しました。(b)出力帳票発送グループ：コンピュータから吐き出される大量の帳票類を、届け先である利用部門ごとに仕訳して発送する任務です。これも、利用者がオンラインで見るようになってから業務は縮小されましたが、大量多種類の帳票を出力する業種では、今も残っています。多くは外注者やパートを使っています。(c)オペレーショングループ：コンピュータのスケジュールを組み（スケジューラという）、実際に運用をする（オペレータという）グループです。特に後者では、外注しているのが通常です。

�A　システムグループ

システムを設計するシステム・エンジニア（ＳＥという）と、プログラムを書くプログラマから構成されます。組織は、(a)システム設計グループ（ＳＥ）／プログラミンググループのような開発段階による分け方、(b)システム開発グループ／保守グループのようなシステムのライフサイクルによる分け方、(c)販売システムグループ／経理システムグループのような対象業務による分け方などがあり、品質管理グループや技術グループ（新技術の調査と自社適用の研究）などを独立させることがあります。これらの形態は企業の事情によりまちまちです。

�B　システム企画グループ

システム部門長の補佐として、全社的な情報化の優先順位づけ、予算作成、実績対比などの任務です。技術グループをここに入れることもあります。

（２）ＩＴ部門としての情報システム部門

ＳＩＳ（ストラテジック・インフォメーション・システム：戦略的情報システム−「第３章　経営情報システム」参照）やＢＰＲ（ビジネス・プロセス・リエンジニアリング−「第１５章　ＢＰＲと情報システム」参照）の概念が出現し普及するに伴い、情報システム部門の任務はＤＰ部門としての任務だけではすまされなくなりました。

情報技術は経営戦略の武器であり、業務革新のインフラであるならば、情報技術動向を把握して経営戦略に活かすことが、企業での重要な業務になります。それには、単に経営的な問題意識だけではなく、情報技術の専門的知識能力が必要なので、情報システム部門の参画が必要になります。このような任務をＩＴ（インフォメーション・テクノロジ：情報技術）部門としての任務といいます。

また、ＥＵＣの普及と共に新しい任務が重視されてきました。ＥＵＣを円滑に利用するには、�@パソコンやサーバ、通信回線、ソフトウェアなどの利用環境を整備すること、�A基幹業務系システムで収集したデータを利用者が使いやすいように整備すること、�B利用者にコンピュータの使い方やデータ検索加工の技術を普及すること、�C情報の活用方法を指導すこと、�Dこれらを推進するための組織を整備することなどが重要になります。すなわち、情報システム部門には、利用者支援のコンサルタントとしての任務が重視されています。

これらの任務を達成するために、上記のシステム企画グループを強化したり、そのグループを情報企画部門としてゼネラルスタッフの一つとすることが現在の動向になっています（図１４−３）。それと共に、情報システムを経営の観点から考えることが重要ですので、経営者が情報システム部門を直接に統率するケースが増加しています。それをＣＩＯ（チーフ・インフォメーション・オフィサ：情報担当役員）といいます。また、情報システム戦略を全社的な戦略とするために、利用部門の上位者からなる「経営情報委員会」のような組織を設けている企業も多くあります。

逆に、ＤＰ部門としての存在意義が薄れてきました。もはやコンピュータの価格は低減しているので、その効率を追求するプログラムを作る能力や、コンピュータのオペレーションができる能力は、戦略的な観点では、あまり重視する必要はなくなってきました。「第１９章　ＥＲＰ」で詳述しているように、最近はＥＲＰパッケージが注目されていますが、これは考えようによっては、システム開発や保守の機能を情報システム部門から、ベンダと利用部門に移すものだともいえます。このような理由により、ＤＰ部門としての業務を別会社にして分離したり、アウトソーシングすることも多くなっています。なお、アウトソーシングについては「第１７章　情報システムのアウトソーシング」で詳述しています。

図１４−３　最近の情報システム部門の位置付け

（３）ＥＵＣの推進組織

ここではＥＵＣ推進組織のことをＩＣ（インフォメーションセンター）と省略します。その全体図を図１４−４に示しました。

図１４−３　ＥＵＣの推進組織

当然ながら、情報システム部門にもＩＣが必要です。そこでは、前述のような環境整備やコンサルティングを担当します。

しかしＥＵＣは、利用部門が利用部門のためにコンピュータを利用するのですから、ＥＵＣの推進では、利用部門が積極的に参画することが重要です。通産省は情報化人材の類型として、利用部門での情報化推進者をシステム・アドミニストレータといっています。上級システム・アドミニストレータとは、その部門の経営的観点から情報システムを考え、部門内の情報化を指導する立場であり、上記の経営情報委員会のメンバーになるべき人材です。初級システム・アドミニストレータは、実際の利用において、基幹業務系システムでの自部門内の要求のとりまとめや入出力の設計をしたり、ＥＵＣの推進に従事する人材で、情報化リーダとか、現場キーマンなどとも呼ばれます。ここでは現場ＩＣと呼びます。利用者からみれば、身近に指導を受けたり相談をするのは現場ＩＣですから、ＥＵＣの推進においては、現場ＩＣが重要な存在になります。

ところが、ＥＵＣの普及に伴い問題が出てきました。パソコン１台あたりの総費用のことをＴＣＯ（トータルコスト。オブ・オーナーシップ）といいますが、現場ＩＣが非常に負荷が高くなるなど、ＣＳＳ環境での見えないコストが大きいことが指摘されています。その解決策の一つとして、利用者からの質問や相談を集中して応じるヘルプデスクを情報システム部門に設置することが多くなってきました。このヘルプデスクをアウトソーシングすることも増えています。

また、情報システム部門ＩＣと現場ＩＣ以外に、営業本部とか本社経理部などの業務を統括する部門にもＩＣを設置することも増えています。情報システム部門ＩＣでは、各利用者のニーズに沿った業務を通しての指導までは手が回りませんし、現場ＩＣに高度な知識を要求することもできません。それに対して業務統括部門は、経営者と密着して、ＢＰＲなどを通して各部門に仕事の仕方を指示する任務がありますから、その実践の一環としてＥＵＣを位置づけることができます。とかく情報システム部門は利用部門の要求には弱いところがあり、ＥＵＣでの問題点が回避しにくいところがありますが、業務統括部門ＩＣならば、業務指示として解決しやすい立場にあります。しかも、業務統括部門の組織数が少ないので、ＩＣのスタッフを割り当てることも比較的容易です。

さらに、業務統括部門ＩＣと情報システム部門ＩＣとの間でのコミュニケーションを図ったり、計画的なローテーションを行うことにより、情報システム部門を、より経営者や利用部門に近づけることができるのです。