システム管理者入門（２）
前回では、ネットワークシステム管理者が抱く苦悩を、多様な観点から列挙した。今回からは、個別事項について、それらの苦悩を少しでも和らげる手段を検討する。まずトップとの関係を取り上げよう。
ＬＡＮやグループウェアなどの分野では、定量的な費用対効果が不明確なので、トップの戦略的観点での判断が必要である。また、この分野での効果をあげるにはユーザの自律的な活動が必須であるが、ユーザ（特に上位者のユーザ）にはトップから働きかけてもらうのが最も有効である。一般的な情報システムの推進でもトップの参画は必要であるが、特にこの分野では、トップが積極的に参画することが不可欠である。ところが、それが現実には難しいのである。
図１は、９４年に富士通システム総研が日米の社長を対象に行った「企業経営における情報の有効活用に関するアンケート調査」結果の抜粋である。数年前の調査ではあるが、現在でも大きな違いはなかろう。
日本も米国に劣らずほとんどの社長は情報は第４の経営資源だと認識しており、情報システム部門は戦略的な部門であるべきだとしている。筆者の体験でも、大企業のトップは、われわれが想像しているよりもはるかに情報の重要性を認識している。
ところが、日本では米国と異なり、自らコンピュータを使う社長は非常に少ないし、情報システム部門を情報収集の重要な部門だとは思っていない。そのために、情報化の投資案件には関与するが、情報化の方向付けなどにはあまり関わっていない。
すなわち、日本のトップは、頭では情報の重要性を理解しているのだが、体では日常的なこととして体得していないのである。
ＬＡＮやＣ／Ｓシステムによる情報の伝達や共有化のメリットは、定量的効果が不明確だし、効果の実現までには時間がかかる。それに対して、販促投資や生産設備投資では、費用対効果が比較的わかりやすいし、トップが経験的に体で知っている。
そのため、情報化投資は不況時の投資優先順位は低くなるのは当然である。不況だからこそ情報化による抜本的対策が必要だともいえるが、体で知っていないトップにそこまで説得するのは難しい。それに情報化の重要性はトップも認識しているので、それを繰り返すのは無駄であるし、あまりそれを主張すると、情報システム部門は企業の状況を理解していないのかと叱られることにもなる。
とはいえ、景気は循環するし、トップは情報化投資は必要だと思っているので、不況が続いてもやや好転した時点では投資を承認する。
ところが、情報システム部門の不手際によりタイミングを失することがある。不況時には、どうせ提案しても認められないからと思って検討もしない。景気が上向いて承認される時点になってから検討を開始する。ところがこの分野の経験がないので、検討には時間がかかる。やっと実施案を作成した頃には、また景気が悪くなり承認が取り消される。これでは、いつになっても進展しないし、部下の志気は低下してしまう。
むしろ、不況の時こそ将来計画を検討すべきなのである。好況になったらすぐに実施して、不況になる前に実効をあげ、不況にさしかかったら、メインフレームを廃棄するなどのコスト削減に踏み切る。このようにタイミングにあった行動をすることが、システム管理者の腕なのである。
Top
トップにパソコンを利用させる目的は、たてまえでは、トップが状況把握や意思決定を迅速に合理的に行うのを支援することであるが、ここでの本音は、トップに情報の価値や情報システム部門の主張を体で理解してもらうことにある。
トップのパソコン利用を推進するには、もし白紙の状況ならば、次の順序で行うのが適切である。
Ａ パソコン通信やインターネットの受信
Ｂ 社内の電子メールや電子掲示板の利用
Ｃ 情報系システムの利用（ＥＩＳ）
情報システム部門としては、ＢやＣから提供したいと思うが、これには問題がある。Ｂを行うためにトップにパソコン利用をさせるのであるから、白紙状態の環境ではそれは未だ確立していない。Ｃは、一般ユーザ向けにある程度は行っているであろうが、当初から行うべきではない。その理由は後述する。
トップは、株価・為替・経済情報・企業情報などに関心を持つ。筆者の見聞では、苦労してＣを作り、付録としてＡを提供したところ、実際にトップが利用したのはむしろＡのほうが多かったという例が多い。
ネットワークの観点では、ＡからＣに移るに伴い、ネットワーク技術が必要になり、それだけトラブルも多くなる。いかにトラブルを経験させるのが目的だとはいえ、当初からトラブル続きでは信用を失う。まず、パソコンは便利だと認識させた上で、機能を上げるにしたがい、トラブルも多くなることを知らせるほうがよい。それに、Ａでもトラブルがあることを知れば、ＢやＣでのトラブルが情報システム部門の無能が原因だとは思わないようになる。
Ｃは、以前にＥＩＳ(Exetive Information System)として注目された形態である。販売状況や財務状況などをグラフ化して提供することが多い。作成当初はトップも関心を持つのだが、毎度同じ内容と飽きるし、重要な情報は事前に知っている、一部の情報を除いては、あまり利用されなくなることが多い。継続して見てもらうためには、常に鮮度を保つことが必要であるが、その維持が大変である。
トップが使うとなると、とかく過剰サービスをしがちである。トップにはキーボードはおろかマウスさえ無理だとして、ペンタッチやフィンガータッチ仕様にしたりする。グラフの体裁にこだわる。ところが、実際にトップが利用するのは、パソコン通信での株価や為替情報であり、それはキーボード入力、文字列表示なのである。トップは体裁ではだまされない。内容がよいものなら、操作が面倒でも使いこなすのである。
また、トップのニーズは常に変化する。緊急に短時間で提供しなければならない。そのつど個別作成するのは大変な作業になるし、バラバラなシステム体系になってしまう。それを回避するには、データウェアハウスなどのデータの体系化が確立するまでは、このようなサービスはできるだけ小規模にしておくのがよい。
インターネットやパソコン通信などを先行させることにより、トップのパソコン操作リテラシーを向上させることができる。その後でのＥＩＳ提供ならば、内容はともかく、操作方法は一般ユーザと同じ程度での提供でよい。
トップが自らパソコンを操作して、その利点を体で理解すれば、ユーザへの指示も説得力があり、ユーザも真剣に取り組むようになる。しかし、トップの積極的参画も、ポイントがずれるとやっかいなことになる。
情報の伝達や共有化は、担当者間の業務を円滑にする機能と、トップが担当者を統制する機能がある。多くのトップは「グループウェアによって、情報が多く速く得られるようになった」というような発言をするが、これは後者の機能を重視していることになる。これではトップはよいかもしれないが、統制される側としては本音の情報を入れるのをちゅうちょしてしまう。
また、掲示板を見てコメントを入れたり直接メールするのは、担当者への励ましになると信じているトップがいる。実際にそれにより勇気づけられる担当者も多いが、なかには、トップが見ているのだから迂闊なことはいわないでおこうという行動に出る者もいる。この違いは、担当者個人の性格や組織の文化、あるいはトップへの信頼感などの違いにより生じるが、それを間違うと、推進しようとしたことが、かえって阻害するように働くことがある。
トップが当初に号令をかけただけで、後は全然無関心だというのでは困る。常にフォローすることは重要である。しかし、それも程度問題であり、直属の部門にして常に報告させるとなると副作用が生じる。
ＬＡＮやＣ／Ｓシステムにはトラブルが多い。いかにトップがそれを理解していても、担当者はトラブル報告は好まない。トラブルの原因や対策が明確にならないのがこの分野の特徴である。トップが熱心のあまりそれを問いただすと、担当者は答えられないので、ますます報告するのをいやがる。トップとしては、自分もこのプロジェクトに期待しており、解決に助力してやろうとの意思表示であるのに、担当者は詰問されているように感じてしまうことがある。
これが進むと、担当者はトラブル恐怖症になる。そのために、コストパフォーマンスのよい新機種や機能がよいソフトが出ても、現行のものが安定していることを理由に、採用しないように努力するようになる。その結果、本来は推進部門であるべき情報システム部門が阻止部門になってしまう。
担当者への直接メールやトラブル恐怖症のような機微は、個々の担当者をよく知らないトップには理解しにくいものである。そのために善意による失敗が生じるのである。システム管理者は、トップよりもはるかに担当者をよく知っている。システム管理者は、トップと担当者の間に入って、善意による失敗が起こらないように調整する任務がある。
トップに担当者と直接話をするなと進言するのは難しい。トップはそれをよいことだと信じているし、それを否定するのは管理者の保身だと曲解されることもある。これは、あなたとトップとの人間関係にもよる。直言しにくい状況ならば、トラブル説明はあなた自身がふだんから説明しておくとか、「若い連中は難しいですね」というような婉曲な表現で話題にすることになろう。あるいは、トップとのつきあいの多い部長から話してもらうような工夫が必要になる。
それに対して、担当者にトップの真意を知らせるのは、あなたの任務である。「もっとトップに実際の状況を知ってもらおう。そのほうが自分たちの仕事がやりやすくなる」ことを体験的に説明し、「励まされているのだから、しっかりやれよ」というようにもっていくのがよい。
グループウェアなどを推進するのは、単にコミュニケーションを電子化することではなく、上下の気持を相互理解して、課題や価値を共有化することが目的なのである。それが成功すれば、前回の「先進企業」のような環境に近づくのである。
読者の山田一隆氏（アローシステム顧問）から、ご著書『Ｃ／Ｓシステム開発リーダー２４×２４の現実』をいただいた。「システム管理者入門」とはやや対象が異なるが、システム開発会社でのリーダーの役割と悩みについて、会話調で臨場感あふれる内容である。紙面を借りて氏にお礼を申し上げる。