トラブルをチャンスに変えるリカバリー法【その1】：ITエンジニア進化論

エンジニアならば、システムトラブルの1つや2つは経験したことがあるだろう。何度経験しても、トラブル対応は嫌なものだ。しかし考え方1つで、リカバリーへの取り組み方を変えられるのだ。

[克元 亮，ITmedia]

はじめに

　技術革新のスピードアップやオフショア傾向の高まりなど、変化の激しいIT業界では、常にスキルアップし、キャリアを自ら築いていくという不断の努力が欠かせない。本コラムでは、エンジニアとして成功するために、身につけるべき考え方やスキルアップ方法、キャリアの築き方などを分かりやすく解説していきたい。

トラブルの対応いかんで顧客の信頼が変わる

　昨今、複雑化するシステムアーキテクチャーの中で、高機能を追求すればするほど、トラブルの火種も尽きない。単一のサーバ構成でも高い信頼性を持っているにもかかわらず、部品を2重化構成にしたばかりに導入する管理ソフトウェアが増え、それが原因でトラブルが頻発するという皮肉な例もみられる。

　最近では、ブレードサーバが普及しており、内部の部品を交換するのではなく、故障があればサーバを丸ごと交換する方法が一般的となっている。この方がコストパフォーマンスが良く、シンプルな構成で運用がしやすいからだ。つまり、構成設計の時点で、シンプルな仕組みにしておくことがトラブルのリカバリーを容易にするわけだ。

　しかし、ハードウェアのレベルでさまざまな対策を施したとしても、データのリストアなど、人間の手によるリカバリー作業は欠かせない。マーフィーの法則ではないが、トラブルは、得てして月末の締め時期など、ユーザーが忙しい時に限ってよく起きる。対応に失敗してシステム復旧までの時間が長引けば、ユーザーの信頼を失い次の新しい仕事を受注することもままならない。

　エンジニアたる者、トラブルの時こそ通常時の何倍もの力を発揮して、ユーザーを助けるよう努めなければならない。迅速に復旧処置を行い感謝されれば、対応の良さから新しい案件の受注に結びつく可能性も開けてくるのだ。

原因追求よりもいかにビジネスを復旧させるか

　エンジニアが陥りやすいのが、起きた現象に対して原因の追究を優先してしまうこと。システム開発の経験が豊富でロジカル偏重にあるエンジニアほど、原因を徹底的に追究しようとする傾向にある。

　しかし、自分が作成したプログラムやソースコードが公開されているオープンソースソフトウェアならいざしらず、Windowsなどパッケージ製品で発生したトラブルを追求していても、ブラックボックスのため調査はメーカー任せになりがちだ。理想的には原因を突き止めて解決したいところだが、短期間に解決する見通しはほとんどないのが現実であろう。

　トラブルの発生時には、「なぜ」を繰り返して思考の迷路に陥ってしまうことなく、どのようにすれば、運用への影響を最小限に抑えられるのか。理想を追わず現実的な対処で、ユーザーへのシステムサービスが早く回復するように対策を打たなければならない。

　そこで、多少のバグには眼をつぶって、ユーザーが直面している問題「システムサービスが使えない」ことを解決する方が先決となる。つまり、ユーザーの視点で、解決すべき問題は何かを意識することが重要なのだ。

　このトラブル対応には初動が肝心である。次回は、初動の方法、ユーザーと揉めたときの対処法について紹介したい。

著者プロフィール：克元亮

All About『ITプロフェッショナルのスキル』ガイド。SEのキャリア形成やスキルアップをテーマに、書籍やウェブ記事を企画・執筆。近著に『SEの文章術』（技術評論社）、『ITアーキテクト×コンサルタント　未来を築くキャリアパスの歩き方』（ソフトバンククリエイティブ）がある。日々の執筆や読書を、ブログ『克元亮の執筆日記』でつづっている。