“読み方”を知って、レビューをもっと効果的に：ソフトウェアレビュー入門（3）（3/4 ページ）

[森崎修司，奈良先端科学技術大学院大学 情報科学研究科]

レビューアによる“観点のブレ”を抑制するならチェックリスト

　一方、自由度の高いアドホックとは対照的なのが、チェックリストです。レビューの目的に応じて、あらかじめ対象ドキュメントのチェック項目を考案してリスト化しておき、それに沿ってチェックすることで、エラー指摘の効率性・確実性を重視するスタイルです。

　チェックリストの全質問を、複数のレビューアで分担する方法もありますが、全員で全質問をチェックするスタイルが一般的です。

　以下の表3はソースコードレビュー用のチェックリスト例です。例えば、ID：1のチェック項目は、対象ソースコードのうち、すべての『配列を操作する部分』について、『配列のインデックス（添え字）が、配列のサイズ（インデックスの最大値）を超える可能性はないか？』チェックせよ、という意味です。1つチェックを終えるたびに「済」印を書き込んでいき、漏れなくチェックを進めていきます。

ID	チェック対象個所	チェック項目	進ちょく
1	配列を操作する部分	配列のインデックス（添え字）が配列のサイズ（インデックスの最大値）を超える可能性はないか？	済
2	ループ	無限ループに陥る可能性はないか？	済
3

表3　チェックリストの一例。レビューの目的に応じて、あらかじめチェックすべき個所とチェック内容を決め込んでおき、それに沿ってレビューを行う。なお、「チェック対象個所」は必須項目ではないが、設けておいた方が作業を効率化できる

図3　チェックリストのイメージ。あらかじめ作ったリストに沿ってレビューすることで、安定した観点で、狙った範囲をまんべんなくチェックできる

　チェックリストでは、レビュー実施前に「リストを作る」という準備作業が必要です。その点、毎回イチからリストを作るのではなく、過去に類似したソフトウェアの開発プロジェクト実績があれば、過去に使われ、社内でメンテナンスされているチェックリストを使うと効率的です。

　既存のチェックリストと、今回のレビュー対象がうまくマッチしない場合は、過去のバグ票を参考にしたり、品質保証にたずさわるメンバーの意見を参考にしたりしつつ、既存のチェックリストのうち、使えそうな部分だけを流用したり、改変したりするのもよいでしょう。

　この技法は、担当者によって観点が大きく異なる場合や、過去のレビューで「同じパターンのエラー」が指摘から漏れがちだった場合に特に有効です。観点のブレが生じないように調整する、過去に見逃してきたエラーをリストに盛り込む、といった工夫により、そうした問題を避けることができます。

　チェックリストについてまとめると、以下のようになります。

■メリット

• レビューアのスキル、観点に依存せず、安定した効果が望める
• 各種ドキュメントの作成担当者に、作成以前の段階でチェックリストを渡しておけば、エラーを未然に防げる

■デメリット

• 指摘の質が、チェックリストに大きく依存してしまう
• チェックリストを作成、管理するための工数が掛かる
• 上手に維持・管理しないとチェックリストが肥大化して使われなくなりがち

ディフェクトベースドリーディングでタイプ別にエラーをキャッチ

　さて、4つ目のディフェクトベースドリーディングは、複数の“エラー指摘のシナリオ”を作り、網羅的にチェックしていく技法です（注3）。

---

注3： ディフェクトベースドリーディングは、「Comparing Detection Methods for Software Requirements Inspections：A Replicated Experiment」（A. Porter、L. G. Votta、V. R. Basili／『IEEE Transactions on Software Engineering vol. 21』／IEEE computer society press／1995年）に掲載された論文で提案された技法です。

---

図4　ディフェクトベースドリーディングのイメージ。エラーのタイプ別に発見のためのシナリオを作り、焦点を絞ってレビューする

　「エラー」と一口にいっても、さまざまなタイプがあります。例えば「一貫性の欠如」「機能上の誤り」「あいまいさ」「機能不足」などです。こうした「エラーのタイプ」別に問題を発見するための“シナリオ”を事前に用意し、それに沿って各種ドキュメントを読み進めることで、より確実に各種エラーを指摘していこうという技法です。

　この名称は聞いたことがなくても、このやり方自体にはなじみがある人も多いのではないでしょうか。以下の表4は、要件定義ドキュメントを対象としたシナリオ例です。シナリオはチェックすべき事柄とそれに対する質問で構成し、基本的に1人のレビューアが1つのシナリオを担当します。

手順	シナリオ 「データ型の一貫性の確認」	シナリオ 「誤った機能の発見」
1	要件定義書のデータに関する部分に目をとおし、外部インタフェースに該当する記述を見つけてください。また、変数名、データ型、変数の取り得る値、起こり得るエラー、初期値を確認して下さい。それらの定義の間に矛盾はありませんか？ 計算結果が変数の取り得る値の中に収まっていますか？	機能要件の入出力データに関する記述をみつけて下さい。 記述は、記述ルールに従っていますか？ 出力データとしてまったく定義されていないものはありませんか？
2	機能要求から「データ参照」個所を洗い出してください。そのうえで、記述ルールに従っているか、入出力に関係のないデータ項目が定義されていないか、計算結果がデータ型、取り得る値の制約を満たしているかチェックしてください。	機能要件から分かるシステムイベントに関する記述を見つけてください。 イベント定義の間で矛盾はありませんか？
3	――	不変条件となる部分を検討し、不変条件を満たさない場合でも、ある状態に遷移できるイベント発生順序がないか調べてください。ある状態から抜け出られなくなるイベント発生順序がないか調べてください。

表4　要件定義ドキュメントを対象としたディフェクトベースドリーディングのシナリオ例。指摘したい「エラーのタイプ」別に発見のためのシナリオを作り、それに沿ってチェックする（表4は注3で紹介した論文「Comparing Detection Methods for Software Requirements Inspections：A Replicated Experiment」を参考に筆者が要約したもの）

　こうした“シナリオ”に沿って要件定義書を読み進めることで、観点を絞り込み、より確実なエラーの発見を狙うのです。なお、シナリオは、過去の類似したプロジェクトにおけるレビューやテストで数多く発見された不具合を参考にして作成することもできます。ODC（直交欠陥分類）（注4）を用いて作成する方法もあります。

---

注4： 障害管理票に基づいて障害をタイプ別に分類し、それぞれの発生件数の統計に基づいて改善すべき工程や作業を特定する分析技法

---

では、これについても簡単にまとめておきましょう。

■メリット

• あらかじめ「特定のタイプのエラーがあると分かっている」場合、「網羅的なエラー指摘が必要」な場合に、特に有効
• 1レビューアが1シナリオを担当することで、指摘の重複を避けられる
• レビューの観点を絞るため、より確実な成果が期待できる

■デメリット

• シナリオのでき次第で、レビュー結果が大きく左右される
• 効果的なシナリオを作るためには、時間とコストがかかりがち