品質がスケジュールよりも優先される理由

CMMIを作ったハンフリーが書いた本「ソフトウェアでビジネスに勝つ」を読んでいる。
mgさんのコメントを書きながら、考えたことをメモ。

【元ネタ】
アジャイル開発は受託開発の方が向いている: プログラマの思索

「ソフトウェアでビジネスに勝つ」の本は、経営者向けに書かれたソフトウェア管理に関する考察した本。
第1章に、SW管理の原則が3ついきなりあげられるが、その一つに「品質がスケジュールよりも優先する」という原則がある。

SW開発に従事している人ならば、この原則をいつも実感しているし、逆に、この原則に逆らうような仕事をしているのも事実だ。
設計や開発という工程よりも、テスト工程でこの原則を実行すべきかどうか判断に迷う。

仕様変更が来たけれど、バグ修正を優先すべきか？
バグ修正よりも、目先のタスクをこなすべきか？
全てのテストをし尽くしてバグをたくさん出してから、バグ修正すべきか？

今、僕はTestLinkで結合～受入テストを管理していて、「品質がスケジュールよりも優先する」の原則の重要性を改めて感じている。

TestLinkでは、テスト実施結果をリアルタイムに表示できるので、テスト実施数だけでなく、成功ケース数、失敗ケース数、ブロック数を毎日集計できる。

仮に、テスト中のテスト計画にあるテストケース数が500ケースあったと仮定しよう。
開発チームあるいはテストチームは、500個のケースをこなしていくと、必ず失敗するケースが発生して、バグが出てくる。

この時に、テストケース同士で依存するケース数が平均10個だと仮定しよう。
例えば、Amazonのような小売系Webシステムならば、カート画面のテストの次に注文画面のテストケースがあるから、カート画面と注文画面のテストケースは依存していることになる。

すると、テストケースが1個失敗するたびに、バグが1個増えて、依存するテストケース10個が「ブロック」になる。
理由は、依存するテストケースは、テストしたとしても必ずバグが出る「みなしバグ」だからだ。
つまり、ブロックしたテストケースは、一生懸命にテストしたとしても工数の無駄だ。
バグが修正されなければ、テストしても無意味なのだ。

今、仮に、テスト計画の全テストケースを実施して、失敗率が5％だったと仮定しよう。
すると、失敗ケース数やバグ数は25件あり、依存するテストケースは250件だから、ブロックするテストケース数は250件になる。
つまり、500件のテストケースのうち45％しかテストで「成功」、つまり、品質が確保されたに過ぎず、残りの55％はテストで確認すらされていない状況になる。

更に、失敗率が10％だったと仮定しよう。
すると、失敗ケース数やバグ数は50件になり、ブロックするテストケースは単純に数えると500件になる。
つまり、10％以上失敗したら、殆ど全てのテストケースが「みなしバグ」の状態なわけで、もはやテストしても工数の無駄。

結局、テストよりもバグ修正を優先しなければ、テストすら終わらない。
バグ修正よりも仕様変更を優先したとしても、みなしバグが多発した状態で機能追加したとしても、状況は一段と悪化するだけだ。

「ソフトウェアでビジネスに勝つ」本では、品質が良ければテスト工程が短縮されてスケジュールは前倒しになる、と書かれているが、おそらく上記のような事実を指しているのだと思う。

TestLinkの良い所は、上記のような事実を過去のテスト実績から集計して分析できることだ。
過去のテストから、バグが頻発した要件は注意したり、あるいは、過去の開発でバグが多発した要件のテストケースを再利用して、念入りにテストするといった戦略を取る事もできる。

アジャイル開発というよりもソフトウェア開発のプロジェクト管理が、品質・コスト・納期の三角形ではなく、スコープ・コスト・納期の三角形でマネジメントする理由も同じだ。

ソフトウェアの品質を優先すれば、自然にコストは下がり、スケジュールも短縮できる。
「品質がスケジュールよりも優先する」原則をIT技術者は再考すべきではないか？