IT Proでシステム・トラブルに関する記事が掲載された際，「原因分析が甘い。なぜそうなってしまったのかをもっと追求すべき」「ソフト業界はバグという言葉を安易に使い過ぎ」といった読者からのコメントをよくいただく。おそらく，ソフト業界とは異なる業界を経験した方なのだろう。

　記事がきちんと事実を伝えていないだけなのかもしれないと考え，トラブルを起こした各社のお詫び文を読んでみた。だが「トラブルの原因はソフトのバグ」となっている事例は少なくなかった。

　ソフトのバグは，人が作り込んだ誤りである。バグがありましたというのは，「誤りを犯しました」「誤りを見逃していました」と言っているのと同じだ。

　トラブルを起こした各社のお詫び文は決まって「今後はこのようなことが起きないように努める」とある。それまでもトラブルを起こさないように努めていたはず。これでは，甘いと言われても仕方がない。

　筆者は，冒頭の書き込み意見に同調した。原因分析が甘い。逆に考えれば，トラブルの原因を徹底的に分析し，そこから対策を見出していけばトラブルを撲滅できるのではないか。この考えを記事企画にまとめ，ネット上でサービスを提供している企業への取材をはじめた。

予想できないものは防ぎようがない

　最初の取材先のカブドットコム証券でこう言われた。

　「トラブル予防ですか？たくさんやっています。でもトラブル・ゼロにはなりません」「予想できないからアクシデントなんです。アクシデントがトラブルに発展することがありますが，予想できない以上防げませんよ」

　言葉に詰まった。

　「トラブルを起こした企業はソフトのバグが原因でしたと報告しますが，簡単に見つかるバグなら絶対に取り除いているはず。複雑な条件が重ならないと発症しないバグだったんですよ。きっと」

　予想できないものは防ぎようがない。それはそうだ。ではトラブルを無くすことはできないのか。カブドットコム証券に聞いてみた。

　「トラブルを起こさないようにする方法はあります。何も変えなきゃいいんです。機能追加をしない，利用者を限定する，ハードやソフトはバージョンアップしない――。そうすれば，トラブルは起きませんよ」「でも，経営サイドは，まったく正反対の臨機応変なシステムを求めます」

　経営サイドの要求は，利用者のニーズを代弁している。ネット・システムは変化が激しく，変化していかないと競争に勝てない。機能追加を頻繁に行い，しかも安価に提供しなければならない。そのような状況では，テストにかけられる時間とコストが限られる。自ずと想定できる範囲が限られ，予想できない事態が起きてしまうというわけか。

　企画は完全に行き詰まってしまった。「トラブル・ゼロを目指すなら顧客満足度を無視しろ」――。これでは何の役にも立たない。

「システムの安定稼働と顧客の信頼は別」

　システム担当者はどうすればいいのか。カブドットコム証券でヒントをもらった。「世間を騒がせたオンライン銀行のトラブルは，ほぼまる一日止まってしまったから（マスコミなどに）叩かれたんです。5分で復旧すれば違っていたと思いますよ」

　トラブル後が大事だということか――。

　取材を続けた。ネット上でチケット予約を提供する劇団四季では，「システムの安定稼働と顧客の信頼は別」と説明する。予約システムがダウンした場合，予約システムと切り離しているWebサイトのトップ・ページで，予約システム以外の予約の手段を案内し，顧客の信頼を確保する。「顧客はチケットを予約できればよく，システムの安定稼働を望んでいるわけではない」

　ネット上でポイント・サービスを提供するネットマイルは，以前データベース・サーバーのパフォーマンスが低下するトラブルを経験した。そのときデータベース・サーバーのリソースには余裕がなく，同社はWebサーバーの一部を意図的に停止することで，データベース・サーバーが過負荷状態になるのを防いだ。

　ネットマイルのサービスは大きくポイントの発行と参照に分かれ，同じデータベースにアクセスする。同社にとって重要なサービスはポイントの発行であり，意図的に停止したのはポイントを参照するWebサーバー。優先順位の低いサービスを犠牲にすることで，顧客にとって重要なサービスを守ったというわけだ。

　顧客の視点で見た場合，システム・ダウンやサービス停止を絶対に引き起こしてはいけないというわけではない。システムがダウンしてもその後のフォローがよければ問題は少ない。また，一部のサービスが使えなくても，重要なサービスが提供されていれば顧客の不満は小さい。

　大事なことは，システム・トラブルをゼロにすることではない。顧客の信頼を裏切らないことだ。顧客のニーズにこたえていくと，変化を許容しなければならない。変化を許容すれば，システムには常に不具合が存在することになる。このことを前提にトラブル後のフォローを考え，トラブルが発症する可能性を少しでも下げる努力をする。トラブル対策における重要な視点ではないだろうか。

（松山　貴之＝日経システム構築）

【あとがき】
本文中に書いた記事企画は，何度か企画を練り直し，日経システム構築2003年11月号の特集記事「トラブルと闘う――不具合を前提とした運用が必要」になりました。