スタートページ主張・講演単発講演等

ユーザー部門のあり方

ISC研究会での講演記録(1997年10月15日)
はじめに
1 情報システム部門の任務
2 基幹系システムでの問題点
3 情報系システムでの問題点
4 グループウエアでの問題点
5 アウトソーシングおよびERPの問題点
6 ダウンサイジングでの問題点
7 情報システム部門の任務は人材育成
おわりに

はじめに

とかくマスコミは情報システム部門バッシングの風潮がある。「社長は情報システムは重要だと認識しているが、自社の情報システムの現状には不満に思っている。それは、情報システム部門が経営を知らないからだ」といわれる。また、ユーザとのコミュニケーションがうまくいかないのは、一方的に情報システム部門が悪いようにもいわれる。

私は、情報システム部門に長く従事してきたが、この論調はどうも公平ではない。情報システム部門の言い分も聞いてくれという思いがある。そこで今日は,情報システム部門から見て、トップのことはさておき、ユーザー部門にこうあってほしいという話をしてみたい。

なお、当然のことであるが、ここで話すことは私が関係している企業に関係したことではないし、読者の企業のことでもない。私は多くの情報システム部門の人とフランクなお付き合いをさせていただいており、ときどき愚痴をこぼし合うことがある。それらをまとめて代弁しようとしたものである。


1 情報システム部門の任務

情報システムのコンセプトは、EDPS→MIS→DSS→SIS→BPRへと変化してきた。それに伴い、情報システム部門も従来のプログラムを書きシステムを作るというDP(データプロセシング)部門としての任務(旧任務という)から,経営戦略に情報技術を統合するIT(インフォメーションテクノロジー)部門としての任務(新任務という)が必要であるとされてきた。

とかくマスコミは、新コンセプトが現れると、旧コンセプトが誤りであったかのようにいうことが多いが、旧コンセプトは旧コンセプトとして厳存し、その上に新コンセプトが加わったと解釈すべきである。すなわち、情報システム部門は新任務とともに旧任務も持っているのである。

ここで問題なのは,その任務について情報システム部門とトップやユーザとの間にギャップがあることである。情報システム部門は,「情報システム部門は従来のDP部門ではない。IT部門としてもっと経営の中核として付加価値の高い業務に活用してほしい。プログラム作成などはユーザー部門が主体になって取り組んで欲しい。そのための教育やインフラ整備は情報システム部門が行う」という。

一方、多くのトップは「コンピュータは役に立っている。しかし、それは省力化などの旧任務での効果だ。確かに戦略的な面でも少しは役立ってはいるが、それについては不十分だ。それにしてもシステム部門は金がかかる」と言う。ユーザーからすると「いまやコンピュータがなければ業務が達成できない。だからこそ情報システム部門の対応の遅さには困っている。われわれの要求を迅速に実現することに徹底してほしい。プログラムの作成は情報システム部門の基本任務である」と考えている。すなわち、トップやユーザが情報システム部門を評価し期待しているのは旧任務なのである。

トップのことはさておき、以下、ユーザと情報システム部門の関係を考えたい。昔から「ユーザー主導」がいわれてきた。システムは業務で活用されてこそ価値が出るのであり、業務を知っていてシステムを活用するのはユーザーなのだから,システムはユーザーの要求によって開発され、運営されなければならない。これは正論である。ところがややもすると,この「ユーザ主導」が曲解されて、パソコンのハードやソフトの選択もユーザが決定したり、業務遂行とは無関係な趣味的な要求までもユーザのいうことを押しつける風潮にもなる。情報システム部門も、あれこれ反対するのも面倒だから言われたとおりやってやろうという風潮に流れていく。

しかしユーザーの言うとおりにして、最終的に誰が情報システムの責任を持つのか。私は、情報システムに一番の責任を持つのは情報システム部門だと思う。ユーザーに任せっきりにするのは危険である。


2 基幹系システムでの問題点

以降、情報システムの各形態について、ユーザの悪口と「ユーザ主導」が危険なことを列挙する。まず、基幹系システムを対象にしよう。

ユーザは、システムのコストにはあまり関心を持たない。しかも、システムが大きくなると、その費用が指数的に増加することを理解していない。「あれもやってくれ、これもほしい」といい、「あった方がいい」という程度のものまで作ることになってしまう。その結果,システムは巨大に複雑になる。

経営環境が急激に変化するので、ユーザーからは頻繁に変更の要求が出される。しかも短期対応が要求される。そのために、プログラムやシステムをパッチ当てで修正することになり、システムはさらに複雑化してしまう。経営環境が激変するのは避けられないが、ユーザの対応が遅くてなかなかニーズが確定できず、それがシステム改訂期間をことさらに短くしているのでは困る。

どの企業においても、従来から情報システムはユーザニーズによって開発し改訂してきた。その結果が複雑怪奇なシステムになり、情報システム部門が硬直化してユーザの要求に応えられない状況になったのである。

考えてみるとユーザーニーズとは何なのだろうか。流通システムを例にすれば、昔のように,「何をどれだけどこへ運んでコストがいくら」を計算するようなものならニーズも明確であるが,最近のように「顧客満足をしながらコストダウンすること」が目的となると、どのようなシステムにすればよいかのニーズを明確にできない。しかも,経営環境は激変するので,現在のニーズは示せてもそれが3年後、5年後も通用するとは思えない。すなわち、ユーザすらニーズを明確に示すことができない状況なのである。

情報システムを経営環境変化に即応させるには、システムを改訂しやすいように、柔軟なシステムにすることが重要になる。ところが、現在のユーザーニーズに忠実なシステムにすればするほど、システムが「堅く」なってしまい,変更しにくいシステムになってしまう。


3 情報系システムでの問題点

柔軟なシステムにするには基幹系システムを簡素化することが必要であるが、それには基幹系システムで収集蓄積したデータを、ユーザが任意に検索加工できる情報系システムを普及することが効果がある。しかし、情報システム部門は,ユーザに使いやすいシステムを提供することを重視するあまり,情報系システムにおいても,ユーザに迎合しすぎて,かえって情報システム部門を多忙にしたり基幹系システムを複雑にしてしまうことになる。

昔は,ユーザーが情報をほしいときは情報システム部門に電話をかければよかった。情報システム部門はユーザーにとって「音声応答・AI付きのコンピュータ」だったわけである。それで情報システム部門は、「1を押せば○○集計表,2を押せば××分析表」というような個別処理メニューを提供しがちである。しかし、これが恒例になると、情報システム部門は多様なメニューを作らなければならなくなる。

それを解決するには、個々の帳票出力のメニューを提供するのではなく、その元になるファイルを整備して公開し、個々の帳票出力はユーザー自身でやってもらおうとする考え方が出てくる。これが公開ファイル提供方式であり,データウェアハウスである。

ところが、この方式ではユーザーに何らかのプログラム作成または操作を強要する。ユーザーは「それは情報システム部門の仕事ではないか」というし、情報システム部門も「ユーザにはジョインは難しい」とか「ユーザに面倒なことはさせられない」といって、「個別帳票直前公開ファイル」を提供するようになる。すると、今度は多様な公開ファイルを作成することになり、それを作成する基幹系システムがむしろ複雑になってしまう。


4 グループウエアでの問題点

グループウエアの狙いは、直接効果としては情報伝達の迅速化と情報の共有化であり、間接的には意思決定の迅速化、組織のフラット化、活性化、創造性向上、ビジネスチャンスを生かすことである。確かにオープンな組織にグループウエアを入れれば大きな効果が上がる。しかし「他人のことに口出しするな」とか常に上司の承認が必要だというようなクローズな組織ではなかなか効果的な利用はされない。

クローズな組織では、「○○には見せてもよいが××には見せられない」ようなことが複雑になっている。そのために,複雑なセキュリティ体系を要求し、本来なら簡単に構築できるグループウェアを複雑なものにしてしまう。それで人事異動のたびにセキュリティ変更にために情報システム部門が大騒ぎするようなことにもなってしまう。

また、グループウェアを導入しても初期の目的が得られないので、残業報告や出張申請など定例的な事務作業をグループウェアで実現させることが目的となる。そうなると,システムの構築が情報システム部門の新しい任務になるし、安定した運用が要求されるので,ネットワークやサーバの管理が大変なことになる。

最近はBPRのインフラとしてワークフローシステムが注目されている。審査業務やクレーム処理など本格的なワークフローシステムにおいては、データの信頼性、正確性、標準化、記録性、統合化が必要である。これは基幹系システムの特性と同じであり、ワークフローシステムは基幹系システムとして考えなければいけない。

ところがユーザーは、グループウエアを発展した形でワークフローシステムをやろうといいだす。ここに大きなギャップが生じる。ユーザーは、今でもメインフレームによるレガシイ文化から抜け出せないので、システムがダウンすると大騒ぎする。ところが、ダウンサイジング環境は安物部品の集まりなのだから、安定して動かないことは当たり前なのである。安物を使って高級品と同等の安定性を要求するのは無理であることを認識すること、どのくらい落ちてもいいのか、落ちたときの手だてはどうするのかを認識することが重要である。私はそれが情報リテラシーだと思う。


5 アウトソーシングおよびERPの問題点

情報リテラシーの一つとして、情報システム業界の特質を理解することが大切である。単純にいえば、アウトソーシングとは旧任務としての情報システム部門を廃止することである。今までは利用部門にとっての窓口は情報システム部門であった。ところがこれからは、ユーザが直接にベンダーと交渉することになる。

ベンダーと情報システム部門は性格は違いながらも同じ文化をもっていた。どんなところが大変で、見積や開発には何を決めておかなければならないかが互いにわかっていた。ところが、いままでユーザー部門は、情報システム部門に「販売システム一式」的な注文をしてきた。これではトラブルは必至である。アウトソーシングではこういう問題が多くなるのではないだろうか。

また、最近はERP(統合型業務システム)が喧伝されている。ERPはユーザに「靴に足を合わせる」ことを強制する。トップやコンサルタントが加わった推進委員会が睨んでいる間は靴に足を合わせるにしても、やがて委員会が解散すると変更の要求が噴出してくる。そうでなくても、企業環境の変化によりシステムへの改訂が出るのは当然である。

ところが、ERPを導入することは、他人の作成したプログラムを使うことであるから、その内容については、情報システム部門もユーザと同じ程度にしか知らない。しかも、勝手に変更したらベンダーはメンテナンスの保証をしないというので、ベンダーに頼まざるをえない。

アウトソーシングにせよERPにせよ、予算の潤沢な部門では、金さえ出せばベンダーは情報システム部門のような文句もいわず応じてくれるので、「ユーザ趣味主導」が実現できる。逆に、予算の取れない部門では、必要な改訂すらいえ出せないので、情報システムとは別の方法で対処することになる。あるいは小回りを求めて、旧任務を目的とする新情報システム部門を部門内に復活させるかもしれない。ところがそこでは、正規のシステムに手出しができないので、ファイルをコピーして他のシステムを作ったりして、システムの二重帳簿のようなことにする危険もある。


6 ダウンサイジングでの問題点

ダウンサイジング環境が普及してきた。そこで従来のSEの問題が発生する。メインフレームのSEは、いわば外科医である。外科医はメスやハサミという道具を使って手術するが、何がやれるかは外科医の腕次第である。同じようにメインフレームではJCLとCOBOLという道具を使って、例えば給与システムは給与計算ができるようにすればよかった。

それに対してダウンサイジング環境でのSEに求められるのは内科医の能力であろう。「クローズな環境からオープンにしたい」というような要求に対して、あるハードウエアを選択して、あるソフトを乗せて、アレンジする。内服薬の調剤みたいなものである。それが効くかどうかはわからない。やってみるしかない。おかしかったら別の薬を出す。このような内科医的なSEが現場にいなければいけない。

そのためには、ユーザー部門で情報化リーダーを育成することが必要になるが、現実には情報システム部門からユーザー部門に異動させることが多い。その情報化リーダーをユーザー部門のスターにすれば、周囲の認識が高くなり、情報化リーダーとしての本来の仕事が充分できるようになり、それによって若い人が情報化リーダーという仕事に関心を持つようになれば、成功の確率は確実に上がっていく。

ところが、統計(94年、日経パソコン)によると、現場のリーダーが一番困っているのは「便利屋にされる」ことで、次に「操作を覚えてくれない」「自分の仕事ができない」が続く。「苦労しているのに周囲が理解してくれない」「トラブルがあると叱られる」「本業がおろそかになり気づいたら自分本来の仕事がなくなっていた」という不満をあげている。情報化リーダーを便利屋にしてしまったら、上図の逆のスパイラルになり、いかにEUCを叫んでみても、根付くとは思えない。


7 情報システム部門の任務は人材育成

前述したように、情報システム部門での旧任務は依然として存在する。では、この旧任務を担うのは誰か。ユーザー部門が引き受けるとは思えないし、任せられないのが実情であろう。アウトソーシングするにしても、前述のようにユーザーはそれに耐えられるだろうか。便利屋システム部門が復活しかねない。

一方、新任務については、情報システム部門は本当に新任務を引き受ける自信があるのだろうか。業務においてもグレシャムの法則は生きており、旧任務と新任務をあわせ持つと新任務はおろそかになってしまう。

私は、新任務を担うのは企画部門であると考える。情報が全社的に戦略的に役に立ち、それが企業の体制まで変える力を持つのであれば、ゼネラルスタッフである企画部門が担当するのが当然である。もし、企画部門に情報技術がないようであれば、それはトップが情報技術をないがしろにしている証拠であるから、いかに情報システム部門が騒いでみても成功するとは思えない。

情報システム部門論は多いが、情報システムと情報技術者と情報システム部門の3つを混同して議論されている。情報システムは企業にとって今後ますます重要性が増していくのは間違いない。システム思考ができ、異なる価値観を融合させる能力を持つ情報技術者も、これからますます多部門で必要になろう。しかし、だからといって、情報システム部門が重要かどうかは疑問である。

むしろ、情報システム部門は、そのような技術者を育成して企画部門などの各部門に提供する役割を担うべきだと思う。情報システム部門は、いわば企業の幹部候補生の育成機関になりえるのではないか。会社の情報が一番集まってくるのは情報システム部門であり、SEは人事や営業以上にシステム思考や対立調整の方法等の教育を受けている。現在のような時代では、情報を知らずに経営者にはなれない。情報システム部門は経営者育成機関としての機能を持たなければいけないのではないだろうか。今日はユーザーの悪口を述べたが、このような人材を育成して提供することが、このような問題を抜本的に解決する最大の方法であると考える。

ところで、情報システム部門はこの人材育成に真剣に取り組んできただろうか。よく「ご用聞きSEから提案型SEへ」といわれる。ところが、コンピュータの本格的導入が始まった1960年代のSEは、提案型SEどころか改革型SEであった。それがいつのまにかご用聞きSEになったのは「ユーザ主導」が原因である。

しかも、この「ユーザ主導」はユーザが主張したのではない。情報システム部門がユーザの参画を呼びかけるために「あなたが主役」といいたかったのであろう。それが、いつの間にか情報システムに関する責任を放棄するいいわけに使うようになってきたのではないか。現在のユーザー部門を育てたのは、情報システム部門が情報システムへの指導的信念を失ったからではないか。


おわりに

今日は、ユーザの悪口をあげつらったが、翻ってみれば、情報システム部門のあり方が問題なのであり、情報システム部門の自己反省を求めるものであった。テーマは「ユーザ部門のあり方」であったが、それを「情報システム部門のあり方」と訂正して、話を締めくくることにする。