PR

仕様書レビューに向く「インスペクション」

 レビューには、ウォークスルー、テクニカルレビュー、インスペクションといったいくつかの種類がある。その中で、プロセスや役割分担を最も厳格に定めて行うのがインスペクションだ。インスペクションは第三者(仕様書の作成者ではない他者)が介入するという特徴が、ウォークスルーやテクニカルレビューとの最大の違いだ。レビューの効果を得やすく、属人的な記述や品質のバラつきの防止につながる。

 仕様書インスペクションでは、第三者がドキュメントに対する目視検証を行う。ソフトウエアを実装せずに実施する「静的テスト」の1つである(静的テストには、ほかにプログラムを専用ツールで確認する「静的解析」などがある)。具体的には次のように実施する。

 検証の対象は、主に基本設計書や詳細設計書などの上流工程で作成するドキュメントである。確認観点の一覧である「観点チェックリスト」を参照しながらチェックを行う。観点チェックリストは欠陥が発生しやすい箇所にフォーカスを当てるためのもので、事前に定めておく。

 アウトプットは、検証対象となるドキュメントに対する指摘事項のリストだ。具体的な指摘事項の例は「ドキュメント間で記載内容が矛盾している」や「表現が曖昧で複数の解釈が考えられる」といったものだ。「インスペクター」がチェックを行い、専門的ノウハウに基づいてありがちな欠陥や見落とされがちな矛盾を指摘する。インスペクターは品質管理担当者や上流工程からの一連の開発経験者が担当する場合が多い。

 仕様書インスペクションは、一般的には基本設計や詳細設計の開発ベンダーの内部レビュー完了後、顧客レビュー前のタイミングで実施する。実装に入る前に欠陥を摘出するのがポイントだ。仕様の欠陥がバグとして顕在化する過程を考えると、実装前に欠陥を摘出する重要性を理解しやすい。

仕様の欠陥が発生するメカニズム

 仕様の欠陥が発生するのは、エンジニアの思い込みや理解不足といった「誤り」が主な原因になる。機能要件が確定した後、基本設計、詳細設計の段階で前述した誤りが「欠陥」として仕様書に埋め込まれる。欠陥は製造工程を経て、テスト工程で「故障」(いわゆる障害)として顕在化する。

仕様の欠陥が生じてテスト工程で障害として検出されるまで
仕様の欠陥が生じてテスト工程で障害として検出されるまで
(参考:ISTQB)
[画像のクリックで拡大表示]

 テスト工程で障害として発見した場合、発生原因や影響範囲の調査を行った上で、仕様書やプログラムを修正して再テストを実施する必要がある。バグの混入工程にまでさかのぼって対応を行う必要があるため、手戻りが大きい。バグへの対応コストは大きなものになる。一方、「欠陥」の段階で摘出できれば、不具合箇所を直接修正するだけで済む。バグへの対応コストはテスト工程で摘出した場合よりもずっと少ない。

 また、テスト工程でのバグ除去を適切にする効果もある。仕様の欠陥がたくさん残った状態だと、その摘出に時間と人を取られてしまう。理想的には、テスト工程の前段階で仕様の欠陥を見つけ出して修正すれば、テスト工程は実装の不良に起因するバグの摘出に集中できる。

 なお、「誤り」の段階で摘出できれば最も低コストだが、要件定義工程のタイミングでは設計における「誤り」が顕在化していない場合が多く、この段階での検知は現実的には難しい。