一般財団法人日本情報経済社会推進協会

ナビゲーションをスキップ

EN

お問い合わせ

2019.03.25

レポート

ITサービスマネジメントの実践

特定非営利活動法人itSMF Japan理事
東京海上日動システムズ株式会社
平川 歩 氏

東京海上日動のITの変遷

東京海上日動システムズ株式会社 平川様

1950年代の業務効率化、70年代のオンライン化、80年代の意思決定、2000年以降のナレッジ形成を経て、現在は、IoTやクラウドサービスを活用したデジタル戦略に取り組んでいる。保険ビジネスは、ITサービスの活用が極めて重要であり、まさにITとビジネスは一体である。私が入社した90年代前半とは比べ物にならないほど、ITサービスの重要性は増しており、それらを安定的に提供するためにITサービスマネジメントは非常に重要である。

ITSMに取組むきっかけ 

ITサービスマネジメントに本格的に取り組み始めたのは2000年頃のことである。この頃はネットワークをTCP/IP化したのち大量のサーバーを導入した時期で、ビジネスにインパクトのあるトラブルが年間約50件、平均すると1週間に1件発生しておりサービスの安定的提供、品質改善が急務であった。そのため、管理すべきサービスを定義するとことから始めた。それをもとにSLMを開始し、その後、インシデント管理に取り組んだ。その後変更管理、移管管理、サプライヤ管理、その他のプロセス整備/文書化を行い、2006年にISO/IEC 20000、ISO/IEC 27001の認証を取得した。つまり当初からISO/IEC 20000の認証取得が目的ではなく、自社の活動が正しかったことを証明するために認証を取得した。

ITSMの実践 (SLM:Service Level Management)

当社の現在のITSMプロセスをITIL 2011と比較すると図1の通りである。当初から2011に合わせることが目的でなく、自社に合ったマネジメントをしていった結果であったため、ITILとの相違点も一部にはある。

(図1)

日々の業務の中では、システムのアウトプットをサービスとして定義し、業務継続性やコストを勘案したサービスレベルを定義・合意、KPIを定めてモニタリング、数値をもとにリスク評価、課題を明らかにして改善するという継続的な改善を行っている。SLMを実践する上で最初に行ったことは、当時200~300人いた現場のメンバーにITILやISOを勉強させることではなく、「お客様はサービスを利用しているのだから『システム』と呼ぶな『サービス』と呼べ、『オペレーション』と呼ぶな『マネジメント』と呼べ」というように運用部門の指向を変えることであった。
 
サービスレベルマネジメントのポイントはサービスカタログ(EAのAsIsをベースに、エンタープライズシステムを約300のコンポーネントに分け、システムプロファイルを作成したもの)である。サービスごとに構成や可用性、利用者などを決め、どのサービスの品質が悪いのかといったようなところをしっかりとマネジメントする目的で約300のサービスを一つずつ丁寧に定義していった。

ITSMの実践(移管管理)

金融庁(所管官庁)のガイドライン等を踏まえ、当社では開発と運用の分離を強く意識している。但し、単に分離すれば良いという捉え方ではなく、開発部門と運用部門は牽制し合いながら協力して適切なサービスを作っていくことを目指している。

(図2)

当社の開発プロセスにおいては、プロジェクト計画レビューからサービスインレビューに至るまでITサービスの品質を担保するための4つのレビューがあり、これに加えて、運用部門も品質担保のために3つのレビューを設けている(図2)。開発の担当は運用部門から承認されないと次の工程に進めない。非機能要件といったような部分がアプリケーション担当者のセンスによって作られているとサービス品質が不均一となるため、決められたサービスレベルの水準を満たすためのルールを運用部門が責任を持ってチェックする。一度承認したものがサービスインした後はアプリケーションのロジックを直すといった保守の部分を除きトラブル対応を含めすべて我々運用部門がマネジメントしている。つまり、開発部門と一緒に、非機能要件やセキュリティ要件などを正式に運用部門がチェックするというルールの中で開発部門と運用部門が牽制しつつ協力し合い作り上げている。DevOpsについては様々な定義があるが、我々が考えるDevOpsは、開発手法が何であれ、開発と運用が一体となって良いものを作っていくことである。

ITSMの実践(サプライヤ管理)

サプライヤの選定ではIT企画部や開発部門が候補をピックアップし、我々(運用部門)も評価に参画している。具体的には、当社の望むサービスレベルを維持できるかを評価項目リストを使って評価している。OKであればSLAを締結する。サービス開始後は、毎月業務評価(月次モニタリング)や、国内・国外に関わらず、定期的に実地確認を行っている。このように、サプライヤの選定からサービス終了まで運用部門が関与している。

ISO/IEC 20000に関する取組み~ISO/IEC 20000-1:2011の活用~

認証取得の目的は、
 1. 説明責任を果たす
   構築したITSMSが、自己流、自己満足ではなく、グローバルスタンダートと比較して適切なものであることを確認し、お客様への一層の責任を全うする
 2. 推進力の維持
   継続的改善活動の推進力の1つとして活用する
 3. 人材(財)の育成
  ・認証取得は事務局主導ではなく、全員が関わる(目的の理解と共有)
  ・ITサービスマネジメントを学び、実践を通じて知識に変換し蓄積していくことで、SEとしてのプロフェッショナリズムにも磨きをかける
 ことであった。

 ISO/IEC 20000の認証を取得すると上層部に伝えた際には、「ユーザー系IT企業が、何故、公的認証を取得する必要があるのか?」という疑問を呈されることもあったが、上記の目的にトップが共感し、当社の重要な業務の一つと位置付けた上で「主役はお前たち」と言ってくれたことが嬉しかった。
 
2006年当時は、我々のやってきたことが自己満足ではないということを示すために、当社の運用プロセスをISO/IEC 20000-1と比較し、充足していることを示すとともに、運用プロセスはガバナンスの一部と捉えているので、COBITの各項目との関係も整理、説明し、予算や人材配置についての理解を得るのにも役立てた。
マネジメントシステムの運用において、トップの理解というのは非常に重要であり、マネジメント層を巻き込む手段としてISO/IEC 20000は非常に有効である。

2度目の認証取得

初回の認証取得から4年間は新たな課題が見つかるなど良いサイクルで回っていたが、4年目以降から指摘事項がプロセスの成熟度よりも作業のミスに対するものが多くなり認証の有効性が薄れてきたと感じるようになった。我々のISO/IEC 20000の認証取得の目的は本質的な課題を見つけることであったので、上層部の判断により2015年の認証満了後、更新を受けないこととなった。
 
しかし、我々運用部門の運営基準にISO/IEC 20000を重要な拠り所として明記し、内部監査においても「ISO/IEC 20000」の視点を取り入れることや、オンサイトでのITIL Foundation, Intermediate研修の継続など、現場のレベルアップの歩みを止めることはなかった。そして、ITサービスに関わるリスクは常に変化し、それに伴い課題は常に存在するとの考えから、それを見つけて改善するプロセスを維持しつづけるために、ISO/IEC 20000を活用し続けた方が良いという信念から、経営層に認証取得を働きかけた。自社内の継続的改善活動だけでは、自社内の常識やその時の状況の影響を受けてしまい、「やり過ぎ」や「非効率」に気付けないこともあることから、外部の審査を活用すべきと考えているからである。

2度目の認証取得の際に「変更管理のデータが更新されていない」という指摘を受けたが、それを単なる記述漏れとせず、そもそものツールの使い勝手、ひいては業務効率、プロセスを見直すことにつなげていった。一見細かな指摘と感じる内容であっても形骸化や非効率化等を改善する要素が含まれているという前提のもと、これまで以上に本質的な対応案を検討した。

ISO/IEC 20000-1:2018に関する取り組み

ISO/IEC 20000-1:2018の対訳版を読んだところ、方向性は他のフレームワークやベストプラクティス(ITIL)等と同じで、
 ● 価値にフォーカスする
 ● ビジネスとの整合性を強く意識(戦略、目的、価値)
 ● 柔軟性を高める(「すべきこと」を定義)
 ● 他のマネジメントフレームワークとの整合性を意識
していると感じた。

2011版の要求事項からの変更点については、自社のプロセスが適切に把握できていれば対応可能であると感じている。当社内において、おおよその作業はすでに完了しており、いくつかの項目についての確認作業を進めているところである。ISO/IEC 20000-1:2018への対応については、対訳版を十分読み込んで、コンセプトを十分に理解することが重要だと感じている。