バグを見つけ出すのはテスト工程を担当するエンジニアの仕事だ――。こうした考え方で、バグの発見と対応をテスト工程まで後回しにしている現場は少なくない。こんな現場にいるテストエンジニアと開発者は大変な目に遭う。テストとバグ修正を何度も繰り返し、リリース日に間に合わせるために残業続きになったりする。慌ただしさのあまりバグを見逃してしまい、本番リリース後に障害が発生したりもする。

 これは仕様書のレビューを十分に行わず、バグの除去をテスト工程だけでやろうとしているからだ。バグはテスト工程で生み出されるのではなく、テストを開始する前の工程で埋め込まれる。この段階では火種のようなものだ。火種は後工程へ進む中で、やがて火が付いて大きな炎となる。そうなると、バグの修正には大きな工数がかかる。

 要件定義工程における修正コストを1とした場合、設計工程での除去コストは5、テスト工程以降においては20~200にもなる(「欠陥を修正するのに要するコスト」Roger S. Pressman and Robert B. Grady(1989)から引用)。

 ソフトウエアを実行して動きを確認するテストの工程は、ほとんどの場合で開発プロジェクトの終盤に計画されている。この段階でバグ修正が必要になると手戻りが大きいし、バグがさまざまな範囲に影響している可能性がある。バグは火種のうちに摘んだ方がいい。そのために効果的な手法が、仕様書や設計書を目視で読んで問題がないかを確認する仕様書レビューだ。

プログラミング前に作り込まれる「仕様バグ」

 ソフトウエアを動かさないとバグの有無や存在箇所は分からないのではないか、と思う読者もいるかもしれない。実はバグの種類や原因は多岐にわたる。大きくは「実装の不良」と「仕様の欠陥(俗に仕様バグという)」の2つに起因し、仕様の欠陥は早い段階で見つけ出せる。

 実装の不良とは、プログラミングなどの実装工程でバグを作り込んでしまうケースだ。開発者が仕様をプログラムに正しく書けず、その結果としてソフトウエアが正しい動作をしない。「バグ」といわれると、こちらを想像する読者が多いのではないだろうか。確かに、実装の不良はソフトウエアを確認しないとバグを摘出できない。

 一方、仕様の欠陥とは、仕様の段階で問題が発生しているケースだ。要件定義や設計の担当者が要件を勘違いしたり、文書を書く際にミスがあって間違った仕様書を作ってしまったりする。仕様の欠陥があると、当然ソフトウエアは期待通りの動作をしない。

 仕様の欠陥は、プログラムを書く前の段階でバグが作り込まれている。そのため、早い段階で摘出することが可能だ。逆に早い段階で欠陥を摘出できないと、広い範囲に欠陥が影響してしまう可能性がある。仕様書レビューは、こうした上流工程の仕様書に含まれる仕様の欠陥を摘出するのが目的だ。