動かないコンピュータ・フォーラム　第35回 複雑化と不信、不況が運用現場を襲っている 動かないコンピュータ・フォーラム　主宰者 中村　建助＝日経コンピュータ編集

日経コンピュータを読む理由No.1　「動かないコンピュータ」連載が単行本になりました

　「運用」という、重要であるけれども、これまでなかなかスポットの当たってこなかったテーマを「動かないコンピュータ・フォーラム」で取り上げたところ、皆さんからは非常に参考になるご意見をいただきました。

人間はミスをする生き物

　なぜ「動かないコンピュータ」を呼ぶような運用ミスが起きるのか。この疑問に対する正面からの回答を含んだご意見を3件いただきました。

　1件目は8月14日に青島さんからいただいたご意見です。そもそも人間はミスをするということを、交通事故の比喩で的確に説明されています。この下りには思わず「その通り」と思いました。

運用でミスが発生した場合、原因分析・対策・教育といった基本活動を行うことは当然とした上で、ミスは絶対になくならないという立場をとる。どんなに重い罰則や規則を設けても、あいかわらず交通事故は減らない。「これくらいなら大丈夫」「不幸は他人事」という思いに支配される一瞬が必ず存在する。自分の命を守るバックアップ（シートベルト）さえ忘れたり、酒を飲んで運転するのだ。 　それに比べれば、たかがデータのバックアップや伝票の送付忘れなど、どれほどのことか。欠陥ソフトウェアを販売して利益を上げ続ける企業。これらが社会的問題であるなら、何故、法的に責任を問われないのか。損害賠償保険制度が無いのか。シートベルトの着用を義務付け、罰則を設けたら着用率が向上した。罰則を重くしたら、飲酒運転が激減した。悲しいかな、人間とは、そういうものだ。 　情報化社会というシステムを安全に運用したいなら、それなりに法規制が必要だ。そして損失リスクに応じて保険をかける。さもなくば、システムから完全に人間を排除するしかないが、社会というシステムから人間を排除する事はできない。 （システムアナリスト　青島弘幸、40代、ユーザー企業、システム企画部門）

　皆さんもご存じだと思いますが、8月からワーム型コンピュータ・ウイルスの「ブラスター（Blaster）」と「ウェルチ（Weichi）」が日本を席巻しました。これらのワームによって被害を受けた企業、団体のなかに日本郵政公社があります。日本郵政公社がワームに感染した一因は、ベンダーの保守作業のミスによるものでした（詳しくは「郵政公社のブラスター感染はNECの作業ミスが原因――損害賠償も検討」を参照のこと）。

　このベンダーの保守作業員は、インターネットに接続してはならないと知りながら、あるパソコンをインターネットに接続してしまい、その結果郵政公社は、ブラスターに感染することになりました。このベンダーのミスなど、まさにシステムの運用にかかわる局面で信じられないようなミスが起きてしまう一例でしょう。

オープンシステムとコスト節約も運用にはマイナス

　　8月18日には、人間がミスをするということに加えて、システム運用が難しくなっている点を指摘された書き込みがありました。

最近のシステム運用はかつてと比べものにならないほど複雑になっている。運用管理システムも高機能になっている。問題の１つにこのような状況下で運用に人間が介在しなくなっていることがあると思う。これで危険なのは移行や障害などその場で人が考えなければならない異例な運用で正しい判断ができないことである。 　また運用というとマニュアル作成と思われがちだが、確かに重要ではあるが本来運用は考えてやるべきものと思っている。これはマニュアルを無視するということではなくマニュアルどおりにすべきかほかに対応方法があるのかを判断するということである。システムはマニュアルどおりに動くとは限らない。 　システム構築の手法がどれほど発達しても人なしで「信頼できる」運用をすることはおそらく不可能だろう。想定外の事態に正しい判断を下せる人間の不足が問題でありこのような人材を育てていく必要がある。 （30代、システム・インテグレーター、システムエンジニア）

　システム運用が複雑化しているというお話が、まさにご指摘の通りだと思います。利用するシステムの種類の増加やオープンシステムの導入によって、システム運用は一気に複雑化しています。しかも、複雑化するシステム運用を上手に管理する方法はまだ確立していません。

　とある企業では、オープンシステムの利用が本格化とともに、システム運用管理ツールの導入を進めてきました。その結果、今では管理ソフトから毎日1万件近い警告を受け取るようになったといいます。これだけ警告が多いと一々対応していくのは無理です。

　大半は無視しても構わない警告なのかもしれませんが、無視した警告がその後の大きなシステム・トラブルを予告しているケースも少なくありません。システム運用において、予兆を見逃さないことは重要なことだと思います。それだけにソフトを導入しても、予兆の発見に十分に役立てることのできない現状には大きな問題があると考えます。

　8月13日には、不況を背景とするシステム・コストの節約が現場に与える影響についてのご指摘がありました。前回のフォーラムで、システム・コストの節約と動かないコンピュータの関係について取り上げましたが、コストの削減による人材の質の低下による悪影響は、運用部門にまで及んでいるようです。

様々な例題が挙げられているが、結局は運用フェーズの軽視が原因のように思う。元来、大昔からプログラマはプログラミングフェーズを中心に考え、実際のプログラムが使われる現場を考えない傾向があった。これに対し、運用時のオーバヘッドや手間、経費の削減などの観点から実際に使う現場を考えた設計をすることが常々叫ばれてきたように感じている。 　ここに来て、開発費のデフレと外注化が原因で実際の現場が考えられない未成熟なプログラマが増え、一方、経費の節減を安易にアウトソーシングに頼ろうという風潮（臭い物でも枯葉をかければ見えない？）が拍車をかけた感がある。本来、プログラマは自らの考えた仕様（実際の現場とは乖離しても）に執着する傾向がある。そこから、運用などの開発後のフェーズを重視させるには、日々のフィードバックとOJTを含めた教育しかない気がする。それでも本人が痛い目にあわないと、なかなか理解させることは難しい。 （40代、システム・インテグレーター、システムエンジニア）

　第34回の「運用ミスと動かないコンピュータについて考える」でもアウトソーシングの失敗例に触れましたが、アウトソーシングは決してすべての問題を解決する魔法ではありません。アウトソーシングについては、いずれこのフォーラムでも考えてみたいと思っています。

やはり重要なのは上流からの対応

　では、どうやって運用ミスによる「動かないコンピュータ」を減らすのか。もちろんすべての運用ミスをなくす解決策はないが、やはり有効なのは上流工程からの対策、事前の準備のようです。

　8月28日には冨田さんから、運用設計の重要性について触れられた書き込みがありました。

システムを開発するときに何が重要視されているかというと、「作ること」になっている。運用設計は後からやればいいという具合に軽視、あるいは無視されていないだろうか。システムは作るために作るのではなく、使うために作るものである。貴誌の「運用は最上流工程」という内容の記事を読ませていただいたときは、同感だった。 　コスト削減を目的にアウトソースするのは一つの考えだが、アウトソースしたプロセスを依頼側でどう管理するかが大切であり、依頼側の責任でもあるだろう。アウトソースは俗に言う“丸投げ”とは違うと思う。 （冨田洋一、40代、システム・インテグレーター、情報システム部門）

　冨田さんがご記憶されている記事は、本誌2002年11月14日号に掲載した特集「運用部門こそ“主役”」のことだと思います。本誌の記事の内容を記者が評価するのはおかしいかもしれませんが、「運用設計」は現在のシステム開発全体に大きな意味を持つことだと思います。

　8月12日には、危機管理の視点を盛り込んだ運用を忘れてはならない、というご意見をいただきました。

記事のようなミスを無くすには、やはりシステムのカットオーバー以前に可能な限りの障害パターンに対する処方や漏れが無いかを、可能な限りの手段で確認することしかないと思う。カットオーバー以降、なんらかの問題点が発生し、それから対策を考えていた場合、全く余裕が無くなってしまう。 　また、システムの変更には細心の留意を払い、データのバックアップや問題が発生した場合の復旧方法を網羅し、手順を定めて置く事が必要。現状、各ユーザも予算・コスト削減が至上命題のようになっているが、こういった準備に要する予算は、設計段階で確保するくらいに重要度が高いと思う。 　また、運用に悪影響を与えるものなら、上司や上位上司、役員位まできちんと説明し、必要な対応を取る位でないと問題は必ず発生してしまうと思う。システム部門は、企業に取っての真の命綱を握っているという自覚を持って作業にあたって欲しい。それは、ベンダを選択する際も同様である。 （30代、システム・インテグレーター、コンサルタント）

　面倒で人に評価されにくいことかもしれませんが、こういった危機管理の基本を徹底することが、「動かないコンピュータ」を減らす上で重要なのは言うまでもないことです。日経コンピュータは、これからも「運用」にこだわっていきたいと思います。