TOP>企業情報>コラム>お客様の声>NO.42 シス・コンピューティング

NO.42 シス・コンピューティング

シス・コンピューティング株式会社(以下、シス・コンピューティング)は、西部ガス株式会社(以下、西部ガス)の子会社「西部ガス情報システム株式会社(以下、西部ガス情報システム)」の運用部門が独立し、2000年に設立されました。運用サービスの提供を主業務とする同社は、従来の運用業務をまわす、こなすという姿勢から、付加価値のあるITサービスを提供するという姿勢へ、運用部門の変革に取り組みました。

Guest Speaker
シス・コンピューティング株式会社
常務取締役 運用本部長 日野 裕人 氏

運用事業部長 秋山 泰志 氏
(2010年6月末まで同職
現、西部ガス情報システム株式会社、 
グループソリューション本部開発部長)

運用事業部 導入グループ 山田 俊輔 氏


1. シス・コンピューティングとは


まず、シス・コンピューティングについて、教えてください。

シス・コンピューティングの親会社の西部ガス情報システムは、西部ガスの情報システム部門が独立した会社です。そのため、まずは、シス・コンピューティングの親会社の、さらに親会社である西部ガスについて説明します。西部ガスは、福岡県、熊本県、長崎県の合計16市16 町112万戸(2010年3月末現在)のお客さまにガスを供給している会社です。供給戸数は、東京ガス、大阪ガス、東邦ガスに次いで業界第4位です。

1986年に西部ガスの情報システム部門が、多角化の一環として西部ガス情報システムとして分離独立しました。当初、西部ガス情報システムは設計/開発から運用まで、システムに関する業務はすべて請け負っていましたが、設計/開発と運用とでは元来、異質の作業特性を持つものです。

そこで、業務効率の改善およびコンピュータ運用のアウトソーシングを積極的に展開するために、2000年、西部ガス情報システムの運用部門がシス・コンピューティングとして独立しました。

シス・コンピューティングの強みはどこにありますか。

ガス供給という公益事業のシステム運用を支える会社として、ITを社会的ライフラインとして捉え、安定性や確実性を強く意識していることです。そうした自社の立ち位置を、社員全員が明確に認識しています。また西部ガス・グループの大規模なシステム運用を通じて培ったノウハウや豊富な経験を生かし、汎用機やWindowsなど様々なアーキテクチャに対応したシステム運用を得意としています。

2. なぜ運用改善に取り組んだのか


ではまず、「運用改善への取り組み」について伺います。2007年から運用改善に取り組まれたとのことですが、その背景について教えてください。

背景としては、2つあります。まず、一般的に運用業務は、サーバの監視やシステムの保守といった、「今あるもの」が「これまでどおり動く」ことをサポートすることが目的です。そのため、取引先や関係部門から「指示されたことを行う」ことが最優先とされていました。正常に動くのが当然と思われているため、何らかの障害が発生すると、運用部門は、マイナス評価を受けがちでした。

必然的に、運用担当者のやる気が低下し、専門家としての創造性やチャレンジ精神もあまり見られなくなっていました。メインフレームの時代には、運用担当者は専門家として、障害が発生した時も「克服する」という意識で対応し、様々なことに誇りを持ってチャレンジしていました。当時を知っている者として、若い運用担当者のやる気が低下していることに驚きました。

もう1つの背景について教えてください。

シス・コンピューティングの請け負う仕事は、すべて西部ガス情報システム経由になるため、親会社の指示に従っていればよいという受け身の姿勢が強くなっていました。その結果、運用に関する権限も、西部ガス情報システムの運用部門として活動していた時よりも縮小していました。しかも、親会社からの出向社員が多くいるため、無難に仕事を済ませればよいという雰囲気もあり、自分たちで何かを考え、提案するという積極性に欠けていました。このような社員の意識を打破しない限り、運用の品質アップは望めないと判断しました。

3. まずは基礎固めからスタート


運用改善はどのようなステップで進められたのですか。

まずは基礎固めとしてITILをベースとした標準化の推進を行い、次に全体最適化の観点から運用品質全体を向上させるためにISO/IEC 20000※1の取得と、また個別最適の観点から「性能管理への取り組み」を並行で進めました。
1つずつ伺います。まず基礎固めのフェーズについて、詳しく教えてください。

当時は、シス・コンピューティングは何ができるのか、世間一般のシステム運用会社と比較して、自社のサービスがどの程度の品質なのかすら分かっていませんでした。自社サービスの品質アップのためには、まずは実態を把握する必要がありました。

「運用とは何なのか」という定義付けから始まり、その中での我々の使命、役割は何かを見つめ直しました。個人の業務を振り返るために「業務の棚卸し」を実施し、品質とは何かを考える機会を作りました。具体的には、以下の3つの施策を実施し、(1)運用の再定義、(2)標準化の再整備、(3)プロセスの再構築を行いました。

(1)運用ポリシーの策定と理想の運用人の定義(運用の再定義)
(2)運用管理規定、マニュアル、ドキュメントの再整備(標準化の再整備)
(3)「ITIL」を取り入れた業務プロセスの再構築(プロセスの再構築)

運用ポリシーでは、担当者の心構えを定め、ガスの安定供給をシステム面で支えていることを強調し、自分たちの仕事はライフラインと密接に関連することを理解してもらえる内容にしました。次に、運用担当者として前向きな意識や誇りを持てるよう「理想の運用人とは」という文書を作成しました。

運用管理規定やマニュアルも変更しました。誰が実施しても、ある一定の品質レベルの仕事を維持するための活動です。人によって成果や品質が左右されると、組織としても問題であり、また、その結果、柔軟なローテーションができなくなり、社員の新しい可能性の芽をつむことにもつながります。担当者の属人的な運用にならないよう、運用ルールを文書化して、各プロセスを可視化できるようにしました。

そして運用業務をITILの考え方で、個々のプロセスに細分化し、プロセスごとの担当者を決め、管理者ではなく、担当者を中心に改善活動を推進するという方針に切り替えました。「ITIL」に基づき、業務プロセスを再構築したのです。副次的な効果として、業務プロセスをきちんと整備したので、内部統制にもスムーズに対応できました。

※1:ISO/IEC 20000
ITサービスを提供する組織のITサービス・マネージメントが適切であるかどうかを評価するための国際規格。ITサービス・マネージメントのプロセスについて記述したもので、認証の直接の対象はITシステムごとのITサービス・マネージメントシステム(運用サービス管理)。

4. 全体最適化の観点からISO/IEC 20000を取得


次のステップとして、ISO/IEC 20000の取得と性能管理を並行して進められたとのことですが、最初にISO/IEC 20000認証の取得を目指された理由について教えてください。

基礎固めのフェーズが終わり、社員が自分たちの業務を真剣に改善する気持ちで取り組むようになるなど意識の変化が見られました。ITILという新しい考えで業務を振り返るようになり、一応の成功を見た、ということになります。しかし一方で、プロセス単位に標準化を進めたために、プロセス単位の完成レベルにバラツキが生まれました。さらに、プロセス間のインターフェースが整理できていなかったので、実作業において、プロセス間のつながりが非効率な場合がありました。

せっかく芽生えた改善活動の取り組みですから、継続的、発展的にしたかったのです。トータルに安定した運用品質を目指そうと取り組んだのが、ISO/IEC 20000認証の取得です。この認証取得を目指したことで、上司や社員が一体となり、我々は何をするのか、何に挑むのかが明確になりました。また、認証を取得することにより、運用を安心して任せられる会社であることをお客さまに理解していただくことを目的に取り組みました。結果的に、都市ガスの情報子会社としてはどこよりも早く、2010年にISO/IEC 20000を取得することができました。

5. 性能管理レベルアップへの取り組み


性能管理にも取り組まれたということですが、その理由について教えてください。

ゴルフで例えるならば、スコアで100を切るという目標を掲げ、得意なクラブ、不得意なクラブを分析し、不得意なクラブはより練習量を増やします(基礎固めのフェーズ)。それは、100を切るにはトータルで安定的にどのクラブも振れるようにならないといけないからです。練習の甲斐あって、その目標が達成できたとします(ISO/IEC 20000認証取得)。

すると、レベルアップのための新たな目標として、次は90を切りたいと思います。そのためには、ドライバーの飛距離を伸ばす等の得意分野を作り出すとか、または、中途半端な距離を補完するために、ユーティリティ・クラブを新たに導入するとか、新たな試みを創造する工夫が必要です。それが性能管理の取り組みだとお考えください。

強化ポイントとして、なぜ性能管理分野を選んだのですか。

安定したサービスを提供し続けるためには、現在の運用状況、すなわち、リソースの使用状況や負荷状況を正確に把握することが必要です。使用しているハードウェアやソフトウェアのスペックから予測値としての性能数値は計算可能です。しかし、実際に稼働させて、そのログ・データを取得しない限り、実運用状態での使用率や負荷状況は分からないのです。シス・コンピューティングには、当時、そのデータを取得する仕組みがなく、性能を分析するスキルもありませんでした。結果、性能に関する障害が発生してもデータを取得していないため、場あたり的な対応になっていました。また、トラブルが顕在化してから気づくというのも問題でした。そこで、性能管理を強化する必要があると考えたのです。

さらに上を目指されるということで、周りに対してはどのようなアプローチを取られましたか。

周りから、「なぜ、性能管理プロジェクトに費用をかけるのか」「今の運用を維持していればよいのではないか」との質問を受けたのは事実です。しかし、背景にある事情や効果をどのようにフィードバックできるのか、問題を未然に防ぎ中長期に渡る安定稼働を実現したい、という意向を伝えるとともに、「性能管理プロジェクト」の目標としてCOBIT※2のレベル4を目指すことを丁寧に説明することで納得してもらうことができました。

※2:COBIT(Control Objectives for Information and Related Technology)
自社の情報システムを適切に構築/活用するための基準を示す、ITガバナンスの成長段階を測るための国際的な規格。IT関連業務を34のプロセスに分類している。

6. COBIT4を目指す


COBITのレベル4がどのような内容か教えてください。

当時のシス・コンピューティングの性能管理は、ITガバナンスのフレームワークCOBITに照らし合わせると、レベル1、つまり一部のスーパーマンに運用を頼っている状態でした。しかし、性能管理以外の運用プロセスは、運用改善の基礎固めの結果、レベル3まで完了していました。「ITサービス・マネジメント体制」の確立により標準化が完了し、手順が整備され、それに基づく運用が実施されていたからです。

そこで次は、遅れていた「性能管理」を強化すべく、まずはレベル3を達成し、さらに次のレベル4を目指すべく「性能管理プロジェクト」を発足し、取り組みました。レベル4とは、サービス・レベルと実績値とを比較するプロセスとツールが用意され、標準化された最新の統計情報が利用できるとともに、問題の警告が可能な状態です。レベル4を実現することにより、必要なデータを収集でき、目標の達成を評価できる「性能管理システム」の実現を目指すことにしました。

「性能管理システム」の具体的な内容について教えてください。

性能管理システムとは、ツールの導入により、サーバのリソースを監視し、性能データを収集し、蓄積します。そして、データを分析/評価し、問題がある場合、またはいずれ顕在化する問題について、関係部署に提起し、設備増強などを提案する一連のプロセスのことです。また、問題の有無にかかわらず、性能データを「性能レポート」として、定期的に上位者や関係部署に提出し、状況を報告します。

そして、ここで言う「システム」とは、単なるツールの導入ではなく、社員、仕組み、ツールの3つの歯車が有機的に回っている体制を指します。最も重視したのは、ツールの導入で解決しようとするのではなく、社員や運用方法を含めた「全体的な体制作り」を目指したということです。

まずは社員を教育して、意識改革を図らない限り設備増強や性能のボトルネックの発見による提案などを積極的に行うことはできません。しかし、教育するだけでは提案のノウハウが属人化してしまい、社員によって差が出る可能性があります。そこで、こうした体制を作って提案のプロセスを平準化しました。また、実際に提案を準備しようとすれば、詳細情報が必要になります。情報を効率的に収集するために、ツールを導入し、効率化や省力化を図りました。

図1. 性能管理システムの考え方

ツールを導入すれば問題は解決する場合もありますが、なぜ、ツールの導入だけでは不十分だと考えたのですか。

これまでの経験から、ツールだけ入れても使いこなせず、逆にツールに振り回されてしまうことが分かっていたからです。ツールは使いこなして初めて効果が出ます。そのためには、社員がツールを使いこなせるように業務をコーディネートしていく必要があります。

性能管理に関して言えば、ツールを使うことで、多くの情報を集めることができますが、生の情報がいくらあっても意味はありません。何らかの意図を持って、その意図に沿った情報を集めていく必要があります。その情報を意図を持って分析することで、提案ができ、運用の付加価値をアップさせることができます。

性能管理システムの狙いは何だったのですか。

収集した情報を活用することです。具体的には、4つあります。

  ・社内やお客さまに対して情報を発信すること(見せること)
  ・ログ・データから、何らかの兆候を発見すること(観察すること)
  ・その兆候について仮説を立てること(考えること)
  ・その仮説に基づき、実際の行動に移すこと(工夫すること)

これらの4つの情報活用に加え、

  ・運用担当者が分析スキルを身につけること(力をつけること)

を実現したいと考えていました。

これらを実行することで、運用の付加価値を高めていきたいと考えました。

性能管理の目的について、どのように考えていますか。

CPU、メモリ、ディスクなどの様々なシステム・リソースが最も高い費用対効果で稼働し、中長期間にわたる安定稼働を実現することです。また、どのリソースを増強すべきか、ボトルネックなどを発見し何を改善すべきかを把握し、お客さまに提案するのが性能管理者の任務だと考えています。確かに、コストを度外視すれば、誰もが満足できる安定したシステムやネットワークを構築することは可能です。しかし、そのようなコスト度外視のサービスがお客さまに受け入れられるわけがありません。お客さまに満足いただけるサービスとコストのバランスをとることが重要になってきます。そのためには、どのリソースが不足しているのかなどの現状をきちんと把握し、不足部分を補っていくことが必要です。

図2. 性能管理の達成イメージ図

7. 性能管理システム導入にあたって


性能管理システムを構築する際には、どのような点を意識しましたか。

監視と分析という2つの面を意識しました。まず、運用担当者は、コンソールの前で常に監視しているので、障害の兆候を早期に把握することが可能です。障害が実際に発生する前に、お客さまに対してアラートを発したり、問題が発生していないかを確認できるようにしました。次に、ログ・データは長期間保存しているので、それらを分析し、傾向を把握することができます。分析によって、現在は問題なくとも、将来的に、障害発生の可能性につながりうる事象を突き止め、障害の芽を摘み取ることができます。

また、人材育成という点では、今回、性能管理システム導入にあたって、運用担当者から4名を性能管理プロジェクトのメンバーとして選びました。そのメンバーには、意識的に開発プロセスの経験をさせました。お客さまに受け入れてもらえる提案をするためには、開発部門の立場を理解する必要があります。そこで、要件定義、基本設計から本番リリースまでのプロセスを定義し、そのプロセスごとの成果物を作成してもらいました。開発と同じプロセスを運用に導入し、スケジュールや納期という従来の運用業務にはなかったタスクを経験してもらうとともに、達成感を感じてもらうようにしました。

図3. 性能管理システムの概要図

性能管理のシステムの中で、アシスト製品をどのように使われていますか。

日々のしきい値監視により障害や障害予兆の早期発見と性能データの収集をJP1/Performance Management(JP1/PFM)で行っています。また、各サーバで収集されたデータを夜間に集めて分析し、ボトルネックを特定したり、サーバの性能状態を評価する「性能レポート」の作成には、様々なグラフを作成でき、様々な視点で柔軟にグラフを変更できる特性から、QlikViewを利用しています。

図4. 性能管理システム導入スケジュール

性能管理システムの構築を進めていくに、苦労した点は何でしょうか。

人材確保の面で苦労しました。ローテーションがすでに組まれており、性能管理プロジェクトのメンバーは運用業務との兼任となりました。通常の運用業務と兼務しながらのプロジェクトでしたので、通常業務や障害対応に追われたり、他部門への説明や連絡が遅れたりして、スケジュールが遅延したことがあります。また、今回のプロジェクトは、要員教育も目的にしており、遅延してもメンバーを交代させなかったため、他部門には一部迷惑をかけてしまうこともありました。

構築した性能管理システムの効果はいかがですか。

これまでは、漫然とシステムを止めなければいいと考えていましたが、どのように運用業務を行えばよいのかが明確になってきました。社員の業務に取り組む姿勢や意識も変化してきています。

性能管理システムの狙いとして目指した「見せること」、「観察すること」、「考えること」、「工夫すること」、「力をつけること」の5つを意識して活動できるようになったと考えています。

具体的には、現在、稼働しているお客さまのシステムに対し、役員等の上層部やお客さまに定期的に性能データをレポートとして公開しています。そのレポートを作成するために、性能データをじっくり観察し、傾向を発見し、その兆候について仮説を立て、見せる相手の立場に立ってどういった性能レポートにするか日々工夫しています。これにより、運用部門のスキルに“分析力”を加えるという付加価値がつきました。新たな物の見方ができるようになり、その結果、違う切り口で見せることができるようになりました。

性能データをレポートとして公開したことにより、運用部門からの初めての提案だったため、お客さまの担当者は驚きながらも、サーバのリソースに関する性能の実態や、それに対するボトルネックの問題などを理解していただき、設備増強などに繋げることができました。

また、ミッション・クリティカルなシステムを、ホスト・コンピュータからサーバに移植するという改修作業にあたって、構築の際に考慮して欲しいポイントをお客さまに伝え、設計/開発に反映してもらうことができました。提案するようになって、どのように設計すれば、運用しやすいシステムが構築できるのかを考慮してもらえるようになりました。

こうした積極的な提案活動を積み重ねることにより、お客さまである親会社も、今回の改善活動を高く評価してくれています。シス・コンピューティングの新たな取り組みへのチャレンジ精神が、運用サービスの付加価値向上として実績に結びつき始めたことで、次の取り組みへの支援も受け入れられやすい体制になってきました。

8. 今後の展望


今後、性能管理について新たな取り組みがあれば教えてください。

今後は、処理とリソースの監視を連動させて、処理が決められた時間内に正しく終わるように、性能管理を行っていきたいと考えています。今日やるべきことを、今日終わればいいという時代は終わりました。例えば、3時間で終わらせる予定のものに、5時間かかってしまったら、処理としては失敗だと考えなければなりません。実際、処理が長引き、お客さまのオンライン開始時間直前に終了することがあります。そのような事態をなくしていきたいと考えています。

さらなる改善活動に向けて、今後はどのように進めていく予定ですか。

改善活動をさらにブラッシュアップしていくために、毎年予算をつけて、費用対効果を検証していく予定です。まずは、お客さまからの要望や希望を伺いやすくするために、シス・コンピューティングが何ができるのかを分かりやすく明示するとともに、お客さまからの要望にそって、サービス内容のさらなる改善に取り組んでいくつもりです。

9. アシストの支援はスキル・トランスファーが前提


アシストはどのようにお役に立ちましたか。

アシストは、ツールの導入サポートだけでなく、シス・コンピューティングが抱えていた悩みを根本から理解し、運用品質の向上というかゆいところに手が届くソリューションの提案をしてくれました。

アシストのコンサルティング・サービスも良い刺激になりました。毎回、的確な指摘をして私たちの課題を明確にしてくれ、それをもとに議論しました。アシストがうまく指針を提示してくれたので、従来とは異なった視点で考えることができ、発想が広がりました。しかも、サービス・レベル評価項目の一覧などを提供し、活用方法までサポートしてもらえたので、アシストの手助けがなくてもシス・コンピューティングだけで展開していけるようになりました。単に教えて終わりではなく、自立していけるように、考え方から使い方まで教えてもらうことができ、とても助かりました。

今後のアシストへの期待について教えてください。

アシストは、扱っている製品を熟知し、私たちに最適な製品を、その使い方とともに提案してくれました。単純なテンプレートの提案は他のコンサルティング会社でも可能ですが、私たちのことを理解し、目標に到達するために必要なスキルを磨くための課題やテーマを設定することは、アシストだからできたのだと思います。改善活動を進められたのも、アシストとシス・コンピューティングが一体になって、取り組んできたからです。その意味で、アシストは改善活動の同志です。今後も教育面や新製品の活用法について、シス・コンピューティングにピッタリの提案をしてもらえると助かります。期待しています。




取材日時:2010年8月

現在、シス・コンピューティング様でご利用いただいている製品、サービス
  ・パフォーマンス管理ツール/ JP1/Performance Management
  ・高速インメモリBI ツール/ QlikView
  ・各種プロダクト技術支援サポート

「お客様の声」の新着コンテンツ


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

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



ページの先頭へ戻る