システム障害で狼少年になる

システム障害の原因の説明に失敗すると狼少年になってしまいます。

狼少年とは、いたずらで「狼が来たぞー」と叫んでいるうちに周囲から相手にされなくなり、本当に狼が来た時にひどい目に遭うという話です。

プログラムでバグを出してしまったのにそれを隠すために「ネットワーク障害です」とか「サーバが不安定だっただけです」という嘘をついてしまうという話を聞いたことがあります。しかし本当にそのような障害が発生した際に「またネットワーク？業者の選定が悪かったんじゃない？」というお叱りを受けてしまうこともあるかもしれません。また、本当はバグだったということが露見してしまった場合は信用を失うことでしょう。

このように自分の不都合を隠すための嘘をつくのはもっての他ですが、システム障害の原因の説明は一筋縄ではいかないことが多いです。システムの知識に乏しいお客様に対してわかりやすく原因を説明しようとして苦労した経験は誰もが持っているのではないでしょうか。例えばこのような説明の仕方があります。

• そもそもこのシステムはこういう動作を想定して作られており、
• 通常はこういうように動作しておりますが、
• このたびこのような想定外の入力があったために、
• このような動きになり、
• その結果こういうことが起きました。
• 今はこのような対策を施しましたので同じ現象は起きません。
• しかしながら恒常的な対策とは言えないために、
• 追加費用が……ごにょごにょ

我々、開発者側の視点で考えると何が悪くて何が起きたかだけに集中してしまいますが、お客様からしたらシステムは雲の向こう側の存在であることもあります。何かデータを放り込んだら結果が出てくるくらいにしか理解されていないような場合、まず普段の動作を説明しなくては「何が異常だったのか」が伝わりません。

また、利用者としてはやはり再発が気になります。何をしたら再発するのか、どうしたら恒久的な対策となるのか、その費用の要不要は、費用が発生する場合はその責任が開発者にあるか発注者にあるか、などの点についても説明を行うことを考えるとこっそりプログラムを修正して「サーバが不安定だったので再起動したら直りました」で済ませたくなっても不思議ではありません。そのほうが早く帰宅できそうですし。

しかしながらきちんとシステムの動作原理について説明をしていくうちに、お客様のシステム担当者の方の知識も蓄積していきます。丁寧な報告は大変なことですが、私は無駄になることではないと思ってしっかりとやることにしています。そうしていると障害が発生した際もお客様で最低限の切り分けを行った上で障害報告をしてくださることもあり、結果として停止時間を短くする事にも繋がります。

なお、最近話題のオフショア開発で某国に発注を行うと「隣のビルが火事になって消火活動で水浸しになった」という報告がよく上がるそうです。慣れた人は「で、何週間待って欲しいんだ？」と本音の交渉に持ち込むそうですが最初聞いたら信じてしまいそうですね。本当に火事があった時はどんな言い訳をしてくれるんでしょうか？