デジタルプラクティス　Vol.8 No.3 (July 2017)

1．はじめに

企業･団体･組織（以下，企業等）における情報システムの役割は近年ますます重要となっており，高い可用性が求められている．特にシステムの大規模化･複雑化が顕著な昨今にあってはシステム障害の発生をゼロにすることは現実的には不可能であり，情報システムの可用性向上に向けてはMTTR（平均復旧時間^☆1）の短縮に力点が置かれている．実際，復旧の遅延により重大な障害に至る事例も後を絶たない[1]．

そのため各企業等のIT部門ではITIL（Information Technology Infrastructure Library^☆2）[2]を導入してシステム障害対応の品質向上を図っている．ITILは1989年にイギリス政府が公表したシステム運用における成功事例集（ベストプラクティス）であり，現在では事実上の世界標準（デファクトスタンダード）になっている．ITILはインシデント管理，性能管理，変更管理，問題管理やサービスレベル管理など25個のプロセスから成り，各企業等におけるプロセスの導入や継続的な改善を促すものである．たとえば，本稿で取り扱うインシデント管理プロセスのエスカレーションの項目には，エスカレーションの内容や伝達方法や留意点などが詳細に記述されている．

しかしながら，IT部門の現場で日々業務改善していくにあたり，ITILにはチーム活動を評価する指標や評価方法が掲載されていないという課題がある．MTTRはシステム障害対応の「成果の指標」（以下，成果指標）であり，その活動を改善するにあたっては，「活動自体を評価する指標」（以下，活動指標）が必要である．

以上の課題から「システム障害対応のチーム活動を定量的に評価する指標と手法を考案して，その有効性を確認すること」が本稿の目的である．

事例として，東京海上日動システムズ（株）（以下，東京海上日動システムズまたは同社と呼ぶ）のMTTR短縮へ向けたチーム活動の取り組みを報告する．同社は東京海上日動火災保険（株）（以下，東京海上日動）のシステムの開発･運用を全面的に受託する情報システム子会社である．

本稿における「システム障害対応」とは，ITILのインシデント管理の一部と定義する（図1）．ITILのインシデント管理にはベストプラクティスとして9つの活動が提示されているが，そのうち下流の5つの活動を本稿におけるシステム障害対応と定義する．インシデントの大部分は，ユーザからサービスデスクへの照会や監視端末へ出力されるエラーメッセージやシステム障害を未然に防いだヒヤリハット等であるが，本稿はそれらのうち実際にユーザに影響を与えたシステム障害のみを対象とする．

インシデントという用語は昨今セキュリティ分野で頻繁に使われているが，本稿ではシステム障害に対象を絞って使用する．また震災対応などの大規模障害については通常の対応とは違う行動要領のため，本稿の対象外とする．

本稿の構成は次の通りである．第2章で関連研究をレビューした後，第3章で事例報告とその中で考案したプラクティスを述べ，第4章でその成果を示し，第5章で考察を行う．

2．関連研究 ─ITILのチーム活動を評価する指標と評価方法

本稿で対象とするチーム活動と成果と各指標の関係を図2に示す．図2の各四角形は能力･活動･指標を表し，矢印は影響を与える方向を表している．また，本稿で焦点とする部分を太枠とした．この図の通り，本稿ではチーム活動を「複数人の個人の能力を結集して成果を生み出すための行動」と定義する．またチーム活動を評価するための指標を「活動指標」，成果を評価するための指標を「成果指標」と呼称する．本章では指標に関する関連研究を2.1節で，その指標を用いてチーム活動を評価する方法について2.2節で述べる．

2.1　指標について

本稿では図2の活動指標に焦点を当てることから，それに関する探索を行った．

まずITILのコアブック[2]を確認したところ，インシデント管理の項目には18個の重要業績評価指標（KPI）が掲載されているが，活動指標にあたるものはなく，すべて成果指標である．

次にITILの指標に関する代表的な関連研究を確認しても本稿の目的に合致する活動指標はない．Marrone他[3]は米国･英国を中心とした世界491社の企業等に対してアンケート調査を実施して，ITILの状況を明らかにしているが，評価指標はCMMI[4]等の成熟度モデルをほぼ同じ形式で利用している．Pereira他[5]はポルトガルの5つの企業等に対してアンケート調査を実施して，ITILの状況を測定している．本研究もCMM-SVC[6]等の成熟度モデルを参考にした指標を用いているが，インシデント管理や変更管理などITILのプロセスごとに独自の質問内容を開発したところに特徴がある．Valverd他[7]は英国の歯科医ネットワークのケーススタディを用いてさらに詳細な調査を行っている．本研究は成熟度調査ではなく，独自の質問内容や評価方法を作成して精度を上げている．以上の関連研究におけるアンケート調査の質問内容は「ポリシーやドキュメントは整備されているか？」「定期的に訓練しているか？」といった項目が多く，いわば組織の成熟度を問う内容である．活動の改善を行うためにはシステム障害の1回ごとに測定できることが望ましいが，関連研究ではそこに至っていない．

一方，成果指標についてはITILをはじめさまざまなものが発表されているが，各企業等のIT部門ではMTTRを利用するのが一般的である．情報処理推進機構（IPA）が日米欧の企業等を調査したところによると，多くの企業情報システムの現場ではMTTRが使用されている[8]．MTTRは情報システムの可用性を表す指標のうち，システム障害の復旧の迅速性に焦点を当てた指標であり，障害件数をn，復旧時間をtとすると，以下の式で表される．

国内の企業等のIT部門ではMTTRに加えて，「復旧までにある一定時間を超えてしまった件数をカウントする」という指標も一部の事例で使用されている[9]．この指標はたとえば「復旧に1時間以上を要した件数を年間10件以内に抑える」と設定すれば，経営目標として利用しやすい．しかしながら，以上はすべて成果指標であり，活動指標に関する事例は皆無である．

2.2　チーム活動の評価方法について

チーム活動の評価方法については教育や学習といった分野で盛んに研究が行われている．Ohland他[10]はチーム員が相互で評価する方法を提示してその信頼性に言及し，Clark他[11]は相互評価の結果を開示する方法を採用している．古川他[12]はそれらの研究を踏まえて相互評価を統合し，それらの結果をチーム成績との関係について論じている．なお，図2は古川他から抜粋して筆者が修正を加えたものである．古川他の内容は実践的で本稿の目的と合致しており，次章で述べるプラクティスの参考にする．

3．実践 ─東京海上日動システムズ・FFAチームの事例報告

3.1　FFAチームの概要

東京海上日動システムズ（以下，同社）は東京海上日動のすべてのシステムの開発と運用を受託する情報システム子会社であり，社員数は1,362名である．親会社の東京海上日動は従業員数1.7万人，411の営業室･課･支社，244の損害サービス拠点を持つ損害保険会社である．一般事業会社の売上高にあたる正味収入保険料は2.1兆円，総資産は9.2兆円，代理店数は5.2万店である（2016年4月1日現在．小数点以下2桁目を四捨五入）．

同社では1998年の金融自由化を機に情報システムの大規模化･複雑化が急伸し，2000年頃にはシステム障害が多発して経営問題となった．そこで同社はさまざまな対策を実施してきた．2005年からはITILを導入し，システム運用部門の社員全員にITILファンデーション資格の取得を義務付けるなど，ITILの推進に積極的に取り組んできた．

同社ではFFAチームと呼ばれるシステム障害対応の専任チームを設置して成果を上げている．FFAとはFire Fighting Actionの略であり，火災発生時の初期消火に例えてFFAと称している．FFAチームには3名の専任者が配置されており，障害対応を行うための専用室（ウォールーム）も用意されている．以上の通りFFAチームは障害を発生させた部署のメンバと共に障害対応を行う体制を敷いている．図3は実際のFFAチームの活動の様子である．この図は専用室（東京･多摩市）と東京海上日動・IT企画部（東京・丸の内）をテレビ会議で結んで対策を協議している場面である．

FFAの活動内容の一例として，図1①の「初期診断」部分について述べる．FFAチームでは初期診断として，システム障害に関連するメンバを緊急に招集し，事象および影響範囲の把握を行う．具体的には次の4つの活動を行う．

障害を検知したら，即座に館内放送を使ってFFAの開催を通知し，開発担当者や運用担当者などの関係者を専用室へ招集する．なお影響範囲の予測により招集する範囲を定めており（勘定系，損害系，営業系，基盤系など），不用意にIT部門すべてが招集されないよう工夫している．

招集されたメンバと一緒に，検知時間や発見経緯や対象システムの種類といった事象の把握を行う．

どのユーザに対して，どの程度の影響を与えているのか，影響範囲の把握を行う．

システム障害が発生していることをIT部門内に周知するため，第一報の携帯メールを発信する．

以上の活動を速やかに行うためには，FFAチーム3名の相当な訓練が必要となる．

システム障害への取り組みには，①発生件数を減らすこと，②復旧時間を短くすること，という2つの目的があるが，FFAチームの役割はその後者にあたる．システム障害の年間発生件数は，2000年頃はシステム障害が多発していたが，近年では10件前後で安定している．それ故，同社における昨今の取り組み課題は，②の復旧の迅速化であり，FFAチームの活動をさらに強化することでなり，その一環として「成果だけでなく活動内容も評価すべき」との論議となり，チーム活動に焦点を当てた取り組みを開始した経緯がある．

3.2　課題解決のプラクティス－活動指標と評価方法の考案

活動指標の作成にあたっては，ITILに詳しい同社のシニアマネージャ2名がKJ法を用いて考案した．出来上がった評価指標が表1である．本稿ではこの表1を「システム障害対応の活動指標」と称する．指標は全部で9個ある．各項目の配点は5点とし，全項目で45点満点とした．

採点者によって評価にブレが生じないように採点基準も明確にした（表2）．採点基準には「FFAチームによるコントロールが可能」「偶然性の排除」の2点を備える必要がある．それらの観点から9つの採点基準を以下の3つに分類することができる．　

項目A/B/D/I）この4項目は作業内容がすべてFFAチーム内で完結しており，コントロールが可能である．また偶然性も排除されている．

項目E/F/G/H）この4項目は作業内容がFFAチームで完結しておらず，採点基準はコントロールの観点からFFAチームの作業内容に限定している．そのため，採点基準はすべて「主導する」に統一する．また偶然性も排除されている．

項目C）この項目は一見するとFFAチームでコントロールできない部分が含まれているように読めるが，同社では連絡先対象者が不在の場合も含めてFFAチームの自責であり，コントロール可能と定義している（FFAチームでは対象者に必ず連絡がつくように社内をリードしている）．また偶然性も排除されている．

評価方法としては古川他[12]を参考に相互評価方式を採用した．具体的には表3の通り，システム障害1件ごとに自分以外のメンバの活動を採点した．FFAチームの各メンバの役割に違いはないため，基本的には各項目における各メンバのすべての行動を相互評価した．その採点結果を論議して決定した代表値を「指標値」とした．これはFFAチーム3名の活動を総括的に評価するものである．採点後はシステム運用部門の責任者（執行役員）による承認を行い，採点の恣意性を極力排除した．

指標の作成に要した時間は社員1名に換算すると延べ約8時間，相互評価に要した時間は活動1回あたり約1時間であった．

3.3　指標改善の取り組み

3.3.1　対象とするシステム障害と対象期間

本稿で対象とするシステム障害は，同社で重大なシステム障害^☆3と種別されたものである．該当のシステム障害とは，たとえばネットワークのハードウェア故障により勘定系のオンラインが一時的に停止したり，処理量の増大により重要なサーバシステムのレスポンスが悪化したり，プログラムの反映ミスによりメインフレーム上の業務システムが機能不全を起こしたりといった事象である．

対象期間は2012年度から2015年までの4年間である．FFAチームでは4年間にわたり指標の取得を行った．

以上のシステム障害の種別と対象期間におけるデータ件数は，2012年度7件，2013年度11件，2014年度9件，2015年度8件の合計35件である．参考までに，対象とするシステム障害の発生部位別の年度別発生件数を表4に示す．

3.3.2　弱点の強化策の実施

指標の活用方法としては，1件ごとの障害対応の振り返りに利用することに加え，年度ごとの傾向分析で弱点を抽出してそれを改善するPDCAサイクルに利用した．

取り組み当初の2012年度の項目別の指標値をレーダチャートで表現したグラフが図4である．レーダチャートとしたのは項目間の強みと弱みを可視化しやすいからである．このグラフから指標値が2極化しており，A/B/C/D/Iが優れ，E/F/G/Hに課題があることが分かる．

FFAチームの弱点を克服することを目的として，2013年度からE/F/G/Hの強化策を実施した．以下に各項目の具体的な取り組み内容を列挙する．

項目Eの強化）速やかなデータ取得や調査の実施

システム障害時のFFAチーム3名の行動を指標から分析したところ，3名ともデータ取得の手法等にあまり詳しくないため，それを主導する際に時折遅延していることが分かった．そのため，チーム全員で勉強会を行うなど知識の習得に努めたことにより，チーム全体の行動が迅速となった．

項目Fの強化）速やかな原因の特定

システム障害の内容を調査したところ，多くは基盤系システムの変更作業時に発生していた．一方，FFAチームの3名の行動を確認したところ，1名（Aさん）の行動が鈍いことが分かった．その理由をＡさんにヒアリングしたところ，基盤系システムに詳しくないため，原因の特定の主導に時間を要していた．そのためＡさんに対して集中的に基盤系システムの学習を行ったところ，迅速な行動が可能となった．

項目Gの強化）速やかな対応策の確定

この項目の指標値が低い理由を分析したところ，対応策実施の最終判断（意思決定）が遅いことに起因していることが分かった．対応策の最終的な意思決定はIT部門長であるため，FFAチームとしては障害時には即座にIT部門長に連絡を取り（IT部門長は東京・丸の内に常駐していることから），即座にテレビ会議で結んで，リアルタイムにIT部門長が意思決定を行えるよう，チーム活動の手順を明確化した．

項目Hの強化）速やかな対応策の実施

システム障害対応には，障害発生個所の修復や代替策の実施などいくつかの対応策が考えられるが，同社ではまず「変更実施前の状態に戻す」という対応策を検討することが多い．それ故，元の状態戻すことができる変更案件では，あらかじめ手順を明確にしたところ，行動が迅速になった．

3.4　取り組み結果

前節の取り組みを推進した結果，チーム活動の指標値は大幅に改善した（図5）．2012年度（図4）と2015年度（図5）のパイチャートを比較するとE/F/G/Hの改善は明らかである．

各項目の指標値の年度推移を図6に示す．特筆すべきはE/F/G/Hの値の変化である．取り組み当初はA/B/C/D/Iの値と差があったが，2015年度には項目によっては同じレベルに達している．特に項目EとFの上昇が顕著であるが，これは前節の弱点の強化策が奏功したものと考えられる．

図7は全項目の平均点の年度推移である．項目別の強化策が奏功したことにより，結果的にシステム障害対応全体のレベルアップを実現できた．

以上の通り，本稿の取り組みがFFAチームの活動のレベルアップに貢献したことが分かる．

4．成果

4.1　MTTRの短縮

FFAチームの目的はMTTRの短縮である．その成果を確認するために，2011年度から2015年度のMTTRの経年変化を図8に示す．2011年度は373分であったMTTRは毎年着実に短くなり，2015年度には168分となり，2011年度対比45％の短縮を実現した．この図からMTTRの短縮化が実現できたことは明らかである．

本取り組みを始めるにあたりMTTRの具体的な数値目標は設けなかったが，同社ではこれは十分な成果であったと評価されている．

4.2　FFAチームの人材育成　FFAチームの人材育成

本稿の取り組みを通じてFFAチーム3名の人材育成も実現することができた．FFAチームの構成は，リーダ1名，中堅担当者1名，若手担当者1名の3名構成であるが，以前からリーダと他2名との行動面での差が大きいことが課題であった．しかしながら，今回の取り組みを通じて，担当者2名の指標値が上昇しており，彼らの育成が実現できたことが確認できた．

活動指標は社員の具体的な行動の改善を促すことから，成果指標よりも人材育成に向いており，結果的にこれも活動指標の有用性であると考える．

また本稿の手法は，チームに新たなメンバが加わる際においても，業務内容や採点基準が明文化･標準化されているため有用である．

5．考察

5.1　活動指標の有用性について

活動指標は主観的な評価が入り込む余地のある一方，成果指標では得られない利点がある．たとえば，2012年度に発生したあるシステム障害が良い事例である．その事例はインシデントのクローズまでの所要時間では良い数値を示していたが，活動指標では悪い評価であった．これは「今回発生したシステム障害は偶然に早期復旧できたが，活動としては課題があった」ことを意味している．具体的にはWeb系システムでハードウェア障害発生した際に，本来は自動的に切り替わるはずの待機系システムにテイクオーバーしなかった．その場合は手順書に基づいて手動で切り替えるのだが，その手順書が古いまま修正されておらず使用できなかった．そのとき偶然にも該当システムに詳しい社員が居たので復旧に時間は要さなかったが，もしこれが社員のいない休日･夜間ならば深刻なシステム障害に至る可能性があった．活動内容を反省すべき事例であり，活動指標を低い点数とした．

システム障害のクローズまでの所要時間はある程度は偶然性に左右される．「運良く早期復旧できた」場合もあれば，「運悪く長時間を要した」場合もある．活動指標はそういった偶然性を排除してシステム障害対応の活動自体を評価するのに適している．このように活動指標と成果指標にはそれぞれ長所があることから，企業情報システムの現場ではその両方を利用することが最善と考えられる．

5.2　成果と指標の相関関係について

MTTRの短縮という成果と指標値の相関関係を確認するため，2012年度から2015年度のシステム障害全件の復旧時間と指標値の関係を散布図で示す（図9）．両者の相関係数は−0.509であり，負の相関を示している．t検定を行うとp=0.002（<0.01）であり，1%以内で有意（両側検定）であることから，復旧時間と指標値には相関関係があることが推定される．

6．おわりに

本稿では，東京海上日動システムズのFFAチームがMTTR短縮化のためにチーム活動の指標と評価方法というプラクティスを考案した事例を報告した．それによりチーム活動の弱点を明らかにすることができた．また活動指標を用いることで，成果指標では分からないメンバの行動面での改善を促す効果があることやMTTRの短縮と活動の指標値には相関関係があることの考察も行った．

本稿は，企業等のIT部門に対してシステム障害対応の業務改善に役立つ手法を提示したことに有用性がある．ただし，この手法を他社でベンチマークする場合は，IT部門の組織文化や情報システムの特性を考慮して，指標の項目や相互評価の手法を自社用にカスタマイズする必要がある．

本稿は1社の事例報告にすぎず，一般化としては不十分である，今後は数多くの事例により実証される必要がある．その点が本稿の限界である．

本稿の手法は，問題管理や変更管理や構成管理などITILのほかのプロセスへの応用も期待できる．その際には各評価項目の採点基準の策定がポイントであり，評価対象をコントロール可能な活動に絞ることや偶然性を極力排除することに留意する必要がある．

参考文献

• 1) 岡部一詩：世田谷区 システム障害で窓口業務がストップ 共同利用形態が復旧遅れの要因に， 日経コンピュータ， 2014年10月30日号，pp.54-56 (2014).
• 2) Office of Government Commerce (OGC) : ITIL^® 2011 edition: Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement, TSO (2011).
• 3) Marrone, M. and Kolbe, L. M. : Impact of IT Service Management Frameworks on the IT Organization, Business and Information Systems Engineering, Vol.3 Issue1, pp.5-18 (2011).
• 4) CMMI Product Team : Capability Maturity Model Integration Version 1.1 (CMMI V1.1), Software Engineering Institute (2002).
• 5) Pereira, R. and Silva, M. M. : A Maturity Model for Implementation ITIL V3 in Practice, IEEE 15th International Enterprise Distributed Object Computing Conference Workshops, pp.259-268 (2011).
• 6) CMM for Service Version1.3 (CMMI-SVC V1.3), Software Engineering Institute (2010).
• 7) Valverd, R., Saade, R. G., Talla, M.:ITIL-based IT Service Support Process Reengineering, Intelligent Decision Technologies 00, pp.1-20 (2013).
• 8) 情報処理推進機構（IPA）:「情報システムの信頼性評価手法の調査報告書」，IPA Webページ（2010年3月公開）， https://www.ipa.go.jp/sec/softwareengineering/reports/20100331a.html （2016年4月17日現在）．
• 9) 情報処理推進機構（IPA），日本情報システム･ユーザ協会（JUAS）：「システム･リファレンス･マニュアル 第1巻」， JUAS, pp.394-395 (2006)．
• 10) Ohland, M. W., Layton, R. A. : Comparing the Reliability of Two Peer Evaluation Instruments, Conference & Exposition, St. Louis, MO (2000).
• 11) Clark, N., Davies, P. and Skeers, R. : Self and Peer Assessment in Software Engineering Projects, Proceedings of the 7th Australasian Computing Education Conference, pp.91-100 (2007).
• 12)古川哲郎，松石正克，松本重男，竹俣一也，山川武人：チーム活動能力の育成と評価，工学教育，55-4, pp.75-80 (2007).

脚注

• ☆1　 一般的にMTTRはMean Time to Repair（平均修理時間）の略であるが，本稿の主旨からMean Time to Recovery（平均復旧時間）の略と定義する．
• ☆2　 本稿では2017年2月時点の最新版であるITIL V3（2011年版）を前提に論議を進める．
• ☆3　 同社ではシステム障害を該当システムの重要性や影響範囲等によりスコアリングして，重大なシステム障害と軽微なシステム障害に種別している．

 

角田 仁（正会員）hitoshi.tsunoda@grp.tmnf.j

東北大学大学院修士課程（精密工学）修了後，1989年に東京海上火災保険（株）入社．2009年に早稲田大学大学院（経営戦略．MBA）修了．CISA（公認情報システム監査人）．筑波大学非常勤講師．2010年より東京海上日動システムズ（株）へ出向して，現在は同社のエグザグティブ･オフィサー（執行役員）．一貫して東京海上グループのIT戦略の業務に従事．

投稿受付：2016年12月12日
採録決定：2017年3月21日
編集担当：小林秀承（日本電信電話（株））