“読み方”を知って、レビューをもっと効果的に：ソフトウェアレビュー入門（3）（3/4 ページ）
ソフトウェアレビューは、ただ漫然と行うだけでは期待する成果を得られない。ソフトウェアの品質向上に寄与する効果的な“指摘”をもっと効率的に行うためには、“それなりの読み方”がある
レビューアによる“観点のブレ”を抑制するならチェックリスト
一方、自由度の高いアドホックとは対照的なのが、チェックリストです。レビューの目的に応じて、あらかじめ対象ドキュメントのチェック項目を考案してリスト化しておき、それに沿ってチェックすることで、エラー指摘の効率性・確実性を重視するスタイルです。
チェックリストの全質問を、複数のレビューアで分担する方法もありますが、全員で全質問をチェックするスタイルが一般的です。
以下の表3はソースコードレビュー用のチェックリスト例です。例えば、ID：1のチェック項目は、対象ソースコードのうち、すべての『配列を操作する部分』について、『配列のインデックス（添え字）が、配列のサイズ（インデックスの最大値）を超える可能性はないか？』チェックせよ、という意味です。1つチェックを終えるたびに「済」印を書き込んでいき、漏れなくチェックを進めていきます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
チェックリストでは、レビュー実施前に「リストを作る」という準備作業が必要です。その点、毎回イチからリストを作るのではなく、過去に類似したソフトウェアの開発プロジェクト実績があれば、過去に使われ、社内でメンテナンスされているチェックリストを使うと効率的です。
既存のチェックリストと、今回のレビュー対象がうまくマッチしない場合は、過去のバグ票を参考にしたり、品質保証にたずさわるメンバーの意見を参考にしたりしつつ、既存のチェックリストのうち、使えそうな部分だけを流用したり、改変したりするのもよいでしょう。
この技法は、担当者によって観点が大きく異なる場合や、過去のレビューで「同じパターンのエラー」が指摘から漏れがちだった場合に特に有効です。観点のブレが生じないように調整する、過去に見逃してきたエラーをリストに盛り込む、といった工夫により、そうした問題を避けることができます。
チェックリストについてまとめると、以下のようになります。
■メリット
- レビューアのスキル、観点に依存せず、安定した効果が望める
- 各種ドキュメントの作成担当者に、作成以前の段階でチェックリストを渡しておけば、エラーを未然に防げる
■デメリット
- 指摘の質が、チェックリストに大きく依存してしまう
- チェックリストを作成、管理するための工数が掛かる
- 上手に維持・管理しないとチェックリストが肥大化して使われなくなりがち
ディフェクトベースドリーディングでタイプ別にエラーをキャッチ
さて、4つ目のディフェクトベースドリーディングは、複数の“エラー指摘のシナリオ”を作り、網羅的にチェックしていく技法です（注3）。
「エラー」と一口にいっても、さまざまなタイプがあります。例えば「一貫性の欠如」「機能上の誤り」「あいまいさ」「機能不足」などです。こうした「エラーのタイプ」別に問題を発見するための“シナリオ”を事前に用意し、それに沿って各種ドキュメントを読み進めることで、より確実に各種エラーを指摘していこうという技法です。
この名称は聞いたことがなくても、このやり方自体にはなじみがある人も多いのではないでしょうか。以下の表4は、要件定義ドキュメントを対象としたシナリオ例です。シナリオはチェックすべき事柄とそれに対する質問で構成し、基本的に1人のレビューアが1つのシナリオを担当します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
こうした“シナリオ”に沿って要件定義書を読み進めることで、観点を絞り込み、より確実なエラーの発見を狙うのです。なお、シナリオは、過去の類似したプロジェクトにおけるレビューやテストで数多く発見された不具合を参考にして作成することもできます。ODC（直交欠陥分類）（注4）を用いて作成する方法もあります。
では、これについても簡単にまとめておきましょう。
■メリット
- あらかじめ「特定のタイプのエラーがあると分かっている」場合、「網羅的なエラー指摘が必要」な場合に、特に有効
- 1レビューアが1シナリオを担当することで、指摘の重複を避けられる
- レビューの観点を絞るため、より確実な成果が期待できる
■デメリット
- シナリオのでき次第で、レビュー結果が大きく左右される
- 効果的なシナリオを作るためには、時間とコストがかかりがち
Copyright © ITmedia, Inc. All Rights Reserved.