freee151108298700_TP_V-2

コンピューターシステムは、常にトラブルと背中合わせの状態で稼働していると言っても過言ではありません。仕事で使うシステムがいったんトラブルを起こすと、業務が停止したり復旧に多大な労力がかかったりして大変な事態に発展します。

そのためシステム開発会社では、何とかしてトラブルを避けたいという思いが強まります。その結果、トラブルが起きたら「再発防止」という名目のもとで何週間もかけて原因追求を行っている会社もあると思います。

そのような再発防止の施策を打ちたくなる会社の気持ちも、わからなくはありません。しかし、実はトラブルの再発防止を目的とした原因追求にはほとんど意味がないのです。

ここでは、トラブルが起きたときに後から原因追求を行ってもほとんど意味がないと考える理由についてお話ししていきます。ここで述べる内容を理解することで、システムトラブルの事後対処に関する正しい考え方を学ぶことができます。

真の原因は、調査者の意図によって塗り替えることができる

システムがトラブルを起こすのはどのようなときでしょうか。それは、次の2つに分けて考えることができます。

  • ハードウェア障害 – サーバーコンピューターやネットワーク機器などの機械が故障し、正常に機能しなくなること
  • システム障害 – システムで動作するアプリが不具合を起こし、正常に機能しなくなること

例えば、サーバーコンピューターがハードウェア障害を起こしてシステムが停止したとしましょう。そしてこのようなトラブルについて、後から真の原因を追求することになったとします。

このトラブルの真の原因は、どのようになるでしょうか。それは、原因調査を行う担当者の立場によって変わってしまうのです。

例えば、原因調査の担当者がシステム開発会社の保守サービスマンだったとします。すると、その担当者は「トラブルの原因は、サーバーを作ったハードウェアベンダーのせいだ」と言うでしょう。

一方、原因調査の担当者がハードウェアベンダーの製造責任者だったとしたらどうでしょうか。そのような場合、その担当者は「トラブルの原因は、サーバーで使っているハードディスク(補助記憶装置)の品質が悪く故障したためだ。したがって、ハードディスクを作ったベンダーのせいだ」と言うのではないでしょうか。

あるいは、原因調査の担当者がユーザー企業の情報システム部門の人だったとします。すると、その担当者は「トラブルの原因は、そのようなサーバーを採用してトラブルを未然に防止できなかったシステム開発会社のせいだ」と言うかもしれません。

これでは、結局のところ真の原因がどこにあるのかわからなくなってしまいます。ほとんど、責任のなすり合いの世界になってしまうのです。同じようなことは、システム障害(アプリの不具合)でも起こります。

すなわち、システムトラブルの「真の原因」は原因調査を行った人の立場で変わってしまいます。起きてしまったシステムトラブルに関して、真の原因を深く追求していくことに意味がないと考える理由が、ここにあります。

システムトラブルには、より深刻な脅威が起こる前兆ととらえて対処する

システムは、多くの精密機器や複雑なプログラム構造を持つアプリが協調して動いています。そのため、システムの中にトラブルの要因は無数に潜んでいると考えるべきです。発覚したトラブルは、そのような無数の要因の中からたまたま一つが目に見える形で発生したに過ぎないのです。

一つのトラブルが起きたことで、他にもっと深刻なトラブル要因として潜んでいたはずの事象が起きずに済んだということもよくあるのです。

そのように考えると、たまたま発覚したシステムトラブルについて「真の原因」を探ることにあまり意味がないということがおわかりいただけると思います。トラブルが起きたときの対処法として大切なのは、「トラブルから迅速に復旧すること」「同種のトラブルを未然に防ぐ手を打つこと」なのです。決して、原因究明は重要ではありません。

このように、システムトラブルが起きたときの対処としては「トラブルからの迅速な復旧」と「同種のトラブルを未然に防ぐ方法を模索すること」が重要であると考えられます。誰もが、システムトラブルは起きてほしくないと考えます。しかし、トラブルは悪ではありません。

したがって、もし不覚にもトラブルに見舞われてしまったら「より深刻な脅威が起こる前兆として、システムが運良く止まってくれたのかもしれない」というくらいにとらえたいものです。そしてトラブルに対しては、正しい対処を行っていくことが重要です。