システム運用管理者のためのノウハウがぎっしり詰まったポータルサイト
 |
 |
|
当サイトは会員制有償サイトです。 検索 |
|
運用の現場を取材したユーザ事例[2007年5月16日]
株式会社 菱食様運用品質向上とサービスレベルアップ 第2回〜当社はこのようにしてITシステム運用現場を改善した、また今後改善していきたい〜 内容
＜第1回 改善前の運用状況と課題＞ ＜第2回 改善への取組みと効果＞ ITILの導入〜「なぜ」を繰り返し、改善を進める菱食は、運用改善のために次のようないくつかの取組みを行った。 まず運用改善手法としてITILを導入し、インシデントによる管理、問題点管理による管理を進めた。BSPソリューションズからのサポートを得て、トラブル原因別のランキングを求めた結果、2005年11月の時点で、JCLミス、ハードディスク領域不足、プログラム不具合（内、約半数がデッドロック）が上位３要因であることが判明した。そこで、「なぜ資産修正のたびにミスが発生するのか？」、「なぜハードディスクの総容量では空いているのに、特定のボリュームで領域不足が発生するのか？」、「なぜデッドロックが発生するのか？」というように「なぜ」を繰り返して、根本原因を解明し、１つ１つ対応することによって改善を進めていった。 しかし、その過程で問題も発生した。ITILインシデント管理では、すべてのオペレーション問合せ、トラブルを含むオペレータ介入事象のインシデントを入力することにとって、問題点を可視化できる。しかし、現実にはオペレータの業務量が増えてしまうためオペレータの不満へとつながり、インシデント入力作業が滞ってしまった。実際、2006年1月から5月の間は、プログラム不具合による処理異常時のインシデントが入力されなかった。そこで解決策として実施したのが、菱食社員とオペレータとの定例会の開催だった。定例会でトラブル件数の削減を数値目標として掲げて約束を取り交わして、入力の徹底を図った。その結果、同年6月からは正確な件数を把握でき、トラブルの内容が明らかになった。  
要因１「JCLミス」への対応〜チェックツールを開発・適用トラブルの大きな要因であるJCLミスに対応するために、人による目検から仕組みによるチェックに切り替えることにした。BSPソリューションズに依頼してJCLチェックツールを開発し、資産修正時に同ツールを適用することを必須とした資産修正ルールを整備し、公開した。ルールの徹底を図るために、修正後に同ツールを実際に稼動させたかを確認する抜き打ち調査も行っている。その結果、JCLミスによるトラブルは、147件（2005年11月）から51件（2006年10月）にまで減少した。 要因２「ハードディスクの領域不足」への対応〜領域管理手法を変更従来、菱食では人手によってファイルのボリューム配置を行っていたが、ITベンダーからの提案を受けて、ハードディスクの領域管理手法を変更した。夜間デイリー処理ではWORKボリュームを活用してOSに配置を任せることとし、日中バッチ処理で使用しているディスク約10本を夜間にのみ巨大なWORK領域として使用できるようにOS設定を変更した。実作業はハードベンダーB社に委託し、同社のSEが調査し、対応した。 また、ボリューム管理手法の変更に伴ってJCLの修正が必要なため、開発業務を担当していたC社から修正要員を派遣してもらい、１ホスト機当たり1.5人月で修正を行った。その結果、領域不足によるトラブルは、134件（2005年11月）から78件（2006年10月）にまで減少した。 要因３「プログラム不具合」への対応〜データベースのデッドロックを解消ITソリューションベンダーA社に開発委託し、デッドロック発生時に異常終了させずに、更新命令のリトライを５〜20回行うようにしてデッドロック解消につなげた。リトライによるデータの二重更新を防ぐ仕様部分は難易度の高いものだったが、2006年10月に修正プログラムをリリースすることができた。その結果、デッドロックによるトラブルは、65件（2005年11月）から45件（2006年11月）に減少し、2007年以降も減少の一途をたどっている。
システム統括部の組織変更〜改善・問題管理の専任体制へ従来は、システム統括部として「オペレーション」、「資産修正（開発依頼対応）」、「改善対応・問題管理」の3つの業務のすべてを行ってきた。しかし、ひとつのチームですべての業務を行うというこれまでの方式では業務の重複が発生するという問題があった。そこで2006年6月から、全社オペレーションチームは、オペレーション班と資産修正作業班の２班体制とし、システム管理チームに２名を異動させて改善・問題管理を専門に行う専任体制を敷いた。 SLMの推進ユーザとITシステム運用部門、システム運用チーム間、菱食とアウトソーシング会社間それぞれについてサービスレベルを定め、SLA（Service Level Agreement）を締結した。 ユーザとの約束事項･基準を明文化するとともに、システム部門間でも部内の役割分担やルールを明文化した。部内の処理依頼ワークフロー、トラブル時対処・連絡フロー、JCLテストマニュアル、JCL作成運用マニュアルなど、開発チームと運用チームの間、サポートチームと開発チームの間、サポートチームと運用チームの間、それぞれのルールを定め、明文化した。 図４ システム部門間のSML
（図をクリックすると拡大表示します） 
その他〜スキルアップ対策などスキルアップのために、オペレータに対して改善提案インセンティブ制度をつくり、教育にも力をいれている。また、社員とオペレータとの連携を強化するために、オペレータから社員業務へ、オペレータからシステム開発者への異動等も実施している。 1年でトラブルは3割減、開発依頼対応件数は2.9倍に菱食は以上のような運用改善を進めた結果、トラブル件数は、月間約1000件から約700件に減り、1年間で30%削減することができた。開発依頼件数は、2005年11月の249件に対して、2006年11月は727件と、1年前の2.9倍の変数に対応することができた。ちなみに調査件数は672件から269件と大幅に減り、開発依頼に工数を割くことができるようになった。2006年には既存資産の修正を専門に行うチームを発足させ、1年前の4,881時間から6,013時間と開発に1.2倍の時間をかけられるようになった。 図５ 1年間でトラブル件数30%削減を達成
（図をクリックすると拡大表示します） 
ITシステム運用として今後の成すべきこと今回の運用改善・品質向上の取組みは、自社だけでは改善できないことも、取組み先企業の協力によって実現できた。それぞれの分野におけるノウハウや技術力をもったパートナー企業をいかに探し出すか、そのためにも他社の事例や情報収集が重要である。 |
