Programming First Developmentは業務システム屋を救うかも知れない

「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 - ITpro

Programming First Developmentの是非は、想定している大規模システムによって変わってくると思う。業務システム開発とコンパイラ開発では難しいポイントが全然違う、というような意味で。業務屋としては、これは画期的で多くの開発者や経営者を救う提案かもしれないと思う。これから成功事例がたくさん出てくるといいなあ。

業務システムの難しいポイントは、たとえば年末調整の面倒くささなんかをイメージしてもらえると近いと思う。あれって気を使う点が２つあるよね。
　(1) どこに何を書くか
　(2) 書いた数字同士の計算は正しいか

乱暴な言い方をすると(1)が業務ルールで(2)がロジック。数字の計算ミスは技術屋でも見つけられるが、記入する場所を間違えるようなミスは事務屋じゃないと見つけにくい。
システムに置き換えると、ロジックのバグはユニットテストで見つけられるが、仕様バグ（＝業務ルールの不理解）は顧客のみぞ知る、ということ。

さらに言うと、仕様のボリューム的には以下の関係が成り立つ。
　業務ルール＞＞ロジック
シンプルで小さなロジックが膨大な業務ルールの海に埋もれている感じ。で、今まではどうしていたかというと、ひたすら客先ヒアリングを重ねて大量に仕様書を書いて業務ルールの理解に努めてきた。それでもたいてい漏れる。

だからこそ、業務システムにおいて本当の意味の「テストファースト」は「仕様バグ検出ファースト」であり「客先試用ファースト」になるべきだろう。まあそれでも一部複雑なロジックがあったりするので、そこについてはユニットテストをきちんと書こうよと。

ひがさんの提案を、そう理解した。