皆様こんにちは。今回から本コラムを担当させていただくことになりました伊藤と申します。

これまで自動車製造業でのシステム管理、運用部門の管理者をはじめ、IT予算管理、J-SOX、セキュリティ対策対応などをしてまいりました。

今回、「システム運用設計」というテーマを頂きましたが、運用設計自体は様々な書籍や教育コースもあります。従いまして今回は、「システム運用設計」で織り込むことや、運用管理とシステム開発の関係など、少し枠を広げて、私の実経験などを踏まえてお話してまいりたいと思います。

第１回は、「障害対応からの障害低減への脱皮」です。

 

目次

システム運用部署の第一印象

システム運用部署の仕事は障害対応だけだろうか

システム開発部署や、ユーザー部署をまきこめ

次回予告

システム運用部署の第一印象

私は、２００９年１月から２年間、当社の情報システム運用部署を担当していました。それまでは、主として技術情報システムの開発、全社情報システムの総括分野を担当していましたので、車両生産システムを含めたシステム運用は初めての領域でした。

さて、初めて運用現場で見たものは、障害回復で走り回っている担当者の姿でした。それは、まるで「障害対応こそ我々の仕事」という雰囲気です。日夜たがわず、大変苦労をして全社のシステムを運用管理している彼らがいるからこそ、当社は仕事が回っていることを実感いたしました。

私の自席とシステムの運用場所が離れていることもあり、私は毎朝一番最初にオペレーション室に行くことにしておりましたが、毎回といっていいほど何らかの障害対応でバタバタしていました。

車両生産システムのトラブルは、放置すれば生産ラインの停止につながり、そのようなことになると、工場の全生産作業員が仕事をできなくなるので、会社としては大きな損失が発生いたします。

又、昨今は電子メールや社内ポータルが業務のインフラになっており、これらが機能しないと苦情や問い合わせが殺到してまいります。

このような状態をしばらく見ておりましたが、その中で、私には疑問が浮かび上がってまいりました。それは、「障害は本来あってはならないもののはずではないのか。障害対応＝自分たちの仕事と思っていて、『障害があるということが問題である』という事にみんな気付かなくなっているのではないのか。」ということでした。

 

システム運用部署の仕事は障害対応だけだろうか

弊社のシステム運用の仕事として、システムの本番移行、システム稼動スケジュールの管理、稼動環境の維持管理、システムの稼動管理というものがあります。たしかに、障害対応（＝稼動管理の一部）以外にも仕事はございます。

前項で、「…『障害があるということが問題である』という事にみんな気付かなくなっているのではないのか。」と申しましたが、障害対応ばかりしていますと、そのことが得手になり、復旧時間は短くなってまいります。それはそれで、結構なことではありますが、それでいいのでしょうか。

障害対応について、システム開発部署に改善などについて相談しても「システム開発で手一杯で対応できない。」とか、「ユーザーの入力ミスだから自分たちは関係ない。」などという言葉が返ってきたり、中には「トラブル対応のために運用部隊がいるのだから、きちんと対応してほしい」という開発者もいました。

運用担当者は、各システムの弱点（入力ミスが起きやすい、データ量の変動が多く中間ファイルサイズがオーバーし易い　等）や管理点（ユーザー部署の担当者が交代するとしばらくトラブルが続くので、注意する）などを実によく知っています。

これらのことから、運用部署は、システム障害が発生したら、どうしたら再発防止できるか。また、いかにしたら障害が発生しにくいシステムできるか。そのことを実感できる最前線だということがわかります。

私は、せっかく持っているこれらの情報を活用しない手はない。と考えました。障害対応作業は、マイナスの状態を正常に戻すだけで、新たな付加価値を生み出しているわけではありません。システム運用の担当者にも、ぜひ付加価値のある仕事をして欲しかったのです。

 

 

システム開発部署や、ユーザー部署をまきこめ

付加価値のある仕事としてシステム運用部署ができることは、大きく二つあると考えています。

一つ目は、先ほどから申し上げている、システム障害を減らすことです。
二つ目は、システム仕様決定時に、運用の知見からシステム障害の芽をつぶすことです。

 

私はまず、一つ目のシステム障害を減らすことから始めました。

障害を減らす　ということは、　一言でいえば再発防止なのですが、これが一筋縄では行きません。システム運用部署だけでは解決できないからです。障害の要因を調べると、運用のミスやハードウェア障害だけではなく、ユーザーの入力データの間違いから、システム内処理、関連システムとの関係など、様々な部署が絡んできます。

このため、「システム障害の見える化」を行いました。ちなみに、弊社の属する企業グループは、この「…の見える化」ということばをよく使います。これは、問題などの発生状態や対応状況を誰でもすぐ判るように情報共有することを意味し、全員で問題解決に取り組むためのツールです。

具体的には、障害発生時に、情報システム部員全員に発生を伝えることと、見える化ボード（横軸に日付、縦軸にシステム名を並べて大きな表にし、障害が起きたシステムと日付の交点にマークをつけ、障害対応状況｛暫定対策、復旧、要因解析、再発防止対策完了｝毎にマークの色を変える）の活用です。

加えて、それまで自分たちの要因で無い部分は、他責として管理外にしていたものも、ユーザーやシステム開発部署での対策実施までフォローするようにし、これを部長管理としたわけです。

 

この活動の結果、ユーザー部門と再発防止の検討を行う中でユーザー目線によるシステムの入力仕様の改善が提案されるようになりました。

またシステム開発部署では、システム開発過程のどこでチェックすれば、発生した障害を防げるのかという見方で検討が行われ、障害発生したシステムだけでなく、それ以外のシステムでも類似障害の発生を抑えることができる体制が構築されるようになってまいりました。

 

以上の取り組みの結果、私が担当していた２年間でも、システム障害は７割減と大幅に低減できましたが、それに加えて、障害を起こしにくいシステムの開発体制が構築できてまいりました。

つまり、二つ目の「仕様決定時に、運用の知見からシステム障害の芽をつぶすこと」が同時並行で推進できていたのです。

加えて、システム運用者の意識も変って参りました。これまでは、受身の意識のようなものなかで仕事をしてきていましたが、障害を見る目が変り、改善提案が行われるようになって、積極性がでてまいりました。これは、システム運用の担当者一人ひとりが、自分たちの仕事の意味を考えるようになったためではないでしょうか。

 

次回予告

次回は、「障害を起こしにくいシステムの開発体制について」お話をしたいと思います。