どのようにしてプログラマは明らかなバグを見逃すのか

プラットフォーム（Web、スマホ、ゲーム機など）に関係なく、プログラムを書いていればバグを作ることはあります。 その中でも今回は「製品のローンチ後に、ユーザが低くない頻度で使う機能で、普通に操作したのにバグる」というあまり想像したくないケースについてそれが何故起こるのかを説明します。例えば、ローンチ直後のサービスでそもそもユーザログインが突破できない、みたいなやつです。

先にいうと、この問題にはまだ明確な解決策はありません。ただ、この記事ではその原因について解説を試みています。あなたの助けになれば幸いです。

唐突ですが、例えば、あなたがコップを作って売る商売をしているとします。仮に、コップを作る工程を大きく2つに分けて、形を作る工程と、絵を塗る工程としましょう。
あなたは先ずコップの形を作ります。コップに水漏れがあってはいけないので、工程の最後に必ず水を注いで水漏れがないかを確認します。あなたは水を注いで水漏れが無いことを確認できたら次の工程に進みます。
次に、あなたはコップに絵を塗ります。絵は綺麗に塗れました。しかし、あなたは絵を塗っている途中で何処かにコップをぶつけたらしく、コップに小さなヒビが入ったようです。しかも、あなたはそれに気づいていないようです。
かくして、ユーザにはヒビが入ったコップが届き、あなたは「なんでこんな明らかな欠陥を見逃すんだ！？」とクレームをうけることになります。

さて、この話から考えられることはいくつかあります。
まず、なぜ絵を塗った後にヒビ割れを確認しなかったのでしょうか？答えは簡単で、絵を塗る工程でコップにヒビが入ると思わなかったからです。逆に言えば、形を作る工程ではヒビが入る可能性があると思っていたということです。これは一般的な感覚から外れていないと思います。ですが、結果としては誤りでした。では、どうすればいいでしょうか？これも答えは簡単で、絵を塗った後にヒビ割れをもう一度確認すればよいのです。ですが、それは無視できない作業コストを生みます。

さて、ここまではずっとコップの話をしてきました。そろそろプログラムの話に戻りましょう。

この再確認のコストに対処するために私たちプログラマは様々な工夫を考えてきました。
一つ目は、総合的な動作チェックをローンチの直前にまとめて行うことです。この手法は「そもそも総合的な動作チェックは開発が一通り終わったあとにしか出来ない」という合理性からよく用いられています。しかし、その手の業界の方はよくご存知かと思いますが、プログラムの変更を要求する多方面からのプレッシャーは凄まじいものです。大抵の場合はそれに負けて動作チェック後に変更を加えてしまい、もう一度コストをかけてチェックをするか、バグがある製品を世に出すかの2択を迫られることになります。
二つ目は、動作チェックをプログラムによって自動化することです。素人感覚で見れば「その動作チェックをするプログラムにバグがあったらどうするのか。しかも自動化するコストは掛かるのでは」と思うかもしれません。これついて詳しく書くとまた文章が長くなってしまうため割愛します。しかし、何はともあれ私たちは積極的にこの手法に取り組んでいます。

こういった話に興味がある方は「人月の神話」を読んでみてください。プログラマの方でもそうでない方でも（多分）読める歴史的名著です。

人月の神話【新装版】