ソフトウェア開発における課題と対策(1)～小さなバグと大きな障害

ここ数カ月、飛行機のニアミスや、電車の踏切事故や脱線等の事故が相次いでいる。このような痛ましいニュースを耳にすると、情報システムの構築に携わる者として、考えさせられることが多くある。

1件の重大災害の裏には、29件のかすり傷程度の軽災害があり、その裏にはケガはないもののヒヤッとした300件の体験がある——これは、米国のハインリッヒ氏が労働災害の発生確率を分析したもので、ハインリッヒの法則と呼ばれている。ハインリッヒの法則はビジネスの世界にもあてはめられている。例えば、マスコミに取り上げられるような大失敗1件の裏には、顧客からのクレームで明らかになった29件の失敗があり、さらにその裏には顧客からのクレームはないが社員が「しまった」「まずい」と思っている潜在化された300件の失敗が存在する…というものである。

"小さな失敗"と言うと、もうひとつ、ブロークン・ウィンドウ理論(割れ窓理論)を思い出す。ブロークン・ウィンドウ理論とは、1枚の割れた窓ガラスをそのまま放置しておくと、その建物は管理されていないと認識され、割られる窓ガラスが増える。やがて建物全体が荒廃し、さらには地域全体が荒れて無秩序となり、犯罪が増える。だから1枚のガラスでも割れたらすぐに修理することが極めて効果的である——というものである。
この理論にもとづきニューヨークのジュリアーニ市長は、警察官による徹底した徒歩パトロールと軽微な犯罪の取り締まりを行った。地下鉄の落書きも消した。その結果、重犯罪が激減したという。

これらと照らし合わせてみると、情報システムの障害もまた突然に発生するものではないと言える。システム障害1件の裏には、社員が「実はテストが不調に終わっていたのだが、テスト環境は本番環境並みに回線等の資源がないため、プログラムの問題（バグ）とは思わなかった」「システム資源（プログラムやデータ等）の管理が非常に煩雑で、いつかシステム移行を誤まるのではないかとびくびくしながら仕事をしている」等、小さな失敗やヒヤッとすることがあると思われる。そして、その小さな失敗を見逃さず放置しない、必ず対策を立てる、という組織力にも問題があると推定される。昨今のインターネットによる各種サービスの普及等を考えると、情報システム障害の影響は社会的に極めて大きく、早急に改めなければならない。

昨今のシステム構築は、技術革新の著しいオープン系システムの普及とともに格段に難易度が増し、また短納期化している。そしてソフトウェアはまだまだ標準化や部品化が不十分で、一から手作りという場合が多い。追込み時期には多忙を極めこともある。しかし、だからといって「こんなに忙しいのだから少しくらいのバグや障害の発生は仕方がない」は、許されるはずはない。そのような空気・風土が最大の敵である。

ジュリアーニ市長の取組みで大きかったのは、安全に対する住民意識の変化だったと言う。軽犯罪法違反も見逃さず、どんどん取り締まるという警察の姿勢が安心感を生んでいった。システム開発現場においても、「どんな小さなバグや障害も見逃さない」という開発者の姿勢をユーザは敏感にキャッチする。ユーザは、そのようなシステム開発者には信頼を寄せる。これこそプロジェクトの円滑な遂行に不可欠な要素なのである。

ハインリッヒの法則は、小さな失敗を放置すると300倍の大失敗になって返ってくるとも言える。情報システム構築のマネージメントを行う立場にある者にとって、小さな失敗をも軽視せず、その芽を小さいうちに摘み取る作業を決して怠らないことが必須であると改めて銘記したい。