システムダウンの原因はIT部門内にあり!?

ギャップ分析でダウンタイムを最小限に

ギャップ分析でITプロセスの欠点を洗い出すことにより、システムダウンの発生を大幅に減らすことができる。

公開 2009年09月08日 07時30分

更新 2012年09月04日 17時49分

著者

Niel Nickolaisen

[TechTarget]

印刷する

　「事業継続」とは正確には何を意味するのだろうか。わたしは長い間、事業継続はディザスタリカバリ計画の一部であると考えてきた。障害が発生した場合に、障害から復旧するために事業継続計画を実行するものだと考えていたのだ。

　そういったときに、わたしの友人のCIOがシステムのダウンタイムに関する調査の結果を話してくれた。

　この友人は、会社で発生したシステムダウンタイムの各インシデントを詳細に分析したのだ。彼は各インシデントについて、ダウンタイムの原因までさかのぼって調査した。この原因分析の結果、彼の会社のシステムダウンタイムの70％以上が自社のIT部門が自ら引き起こした原因によるものだったという。

　例えば、未検証の変更を実業務システムに加えたために、一時的にシステムがダウンしたというようなケースだ。新しいカスタムコードを導入したら、運用中のデータベースとコンフリクト（機能干渉）を起こしたという場合もある。電源コードがどの機器につながっているのか確認するために、それをコンセントから引き抜いたりする人もいるかもしれない。このCIOは、部下のITスタッフが実業務システムをダウンさせるような行為をやめるだけで、システムのアップタイムを70％改善できることをすぐさま理解した。しかも、これらの改善は、彼と部下のITスタッフが完全にコントロールできるのだ。

　友人からこの調査結果を聞かされた後、わたしにとって事業継続は新たな意味を持つようになった。継続的事業活動はディザスタリカバリ計画の一部ではなく、業務活動の「標準モード」であるべきだと考えるようになったのだ。災害から復旧する能力が必要であることには変わりはないが、それは信頼されるIT部門を運営する能力の一部なのだ。

　わたしは継続的事業活動という新たな目標を設定し、独自の分析を実施することにした。それはシステムダウンタイムの原因分析ではなく、自社のITプロセスの「ギャップ分析」である。パッチを適用する前にそのテストを行わない、電源コードがどれにつながっているのか知らない、開発ツールとデータベースとの互換性問題を把握していない、といった問題につながるプロセスの欠点を洗い出すのが目的だ。

　このギャップ分析では、IT部門の中で技術知識が最も乏しい人間を見つけることにした。彼にさまざまなプロセスの中を“歩かせる”ことにより、新米のスタッフがうっかり落ち込んでしまう恐れがある穴を特定させようとしたのだ。幸いにも、この任務に最適な知識不足の人間を見つけることができた。それはわたし自身だった！

　わたしは疲れ果てるような徹底したプロセスレビューを実施したわけではない。パッチを適用するプロセス、コードの変更を本番環境に導入するプロセス、変更を検証するプロセスなどについてスタッフに説明を求めたのだ。その説明に基づき、ギャップ分析を3つの部分に分けることにした。

ギャップ分析の目的は、ITプロセスがスタッフの業務にどのように貢献できるかを確認することである。スタッフを責めることが目的ではない。スタッフを責めても、プロセスの改善につながることはめったにない
ミスの可能性を減らすには、プロセス内のどの穴をふさぐ必要があるのか
スタッフ全員が理解して順守できるようにするために、プロセスをどのように簡素化すればよいのか（わたしはずっと以前に、プロセスが複雑化するほどミスが起きやすいことを学んだ）

　これらのプロセス改善の導入を進めるのに伴い、自社の事業継続能力が向上していった。予期せぬダウンタイムが発生することもまだあるが、その頻度は大幅に減少した。ダウンタイムが発生しても、それは変更管理、プロジェクト管理、サービス管理、コミュニケーションなどにかかわるITプロセスをさらに改善する機会を提供してくれるのだ。

　また、復旧作業が必要な災害が万一発生した場合に備えて、効果的かつ迅速な復旧を可能にする強固なプロセスも確立された。

本稿筆者のニール・ニコライゼン氏は米HeadwatersのCIO兼戦略計画担当副社長。

印刷する