“確実な記録”こそが、品質・コストに貢献する：ソフトウェアレビュー入門（1）（3/4 ページ）

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

記入フォーマットを整備しよう

　レビュー会議には4つのポイントがあります。1つは「指摘内容を項目ごとに分けて記入する、記入フォーマットの整備」、2つ目は「取りこぼしなく、きちんと記録できているかの確認」、3つ目が「レビュー会議進行中の指摘内容の確認」、4つ目が「レビュー会議終了間際の指摘内容の見直し」です。

　中でも1つ目のポイント、「指摘内容を項目ごとに分けて記入する、記入フォーマットの整備」は、確実なレビューを行うための基本中の基本となります。レビューで押さえるべき項目をまとめたフォーマットを定義しておけば、これに沿って会議を進めることで、指摘内容のモレや、修正担当者の未決といった初歩的なミスを防ぐことができるのです。

　以下は記入フォーマットの一例です。大きく上部3分の1と下部3分の2に分けており、上部はレビューの属性を、下部は個々のエラー指摘を記録する部分とし、それぞれに細分化した記入項目を設けています。

図1　記録用のフォーマットを用意しておくことで、ポイントをついたレビューを効率よく進められるほか、指摘内容の確実な理解、共有を実現する（クリックで拡大）

　上部のレビュー属性欄には、会議の日時、参加者指名などの記録欄を設けます。中でも「対象ソフトウェア／システム」欄は必須です。後で参照した際、何のレビュー結果だったか分からなくなってしまうことが意外にあるのです。下部にはエラーの指摘内容を記録しますが、最低限、以下のような記録項目を作っておくことをお勧めします。

ID

　個々の指摘の識別子となるものです。個々の指摘を修正するとき、IDがあれば確実に行えるほか、ほかの文書で個々の指摘を参照させたい際などにも便利です。また、それぞれに関連性がある指摘の場合、「1-1」「1-2」といった具合にグループ化したIDを付与すると、第三者が見ても正確に関連性を理解できます。

ファイル名／ページ番号

　指摘の対象がドキュメントの場合、ドキュメントID、ファイル名とドキュメント名称、ページ番号を記入します。ソースコードの場合は、ファイル名を記入します。こちらも指摘対象の誤認を防止するためです。

項目/行数

　対象がドキュメントなら章、節番号、段落数、行数を、ソースコードなら関数名、メソッド名、および行数を記入します。行数だけではなく、章、節番号、関数名、メソッド名とともに記入する理由は、ほかの指摘を反映した際にドキュメントやソースコードの行数が変わってしまうためです。手掛かりが行数だけでは、まだ反映されていない指摘か所を見つけにくくなってしまいます。

指摘内容

　指摘内容を記入します。その際、「?が正しくない」といったように問題点のみを記入するのではなく、「?との整合性が取れておらず、正しくない」「?の場合が考慮されておらず正しくない」といったように、「正しくない理由」とともに記録しておけば、いつ閲覧しても正しく理解できます。

修正担当者

　指摘内容について、誰が修正、確認を行うか、レビュー会議の場で決めて記入しておきます。特に関係者の人数が多い場合や複数の担当者にまたがる指摘の場合、まずはこれを確実に決めておかないと修正モレの原因になります。必ず担当を決めてからレビュー会議を終了してください。

---

　なお、今後、連載の中で紹介していきますが、「誰の視点でチェックするか、視点を定めたもの」「決められた不具合だけに着目するもの」など、レビューでのドキュメント類の読み方（リーディング技法）には複数の方法が存在します。このうち、今回のように「特に決まったルールを定めず、気付いた点を指摘していく」基本的な読み方を「アドホックリーディング」と呼び、図1はそれに最適なフォーマットとなっています。

　この図1のExcelデータ「アドホックリーディング記録様式」を、私が所属する奈良先端科学技術大学院大学のソフトウェア工学講座のWebサイトからダウンロードすることができます。ぜひ使ってみてはいかがでしょうか。

関連リンク
「アドホックリーディング記録様式」ダウンロードページ（奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア工学講座）