ITサービスマネージャH22PM2Q3
■サービス又はシステムの名称
�名称 30 字以内で，分かりやすく簡潔に表してください。
【例】
1. インターネットを利用したオンラインショッピングサービス
2. 金融業における総合オンラインシステム
3. 製造業の調達・生産・販売のための国際ネットワークシステム
通信教育サービス業のイントラネットシステム
■対象とする企業・期間
�企業・機関などの種類・業種
1. 建設業 2. 製造業 3. 電気・ガス・熱供給・水道業 4. 運輸・通信業
5. 卸売・小売業・飲食店 6. 金融・保険・不動産業 7. サービス業 8.情報サービス業
9. 調査業・広告業 10. 医療・福祉業 11.農業・林業・漁業・鉱業
12.教育（学校・研究機関） 13.官公庁・公益団体 14.特定業種なし
15. その他（ ）
７
�企業・機関などの規模
1.100 人以下 2.101 〜 300 人 3.301 〜 1,000 人 4.1,001 〜 5,000 人 5.5,001 人以上
6. 特定しない 7. 分からない
４
�対象業務の領域
1. 経営・企画 2. 会計・経理 3. 営業・販売 4. 生産 5. 物流 6. 人事 7. 管理一般
8. 研究・開発 9. 技術・制御 10. その他（ ）
２３５６７
■システムの構成
�システムの形態と規模
1. クライアントサーバシステム ｱ. （サーバ約 台、クライアント約 台）
ｲ.分からない
2. Webシステム ｱ. （サーバ約 台、クライアント約 台） ｲ.分からない
3.メインフレーム又はオフコン （約 台） 及び端末 （約 台） によるシステム
4. その他（ ）
１ サーバ２００台、クライアント５０００台
�ネットワークの範囲
1. 他企業・他機関との間 2. 同一企業・同一機関の複数事業所間 3. 単一事業所内
4. 単一部署内 5. なし 6. その他（ ）
２
�システムの利用者数
1. 1 〜 10 人 2 .11 〜 30 人 3. 31 〜 100 人 4. 101 〜 300 人 5. 301 人〜 1,000 人
6. 1,001 人〜 3,000 人 7. 3,001 人以上 8. 分からない
７
■システム運用の規模・形態など
�運用管理及びオペレーション要員数
1.（約 人） 2. 分からない
５０
�運用対象の区分
1.他社システムの運用受託 2.他社システムの運用支援 3.自社システムの運用
１
�運用開始年月
1.（ 年 月） 2. 分からない
２００５／１２
■ITサービスマネジメントにおけるあなたの立場
�あなたが所属する企業・機関など
1. ソフトウェア業・情報処理・提供サービス業など
2. コンピュータ製造・販売業など 3. 一般企業など
4. その他（ ）
１
�あなたの担当業務
1. システム管理 2. システム運用 3. プログラム企画・計画 4. 技術支援
5. システム設計・開発・保守 6. その他（ ）
１２
�あなたの役割
1. 部門マネージャ 2. 部門スタッフ 3. チームリーダ 4. チームサブリーダ
5. 担当者 6. その他（ ）
１
�あなたの担当期間（ 年 月）〜（ 年 月）
２００６／４
（設問ア）800字以内
（設問イ）800字以上1600字以内
（設問ウ）600字以上1200字以内
１．私が携わったＩＴサービスについて
1.1.ＩＴサービスの概要
私は、通信教育サービスを行うＡ社の情報システム子会社に勤務しており、Ａ社のＩＴサービスマネジメントを主な業務にしている。
今回取り上げるＩＴサービスは、Ａ社が全国に展開している事業所をネットワークでつないだイントラネットシステムである。このイントラネットシステムはＡ社の利用者が業務に使用するメールや販売管理のシステムを含み、事業上でも重要な位置づけになっている。
私の部署では、このシステムに関する利用者からの問い合わせを受けるサービスデスクや、システム運用、障害対応を行うための機能を持ち、Ａ社への安定したＩＴサービスの提供を目標としている。
また、事業上の重要性をふまえ、Ａ社とのＳＬＡとして、２４時間３６５日のシステム運用を行い、サービスに支障のある障害が発生したときでも半日以内にシステムを復旧させることを取り決めている。
1.2.インシデント発生時に想定される問題
私の部署では、システムを安定稼動させるために一定のスキルを持ったメンバーがそれぞれの分担を行っており、平日日中であれば十分な体制が確保できていると言える。しかし、システムは夜間や休日に障害が発生することも想定しなければならない。このようなとき、監視システムの見地を受けた担当者が正しい手順のもので、エスカレーションと復旧を行わなければ、システム障害の影響を見誤まり、他の担当者への連絡が遅れたり、復旧手順のミスによるシステム復旧の遅れが発生する恐れがある。
上記のことから、Ａ社とのＳＬＡ順守のためにも、夜間のインシデント発生への対策を検討する必要があった。
２．問題への対策
2.1.対策を検討するにあたって留意した点
インシデントが発生した際の対策検討にあたっては、費用対効果を考慮し、ＳＬＡへの影響が最小となるように留意しなければならない。今回の場合は、以下のような対策案より評価を行った。
�夜間の勤務体制を整備し、日中と同等の体制を整える
�システムを完全冗長化し、障害対応のオペレーションを減らす
�マニュアルを整備し、担当者のスキルに依存しない復旧手順を確立する
まず�については、現在のメンバ構成では十分な体制を整備できず、体制強化のための人件費が現行の運用コストでは確保できない。
また、�についても、システムの冗長化のために機器コストが必要になること、システムの整備を行うために数ヶ月の期間を必要とするため、有効な対策とは考えられなかった。
最後に�については、現在のメンバーですぐに作成することが可能で、この対策を行うこととした。
2.2.対策の内容
夜間のインシデント発生時、担当者が限られた体制のなかで正しい手順、判断ができるよう、私は障害対応マニュアルを整備することにした。
まずシステム障害が発生した時、監視システムのアラートがメールで担当者へ送られ、これをインシデント発生のトリガとする。この後の以下の流れを、マニュアルとして記載することにした。
�システムの障害がどこまでの範囲で発生しているか影響範囲を確認する
�影響範囲に応じた他の担当者へ障害の連絡をする
�メンバーの担当する部分に障害が発生しているときは手順に基づき、手動での復旧を行う
このマニュアルを担当メンバーへ配布し、年に一度のトレーニングを行った。
上記の対策により、夜間でも日中と同等の品質でインシデントへの対応が行えるようにした。
３．対策の改善
3.1.インシデント発生時の対応の過程で判明した不備
インシデント対応のマニュアル化を行うことにより、数回の夜間障害が発生したが、ほぼ日中と同等の対応が行えるようになり、ＳＬＡの順守という観点からも問題は発生していなかった。
ある日の障害で、手順どおりにオペレーションを行ってもシステムが復旧しないというトラブルが発生した。原因を調査したところ、数ヶ月前に行ったシステム改修で構成が変わっており、この改修がマニュアルに反映されていなかったことが判明した。
幸い、システム改修を行った担当者とすぐに連絡が取れ、大事には至らなかったが、マニュアル作成後のメンテナンスが不十分であったことは今後のＳＬＡ順守に重大を影響を及ぼす可能性がある。
私は、この対策の不備に対して、改善を行う必要があると考えた。
3.2.対策の改善内容
判断したマニュアルの不備はすぐに修正を行ったが、システム改修は今後も行われるため、根本的な対策とはいえない。現在のシステムリリースに対してプロセス上の改善が必要である。
そこで私は、システムリリースの見極め基準として、運用マニュアルへの影響はないかどうか、ある場合はマニュアルの改訂は行えているかどうかという点を追加することにした。これにより、システム改修時に運用への影響を考慮し、正しい手順を常に最新かしておくことができる。
最後に、運用マニュアルを最新化し、一定以上の品質を確保することも重要であるが、メンバーのスキルを更に底上げし、マニュアルに無いことでも異変に気づき、障害の予防につなげていくことや、様々なケースに対応できるようマニュアルの拡充を行うことも重要である。これからも、メンバーの育成を行い、安定したＩＴサービスを提供できるプロフェッショナル組織を目指していきたいと考えている。
−以上−
