4/25号の「日経ビジネス」誌を読んでいて、ふと昔のことを思い出した。記事は、「ソフトが危ない―品質危機」といったものだが、要するに世の中を支配するにも至ったコンピュータソフトウェアと、その大規模化・複雑化による諸問題といった話だ。かねてから、ハード的な問題とソフト的な問題には大きな性格の違いがあると思っていた。
ソフトウェアにはバグ（プログラムの論理上の誤り）が付きもので、そのバグをなくすのは機能の向上、性能の向上とともに開発者の命題といえる。バグが全くない、すなわちバグゼロという状態が理想であることは言うまでもないが、現実はそううまくはいっていない。ほとんどのソフトウェアは、表面化しているもの、潜在的なものを含めて、何らかのバグを持っていると言ってしまってもよいだろう。
バグとは、bugということであり、カメムシのような小さな虫を指す。プログラムに紛れ込んで悪さをすることから、そう呼ばれるようになった。
そもそもなぜバグが発生するのか？ソフトウェアというのは、あらゆる入力のパターンに対してもなんらかの対処を行い、入力に見合った出力を行うというのが基本的な動作になっている。開発者は、あらゆる入力のパターンというものを一般化し、それをアルゴリズムと呼ばれる一定の論理回路に変換し、それをさらにプログラムコードという形で具現化するということを行っている。このとき、入力パターンの一般化において取りこぼしがある、論理回路に誤りがある、プログラムコードに誤りがある、ということになればそれはバグという形で表面化する。
もっとも深刻なのは、入力パターンの一般化がうまくいっていなかったときである。シンプルな例を挙げてみる。誰かがとにかく数値を入力できることになっているとして、開発者はその入力された数値を直前に入力された数値と比較して、大小を表示するプログラムを組んだ。大小比較をしたら、今入力した数値を覚えておき、次に入力された数値との比較に使う。しかしこのプログラムは、最初に数値を入れたときにおかしなことになってしまった。なぜか？
それは、最初の入力時には、比較するものがよくわからないということだ。2回目以降なら、直前に入力された数値を使えばよい。しかし1回目では、これが何かわからない。そのため、1回目の入力に対しては、特別な処理を行わなければならない。数学の漸化式、たとえばフィボナッチ数列では、求める位置に対して2つ前の数値が必要だから、1個目、2個目では特別な結果を与えておく。
- f(1)=1
- f(2)=1
- f(n)=f(n-1)+f(n-2) n>=3
1番目と2番目の状況を想定していないと、有り得ない位置の計算を行うことになり、プログラムは一般的に異常動作する。
入力パターンの一般化を完全に行うのがどれだけ難しいかは、ほぼそこで開発者のセンスが決まってしまうことからもわかる。センスのよい開発者は、一般化をできるだけスマートな形で行うことを考える。プログラムを複雑にせず、できるだけシンプルな形で済ませようと考える。これがセンスの悪い開発者だと、一般化がうまくいかないので、複雑でわかりにくいものができあがる。いや、スマートにシンプルに行おう、ということすら考えないかも知れない。
入力パターンの一般化は、実は非常に難しい。現時点のように複雑なインタフェースを持った機器が普通になってくると、ユーザからの入力も多岐にわたり、さらにプログラムが内部に持っている状態も多岐にわたる。ユーザからの入力と、内部の状態という入力の組み合わせのすべてを想定したプログラムを書くのだ。携帯電話だって、入力はあのいくつかのボタンしかないが、状況に応じて振るまいが変わる。そういったことをすべてプログラムとして表現しておく必要がある。
プログラム論を書きたかったわけではないからこのへんにしておくが、冒頭にあった思い出したこととは、私がシステム開発部門の責任者をやっていたときのことである。そのとき、かなり(当時としては)複雑なアプリケーションを開発しており、案の定バグに悩まされていた。すでにリリース済みの製品であり、顧客からのクレームも相次いでいた。業を煮やした経営者は、私を別室に招き、こう言ったのである。
バグがゼロになるのはいつか？その日が決まったら、教えて欲しい。
真面目な私は、こともあろうにこう答えてしまったのである。
その日は永久に来ません。
プログラムの経験があれば、この一言に含む意味がわかるのだろうが、システム開発には素人同然の経営者は、この一言で切れてしまった。無責任だ、やる気がないのか、という言葉を浴びせたあげく、人を呼び、代わる代わる説得、罵倒といったことをやってのけた。この間数時間。この時間があれば、バグをいくつかはつぶせたかも、などとのんきなことを考えていた。
今ならば、もっと論理的な応答をしただろうが、若く、しかも連日のオーバーワークにはまっていた私は、やけくそ気味な返答をしてしまったのである。今ならば、
あと一週間あれば、現在発覚しているバグの90%は除去できる見込みです。
残りについての時間は不明ですが、一週間経過した時点でもっとはっきりする見込みです。
とでも言うだろうか？自分で書いていて恥ずかしいが、虚構である。空論である。何しろ、原因をこれから調べて、それに対する回復処置をするのだから、時間など読めるわけもない。おおざっぱな回答をして、とりあえずその場を逃れようというのが見え見えである。
バグとは冷静に向かい合わなくてはならない。見つかったバグは、その影響の度合いを見定めて、それに応じた対処を行う。影響度の高いものは急遽対策が取られるだろう。影響度の低いものはとりあえず放置され、次バージョンの開発時に回されるかも知れない。そういったものだ。バグはあるもの、そういう割り切りが必要だというのは、そういうことだ。
今では、バグによってプログラムが異常動作して、最悪異常終了してしまっても、編集中のデータなどを保全する処置をとることが多くなっている。たとえばMicrosoft社のWordやExcelでは、編集中のデータを自動バックアップし、もしプログラムが異常終了したりコンピュータ自身が止まってしまっても、最終バックアップ時点のデータを復活できるようになっている。
バグがゼロになるのは求められるべきであり、必要なことなのだが、プログラムを人間が作る以上は、誤りの紛れ込む余地が残されている。それを理解した上でバグに対処することが、求められるのだろう。しかし、ソフトウェアがインフラに深く入り込み、社会の安全性をも左右するような状況では、もはやこんな甘いことを言っていられないのかもしれない。いや、むしろそういう用途のソフトウェアに対しては、バグの影響度を最大に設定して、対処する必要があるということなのだろう。
修正記録：誤字を修正（2012/1/17）