最近、『The Atlantic』に掲載された非常に重苦しい 記事 「The Coming Software Apocalypse」（きたるソフトウェア大惨事）を読み終えました。同記事は最初のうちは、人に傷害を与えたり、人の命を奪ったりした恐ろしいソフトウェアバグについて述べており、いい内容です。しかし、途中から急に残念な展開になっているのです。

同記事の著者はソフトウェア業界の多くの思想的リーダーにインタビューをしましたが、 Light Table 、 モデル駆動工学 、 TLA+ といった新しい技術を生み出したリーダーだけを選んでいます。

私はこうしたツールに何ら反対しているわけではありません。Light Tableプロジェクトに資金提供さえしました。優れたソフトウェアツールは優れたソフトウェアを書きやすくすると思います。しかし、ツールは「大惨事」に対する解決策ではありません。

著者は同記事において、プログラマが概して不規律であるという可能性を検討していません。また、Kent BeckやWard Cunningham、Martin Fowlerといったソフトウェア専門家にもインタビューしていません。著者は、プログラマの仕事の質さえ向上すればソフトウェア大惨事を回避できるかもしれないという考えを、完全に避けています。そして、ソフトウェア大惨事の回避、つまり質の悪いコードをなくすには、もっとコードを書くことが必要だと信じ切っているように見えます。

私は同意できません。ツールは便利なものですが、ソフトウェア大惨事の回避に必要なのは、ツールを増やすことではなく、プログラミング規律を向上させることなのです。

昨晩、『 Wisdom of the Crowd 』（原題）のパイロット版を見ました。CBSの面白い新シリーズです。ストーリーの主人公は、娘を殺害された、巨大なソーシャルネットワークプラットフォームの考案者です。彼は何もかも捨て、犯罪の解決にクラウドソーシングを活用する新しいソーシャルネットワーク「Sophie」を作ります。

この番組は、プログラマの監修を受けなくてはなりません。というのも、見ていて恥ずかしくなる1場面があったからです。誰かが犯罪現場の動画をSophieに投稿します。それを基に捜査員がある方向で調べるものの、うまくいきません。その後、投稿された動画が実際はもっと長いもので、明らかな証拠が含まれていたのに、Sophie上で30秒に切り取られたせいで捜査員がその証拠を見逃していたことが判明するのです。

主人公は激怒しました。殺人犯は逃亡したかもしれません。被害者が増えたかもしれません。彼は主任開発者に、事態の原因は何かと問いただしました。すると、プログラマの1人が別のプラットフォームのコードを一部再利用したが、30秒に切り取られる機能が組み込まれていたことに気付いていなかったと告げられます。彼は激怒し、そんなにずさんなプラグラマは誰なのかと迫ったものの、主任開発者は明かすのを拒みました。彼女は主人公に、誰かを解雇したいなら私を解雇するべきだと告げます。主人公は引き下がりました。

その後、問題のプログラマは、自分を守ってくれた主任開発者に感謝し、「あのコードを再利用するべきではないと分かっていたが、急ぎだった」と弁解します。主任開発者は彼にほほ笑み、気にしないようにと伝えました。

この時点で、皆さんはこの大惨事の原因も明らかな解決策もお分かりでしょう。

原因：

1. スケジュールの重圧から、手っ取り早いずさんな方法を取るプログラマがあまりにも多い。
2. それで問題ないと考えてカバーする周りのプログラマがあまりにも多い。

明らかな解決策：

1. ソフトウェア規律とプロ意識のレベルを上げる。
2. 手っ取り早いずさんな仕事の弁解をしない。

これこそ、前述した『The Atlantic』の記事の著者が完全に見落としている点です。著者が考慮しなかったのは、人の命を奪ったり金銭的大損害を出したりするバグ、つまりソフトウェア大惨事に私たちが直面する理由は、スケジュールがきつければ仕事が不完全になっても構わないと考えているプログラマがあまりにも多いということです。

その長文記事の中で、テストの概念が解決策として全く検討されていないことには驚きました。テストは、見込みのない愚かな望みとして言及されているだけなのです。ある箇所で、著者はバグについてこう述べています。

必要なテストを全て行っても、バグを全部発見することは決してできない。

これは真実かもしれませんが、規律としてのテストを放棄したり、減らしたり、増やさなかったりする理由にはなりません。

著者の挙げたいくつかのツールは、REPLを良く言ったものにすぎません。REPLは、プログラマがコードの結果を即座に見られるようにするものです。

そのように素早くフィードバックが得られるのは素晴らしいことだと思います。非常に有益だと思います。ですが、REPLはテストの代用にはなりません。

プログラマが「REPLでテストした」と聞く度、私はうんざりします。REPLでするのは”テスト”ではありません。”試し”です。テストは、試しよりもはるかに正式なものです。テストは、繰り返すことができます。質的に向上できます。増やすことができます。レビューできます。より規模の大きいテストスイートに追加することができます。テストはドキュメントです。テストは”プログラム”です。

解決に必要なのは、より優れたREPLではありません。モデル駆動工学でもありません。ツールやプラットフォームでもありません。より優れた言語でもフレームワークでもありません。

確かに、それらはキラキラと光り輝いています。しかし、

ブルータス、これは運命ではなく、私たち自身のせいだ……

数日前、大勢のプログラマに向かって、私の恒例の質問を投げかけてみました。「定期的にユニットテストを書いている人はどのくらいいますか」。手を挙げた人は5％もいませんでした。