「システムトラブルはたまに起こったほうがよいのですよ」。ある物流大手の経営企画担当者と話をしているとき、そんな発言が飛び出した。一見、暴論のような発言だが、よく話を聞いてみると極めて理に適っていた。

 物流業では、日常的に発生するトラブルをいかに克服するかが、ビジネスにおける重要なポイントになるという。確かに、いつ交通渋滞、あるいは交通事故に巻き込まれるか分からない。トラックが故障することもあり得る。宛先の記載が誤っている場合もある。だが、そうしたトラブルに遭遇しようとも、荷物を約束した期日に顧客のもとに届けるというサービス品質は守り通さなければならない。

 そんなわけで、物流業はあらゆるトラブルに対処するためのノウハウをため、実際にドライバーらが適切な行動を取れるように訓練しているという。システムトラブルも数あるトラブルの一つにすぎない。もちろん全く起こらないなら、それにこしたことはないが、たとえトラブルが発生しても人間系で対処できるわけだ。

 ところが、想定外の極めてレアなシステムトラブルが起こると現場は辛い。全くの未経験のトラブルに現場はお手上げになってしまう恐れがある。だから、システムトラブルはたまに起こったほうがよい、という理屈になるわけだ。

 考えてみれば、情報システムの開発においても、技術者はあらゆるトラブルを想定している。システムの利用者がどんな操作ミスを犯したとしても、システムが誤動作したりダウンしたりすることのないように、エラーロジックを書く。いわゆる“バカよけ”のロジックである。

 このバカよけのロジックは、利用者がバカなことをしないようにするためには大変有効だが、困ったことに副作用がある。利用者を本物のバカにしてしまうのだ。

 ビジネスは本来、トラブルやエラーの連続だ。むしろ、そうした出来事に対処し乗り越えることが、ビジネスパーソンの仕事の本質と言ってよい。だがシステムのエラー処理が一見完璧だと、そのシステムを使ってビジネスをする人は、いつの間にかシステムに依存してしまう。少なくともシステム化されている業務プロセスの範囲では、トラブルやエラーを想定しなくなる。

 だがシステムに完璧はない。バカよけのロジックが欠落していたりすると、いずれ“想定外”の事態に立ち至る。当事者はパニックになり、適切な対処ができず被害を拡大する。典型例が、2005年12月に起こった株大量誤発注事件だ。みずほ証券の誤発注を東京証券取引所のシステムが受け付けてしまい、結果的にみずほ証券は400億円以上の損害を被った事件だ。損害賠償を巡る裁判は依然として継続しており、証券業界やIT業界に残した爪あとは大きい。

 結局のところ、システムを使う側もバカならば、システムを作る側もバカである。なぜなら人間だからだ。人間は必ずミスをする。ところが日本人、特に技術者は真面目だから「絶対にミスやトラブルがあってはならない」と考える。それ自体は良しとしても、いつの間にか「絶対にミスやトラブルは起こらない」という油断にすり換わってしまうのは問題だ。

 さすがにシステムトラブルをたまに起こして訓練するのは難しいが、トラブルは必ず起こると想定し、現実的な対処法を決めておくべきだ。「動かないコンピュータ」の問題の本質はシステムトラブルではなく、そこから生じるビジネストラブルである。

出典:日経コンピュータ 2013年4月4日号 p.81
記事は執筆時の情報に基づいており、現在では異なる場合があります。