偽札の証明

　私は「バグ取り地獄」に直面した経験がおそらくない。ここで言うバグ取り地獄とは，プログラムのバグがなかなか取れなくて，ようやくバグを取ったと思ったら今度は別の場所にバグを作り込んでしまい，その繰り返しに陥ってしまうような状況である。

　私の書くプログラムはバグの数が少なくて信頼性が高いと自慢しているわけではない。ほかのコンポーネント，例えばOSやミドルウエアとの関係で思惑通りの動作が得られず，原因究明に長い時間を費やしてしまうこともある。システムに過剰な負荷がかかった結果，予期していないところでプログラムが異常終了してしまう事態に悩むこともある。短い納期や，度重なる仕様変更などが原因で，きれいなコードを維持することが困難になり，結果として「あのプログラムにはもう触りたくない」という状況になってしまったこともないわけではない。

　ただ，言い訳をするつもりはないが，これらは外部的な要因に基づく問題に分類できる。少なくともプログラム自体の不備によるものではないと考える。コーディング上の間違いは，かなり初期の段階で明確になり，修正されているのである。

　だが一方で，「うまくやらなければきっとバグ取り地獄に落ちるに違いない」と考えていることも事実である。これまでの経験を振り返ってみると，杞憂に過ぎないようにも思えるわけだから，これは一種の強迫観念なのかもしれない。

異常系のコードにどこまで手間をかけるのか

　とにかく私は，わざわざ時間と手間をかけてエラーをトラップしたり，プログラムにトレースを入れなくてもいいようにエラーの発生した場所や原因をわかりやすくきれいに表示し，ログに記録を残したり… といったコーディングをしている。一体，何を恐れているのだろうか。

　こうしたいわゆる「異常系」のコードは，問題が発生しない場合の処理，すなわち「正常系」のコードから見れば，保険のようなものにすぎない。想定していなかった問題が起こった場合に備えて手間をかけておくわけだから，問題が起こらなければ無用の長物にすぎない。では，私が書いている異常系のコードはいったい何が起こることを想定しているのだろう。

　ユーザーに再入力を促せる入力ミスや，リトライでリカバリできるケースは正常系の範ちゅうである。ここで言う異常系とは，コーディング上は想定しづらいケースへの対応だ。しかし現実には，思ってもいないところで突然メモリーが不足したり，ハードウエアのトラブルが起こってプログラムが続行不能になればエラー検出どころではない。

　とすると，私が保険として書いておく異常系のコードが役に立つ範囲は，どこからどこまでなのだろう。手間をかけるほどの価値があるのだろうか。もしかすると私は，手がけているシステムは，その価値に比べて保険を払いすぎているのではないだろうか。何でもないことを恐れて過剰投資し，その結果不必要に工数を費やしているのではないだろうか。

　その昔，火力発電のプラントにかかわったとき，「異常系のコードは正常系の約2～3倍の量になる」と聞いたことがある。こうした経験が私を必要以上に重くしてしまったのかもしれない。トラブルが発生しても現地で立ち入り調査もできなかったり，不特定多数の人が不特定な環境でシステムを利用し，トラブルが起こってもヒアリングによる情報収集ができないような状況を経験したがゆえに，高コスト体質になってしまったのかもしれない。私が現在扱っているプログラムは，一人で把握できないほど大規模なわけではないし，何度かこけたところで人命を左右するわけでもない。もっと気楽になっても構わないはずなのだが…。

　あれこれ考えているうち，昔聞いた話を思い出した。記憶が確かではないが「偽札の証明」というようなタイトルだった。ここに1万円札がある。私が「これは私が作ったものだ。偽札だ」と言ったとする。しかし，誰が見ても，どうやって調べても本物のお札と区別がつかない。たった一つの違いは，私が作ったという事実だけである。それ以外は私を含めて，誰も偽札であるということを証明できない，というものである。

　この話はいろいろな局面に適用できて結構おもしろい。逆の主張をしてみよう。私が銀行に行って1万円札を出し「この札はなんとなく怪しい。本物であることを確かめてほしい」と言ったとする。いろいろ調べた結果「問題ありません」と答えが返ってくる。しかし，調べた人は本物であることを確認したわけではない。偽物だという事実が見つからないことをもって，本物と見なすしかないのである。

　もう一つ例を挙げてみよう。横断歩道を渡るときに「安全を確認して」と言われる。でも，すべての可能性を網羅して安全を確認することは不可能である。人間なら機転をきかして，安全でない要因が見当たらないから安全であるとみなすだろうが，ロボットに指示したら，バッテリーが切れるまで安全を確認し続けてしまうかもしれないのだ。

　「プログラムにバグがないことは証明できない」という言葉がある。これもまったく同じ理屈である。「バグがあるという事実が認められない」ことをもって「バグがない」とみなしているのである。時折勘違いしている人がいて，「プログラムの品質を上げるためにチェックリストを作りました」などと言うのを耳にする。別にチェックリストを作ること自体が品質向上に役立つわけではない。「この範囲で動作確認を行いました」という内容表明にすぎない。チェックリストの品質が低ければまったく意味をなさないのだ（そのために，チェック項目を作り出すための技術があるほどだ）。

　異常系を意識しすぎるのは，やはり過剰投資である。しかし「何かあったときにトレースを入れればいいや」というのは怠慢すぎる。プログラムに内因しないトラブルに出くわしたときに，それが自分のコーディングのせいではないということを明らかにしてくれるのは，自分が書いた例外処理のコードにほかならないのだから。