何事にも限度があるよねぇ・・・

製品のサポートをしていて、様々な問い合わせを受けていると、トラブルシューティングにもパレートの法則（80:20の法則）があると感じる。よく起きる80の問題は、調査時間の20、そして、なかなか発生しない20の問題に調査時間の80を割く、というようなことを。

頻繁に再現する問題は、調査する際も再現しやすいので結果的に調査に要す時間も短くなる。逆に、なかなか再現しない問題は、調査に時間を要す。10回動かせば５〜６回は発生する、という問題と、100億回動かしても１回発生するかどうか、という問題だと、当然、後者の方が調査は難しい。この発生しにくい問題が発生した場合、何がなんでも原因を特定して、問題が発生しないように対応してくれ、とリクエストされることもある。

このとき頭をよぎるのは次の点。

• 回避策はあるのか。あるとすれば、どういう回避策か。その回避策を取るコストと原因を特定するコストはどちらが大きいのか。
• 実害のある問題なのか。
• 再度やり直せば済むような問題かどうか。

事象が発生しないようになるのが一番とは言え、その原因を特定することってどうなんだろうか。発生した際の対応のコストを抑えたい、という気持ちがあるのかもしれないが、本当にそうまでして原因を特定しなければならないのか、疑問に思うことも多い。そこまで完璧を求めようとするならば、

• システム稼働中に停電になる可能性
• システム稼働中に災害等でネットワーク断線する可能性
• 某国からミサイルを撃ち込まれる可能性
• 宇宙からの隕石が衝突する可能性

とかまで考えたほうがいいのでは？というように思うことも。
もちろん、停電やネットワーク断線レベルならシステムの冗長化という比較的取りやすい対処があるから、たいていはそういうことをしているだろう。でも、最後の二つについては、「こういう問題も起こる可能性ありますがどうしましょう？」というと、アホか、の一言で終わるような気が・・・原因が明らかでも対処のしようがない問題もあるのに、今後発生するかわからない問題の原因を調べて、対応策を考えるというのは、それ自体無駄な作業と思ってしまう。

実際、ミサイルとか隕石のことまでは考えていないだろう。原因特定より、発生時の対処をしっかり決めることの方が有意義な問題もたくさんあると思うのだが。もちろん、問題が発生したときのインパクトを考えると、そこまでやらざるを得ない、というケースもあるけれど。でも、そういうケースはそう多くない。セキュリティが絡む問題くらいしか思い浮かばない。効率化を目指してシステムを使っているはずなのに、時間の使い方を非効率にしている、ということを問い合わせ内容から感じると気の毒になることも。何のためにシステムを使っているのでしょうか、と。でも、日本はそういうの多いかもな・・・