トラブルシューティングにおける社員の評価指標

ウェブ周辺のシステム開発現場では、日々がバグやトラブルの連続になります。
これをひとくくりにトラブルシューティングと私は読んでいますが、トラブルシューティングは人によっては3週間経過しても未だに解決していない、もしくは進展があまり見られないものもあれば、ある別に人がやった時は3時間で解決してしまったというケースもあります。

トラブルシューティングにかかった時間が3週間と3時間では天と地ほどの差がありますが、同じ人間でも仕事の進め方や考え方のほんのちょっとの違いがこれほどの差を生み出してしうのが事実です。

トラブルシューティングは、火災や災難、緊急時の避難などと私はかなり似ていると思います。こうした緊急系の事態になったときには、まず問題の本質はなにか？を正しく見極めることが重要です。しかし、緊急時には近視眼的に目先の火消し（課題解決）を優先してしまいがちですが、問題の本質を見極めなければ、火消しに当たっても大元から火消しをしない限り、何度もトラブルが再発してしまいます。

ここでは、以下のケースを想定してトラブルシューティングをシミュレーションしてみます。

１）スマートフォンのGPS機能を利用して、日本政府が提供する人口統計データをAPIを介してウェブサイトに取り込むウェブサイトがあったとします。


２）APIで取得したデータは、データベースサーバに保存し、ウェブサイト上では加工をしてグラフやランキングを表示します。

３）ある日気づいたら、ウェブサイトに全くデータが反映されていないことに気づきました。


さて、あなたならどうやってこのトラブルシューティングを解決しますか？

このケースのトラブルシューティングは早い人なら、3時間程度で解決できると思いますが、勘所の悪い人は1日もしくはそれ以上かかってしまいます。

まず、疑うべきポイントは　

1. エラーログが出力されるような設計であれば、エラーログ周りの確認
2. 外部サーバであるAPIが正常稼働しているか、エラーはないか
3. 内部データベースサーバが正常に稼働しているか、SQLエラーはないか

この辺です。上記ケースは非常に小さなトラブルシューティングではありますが、これを組織的に運営しているのであれば、あなた自身がリーダーとなり、これを的確に現場エンジニアに指示する、ないしは現場が持っている情報を吸い上げ、各自の知恵を周知して問題の本質にトレースできるか、それをあなた自身がリードできるかどうかは大きな評価指標であると思います。


トラブルシューティグは、自らが先頭に立って最後の最後まで責任をもってこの問題を絶対に解決する！という揺るぎない強い心を持っていることも大事です。こうしたリーダーがいる組織というのは、たとえリーダーが間違った判断をしたとしても、現場が軌道修正をおこなってくれるので、結果的に問題解決のプロセスはものすごく早いです。

一方、トラブルシューティングに3週間もかかってしまう組織では、各自が個人商店の集まりなのが特徴的です。普段から各自のコミュニケーションが必要最低限以上はとらない個人の集まりだと、トラブルシューティングが起きた時の緊迫度が3時間で解決できる組織と比べて全く違います。

これは私の持論ですが、IT業界に限って言えば、ウェブサイトのトラブルシューティング収束までにかかった時間＝その人の評価　だと思います。

トラブルシューティングを行うために、自らがその解決技術を持っている必要はないと思います。リーダーは適時それを解決できる人を見極めて指示できるかどうかです。

やはり、詰まるところとして普段のコミュニケーションの質がこうした緊急事態で火事場の馬鹿力をどれだけ発揮できるかだと思います。