TOP>企業情報>コラム>お客様の声>NO.13 宇部情報システム

NO.13 宇部情報システム

ITILという言葉が出る以前から、システム運用の価値を高めるために、「見える化」による情報共有基盤の構築や、それを発展させた「情報活用」への取り組みを行う宇部情報システムのお二人に、運用にまつわる話題を幅広く聞いた。

Guest Speaker
株式会社宇部情報システム
営業本部 山口営業部長
猪八重 雅夫 氏

情報処理サービス部
運用技術グループ
登根 浩 氏


1. 宇部情報システムの概要


宇部情報システムの概要についてお聞かせください。

宇部情報システムは、宇部興産の情報システム部門が、1983年に、分離独立してできた会社です。宇部興産は、化成品、機能品、建設資材、機械・金属成型、エネルギー・環境等などに強みを 持つ製造業グループです。創業は明治30年にさかのぼります。いわゆる老舗の製造業です。2005年度の売上げは5953億円でした。

宇部情報システムは、主な業務として、宇部興産グループの情報システムを構築、管理しています。したがって、製造業まわりの情報システムには強みがあります。

2. 宇部情報システムはアシスト製品をどう活用しているか


社内情報システムにおいて、アシストから購入した製品はどのように使われていますか。

現在は、運用支援ツール JP1、レポートツール WebFOCUS、セキュリティ対策ツール 秘文の三製品をアシストから導入しています。

2000年に全社基幹システムをERPパッケージ「SAP R/3」で再構築し、電子帳票システムを含むR/3を中核とした基幹システムを、JP1を使って運用してきました。

さらに、より効率よく運用を行うために、WebFOCUSを使った情報活用の仕組み作りを進めているところです。

3. 宇部情報システムが運用においてISOを取得した理由


運用においてISOを取得した経緯についてお聞かせください。

1999年に弊社の開発部隊が、先行してシステム設計やドキュメント制作・管理の分野でISO9001を取得しました。開発部門ではそのように業務管理が進行しているのに、運用部門だけが、いつまでも属人的であってはならないと考えたのが発端です。

それまでのシステム運用は、極論すれば、「行き当たりばったり」、「火事が起きれば火消しをする」という方式で進行していました。また、組織的な対応も未発達であり、基本的には「個人の判断と作業」で対応していました。つまり、対応の記録も残らず、その人がいなくなれば記憶もなくなるという属人的な世界でした。しかし、ISOの取得に合わせ、計画策定、ドキュメント作成、審査、承認という業務手順を踏むことにより脱俗人化を果たし、こうして運用部門も2004年にISO9001を取得しました。ITILや内部統制などのキーワードが市場を賑わす以前のことです。

運用でISOを取得するにあたり困難だったことはありますか。

ISO9001は基本的に開発寄りの規格だったので、それをどう運用に引き寄せるかに腐心しました。開発部門用に整備されたやり方を、運用部門用に「翻訳」する努力を続けました。

4. 運用にツールを活用するにようになって、何が変わったか


現在、JP1やWebFOCUSを使って、運用のシステム化を進められていますが、かつてと今とで変わった点は何ですか。

総合的な情報共有が進んだことが最大の変化です。

ISOを取得した後も、結局、運用の「情報共有」は進みませんでした。社内にシステムA、システムB、システムCとあった時、運用は各システムで完結しており、システム間で情報が共有されることはなかったからです。

現在、JP1を使うことによってシステム運用「全体」の情報共有がなされるようになりました。個々の担当者は、自分が担当しているシステムの運用状況を把握できます。管理者や上司は、メンバー全体、システム全体の運用状況を鳥瞰的に把握できます。このように、情報共有が進んだ結果、各個人にかかる負荷、言いかえるならば、「属人性に起因するトラブルに対する脆弱性、ボトルネック」が大幅に減りました。

このJP1による情報共有を進める流れをさらに押し進めるために、WebFOCUSを導入しました。JP1に蓄積されたデータを、WebFOCUSを使ってわかりやすく「見える化」しようという考えです。

5. 運用部隊の次なる課題


現在の運用部隊の課題は何ですか。

運用の価値を社内に知らしめることですね。

利用部門にとってのシステム運用は、今なお「宿直室」のイメージがあります。「システム運用部門が24時間待機しているといっても、それは宿直室で雑誌を読みながら待機しているようなもので、何かアラートが起きたときだけ、スポット対処しているのだろう」という解釈です。それは、一昔前の運用であり、今はもう違います。

運用を確実に行うことが、会社全体、経営全体にどのように貢献するのか、定量的に示せねばなりません。JP1やWebFOCUSの活用も、「運用の価値」を定量化する努力の一環です。

6. 運用の価値とは


少し抽象的なことを聞いてみたいと思います。「運用の価値」は何だと思いますか。

「運用の価値」は「予防医学の価値」に近いと思います。予防医学においては、病気になってから病気を治療するというのではなく、普段から食べ物に気をつけ、姿勢に気をつけ、最初から病気にならないよう生活するための医学です。

同様に、いったん開発したシステムが、いつまでも順当に稼働し続けて、利用部門の役に立ち続けるよう、普段から目を配り、気を配り、手当てをすること。それがシステムの運用だと思います。

7. 汎用機の時代に、「運用」の概念はなかった


運用」は、以前に比べ、だいぶ重要視されるようになりました。この変化の原因は何だと考えますか。

運用の価値が向上した背景には、「汎用機 → オープンシステム」という変化があるでしょう。極論すれば、「運用」が重要になったのは、オープンシステム以降であり、汎用機の時代には、「運用はなかった」とも言えます。
「汎用機の時代には『運用はなかった』」とは具体的にはどういうことですか。

汎用機時代のシステム保守は、「運用」というより「操作(オペレーション)」と呼ぶべき作業でした。ダム端末から、汎用機メーカー指定のバッチを起動して、出力された結果をプリントアウトして、社内に配布する。このルーチン作業は、今日の「運用」とは性質を異にします。

また、汎用機時代の「運用」は、すべてメーカーがやっていました。われわれ発注側は、いわゆる「丸投げ」をしていました。

汎用機のような大規模なシステム体系は、いったん構築が完了し、運転が始まってしまえば、使用者側である我々が、システム構成に手出し、口出しできる部分はほとんどありません。だから「丸投げ」以外の契約形態はとりたくてもとれませんでした。

丸投げにも良い点はあります。汎用機の頃は、責任の所在が明確でした。システムにトラブルが起きた場合は、汎用機メーカーが責任を持って復旧してくれました。

平たく言いますと、当時は、発注者側の情報システム部門には、「責任の持って行き先」があり、汎用機メーカー側に「逃げ道はない」という、構造でした。

汎用機メーカー側も、したたかです。普段から巨額の保守費やSE支援費用を請求していました。また、不要のトラブルを発生させないよう、自社製ハードウェア、自社製ソフトウェアだけの閉じた体系でシステムを構築していました。なるべく安定稼働が続くよう、ソフトウェアやハードウェアの部分更新やバージョンアップも、最小限にしていました。

しかし、オープンシステムの普及に伴い、状況は変わりました。

8. オープンシステムの普及が「運用」の必要性を加速させる


「オープンシステムの普及に伴い、状況が変わった」とは具体的には。

オープンシステムにおいては、ハードウェアやソフトウェアは、一社に統一されることなく、数社のものを組み合わせて構築します。OSやミドルウェアも複雑に絡み合います。

システム相互の連携は"いびつ"であり、システムトラブルも汎用機の時代に比べて、頻発するようになります。「システム相互の相性」という問題も発生してきます。

オープンシステムは、「コスト」と「柔軟性」に優れているものの、「安定性」においては汎用機システムに劣っています。

したがって、オープンシステムを安定稼働させるための「運用」がクローズアップされてきたのだと考えます。もう丸投げはできません。システムを安定稼働させるには、自分で頑張らねばならないのです。

9. オープン化が進むにつれ、運用は、どのように困難になったか


「オープンシステム化が進むにつれ、汎用機の時代に比べ、運用が困難になった」ということについて、具体的なエピソードがあれば、お聞かせください。

SAP R/3基幹システムの運用を行う中で、「やっぱりややこしいなあ」と感じるエピソードがありました。

SAP R/3基幹システムを2000年にカットオーバーしました。当初は、R/3ネイティブのバッチを、R/3のクローズな環境の中で動作させていただけでした。このようなクローズな環境は、汎用機の単一環境に近いものです。運用の仕事はあまりありませんでした。単に「操作」を行うだけで十分でした。

しかし、R/3と、周辺システムの接続、連携が進むにつれ、運用の困難が生じてきました。

この場合、R/3のジョブを、周辺システムのジョブと連携動作させねばなりません。しかしR/3と、周辺システムとでは同じジョブでも実装体系、管理体系が異なります。

ここで、数種類のジョブを一つの体系で管理する「運用」の必要が生じたのです。

最近は、R/3ネイティブのジョブと、周辺システムの非ネイティブのジョブを一つのカプセルに入れて、統一管理するようにしています。

10. 「システム開発」と「システム運用」の仕事としての性質の違い


「システム開発」と「システム運用」の仕事の性質の違いは何だと思いますか。

今、思い浮かぶのは以下の3点です。

  ・開発は「集中」だが、運用は「継続」である。
  ・開発では「演繹的に正しいことが重要」だが、運用では「帰納的に正しければ」良い。
  ・開発は「見えやすい」が、運用は「見えにくい」(だから「見える化」が必要)。

11. 違いその1:開発は「集中」だが、運用は「継続」である


開発は「集中」だが、運用は「継続」であるとは具体的にはどういうことでしょう。

システム開発は、設計して、プログラミングして、カットオーバーするまでの間は大変です。しかし、いったんカットオーバーすれば、「一応の区切り」がつきます。

運用においては、開発のような「繁忙ピーク」はありません。そのかわり、毎日、根気強く、システムを監視し、改善し、PDCAサイクルを回さねばなりません。

開発の肝は「集中」、運用では「継続」が重要である気がします。

12. 違いその2:開発では「演繹」。運用では「帰納」


次に、開発では「演繹的に正しいことが重要」だが、運用では「帰納的に正しければ良い」とは具体的には。

開発は、システム「構築」と言われるように、基本的には、建築物のように根本から論理的に「演繹的に」正しく築き上げるものです。

一方、運用には、「こうすれば上手くいく(理由はよく分からないが)」という「帰納的に正しければそれで良し(結果オーライ)」の側面があります。

まず「結果オーライ」を獲得し、その後で、上手くいった要因を分析し、それを元に「より良い方法(または、より上手くいく確率が高い方法)」を模索するわけです。

PLAN、DO、CHECK、ACTIONのPDCAサイクルに、GOD(神頼み)を入れる必要もあります。半ば冗談ですが、半ば本気です。

弊社のマシンルームの中の、ある重要なハードウェア。そこに、そのメーカーの技術者が「お札」を貼り付けました。気持ちはわかります。

もう一つ余談。オープンシステムのような「自由度や柔軟さを許容している技術」と対極にあるのが、電話交換機の世界。完璧性の高いエンジニアリングの代表格です。しかし、そこでも、理論を超えたオカルト現象が起きることがあるそうです。

ある電話交換機において、いくつかの使用条件が重なると、設計上の理論的限界の「1割増し」の能力が出ることがあるそうです。1割減ではなく、1割増しです。この話を本で読んだとき、不思議な気持ちがしました。

13. 違いその3:「開発は「見えやすい」。運用は「見えにくい」。


最後に、開発は「見えやすい」が、運用は「見えにくい」とはどういうことですか。

システム開発においては、プログラムという「成果物」があります。一方、運用には、明示的な成果物がありません。

社内や社外に活動の成果をアピールしにくい分野とも言えます。だからJP1やWebFOCUSを導入したわけです。

JP1が持つ運用情報をWebベースに公開する仕組みは、WebFOCUS導入以前から実装していました。検索・一覧表はASP、グラフはExcelを利用して運用現場のメンバーが独自に開発した仕組みです。ところが運用に対する要求は、システムやテクノロジーが増すごとに複雑となり、かつスピードも求められるようになりました。

これらの要求への対応で独自開発した仕組みのメンテナンスに追われる日々も増え、本業である運用、共有、改善に手が回らないという状況に陥りました。これを解決するツールとして、簡易レポート開発ツールWebFOCUSに目をつけた訳です。ほぼGUI操作のみで構築できるWebFOCUSによりシステム構築は元より、メンテナンスやスポット的な要求事項に迅速かつ柔軟に対応できるようになったと言えます。

と同時にJP1データを取り込み、ASPでデータ入力、WebFOCUSで見せるという体系のシステムへの発想が生まれ、当時、運用ビジネスで注目を集めていたITIL思考を取り入れ、運用状況の見える化システムの構築へと発展。さらに社外にも展開するべく、開発部門を巻き込んだ強固なシステム開発に取り組んでいます。


14. アシストへの評価


アシストへの評価をお聞かせください。

アシストは、「対応の迅速さ」、「相談のしやすさ」、「提案のニュートラルさ」の三点において評価しています。

第一に、「対応の迅速さ」。問い合わせへの回答が迅速です。一つのエピソードがあります。ある製品Aの、ある問題について、製品Aのメーカーとアシストとに同じ質問を同時に投げたことがあります。2社から返事が来ました。回答内容の質はさほど変わらなかったのですが、スピードはアシストの方が断然早かった。「メーカーと同等の質の回答を、メーカーよりも早く返してくる」。すごいと思いました。

その製品Aは、昔は、メーカーから直接購入していました。でも今は、アシストからの購入に切り替えました。

第二に、「相談のしやすさ」。アシストは相談しやすい会社です。メーカーによっては、一つ相談をするにも「まず環境説明書を書いてください」と官僚的に対応してきます。こちらは、ちょっと相談したいだけなんですけどね。一方アシストは、面倒な手続き抜きに、気軽に話せるので好きです。

第三に、「提案のニュートラルさ」。アシストは、特定のメーカーに依存せずにニュートラルな提案をしてくれるのが良いです。

『お客様の声』で、M&Cシステムさんが「アシストの提案は断りやすい。だから良い」とおっしゃっていましたが、我々も同感です。断りやすいことと相談しやすいことは表裏一体です。

15. 今後の期待


最後に一言お願いいたします。

宇部情報システムでは、「運用=予防医学」という考えで、今後も宇部興産をはじめとするお客様のシステムを「健康体」に保ちたいと考えています。アシストには、今後もユーザ寄りの姿勢、提案力、サポート力という、今の良さを失わないようにして、より一層のご支援を期待いたします。




取材日時:2007年6月

現在、宇部情報システム様でご利用いただいている製品、サービス
  ・統合運用管理ツール
  ・セキュリティ・ツール
  ・BIツール
  ・Webレポーティングツール
  ・各種保守サポート


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る