私は間違える

法則

1. SE は人間である。
2. 人間は間違えることがある。
3. したがって、SE は間違えることがある。

いきなりの三段論法ですが、これは重要なことです。SE は、慎重だったか不注意だったかにかかわらず必ず間違いをおかすものです。SYNTAX ERROR を一度も出さずにプログラムが書けるでしょうか？もちろん無理ですよね。（このホームページにだって、きっと誤字脱字があるでしょう。だいぶ慎重に作成しているにもかかわらず！）

あなたはプログラムを書くとき（もちろんあなたがプログラマーであると仮定した場合の話ですが）、自分が間違えるかもしれないという可能性を前提にしているでしょうか？あるいは会社であなたが参加しているプロジェクトチームではどうでしょうか？

システムを開発する際には、ほとんどの場合に仕様書を作成します。「ほとんどの場合」と言ったのは、仕様書を作成しないシステム開発に参加した私の経験からです（それは恐ろしく効率の悪いプロジェクトでした）が、それはさておき、仕様書と現実の仕様との同期をとるために我々は常に苦労することになります。ソフトを修正してはそれに仕様書をあわせ、仕様（書）が変わればソフトを修正します。しかし誰が間違えないと言えるのでしょう？一体誰が「めんどくさいからいいや」という誘惑に負けないと言いきれるでしょう？そしてあなたのボスは仕様書を書くのに十分な時間を与えてくれるでしょうか？かくして、現実をまったく反映していない仕様書が大量にできあがるわけです。そして次のメンテナンスを引き継いだときに「仕様書はあてにならないから気をつけてね」などと言われて唖然とするのですね。

仕様書を人類に変わって作成してくれる魔法のツールが市販されています。もちろん魔法は現実には（少なくとも SE の仕事上の現実には）存在しません。このようなツールはほとんどの場合、ソースコード中のコメントを抜き出して整理しているだけです。しかも特別な文法でコメントを書かなければなりません。コンパイラはコメントをチェックしないので、ちょっと油断すると大量の間違いが発生することは必至です。だって、コメントと実際のアルゴリズムを同期させるのは大変でしょう？

以前にひどいシステム開発を見たことがあります。

そのプロジェクトではある高級スクリプト言語で開発を行っていました。各モジュールにはただ１つのグローバル関数が含まれていて、その関数には必ず一意な識別番号が割り振られなければならないという画期的な（？）決まりになっていました。識別番号と関数名との対応表が作成され、そのメンテナンスは手作業でした。

各モジュールにはそれに含まれるグローバル関数の識別番号がファイル名として与えられました。そして作成すべきモジュールはかなり大量に存在しました。モジュールが増えるにつれて、どのファイルがどの関数なのかを調べるのが大変になってきました。そこで、ソースファイルを HTML に変換するツールが作成されることになりました。関数呼び出しをハイパーリンクに置き換えれば関数名を対応表から探し出す手間が省けるだろうというわけです。

ソースを HTML に変換するというアイディアは大変良かったのですが、そのためのツールを作る時間は十分に与えられませんでした（間接的な作業に時間を割くことを喜ぶ上司は少ないのです）。そこでツール作成を簡単にするために、関数呼び出しのときには呼び出される関数の識別番号をその行の右端にコメントで書く決まりにしました。

十分予測できることですが、出来上がった HTML は間違いだらけでした。人間なら誰でも間違える可能性があるという大前提を考慮しなかったためです。ちょっと考えただけでもまずい点がいくつも挙げられます。

• そもそもスクリプト言語はエラーチェックが甘い
• １つのモジュール内に２つ以上のグローバル関数を定義できない
• 別の関数に同じ識別番号をつけてしまうかもしれない
• 同じ名前の別の関数があるときに、対応表から識別番号を一意に決定できない。これは、同じ名前の別の関数があることに気付いていないときに重大である
• 関数呼び出しのときのコメントを書き間違えるかもしれない
• HTML のリンクをブラウザで辿るときに、誤ったリンクがあっても気付かないかもしれない。または、「せっかくこんなに便利になったのだから間違っているはずがない」と思い込むかもしれない
• などなど…

ほかにもまずい点はたくさん考えられます。あなたはあといくつ指摘できるでしょうか？挑戦してみて下さい！

どうしたら間違いをなくせるでしょう？なくすのは無理だとしても、どうやったらそれは減らせるでしょう？

いまよりももっと慎重になれば良いのでしょうか？（ちがいますよね！！）

間違いの頻度をゼロにすることは決してできません。絶対に落ちない飛行機や絶対に沈まない船や、絶対にぶつからない自動車なんてないですよね。絶対に間違えない方法もないのです。そこで発送の（おっと間違えた、発想の）転換をします。間違えない方法ではなく、間違えたら気付く方法を考えるのです。あらゆる場面で、このような誤り防止策を検討する価値があります。

プログラミングでは、間違いを検出するための方法がほぼ確立されています。それは、デバッグコードを書くという方法です。