「レビューが形骸化に至る原因は、（1）コミュニケーションの問題、（2）リソースの問題、（3）事前合意や意識合わせの不備──の大きく三つある。それぞれに対策が必要だ」。奈良先端科学技術大学院大学の森崎修司 情報科学研究科 ソフトウェア工学 助教（写真）は、開発者向けイベント「X-over Development Conference（XDev）2010」で「がんばるだけのレビューになっていませんか？～実測データの分析と国際研究動向から対策を導く～」と題して講演。システム開発におけるレビューの問題点をこう指摘した。
レビューは、要件定義や設計、製造などの各工程の成果物の欠陥を、次工程に移る前に見つけ出して対処するためのもの。「製造後のテスト工程でバグをつぶすのに比べて、格段に少ない工数、コストでシステムの品質を高めることができる」（森崎氏）。しかし現実には、時間をかけたレビューを実施しても重大な欠陥を見つけることができず、ただ頑張っているだけ、形だけの“形骸化”したレビューになっている開発現場が少なくないという。
「お互いに余計なことを言わない」文化が浸透
森崎氏が挙げた形骸化の三つの原因のうち、コミュニケーションの問題とは、重大な欠陥を見つけるというレビュー本来の目的が実施メンバーの間で共有されていないことだ。そのため、「レビュアーが日頃の恨みを晴らすための攻撃手段になってしまったり、逆に『お互いに余計なことを言わない』という文化が浸透していたりして、効果的なレビューができなくなる」（森崎氏）。
リソースの問題で最も大きい原因は、レビュー対象物の量が多すぎることだ。その上、レビューの進め方が分かる人材や専門知識、業務知識を持つ人材がないため、満足なレビューを実施することができないという。
三つ目の事前合意や意識合わせの不備とは、レビューで何を指摘すべきかの事前合意がなく、指摘に対する言い訳ばかりになったり、仕様変更を要求する場になってしまったりする。その結果、「欠陥の指摘件数を目標値内に収めるための儀式のようになる」（森崎氏）。
国内外の研究技法を紹介
森崎氏は、これら形骸化の原因それぞれに対策があるという。コミュニケーションの問題や事前合意、意識合わせの問題については、レビューの目的や効果を関係者全員で事前に確認する、レビューをできるだけ早いタイミングで実施する、といった対策を解説した。
リソースの問題に関しては、レビューのやり方を見直すことで足りないリソースをカバーできるとし、国内外のレビュー技法の研究事例を紹介。具体的には、「ツールによる一部自動化」「専門・業務知識を持つ人材の担当分の削減」「特定の観点に限定したレビュー」が有効だという。
ツールによる一部自動化では、プログラムコードの事前レビューや、仕様書の注意すべき個所の自動抽出といったレビュー技法を解説。例えば仕様書の場合は、「短時間で」「～などの」「検討中」といった典型的なあいまい表現をツールによって抽出することで、目視でレビューすべき部分をリストアップしてレビュー効率を高められる。
専門・業務知識を持つ人材の担当分の削減に関しては、レビューを担当するメンバーの知識レベルに応じてレビューの質問を変える技法を解説した。
3860行/時、76％の正答率で欠陥を指摘
特定の観点に限定することで効率を高めるレビュー技法については、データを基にした分析結果を紹介。奈良先端科学技術大学院大学や日本IBMなどが共同で実施したテストの結果を披露した。Javaで記述された4500行のソースコードをレビューするときに、ユーザー認証やユーザー登録、パスワード再設定といったセキュリティの観点に絞って実施すると、3860行/時のレビュー速度、76％の正答率で欠陥を指摘できるという結果が得られた。「観点を指定していない場合よりも、レビューのスピードは格段に上がる」（森崎氏）という。
さらに、観点の絞り込みに加えてチェックリストを利用する手法についても、データを用いて示した。チェックリストを併用すれば、レビュー担当者の開発経験年数が短くても、経験年数の長いエンジニアと同等レベルの欠陥指摘件数を確保できる。
森崎氏は、これらのレビュー技法を解説した上で、「レビューは、対象となるプロジェクトの特性によって適した方法が異なる。自社で適用できるやり方かどうか、やるならどういうやり方をするかを、検討すべき」と指摘。紹介した技法はいずれもレビューの工数を削減するための手法だが、「限られたリソースで最大限の効果を上げるためのもの。既に手抜きをしているレビューをさらに手抜きするためのものではないので誤解しないでほしい」と、冗談交じりに注意を促した。
