今回は品質管理の重要性と、その品質の確保に最も効果が高いといわれるレビューを中心に述べる。レビューは品質確保のためだけでなく、第三者が実態をつかみにくい設計の進捗状況や出来上がり状況を見るのにも大事である。
 |
日本のソフトウエア品質は世界最高水準にあるという、米MIT（マサチューセッツ工科大学）のマイケル・クスマノ氏の報告がある。品質を大事にするのが日本の特徴だが、最近は短納期が増えてきたこともあり、品質に対する感覚が薄れ、納期、コストを優先的に考え失敗する例が増えていることは残念だ。Q（品質）が不十分なままで、C（コスト）やD（納期）を無理に守ろうとするのは本末転倒である。仮にCとDを守ったとしても、結局はQ対策に時間を取られたり追加費用が掛かる宿命に追い込まれてしまう。
最近よく見られる現象は，仕様決定が遅れ、この遅れを取り戻そうと十分に設計しないまま次の工程を急ぎ、結果としていつまでもバグが収まらず、苦戦することである。こういうときこそ“急がば回れ”だ。やるべきことを省略しても決していい結果は得られない。もし納期が絶対条件なら、まず顧客責任者の顔が立つ最低限の必須機能に機能を絞り込んで、着実に対応すべきだろう。
 |
テストは一見易しく見えるが極めて難しい仕事である。テストの第1の課題は、「要求機能が動くことの確認」だ。ある機能を確認するといっても、1件のテストではその機能の1ケースしか確認できず、とはいえ全ケースの確認は無理なだけに、どのケースを選べばよいかの難しい判断が必要になる。
第2の課題は、「バグのないことの確認」である。この確認も原理的には無限のテストが必要だ。もう少し現実的に、「バグの発見」を課題にしても、どこにどんなバグがあるのか分からない状況下でバグ探しをするわけだから、「あてのない犯人探しをする」ような難しさがある。有限の予算と期間の中で、どういう条件下で何をテストすればよいかを考えなければならない。
対象がはっきりしている「プログラム設計」より、何を対象とするかをまず決めなければならない「テスト設計」のほうが、難度の高い仕事と言えるのではないだろうか。
 |
テスト工数はシステム開発工数の30～50％を占めると言われるだけに、テストを効率的にかつ効果的に実施することは極めて大事なことだ。そのためには、コーディングが終わってからテストのやり方を検討するのではなく、システムの基本設計が固まってきたら、設計部隊が詳細設計に入ると同時に、テストの設計を立ち上げることである。設計がまとまるころには、テスト方式もまとまり、そのテスト方式に基づいて、テスト・ツールやテスト・データがそろっているように準備しなければならない。
優れたテスト方式を設計するためには、トップクラスの設計者の中から、少なくとも１人を引き抜いて、テスト設計のリーダーに割り当てる必要があるだろう。これを場当たり的にやっていると、絶対見つけるべき不良を見逃したり、テスト時間ばかりかかり効果のないテストをやらざるを得なくなったりしてしまう。
 |
「テストはエラーの存在を示せるが、エラーがないことは示せない」という『Dijkstraの法則』と呼ばれるものがある。テストによってバグが発見されないからといって、ソフトの品質を保証することはできないのだ。さらにバグが発見されなかったのは、単にテストのバグ検出力が弱かったためなのかもしれない。
設計者が十分テストしたと自信を持っていても、全パスの5～6割程度しか網羅していないと一般に言われているだけに、管理者は設計者だけにテストをやらせず、設計者とは別の担当者の目で冷静にさまざまな角度からテストや機能確認をさせる必要がある。
また、テスト・ツールやテスト機器の改良に努め、テストによるバグ検出力の強化に努めなければならない。
