ITサービスマネージャ 2018年 秋期 午後I 問題

共通の文章

ITサービスの継続性に関する次の記述を読んで,設問13に答えよ。 F社は,医療品製造・販売会社である。F社の情報システム部は,製造部が利用す る生産管理サービス及び財務部が利用する財務会計サービスを提供している。 [サービスの概要〕 生産管理サービスは生産管理システムで,財務会計サービスは財務会計システム で提供されている。各システムでは,オンライン処理とバッチ処理を行う。各サー ビスの概要を表1に,F社のシステム構成を図1に示す。 表1サービスの概要 生産管理|生産管理システムのオンライン処理で提供されるサービスであり,生産管理業務” サービスを支援する。サービスの提供時間帯は,平日9.00て18:00 CHS. 財務会計|財務会計とシステムのオンライン処理で提供されるサービスであり,財務会計業務9 サービスを支援する。サービスの提供時間帯は,平日9.00て20:00 CHS, 注!生産管理業務では,生産管理端末からオンライン処理で生産実績を入力し,生産計画データ ベース(以下,生産計画DBという)を更新している。 2財務会計業務では,財務会計端末かあからオンライン処理で会計伝票を入力し,会計データベー ス(以下,会計DBという)を更新している。 本社(関東地区)支社(関西地区) サーバ室_______.....,|WBS](RAYS |財務会計システムー1ンズ!生産管理鉄トレージ ||サーバ|生産計画DB(| |サーバ(人80タバーーニーニーニーニー eee pe支社 端末|}|ファイル|! 工場(関東地区)||サーバ| 生産管理||生産管理1LL3SWレステム| 共有ファイル! 端末端末ーーーーニーーーーーーこ L3SW:レイヤ3スイッチee ae A=ae 注記1生産管理サーバと財務会計サーバの容量・能力は同じである。 注記2共有ファイルシステムは,情報を共有するために利用するシステムであり,生産管理端末, 財務会計端末及び運用端末から利用できる。 図1システム構成 3 Na [システムの運用] 情報システム部の担当者は,オンライン処理の前に,システムの立上げと動作確 認を行うオンライン起動処理を実施し,オンライン処理の後に,オンライン停止処 理を実施する。また,オンライン停止処理終了後は,バッチ処理を実施する。平日 の運用スケジュールを表2に示す。 表2運用スケジュール 生産管理 システム 注記各システムとも,バッチ処理の終了からオンライン起動処理の開始までの間(予備時間帯) は,臨時のシステム修正作業などを行う。 SEDオンライン処理では,データベースのデータを更新するときにデータベース更新ログ(以下, DB更新ログという)を取得している。生産管理システムでは,DB更新ログを生産管理システ ムのストレージに記録している。同様に,財務会計システムでは,DB更新ログを財務会計シ ステムのストレージに記録している。 2バッチ処理の時間(バッチ処理の起動及び停止の時間を含む)は,データ処理量に影響され ないものとする。バッチ処理の最終工程では,それぞれのシステムで使用するデータのフルバ ックアップを磁気テープに記録している。磁気テープは,システムが稼働している当該サーバ 室に保管している。 [被災時の事業継続計画の検討] 近年,大規模地震などの自然災害によってITサービスが停止するなどの被災例が 報告されている。そこで,F社の経営層は,F HO ITサービスのオンライン処理時 間帯に,本社及び工場のある関東地区で大規模地震が発生した場合を想定して,事 業継続計画(以下,BCPという)を策定するよう,経営企画部に指示した。 F社の事業継続管理を担当している経営企画部のL氏は,F社にとって特に重要な 医療品を安定供給できるように,関連部門と連携して事業影響度分析を実施するこ とにした。事業影響度分析の概要は次のとおりである。 ・分析対象業務を決定し,目標復旧時間(RTO),目標復旧時点(RPO)及び目標 復旧レベル(RLO)を検討する。 また,大規模地震による被災の影響調査では,次のことが分かっている。 —4= ・工場は被災した2日後から稼働可能である。サーバ室を含む本社は約1週間使 用できず,全面復旧までには数週間必要である。 全面復旧までの間は業務再開フェーズとして事業を継続する必要がある。事業影 響度分析の結果(抜粋)を表3に示す。 表3事業影響度分析の結果(抜粋) |王族|mv|me|moew%| 注RTO lk,大規模地震発生後,業務再開フェーズとなるまでの所要日数である。大規 模地震が発生した当日にBCPを発動し,生産管理業務及び財務会計業務は2日後から 業務再開フェーズとなる。 2 RLO lt,業務再開フェーズの操業度レベルのことで,次の式で示される指標である。 RLO=一業務再開フェーズにおける1日当たりの勤務時間x当該業務を行う要員数 平常業務運用における1日当たりの勤務時間x当該業務を行う要員数 )生産管理業務の平常業務運用における1日当たりの勤務時間は8時間である。大規 模地震発生時には従業員の通勤事情などを考慮して,業務再開フェーズにおける1日 当たりの勤務時間は13:00て16:00の3時間とする。業務再開フェーズにおいて生産管 理業務を行う要員数は,平常業務運用の要員数と同じものとする。 9財務会計業務の平常業務運用における1日当たりの勤務時間は8時間である。大規 |横地震発生時には本社の被災を考慮して,関西地区の支社に所属する部員だけで日々 必要な最低限度の業務を行う。業務再開フェーズにおける1日当たりの勤務時間は4 時間とする。関西地区の財務部員の要員の比率は,財務部全員の50%である。 L氏が,生産管理業務と財務会計業務について調査したところ,業務再開フェーズ においてもFO ITサービスの利用が必須であることが判明した。そこで,サービ ス継続計画の検討を,情報システム部のITサービスマネージャのR氏に依頼した。 [サービス継続計画の検討] R氏は,関東地区で大規模地震が発生した場合を想定して,サービス継続計画案の 検討に着手した。その案とは,業務再開フェーズの限定された勤務時間に合わせて サービスの提供時間を短縮できることから,財務会計システムを関西地区の支社の 生産管理サーバで運用するというものである。R氏の調査・検討の経緯は,次のとお りである。 1)財務部における業務再開フェーズの運用 ーー5ーー ・業務再開フェーズでの財務会計業務は,関西地区の支社の財務部員だけで行 om ・生産管理業務が実施された後で,日々必要な最低限度の業務として当日中に 確認する財務会計業務があるので,生産管理業務が完了後,財務会計業務を 実施する。 ・勤務時間帯は,夜間を含めて柔軟に対処するが,RLOで計画した4時間は勤 務する。 (2)生産管理システム,財務会計システムの順番で運用するときの変更点の確認 と運用の設計 ・生産管理システムと財務会計システムを同一のサーバで運用する場合のシス テムリソースは,二つのサービスに対応するデータを格納するためのストレ ージの容量が必要となるが,関西地区にある生産管理システムのストレージ には現在余裕があり,必要な容量を確保可能である。 ・生産管理システムのオンライン停止処理終了後に財務会計システムのオンラ イン起動処理を開始する運用にすることで,1台のサーバで生産管理システム と財務会計システムを運用することができる。 (3)生産管理システムと財務会計システムを切り替えて運用するときの設計 ・BCP発動から,業務再開フェーズとなるまでの間に,関西地区の支社サーバ 室の生産管理サーバとストレージに財務会計システムの稼働環境を整える。 ・本社サーバ室から財務会計システムのフルバックアップデータを取り寄せて, データの復元と復元後の確認を行う。 ・業務再開フェーズでの生産管理システムと財務会計システムの運用は,生産 管理システムのオンライン起動処理,オンライン処理及びオンライン停止処 理を行った後に,財務会計システムのオンライン起動処理,オンライン処理 及びオンライン停止処理を行う。その後,生産管理システムのバッチ処理に 続いて財務会計システムのバッチ処理を行う。 [財務会計システムの運用の検討] R氏は,財務部から,“生産管理業務と同じように,財務会計業務のRPOを(ア)_ 障害発生時点としたい"”という要望を受けた。そこで,RAM,磁気テープのフルバ ー6一 ックアップデータとDB更新ログの情報を用いて会計DBを回復させる運用を検討し, 次の手順で回復させることにした。 ・BCP発動から,業務再開フェーズとなるまでの間に,関西地区の支社サーバ室 の生産管理サーバとストレージに財務会計システムを稼働できる環境を整え, 財務会計システムを起動する。 ・前日のバッチ処理のフルバックアップデータから,当日のオンライン起動処理 直前の状態にデータを復元する。 ・障害発生直前までのDB更新ログの情報を用いて,Sit DBを回復する。 R氏が,回復手順及び財務会計システムの運用を机上で確認したところ,DB更新 ログの運用上の問題点があることが分かり,対策を検討した。 [訓練の実施] R氏は,サービス継続計画を社内に定着させ,対応能力の向上につなげるための訓 練の実施を計画した。今回の訓練では,関東地区の本社サーバ室が被災し,サーバ が稼働できない事態を想定した。 訓練には,情報システム部及びサービス利用部門の財務部と製造部が参加した。 情報システム部の担当者は,財務会計システムを生産管理サーバで運用するために 必要な作業を行った後,確認作業をサービス利用部門に依頼した。確認作業依頼の 連絡は,各部門に配付されている緊急時連絡先リストの印刷物(以下,連絡表とい う)に従って行った。その際,財務部の担当者への連絡に想定以上の時間が掛かっ てしまた。 訓練実施後,R氏が今回の訓練について調査したところ,次の問題点が判明した。 ・連絡表に記載されていたのは,担当者が複数の場合はその担当者の代表者1名 であり,代表者の電話番号が最新化されていなかった。 連絡表の内容は,情報システム部が一括管理している。R氏は,(イ)連絡表の内 容を見直し,定期的に連絡先が最新かどうかを確認することにした。 最新の連絡表の情報は,本社ファイルサーバに保存し,連絡表を各部門に配付す ることになっている。訓練では,連絡表の連絡先に連絡できなかったとき,PRY ステム部の担当者は本社ファイルサーバに保存されている情報を確認して適切な連 絡先を検索しようとした。しかし,本社ファイルサーバを利用できないので,確認 ーァー できなかった。そこで,R氏は,本社ファイルサーバを利用できないときでも最新の 連絡表の情報を参照できるように(ウ)システムを使った対策を実施した。

共通の文章

リリース及び展開管理に関する次の記述を読んで,設問13に答えよ。 W社は,家具販売会社であり,東京に本社がある。W社では,海外で日本製家具 の需要が高まっていることから,ME,欧州支社を設立した。今後も事業のグロー バル化を積極的に推進していく方針である。 [情報システム部の概要] 情報システム部は,東京本社にあり,システム開発課とシステム運用課で構成さ れ,W社の社員が利用する受注管理サービスを提供している。 ・受注管理サービスの利用は,定期保守の作業時間帯以外であれば,KA,夜間 も可能である。最多利用時間帯は平日の8て18時である。 ・受注管理サービスは,受注管理システムで提供される。受注管理システムの構 成を図1に示す。 |BT rp]APサーバ||APサーバ|[APサーバ||| |er ee||3号機7 FW:ファイアウォールDBダーバの在庫管理ファイル(|= ‘yeーバ5|! LB:負荷分散装置トーoo eee APサーバ:アプリケーション サーテスト用サーバ9% サーバ人 注"ソースコード(以下,SCという)の管理,及びSCのビルドを行うサーバである。ここで, ビルドとは,コンパイル,リンクなどを行い,動作可能なプログラムの版(以下,PGという) を作成する作業のことである。 2システム開発課が作成したプログラムをテストするサーバであり,開発環境と保守環境の二 つの環境がある。 3?新規システム開発のテスト及び適応保守で修正したプログラムのテストを行う。 9プログラムの不具合対応などの是正保守で修正したプログラムのテストを行う。 9保守作業などで受注管理サービスが利用できない場合に社員PCに対してメッセージを返答 するサーバである。 図1受注管理システムの構成 <9 coty システム開発課は,システム開発及びソフトウェア保守を行っている。システム 運用課は,システム運用,SCのビルド及びPGのデプロイを行う。PGのデプロイと は開発環境,保守環境又は稼働環境にPGを展開し,利用可能な状態にする作業のこ とである。システム開発課とシステム運用課の役割を表1に示す。 Rlシステム開発課とシステム運用課の役割 システム開発及びソフトウェア保守を行う。 woe・SCを作成又は修正した後,システム運用課に対してSCのビルド及びPGのデプロ システム 開発課イを依頼する。 の・新規に作成したPGの誤りを検出するためのテストのほか,PGを更新したことによ って想定外の影響が出ていないかどうかを確認するためのテストなどを行う。 稼働環境の維持・運用だけでなく,システム開発課が円滑にテストできる開発環境・ 保守環境を維持するために,次に示す作業を行う。 ・開発環境と保守環境について,当日の12時までに依頼を受け付けたSCのビルド及 O PGのデプロイを18時から実施し,18時までに依頼を受け付けたSCのビルド及 システムO PGのデプロイを翌営業日の12時から実施する。 運用課・稼働環境について,1日1回,18時までに依頼を受け付けたPGのデプロイを22時 から実施する。 ・PGを稼働環境にデプロイする場合は,LBの設定変更によって,社員PCからの受 注管理サービスに対する要求振分け先をSorryサーバに変更し,全てのAPサーバの サービスを停止する。 [ツールによるデプロイの自動化〕 欧州支社の業務が本格化してきたある日,欧州支社から情報システム部に,“東京 ALO 22時は欧州支社では14時であり,業務に影響を与えるので,PGを稼働環境 にデプロイする時間帯を変更してほしい。”という要望があった。W社では,RIN 社の1時間の休憩時間帯の開始時刻に当たる東京本社の20時に作業の開始を前倒し する案を検討した。しかし,この作業を1時間以内で完了させることはできないこ とが判明した。また,システム開発課からは“SCのビルドの作業頻度と,PG ET スト用サーバにデプロイする作業頻度を増やしてほしい。”という要望があった。 これらの要望に対して,システム運用課のITサービスマネージャであるY Kid, ビルドとテストを反復してシステム開発できる環境を整えることが重要だと考えた。 そこで,Y氏はシステム開発課と協力し,PCGのデプロイを自動化する支援ツールを 開発・運用することにした。ライブラリ管理サーバで支援ツールを運用することに よって,要員による作業ミスの防止,作業品質の向上も期待できる。 開発・運用する支援ツールについて,表2に示す。 表2開発・運用する支援ツール ビルド・SCをライブラリ管理サーバに登録する。 ッール|ライブラリ人管理サーバで指定したSCをビルドして,PGをテスト用サーバの指定 境にデプロイする。 ・受注管理サービスの利用に影響を与えないように,振分け先のAPサーバをLB CHI AP展開BRL,稼働環境のAPサーバ1台ごとにPGを順次デプロイする。3台のデプロイは ッール|約30分で完了する。 ・データベースのテーブル定義変更などの場合は,保守作業時間帯を設けて受注管理 サービスを停止させる必要があるので,変更内容に店じて,使用可否を判断する。 AP展開ツールの処理手順を表3に示す。 表3 AP展開ツールの処理手順 手順名処理概要 ・APサーバ1号機で新規のサービス要求を受け付けないように,LBの 要求振分け先の設定を変更する。 1|paz・APサーバ1号機で既に受け付けている要求の処理に彫響を与えない ように,実行中のセション?の解放を待ってから,LBはAPサーバ1 号機との通信を遮断する。 サービス停止|・APサーバ1号機で起動中のサービスを停止する。 。|PGのデブロ|・ライブラリ管理サーバからAPサーバ1号機に対象のPGをデプロイ 4する。 ・APサーバ1号機で手順2によって停止したサービスを起動する。 ・LBの要求振分け先の設定を変更し,LBからAPサーバ1号機に対す 5|閉塞の解除る閉塞を解除する。 ・APサーバ1号機で要求の受付が可能な状態になったことを確認する。 |6|・APサーバ1号機で行った手順1ご5の処理を,APサーバ2号機に対しても行う。 ・APサーバ1号機で行った手順1ご5の処理を,APサーバ3号機に対しても行う。 注り手順の途中で異常終了が発生した場合,後続の手順は実行されない。 2社員PCからサービス要求を開始するときにLBとAPサーバ間でセションが確立され,要求 の処理が終了したときにセションが解放される。LBとAPサーバ間で通信が5分間発生しない 場合,セションは解放される。 [受注管理サービスの変更] W社では,販売条件に関する業務ルールを改正することになり,受注管理システ ムの適応保守が必要になった。新たな業務ルールは11月から適用されるので,稼働 環境の受注管理サービスは10月末までに変更しておく必要がある。W社の変更管理 プロセスでは,変更府問委員会が変更の影響について助言を与え,変更を承認する。 また,緊急に変更しなければならない場合は,緊急変更府問委員会が変更の受入れ 及び承認に関する決定を行う。受注管理サービスの変更について,システム開発課 で調査した結果,請求プログラム及び共通プログラムの修正が必要であることが分 かった。 システム運用課では,次のように対処した。 ・修正されたSCをビルドツールでビルドして,PGをテスト用サーバの指定環境 にデプロイするまでを完了した。 ・データベースに影響を与えない変更なので,AP展開ツールを使用して,10月 12日(金)10時に稼働環境にデプロイする変更計画(以下,業務ルール変更計 画という)を立案した。 10月3日(水)の変更府問委員会で,業務ルール変更計画が承認された。 [受注管理サービスのインシデント発生と対応] 10月4日(AR)13時に,受注管理サービスでインシデントが発生した。対応完了 までの経緯は,次のとおりである。 ①インシデントの内容を確認し,原因を調査したところ,売上プログラム及び 共通プログラムに不具合があることが判明した。特定部署の業務に対して限定 的な影響を与えるだけなので,受注管理サービスは停止していない。また,プ ログラムの不具合によって,DBサーバの在庫管理ファイルの一部に誤りが発生 しており,在庫管理ファイルの誤り修正作業が必要であることが判明した。シ ステム開発課は,プログラムの不具合を修正した。 ②在庫管理ファイルの誤り修正作業は,APサーバからDBサーバへの通信が発 生しない状態で行う必要がある。そこで,不具合を修正したプログラムについ て,AP展開ツールを使用して稼働環境にデプロイした後,LBの閉塞処理,(ア)_ 在庫管理ファイルの誤り修正作業,LBの閉塞解除処理の順で作業を実施するこ ー12一 とにした。 @修正されたSCをビルドツールでビルドして,PGをテスト用サーバの指定環 境にデプロイ,PGのテストまでを完了し,10月4日(木)18時に緊急変更府 問委員会を開催した。 ④変更要求では10月4日(AK)22時から一連の作業を開始する計画であった。 LOL,緊急変更府問委員会に出席したY氏は,サービス利用者への影響を少 なくするために,(イ)計画した作業を10月4日CK)20時に開始するよう提 BL,計画は変更された。開始時刻が当初の計画よりも2時間早くなるので, 必要な準備を急ぐことになった。 ©10月4日(A)20時から,不具合を修正したプログラムについてAP展開ツ ールを使用して稼働環境にデプロイする作業を開始し,20時30分に完了した。 その後,在庫管理ファイルの誤り修正作業を開始し,20時50分に完了した。 業務ルール変更計画の実施] 10月10日(水)に業務ルール変更計画に関する緊急変更府問委員会が開催された。 緊急変更府問委員会は,10月3日(水)の変更誠問委員会で承認されたときにテス トを完了していたPGに対し,(ウ)追加で実施した修正,及び(エエ)追加で実施し たテストが問題なく完了していることを確認し,業務ルール変更計画を承認した。 そこで,システム運用課では,10月12日(金)10時にAP展開ツールを使用して, 請求プログラム及び共通プログラムを稼働環境にデプロイした。

共通の文章

サービスデスクに関する次の記述を読んで,設問1こ3に答えよ。 A社は情報サービス会社である。A社の1aaS事業部は,数年前から演算リソース 及びストレージリソース(以下,これらをITインフラ群という)を顧客企業向けに 提供するクラウドサービス事業を営んでいる。ITインフラ群は,A社シルステムセン タに設置されており,1aaS事業部の技術課では,サービス利用者の要求を受けて実 |施する変更作業及びインシデント対応を行っている。 〔【インシデント対応の概要〕 これまで技術課では,顧客が利用するITインフラ和群を担当する技術者が,サービ ス利用者からのインシデントの受付を行ってきた。しかし,技術課の業務効率向上 の観点から,次のように運営することにした。 ・IaaS事業部内に新たに設置したサービスデスクで,インシデントを受け付ける。 ・サービスデスクの受付手段は電話とし,受付時間帯は平日の9て17時の8時間 とする。 ・技術課は,サービスデスクで対応できるインシデントの解決手順をノウハウデ ータベース(以下,ノウハウDBという)に登録し.サービスデスクは,インシ デント対応に利用する。 ・インシデントの解決手順をノウハウDBに追加する場合,及び既存の解決手順に 問題点又は改善点があってノウハウDBを更新する場合は,サービスデスクでは なく,内容の妥当性が判別でき専門知識がある技術課が対応する。 ・サービスデスクがノウハウDBだけではインシデントを解決できない場合,サー ビスデスクから技術課に解決を依頼する。 インシデント対応の種類を表1に示す。 表1インシデント対応の種類 ee ad サービスデスクがノウハウDBだけではインシデントを解決できない場合,技術課に解決を依頼す たときは,サービスデスクに解決手順を指示し,サービスデスクが解決する。 クでは解決できないと判断したときは,技術者自らが解決し,結果をサービスデスクに回答する。 ー15一 [インシデント対応のフロー及びインシデント対応の手順] インシデントト対応のフローを図1に,インシデント対応の手順を表2に示す。 顧客vets A社IsaS事業部 インシデント 発生の通知解決の依頼 ーー 利用者解決の連絡デスク|~解決手順の指示又は 解決の結果の回答 図1インシデント対応のフロー 表2インシデント対応の手順 記録・サービスデスクは,サービス利用者からインシデント発生の通知を受け付け,受付内容をインシ -FY bh SHGりに記録する。 優先度の・インシデントに,対応の優先度("高",“中”,“MB?のいずれか)を割り当てる。 割当て・優先度によって解決目標時間2?が定められている。 (優先度“高":2時間,優先度“中":4時間,優先度“低":8時間) ・インシデントを,あらかじめ決められたカテゴリ(ストレージの障害など)に分類する。 記録の更|・インシデントの内容,割り当てた優先度,分類したカテゴリの内容などで,インシデント管理徳 新を更新する。 ・インシデントがタイプ1に該当する場合は,サービスデスクが解決するので,段階的取扱い(以 段階的取|下,エスカレーションという)は行わない。 扱い・インシデントがタイプ2又はタイプ3に該当する場合は,サービスデスクが回答期限?を定めて技 術課に解決を依頼する。これを,機能的エスカレーションという。 ・タイプ1の場合,サービスデスクはノウハウDBに登録されている文書化されたインシデントの 解決手順に従って解決する。 apy・タイプ2の場合,割り当てられた技術課の技術者がサービスデスクに解決手順を指示し,サービ スデスクが指示された解決手順に従って解決する。 ・タイプ3の場合,割り当てられた技術課の技術者が専門知識に基づいて解決する。解決後,サー ビスデスクに解決の結果の回答を行う。 ・サービスデスクは,サービス利用者に解決の連絡をする。 終了・サービスデスクは,サービス利用者がサービスを利用できるかどうかを確認する。 ・サービスデスクは,インシデント管理科に必要な内容?を記録・更新する。 SE)サービスデスクは,全てのインシデントについて,サービス利用者とのやり取りの内容,インシデントの 内容などをインシデント管理短に記録する。 2)解決目標時間は,インシデント発生の通知を受け付けてからインシデントの最終的な解決の連絡をする までの目標とする経過時間である。ただし,サービスデスクの受付時間帯以外は経過時間として加算しな い。 2サービスデスクは,手順"優先度の割当て”で設定された解決目標時間を超過しないように,前もって 技術課の回答期限を定める。 9技術課の技術者からの解決手順の指示内容及び対応結果,並びにサービス利用者とのやり取りの内容を 記録・更新する。タイプ3の場合は,技術課の技術者にインシデント対応の内容をヒアリングする。 [エスカレーションの手順における問題点とその改善策〕 IaaS事業部のITサービスマネージャのS氏は,顧客に対するサービス責任者とし て,顧客に対して定期的にサービス報告を行っている。 ある日,サービス報告の一環として,インシデントの解決時間について調査した ところ,タイプ1の場合は全て解決目標時間を達成していた。タイプ2及びタイプ3 のインシデント対応に関しても,解決目標時間は達成していたものの,技術課はサ ービスデスクが定めた回答期限に遅れることがあった。S氏は,サービスデスクと技 術課の対応状況について,次のように整理した。 (1)サービスデスクの対応状況 ・問題点:技術課の技術者の回答期限が迫っている場合,サービスデスクは技 術者に回答を督促していた。しかし,技術者からの解決手順の指示又は解決 の結果の回答が回答期限に遅れることがあった。 ・改善策:解決目標時間を達成できないおそれがある場合は,エスカレーショ ンの手順に,| 』|を追加する。この場合,エスカレーション先は,願 客に対するサービス次任者であるS氏とし,インシデント対応の手順“解決" に関与することによって,組織的なかインシデント対応を行うことにした。 (2)技術課の対応状況 ・問題点:解決までに時間を要したインシデント対応の中には,難易度の高い ものもあった。しかし,大半はサービスデスクが定めた回答期限内で対応で きる内容であった。インシデントの解決を担当した数名の技術者へのヒアリ ングによって,次の状況が判明した。“ITインフラ群の変更作業を計画的に実 施していることから,サービスデスクからインシデントの解決の依頼を受け た場合に,解決手順の指示,技術者自身での解決を後回しにしてしまうこと MHS,” ・技術課への要請:S氏は技術課の課長に,“技術者が回答期限を遵守する対策 を取ってほしい"と要請した。技術課の課長は,対策を検討することにした。 技術者は,毎日始業時に当日の作業計画を策定し,作業を計画的に実施して いた。そこで,技術課の課長は技術者が策定する当日の作業計画について (7)調査を行った。 a Hitt os 〔タイプ1の比率向上への取組] S氏は,解決時間について,タイプ1がタイプ2及びタイプ3に比べて短い点に着 目し,“タイプ1の比率が増加すれば,インシデントの平均解決時間は短くなる”と -考えた。サービス利用者にとって利点となることから,S氏は,タイプ1の比率向上 への取組として,ノウハウDBに関する二つの改善活動を開始した。 ①)検索容易性の向上 サービスデスクでタイプ2と判断されたインシデント対応の中には,ノウハ ウDBに解決手順が登録されていたものもある。しかし,解決手順の抽出に必要 な条件の設定が複雑でノウハウDBの検索がうまく行えず,結果としてタイプ1 と判断できていないことがあった。 そこで,ノウハウDBの検索にAlを活用し,入力したキーワードから適切に インシデントの解決手順を検索するシステムを開発し,経験の浅いサービスデ スク担当者でも迅速かつ適切に対応できるようにする。 (2)登録内容の充実 S氏は,技術者がサービスデスクからインシデントの解決の依頼を受け,解決 までに実施した対応の詳細をヒアリングした。ヒアリング結果は,次のとおり である。 ・タイプ2については,技術者からサービスデスクに対して解決手順を速や かに指示できている。技術者は過去に同様のインシデントが発生したとき でも同じ指示を行い,サービスデスクも同じ対応を行っている。 ・タイプ3については,技術者でなければ解決できないインシデントだけで なく,工夫をすれば,サービスデスクで解決できるものも含まれているこ とが分かった。サービスデスクで解決できるインシデントは主に二つに分 類できた。一つ目は,再発性のあるインシデントであり,タイプ3全体の 半数以上を占めていた。これらは,初回発生後に解決手順を文書化してお けば,2回目以降はサービスデスクで対応できる。二つ目は,ITインフラ 群の使用状況を可視化している“ダッシュボード”の機能拡充のような, サービスを変更した際に発生するインシデントであり,タイプ3全体の3 割程度を占めていた。これらはサービス変更後の短期間に集中して発生す る。 ー7%= S氏は,このような状況から,“ノウハウDBの登録頻度をこれまでよりも高 OT,ノウハツウDBの登録内容を充実する取組が必要である"と考えた。そのた めに,S氏は次の2点を技術課の課長に提案した。 ・サービスデスクにおいては,インシデントの再発に備えて,タイプ2及び タイプ3のインシデントが解決した後に.インシデントの解決手順をノウ ハウDBに登録し,技術課に登録内容の確認を依頼する。ここで,タイプ3 のインシデントの解決手順は技術者があらかじめ文書化したものをサービ スデスクが受け取って,ノウハウDBに登録する。 ・技術課においては,これら以外に必要な_(イ)ノウハウDBへの登録を,業 務として実施する。 技術課の課長は,“S氏の提案を実施するには,技術者の取組が必要となるが, (ウ)技術課にとっても利点がある"と考え,S氏の提案に同意した。 [サービスデスクの業務拡大〕 IaaS事業部の業務拡大に伴い,技術課の技術者の業務量が増加した。そこで,技 術課の業務の一部をサービスデスクに移行できないか,S氏が検討することになった。 技術課の現在の業務について調査したところ,サービス利用者の要求によって実施 するITインフラ群の変更作業の一部が,移行可能な業務の候補として挙げられた。 具体的な内容は,次のとおりである。 ・サービス利用者がストレージリソースにアクセスするときの,アカウント作成 及び更新についての変更作業である。 ・サービス利用者からの変更要求の頻度は高く,内容的に失敗するリスクが低い 作業である。 ・変更要求は,A社の変更管理プロセスに従って,週1回実施している社内の変更 審査会の前日までに申請が必要であり,変更審査会で承認を受けてから,翌日 以降に行う作業である。 今後,サービスデスクで変更要求の処理を行えをるようにするには,変更管理プロ セスに従って,IaaS事業部として事前に認可を受ける必要がある。S氏は,該当する 変更要求の処理をサービスデスクで作業可能となるよう検討を進めた。検討の結果, サービスデスクの体制強化及び必要な教育は,実施可能であることが分かった。サ ー19一 ービスデスクで行う変更要求の処理は,優先度“低"として行うことにした。 S氏は,技術課に依頼して,(2)技術課が実施すべき作業をまとめた。