単体テストの失敗と開発トラブル
一昔前のシステム開発契約のトラブルの典型は、（ユーザが伝えなかったのか、ベンダが理解しなかったのかはともかく）テストの段階になって、アプリケーションの仕様が業務に合わないことが発覚し、もはや作り直すしかなくなる、というものでした。アプリケーション仕様は、業務とシステムという異質なものの接点ですから、これが難しいのは、やむを得ないところです。
ところが、最近になって、従来は力仕事と思われていたところでのトラブルが多発するようになりました。総合テストくらいの段階に至っても、単体レベルのバグが収束せずに発生し続けてテストが進まず、もはや単体テストをやり直すしかなくなる、というものです。この「単体バグ型」トラブルは、従来の「アプリケーション仕様型」トラブルよりは後の工程に原因があるため、品質強化策（実態は単体テストの部分的やり直し）のような手を打って何とか本稼働にこぎ着けられる場合もあり、直ちにプロジェクトの破綻につながるわけではありません。しかし、ベンダ／ユーザ双方の大幅な作業増、本稼働の延期、より重要な課題の積み残しなど、多くの問題を派生させ、契約上のトラブルを発生させます。
では、このようなプロジェクトでは単体テストをやっていないとか、いい加減にしかやっていないかと言うと、そうではありません。むしろ手続的な面では、従来より厳格にやっていると言っても良いくらいです。しかし、欠けてしまったものが一つあります。それは、「単体テストのチェック」です。従来は、単体テストは独立した活動というより、プログラミングという「作業」の延長程度に理解されることが多かったと思います。しかし、あくまで「作業」なのだから、その作業結果を上位者がチェックするのは当然、という意識もありました。品質は、そこで担保されていたのです。
これに対し、最近の方法論では、プログラミングはプログラミングで、単体テストは単体テスト、というように、同レベルの並列的な位置づけになっています（「共通フレーム２００７」でも「1.6.7.1」「1.6.7.2」と別個のタスクとなっていますが、必ずしも相互独立のタスクではないようです。）。別個の活動になっているのは良いのですが、位置づけが同レベルなのでプログラマ・レベルの担当者が行います。しかも、「作業」の延長ではなく、プログラミング作業にに対する独立したチェック活動なので、これに重ねてチェックを行う必要はない．．．と、無意識にこのような考えに立ってしまっているようです。しかし、平均的なプログラマが作業を終えたばかりのプログラムの品質は、残念ながら、次のテスト工程に耐えられるものではありません。
単体テスト以降のテスト工程は、言わば「統計」の世界です。品質数値を見ながら、品質を積み上げていく工程です。これに対し、単体テストは、「網羅性」を確保する最初で最後の工程です。「網羅性」のためには、数字は役に立ちません。愚直に、やるべきことをやるしかありません。ここで一度失った品質は、二度と回復することはできないからです。もっとも、このとおりにやろうとすれば、工数が倍増することも見易い道理です。品質基礎を変えると同時に、工数基礎も大きく変えてしまう、というジレンマがここにあります。