品質工学に洗脳されてしまった，ごみためまんです，どうも。
「エクストリーム・プログラミング入門」より・・・全てをテストする必要は無いということについて・・・
テストは賭けである。期待に反した時に賭けた金額がペイオフ（払い戻し）される。また，動かないと思ったテストが動いたときもテストがペイオフされる。・・・もうひとつテストがペイオフされるのは，動くと思ったテストが動かなかった時である。どちらの場合も何かを学ぶ。・・・
できるなら，ペイオフがおこなわれるテストだけを書こう。どのテストがペイオフされるかわからないので（もしわかるなら，既に何もかも知っていて，何も学ぶことが無い）・・・＠18章
「デッドライン」より・・・
14連続ビルドにおいて検出されたバグがゼロ件であった。その検査工程を主人公が「無駄だから削れ」と指示する場面＠第21章。
私は最初にXP入門を読んで，「パスするのが当たり前のテストを書くことは無駄である」と理解しました。総当りテストそのものが割りの合わない作業であると考えたのです。つまりかけるコストと見返り。
続いてデッドラインを読んで，その考えが強化されたつもりでいました。
さらに「ロバスト設計のための機能性評価」第8章には・・・
すなわち直交表の実験は，その実験で推定した利得が確認実験と一致しない。すなわち失敗した時だけ直交表の実験をした価値があるのである。
（太字は著者によるもの）
とあります。しかもその喩え話として，品質検査について
不良品を見つけられない検査は無用である。不良品を見つけたときだけ検査は価値があるのであり，検査で合格だったら，ソノ検査は無用だったのである。
という刺激的な主張も書かれています。これを見てさらに私の考えは強化されたのです。しかし同じ章のQ&Aには，この喩えについて
不良品があったとき，不良品を見逃す検査という意味です。不良品があってもそれを見逃す検査は識別能力のない無用な検査です。
と補足されています。やや混乱し，デッドラインを読み返しました。そこを理解するには第14章の「デバッグのいらないプロジェクト」を読み返す必要があります。ぶっちゃけると，いわゆる低レベル設計・詳細設計をとことんまでやることで，実装すなわちコーディング工程を最後の最後までやらないというのです。コードとほぼ1対1に対応するレベルまで「設計」をおこなえば，コーディング後の検査でひっかかるようなバグは発生しないと。そしてそれを「最終段階インプリメンテーション」と呼ぶと。
個人的な経験では，確かに実装中に設計上の不具合を見つけると，関連するモジュールに手戻りが波及しいろいろ大変です。しかも根本対策するためには，コーディネートが必要となり，非常に厄介です。しかしそれはバグではなくて設計ミスなんです。
そんなことを考えていると頭の中でチャイムが鳴りました。
つまりデマルコさんは，ほとんどのバグはいわゆるバグすなわち実装ミスではなく，設計ミスが原因だと言っているのです。（←第18章をよく読め，ごみためまんよ。）設計ミスと言うよりは「悪い設計」あるいは「設計が甘い」と言うべきかもしれません。
つまり実装以降の工程の生産性をあげるには，良い設計をするに限るというわけです。
ここまで来て，いままで上り坂だとおもっていた道が下り坂に見えてきます。進むべき道は合っていたのに，方向がさかさまだったことに気づいたようなものかもしれません。
デマルコさんが書いているのは品質工学的視点からの視界だったのではないでしょうか。品質工学でいう「品質が欲しければ品質を測るな」というスローガンで言い表される哲学です。
従来のデバッグやテストは，まさにバグの件数やパフォーマンスを「モノを作った後で」計測しています。そしてそれをもって品質だとしています。すなわちテスト工程で検出されるバグが少なければ品質が高いというわけです。
でもそうではない。品質は設計時に決まるのであるから，それを具現化する作業である実装後にいくら品質を測ってもだめなんですな。
あとはソフトウェアと品質工学的SN比の話なので，そういうタグチ氏の著書にあたってみることにします。
いずれにしても，品質工学的見地からデマルコさんが21章の後半を書いていたのだとすれば，ただただオドロキです。
もう1歩。XP入門へ戻ります。期待に反するテストを書くべし，というのはマチガイではなく。これを「パスするのが当たり前のテストを書くことは無駄である」と理解することがビミョウに間違っているということなのですな。微妙というか，もはや禅問答ですな。
