ITサービス・マネジメントのPDCAを回していく上で“肝”となるのは、モニタリングだ。組織体制を含め、モニタリングを適切に実施することが、運用品質の向上および維持に直結する。そして、そうした組織や仕組みを支える人材をいかに育成していくかが、ITサービス・マネジメント実現の成否を決める。
東京海上日動システムズ 常務取締役 島田 洋之
同 ITサービス本部 ITサービス管理部長 小林 賢也
システム運用を「ITサービス」としてとらえ、いかにして業務を改善しながらシステム運用力を強化してきたか―。東京海上日動システムズにおける取り組みを紹介してきた本連載では、前回までで何度か「モニタリング」について説明してきた。
このモニタリングこそが、ITサービス・マネジメントを進化させるべくPDCAを回していく上で、最も重要な要素の一つである。そして、モニタリングを常に適切に実施し続けるためには、これを組織的に担保する体制が不可欠だ。この取り組みは、リスク管理や内部統制とも一体になっている。連載の最終回は、モニタリングを確実に実行していくための体制作りと、ITサービス・マネジメントを担う人材の育成について説明する。
モニタリングの基本
システム運用業務は、「何事も起こさない」、「何か起きた時には、定められた手順で確実に影響範囲の最小化を行う」といった業務の積み重ねである。運用担当者には自己責任として、その一つひとつの業務の確実性、妥当性についての説明責任が求められる。
説明責任を果たすためには、プロセスを管理し、その評価基準を明確にした上で、業務遂行状況を確実にモニタリングすることが必要だ。モニタリングでは「認識・評価」が重要であり、これが継続的に同じ視点で行われなければならない。
当社では毎月、ITサービスを提供する各プロセスの正確性、妥当性を確認する活動の成果物として「パフォーマンス・レポート」を作成している（図1）。認識・評価の一環だ。パフォーマンス・レポートでは、毎月の運用業務の活動結果を分析・評価してまとめている（本連載第2回参照）。
 |
| 図1●システム運用のモニタリング結果をレポートとして提出する |
また、パフォーマンス・レポートからリスクを洗い出し、分析・評価した結果を「リスクベース・レポート」としてまとめる。リスク管理の観点から認識しておくべき内容を、「サービス品質にかかわるリスク」、「サービスの継続性にかかわるリスク」、「セキュリティにかかわるリスク」の三つの切り口で分析、評価したものだ。
これをエグゼクティブ・サマリーレポートとして、当社や東京海上日動火災保険などの経営層と相互に評価する。こうすることで、効率的で実効性のあるモニタリングを実現している。
情報を共有しPDCAの輪を広げる
レポートは、単に作成や報告を目的としている訳ではない。これを作成する過程も含めて、関係者が、ITサービス・マネジメントにかかわる情報や課題を共有する意義がある。
そもそも当社ではリスク管理のPDCAを、東京海上日動などと一体になって進めている（図2）。すべてのベースになるのは、「ビジネス・リスクとしてシステム・リスクをどのようにとらえ、コントロールしていくか」を考えること。その上で、個々の運用担当者レベルから部門レベル、全社レベルに情報共有を広げていくことで、ITサービス・マネジメント全体のPDCAサイクルが回る。単純なボトムアップの体制ではない。
 |
| 図2●東京海上日動と一体で実践するリスク管理体制 |
具体的には、前述したように、毎月のITサービス・マネジメントの活動結果を「パフォーマンス・レポート」や「リスクベース・レポート」にまとめながら、運用プロセス単位での作業結果の振り返りや、改善活動を実施している。これが各プロセスごとのPDCAサイクルに当たる。その結果を、当社の取締役会に報告するとともに、東京海上日動をはじめとする利用部門に報告。それぞれの立場で相互評価を行うことで、ITサービス全体のPDCAサイクルを回す。
少し詳しく説明すると、現場レベルでは、毎日行う稼働報告会や毎週のプロジェクト進捗連絡会などがある。さらに、その上位レベルで4段階の会議を実施する（図3）。
 |
| 図3●システム運用業務にかかわる情報共有の仕組み [画像のクリックで拡大表示] |
1段階目の会議は、ITサービスの継続性に最も影響を与える「リソース状況報告会」だ。外部委託管理については外部委託事業者（アウトソーサ）とともに「業務相互評価会議」を毎月開催する。会議に参加するアウトソーサは20社超。会議を開催する代わりに書面で相互評価を行うアウトソーサは40社に上る。
次のレベルの会議は、各運用プロセスごとの評価結果を踏まえて部門レベルで実施する「ITサービス本部内・評価会議」だ。その上に位置するのが、東京海上日動システムズの「取締役会」である。運用にかかわる全社の課題を共有し、トップの決定機関として対策を議論し決定する。
さらに東京海上日動などを交えて実施する会議が最上位にある。「IT企画・月例業務報告会」や「システムズ・東京海上日動SLA報告会」が、それだ。
認識・評価を実施する体制を作る
こうした当社のPDCA活動は、ITガバナンスの成熟度を測るフレームワークであるCOBITをベースにした内部統制につながっている。内部統制のフレームワークにあるように、関係者全員が参加して相互認識・評価を実施する。これによりリスク管理の実効性を高め、内部統制機能の発揮や、リスク評価の一層の高度化を図るのだ。
ただ、そのためにはリスク管理の体制を確立しておくことが不可欠である。まずは「開発」と「運用」にかかわる役割、責任と権限を明確にする。COBITでも「IT組織の運営・権限に関するプロセスを確立すること」を求めている。もちろん当社でも運用と開発の組織を分け、リスク管理と併せて、職責や環境を分離させている。
職責の分離では、当社が担っている業務はすべて、運用か開発のいずれに属するかを明確にする。職責を分離すれば責任が明確になり、継続的なPDCAサイクルを回しやすくなるからだ。なかには、アプリケーション基盤開発支援やシステム基盤の環境構築・管理などのように、開発と運用の両方の側面を併せ持つ業務もある。従来、こうした業務は開発と運用のどちらとも言えず、責任の範囲があいまいになりがちだった。今は、基盤関連業務は運用業務と位置付け、担当する組織を基盤担当部として独立させている。
環境の分離では、当然といえば当然だが、特に本番運用環境を開発環境とを厳格に分ける。基本的に、開発担当者は本番運用環境にアクセスできない。これをルール化したり、仕組みで制限していないと、例えばシステムが想定外の動きをしている時に、開発者が、トラブル回避用に暫定的にプログラムを修正してしまう恐れがある。
リスク管理の観点では、職責と環境を分離しただけでは不十分だ。運用担当者の作業の妥当性や安全性を確保するために、すべてのアクセスを管理し、その記録を常に把握・分析しておく。運用環境を変更しなければならない場合は必ず、事前に運用部門からの評価・承認を受ける。その変更作業は、特定の運用担当者しかできないようにしておく。
「管理」と「監理」の違いを意識
さらに、実効性の高いリスク管理を実現しPDCAを実現するためには、注意すべき点がある。モニタリングの際に、「管理」と「監理」の二つを実践する意識が欠かせないということだ。
「管理」とは、個々の運用プロセスについて、現場が中心になって常に状況を点検・把握し、ITサービスを継続的に提供できるようにすること。一方の「監理」は、現場のプロセス管理が順調に進むように、経営層やリスク管理部門などが責任を持って監督・指導することである。
つまり「管理」と「監理」は、ITサービス・マネジメントの状況を把握し、よりよい方向に持っていくという点では共通するものの、実施する人の立場や視点が異なる。当社ではこれらを、漢字の部首から「たけかん」と「さらかん」と明確に区別している。その違いを運用担当者全員が意識して、業務に当たるようにするためだ。図2では、当社のリスク管理体制における「管理」と「監理」を意識して明記しているので参考にしてほしい。
