みずほ銀行のトラブルからソフトのバグについて思い出した話です。
みずほ銀行トラブル
前にもチョット書きましたが、仕事をしている頃に、情報システム関連の部署にいたことが有ります。
その経験から、最近のみずほ銀行のトラブルについては、色々と思うところがありました。
端的には、あんなトラブルが起こった時の担当者には絶対になりたくないなというのが正直なところです。
担当者の何人かが、胃に穴を開けていても不思議は無いと思います。
システムに、ソフトのバグなどのバグは付き物なところは有るのですが、それにしてもトラブル多すぎだろうとは思っていました。
そうしたら案の定、システム要員を削除しすぎたのでが原因では無いか、といった話が流れて来ました。
情報システムに限らず、運用、保守を軽んじるというのはありがちな話ですよね。
その挙句、なにか事が有った時に、傷口を広げてしまうんですよね。
ソフトはテストが大変
というような話を、情報システムとかプログラミングとかに関係の無かった人に話すと、まあまあの頻度で帰ってくる反応の一つが、「ソフトのバグは付き物って、ちゃんと調べて、そんなものが無いようにしてから使えばいいだろう」というものです。
御説ごもっともで、全くその通りなのですが、それがまた悩みの種な訳です。
勿論、実際に使ってみる前にテストを行います。
考えられる状況を人為的に作って、想定通りの動きをするか見て見るわけです。
その上で、バグが有れば直していきます。
ここで問題になるのは、全ての発生する可能性のある状況を用意出来るのかという点です。
特殊な場合を除いて、そんなことはほぼ不可能です。
そのため、現実的には、どこかの時点で妥協することになります。
簡単に言えば、どこまでテストをやるのかという事です。
逆に言えばこの辺りのさじ加減が腕の見せ所という事も言えます。
昔聞いたテスト法
この辺りの難しさを示す例を一つ上げます。
システム部門にいた時に、講習会のようなものに参加しました。
そこで聞いた、テストの方法論についてです。
名称を思い出せなくて、ネットで調べてみたんですが分かりませんでした。
その方法論というのが、いかにテストの終了を判断するかというものでした。
理想論は、システムのバグが全て発見された時が、システムの終了時点という事になります。
しかし、そもそもバグが全て発見されたかどうか分かるためには、バグが全て分かっていなければならない訳で、ニワトリか卵かという話になってしまいます。
そこで、あらかじめ人為的なバグを、ある数量システムに入れておいた上で、テストを行います。
すると、本当のバグと人為的なバグが、それぞれ発見されていく事になります。
一般に、最初は順調に発見されるのですが、時間と共に発見頻度は下がっていきます。
収穫逓減の法則というやつです。
ここで、当然全数が分かっている、人為的なバグの方の発見状況を、テストの進捗管理に使おうという訳です。
分からないものを管理するために、既知のデータを付加してそちらを見ればいいだろうという事です。
テストが完了したことの判断は
最初聞いた時には、なかなか上手い事考えたなと思いました。
ところが、最後まで聞いて驚きました。
テストの終了は、人為的バグの発見が横ばいになった時点とするというのです。
勿論、中には全ての人為的バグがみつかる場合もあるのですが、多くの場合、現実的な時間内でそれを期待するのは難しい、というような理由だったと記憶しています。
これはどういう事を意味するかと言うと、人為的なバグもすべて発見される訳では無いという事です。
という事は、実際のバグもすべて取り切れていないという事になります。
ずいぶん昔の話なのですが、その後完全にバグを無くす方法が発見されたという話は聞きません。
世の中で使われているどのシステムにも、バグは潜んでいると考えた方がいい、という話でした。
ではでは
