システム管理者入門（３）

　前回は、ネットワークシステム管理者はトップをうまく操縦することが重要であることを述べた。それに続いて今回から数回にわたり、ユーザをどう操縦するかを述べるが、今回はＣＳＳ環境が技術的に未だ不安定であることの影響について考察する。

１　ＣＳＳ環境は不安定なのだ

　パソコン、ＬＡＮ、サーバなどのＣＳＳ環境が不安定であることは、当事者ならば誰でも痛感していることであるが、あらためて整理してみよう。

（１）神の没落か悪魔の所業か

　レガシィ環境（メインフレームによる集中処理の環境）で育った旧ＳＥにとって、最近のＣＳＳのシステム開発や運用の環境は驚きの連続である。
　Ａ社のブラウザをインストールしたら、Ｂ社のワープロソフトが動かなくなってしまった。Ｂ社のワープロソフトを立ち上げて、Ｃ社のグループウェアを起動するとパソコンがホールドしてしまう。クライアントが５台しか接続していないのに、サーバのレスポンスが悪くなったり、ＬＡＮにトラフィックネックが起こる・・・。
　このような常識では理解できない摩訶不思議な現象がＣＳＳ環境では日常茶飯事である。神の絶対性を信じていた旧ＳＥにとって、これらは悪魔の所業としか思えない。
　レガシィ時代の旧ＳＥにとってハードやＯＳなどの基本ソフトは神であった。ＣＯＢＯＬプログラムを記述して思い通りに動かないときは、ハードウェア、ＯＳ、コンパイラを疑うのは神への冒涜であり、自分の不注意を虚心に反省し、デバッグという懺悔をするのが正しいありかただとされてきた。
　ところが現在では、ハードや基本ソフトはバグがあるのは当然のことと了承している。バイブルであるべきマニュアルは存在しないし、あったとしても、その通りにシステムが動くことがあれば僥倖だと神に感謝するような状態である。オープン化と称して多数の神が和解をしたが、それぞれの教義があるのか、組み合わせて信仰しようとすると、思いもかけない罰をこうむることになる。

（２）誰も頼りにならない

　ＣＳＳ環境は、マニュアルなどは当てにならず、ともかくやってみないとわからない環境なのである。メーカやベンダのＳＥやシステムインテグレータ（ＳＩ）もいるが、それもあまり頼りにはならない。
　まず、ソフトメーカとしての代表格のマイクロソフト社の態度である。マイクロソフト社は自社製品のサポートは自社の任務ではなく、パソコンメーカやベンダの責任だと考えているようだ。ところがパソコンメーカやベンダのＳＥの知識は、ユーザ企業の素人マニアにも遠く及ばない。ましてＴＣＰ／ＩＰなどは、責任母体そのものがいないのだから、文句のつけようもない。
　ＳＩも、結局はやってみないとわからないし、経験したシステムはたかが知れている。自分が経験したハードやソフト、ＬＡＮの構成にして、自分が経験したサーバ管理の方法を提案する。しかも、ＣＳＳ環境の知識は失敗経験を徒弟制度的に習得するしかないので、ＳＩ会社が経験したとしても、自社にＳＥとして来た人が経験していないこともある。
　ところが、ＣＳＳ環境は急速な発展をしており、多様なメーカやベンダの製品を使っており、新製品や新バージョンが次々に発表されるので、その組合せは日常的に変化する。その複合した環境でのトラブルは、到底人智の及ぶところではない。ＳＩといえども経験しない状況での試行錯誤的な仕事になるのはやむを得ない。

（３）しょせん「リセット文化」なのだ

　『日経コンピュータ』(1997.1.6)では、ＮＴによるＣＳＳ環境が未だ不安定であることを「リセット文化」と評したが、これはＮＴに限らずＣＳＳ環境の適切な表現である。
　多くの企業がエンドユーザサポートの一環としてヘルプデスクを設置している。これは非常に有効な手段である。しかし、筆者の知るヘルプデスクでの応対の過半数は「とりあえず、リセットしてやりおしたら」である。これはヘルプデスクが無能なのではなく、おそらくメーカやベンダに問い合わせても同じような状態であろう。状況が千差万別であり、適切な経験例がないのである。
　ヘルプデスクは、状況を記録してＳＩに連絡するが、その結果はほとんど「再現性なし」「有効な対策不明」で戻ってくる。通信レスポンスでのトラブルなどは、データを採取して分析することもあるが、大部分は有効な分析ができずに、試行錯誤的に臨床的措置をするだけで、病理的解決にはならない。試行錯誤でトラブルとは無関係なところもいじってしまい、それが別なときに原因となることもあるし、どさくさでの変更記録が整理されずに、現在の設定状況が誰にもわからなくなり、それが運用管理を複雑にするという副作用を引き起こすことも多い。
　このようにＣＳＳ環境はきわめて不安定な基盤の上に構築されているのである。ダウンサイジングによりコストダウンが図られるというが、考えようによっては安物を使おうというのだから、トラブルが多くなっても当然だともいえる。

２　ユーザをレガシィ文化から改宗させる

　ところがユーザは、長年のレガシィ時代の文化に漬かっており、コンピュータ絶対の崇拝を捨て切れていない。あるいは、それが崩れ去ったことを知ってはいても、その文化のほうが都合がよいので、ＣＳＳ環境においてもレガシィ時代のコンピュータ無誤謬性を要求する。システム管理者は、ＣＳＳ環境の実現に先立ち、ユーザに改宗を迫ることが大切である。

（１）ユーザに現実を直視させる

　ユーザはいままで、レガシィ環境での比較的安定した操作環境と、情報システム部門の手厚い個別処理システムの開発運用体制を享受してきた。ＣＳＳ環境になっても、それと同等の環境を要求するのは当然である。
　ところが、パソコンはＯＳまでいれて２０万円、アプリケーションソフトはあれほどの機能をもったOffice97が３万円である。新入社員の１ヶ月の給料程度のもので、数億円もするメインフレームと同等の品質管理やサービスを期待するのは虫がよすぎる。
　また、レガシィ時代は集中管理だったので、情報システム部門は１台のハードでのシステムを管理していればよかったが、ＣＳＳ環境では数十台の遠隔地のハード環境になる。同じようなサービスをしようとすれば、数十倍の労力が必要になるが、情報システム部門の人数は増加させてもらえないし、そんなことをしたら何のためにＣＳＳ環境にするのか（当然人員削減）の意義を失ってしまう。むしろ、従来よりも情報システム部門を縮小したいのだ。だからサービスが悪くなるのは当然である。
　それを少しでもカバーできるように、現在のパソコンはその能力の大部分（９０％以上？）をヒューマンインタフェースの向上に費やしている。すなわち、パソコンそのものが、名前からもわかりように、自分でやることを前提とした機械なのである。ＣＳＳ環境にしても、その利用するグループで自律的に運営するのがスジなのである。
　そもそも、社員の稼ぎが悪いので、会社が安物しか支給できないし、サービスに人をかけられないのでＣＳＳ環境にするのだ。しかし、安物の割にはよくできており、たいていの時は正常に動くし、あまりサポートもしないでも使えるのだから、これをうまく使えばトクではないか。
　実は、ＣＳＳ環境を推進する前に、ユーザにこのようなことを説明することが重要なのである。それを情報の共有化だの生産性の向上だのと、あたかもＣＳＳ環境にするとユーザが楽になるようなことをいうから話がこじれるのである。

（２）適用業務に注意する

　不思議なことに、ユーザは自律的利用よりも強制的利用を好む。ＣＳＳ環境で基幹系システムのデータエントリをして、すぐにデータが更新されることを期待するし、グループウェアもそれだけで日常活動ができることを欲する。情報システム部門もＣＳＳの実績をあげるために、強制的利用が好ましいことだと受け止める。
　ところが、ＣＳＳ環境は不安定な環境なのである。これが円滑に動かないと業務がストップするようなミッションクリティカルな用途に適用させるために、９９.９９％ではなく１００％の信頼性を持つＣＳＳ環境を維持運営することが至上任務になる。そうなると、ユーザの自主的な利用どころか、ソフトのバージョンアップすら保守的になってしまう。すなわち、ＣＳＳ環境の特質である小回りの良さは放棄されてしまう。
　当然ながら、このような業務をするなというのでない。むしろこれからは、基幹的な業務をＣＳＳ環境で構築することが当然になろう。しかし、それには数倍数十倍の労力と費用がかかることをユーザに認識させる必要がある。

（３）ユーザ趣味に注意せよ

　ユーザは入出力の画面に興味を持つ。最近ではメインフレームのＴＳＳ利用ではなく、ＣＳＳ環境での利用を要求するが、その理由が画面がきれいだからということが多い。この画面偏愛症候群が大きな問題になる。
　最近のミドルウェアやアプリケーションはかなりの表現力を持ってはいるが、その本質は、その機能に業務（趣味）を合わせることを要求している。ところがユーザは従来の個別開発依頼に慣れているので、自分の趣味に合致した画面体裁を要求する。
　たとえば、多次元データベースを利用すれば各種の切り口での集計情報が、ほとんど手を加えずに得られるのであるが、得意先別集計では○○のデザインにし、商品別集計では××のデザインにしてくれと要求する。すると、多次元データベースの出力をスプレッドシートの形式でファイルにとり、それをマクロで変形してというプロセスが必要になるが、それを自動的に行うようにする仕掛けが必要になる。それを汎用的にすることは困難なので、新得意先の追加や商品区分の変更のたびにその仕掛けを変更することになる。これらは特殊な手順になっているので、ソフトの遠隔配布ができない・・・。
　また、ユーザの完全偏執症候群にも注意が必要である。たとえば基幹系システムでメインフレームの製品マスタが変更になったとき即座に情報系システムでのサーバの製品マスタに反映させることを要求する。ところが、ファイルの都合により差分データだけを送り修正するのが困難だとの理由で全データを送りつけるとか、スケジュールが作りにくいのでリプリケーション機能を使おうということになる。その結果、大量のデータがネットワークを走ることになり、通常に利用しているユーザからレスポンスが悪いとクレームがでる・・・。
　これらはユーザが勝手なのではない。ユーザはその副作用を知らないのである。情報システム部門の担当者がそれを指摘するべきであるが、個別の要求が発生したときになって初めてそれを指摘したのでは、しかるべき代替案がなければユーザは承知しない。担当者もいいにくい。それで「とりあえず」要望に応えることになる。するとそれが前例になりので、次にはなおさら断れない。 　このようなことが起こらないように、具体的な要求が起こる前に、ガイドラインを作成するなどして、ユーザを説得しておくのがシステム管理者の任務である。