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

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

“目的のない間違い探し”が一番よくある失敗

　さて、以上からレビューの定義と目的、メリットをあらためて確認できました。ただ、もう1つ考えておきたいのは、「テストに比べると、なぜレビューは形だけの、なおざりなものになりやすいのか？」ということです。

　確かにレビューという取り組み自体は浸透しつつあります。しかし、テストでは一般的になりつつある「テスト計画」や「テスト実施報告」といったエビデンスを残す取り組みまでは浸透していません。エビデンスを残すとしても、せいぜい指摘エラーのリストくらいです。つまり、“読んで問題点を発見する”という一見シンプルな取り組みゆえか「どうやってもいい」と解釈されている例が多いわけですが、それによって「何のために行うのか」という目的意識まであいまいになっているケースが多いのではないでしょうか。

　例えば、対象ドキュメントをぱらぱらとめくって、誤字脱字を10カ所くらい指摘するだけでもレビューを実施したという形だけのエビデンスは作れてしまいます。逆に、レビューの時間をたっぷりと確保して、テスト・保守・セキュリティの専門家を迎えて問題点をビシビシ指摘してもらってもいいわけです。しかし、両方ともレビューとしては十分とはいえません。レビューを行う最終的な目的は「ただ問題点を見つける」ことではなく、前述のように「ソフトウェア開発の円滑化、低コスト化に貢献する」ことにあるからです。

　つまり、レビューで最も大切なのは目的意識なのです。具体的には「いま開発に取り組んでいるこのソフトウェアの開発作業を円滑化、低コスト化するためには、どこに重点を置いてレビューを行うべきか」を考える──すなわち、各開発案件の内容や状況に応じた個別の視点、テーマを設定したうえで取り組むことが大切なのです。

　例えば、いま作っているソフトウェアの次のバージョンで大がかりな再設計が予定されているのに、ソースコードの保守性にかかわる部分を重視するのは時間と労力の無駄です。それよりは機能性にかかわる部分のミスを重点的に洗い出すべきでしょう。前述した「ぱらぱらとめくって誤字脱字を10か所くらい指摘する」という例は論外ですが、「専門家を呼んでビシビシ指摘してもらう」という方法も必ずしも正しいとは限りません。目的がはっきりしていない以上、洗い出される問題点の数こそ違うでしょうが、開発作業の円滑化、低コスト化に必ずしも寄与するとは限らないからです。

　ただ漫然と“校正”をする──これがレビューで最も犯しやすい失敗です。しっかりとした目的意識を持ち、何を重視するかを決め、そのために、どのような準備をし、どのような手順で行うのかを考えることが、レビューを生かす前提条件となります。まずはこうした基本認識を持ったうえで、個別の問題について考えていきたいと思います。

指摘した“つもり”になっているだけにしない

　では早速、事例に入りましょう。皆さんの周りではこんなことはありませんか？

レビューアA　「あれ？ そこ、タイムアウトしたときの処理を1つ追加してほしいってレビューで指摘したつもりだったんだけど……」

修正担当者　「そんなのありましたっけ」

レビューアA　「記録を見てごらん」

修正担当者　「手書きのメモしかないんですが……書いてないですね」

レビューアB　「うーん……。僕もそのタイムアウトの件では、『ほかとの整合性が取れるように、そろえてほしい』といったように記憶している。それがつまり『処理を追加してくれ』という意味だったんだけど」

修正担当者　「……書いてないですね。でもBさんの指摘は確かにメモがあります。ただ、『そろえてほしい』というのは、その直前まで話していた“タイムアウトした際のエラー画面のレイアウト”についてだと思っていました」

　もし、こんなことが起きているようであれば、レビューの場での記録方法の見直しが必要です。こうした失敗は、主に以下の3つが原因になっているのです。

1. フォーマットなしのメモ程度の記録で、エラー指摘に必須の項目（対象ドキュメントのページ番号、指摘項目など）が記録されていない
2. 記録担当が記録するよりも速いペースでエラーが指摘されてしまい、記録を取りこぼしている
3. 記録内容について参加者の間での確認、合意がないままレビューを終えている

　レビューにおいて、エラー指摘の記録は非常に重要です。では、指摘内容の取りこぼしを防ぎ、レビュー結果を確実に開発作業の効率化に生かすためには、具体的にどうすればよいのでしょうか。レビューの基本となる“正しい記録方法”を紹介しましょう。