技法の分類とテンプレート（基本編）

アドホックリーディングの記録テンプレート

　図2はアドホックリーディングの記録テンプレートです。シートはここからダウンロードできます（878_1.zip/13.0 KB）。また、筆者の研究グループのWebサイト（http://se.aist-nara.ac.jp/html/review/formats.html）からも入手できます。図2はテンプレートの一部です。

　テンプレートの最上部はインスペクション／レビュー記録の管理情報です。

　「対象ソフトウェア/システム」の欄には、インスペクション／レビューの対象が何であるかを記入します。特に類似の機能やサブシステムが多い場合には明確にしておかないと何に対する指摘結果かがわからなくなりがちです。

　「会議体」の欄には、同期型(前回の記事で紹介しました)で実施した「工数」は参加者の工数を合算したものを記入します。アーキテクトやマネジャー等の工数は重み（何倍かする等）を付ければインスペクション／レビューの効果をより正確に測れるようになります。

　それ以降の部分（グレーのヘッダ部分以降）が、インスペクタ／レビューアの指摘結果を記入していく部分です。1件の指摘を1行に記入します。指摘個所（「ファイル名/ページ番号」列「項目/行数」列）、「指摘内容」列は必ず記入します。これらの項目よりも右の列は必ずしもすべて埋める必要はありません。「エラー/質問/要確認」列を記入すれば、指摘に対してどのようなアクションをとればよいかが、わかりやすくなります。

　「事由」「重要度」「混入工程」列を記入しておけば事後分析（混入されがちな欠陥の分析、改善策の考案）に役立ちます。事後分析のための記入項目を増やすと振り返りや分析へのインプットが増えますが、記録コストはあがります。また、これらの項目は全指摘について記録しないと事後分析の効果が出にくいでしょう。

　「修正担当者」「修正期限」列は管理用の項目です。指摘が一通り終わった時点で、指摘ごとに、誰が修正するか、いつまでに対応するかを決めて記入します。担当者を決めておかないと、指摘はされたものの結局修正されないということになりますので、アサインを忘れないでください。

　インスペクション／レビューでは、欠陥の指摘のみで具体的な修正方法は検討しないのが通常ですが、指摘内容や修正担当者によっては、修正方針や対応を決め、「修正内容、検討結果」列に記入しておいたほうがよい場合もあります。また、指摘は必ずしも修正する必要はなく、制限事項としたり、顧客と折衝したり、次期開発への申し送り事項にしたりする等の解決策もあります。

　「修正確認者」「完了日」列はフォローアップのためにあります。指摘にそった修正がなされているか、誤って修正されていないか、デグレードの可能性がないかを確認します。

アドホックリーディングの効果と限界

　アドホックリーディングは、読み方をインスペクタ／レビューアに強制しませんので指摘結果が読み方に限定されない点、読み方の準備コストが必要ない点で優れています。また、周知のためのコストも少なくてすみます。エキスパートであっても「いやー。そこまで考えていなかった」というような指摘が出て、インスペクション／レビューの効果に快感さえもおぼえてしまうのは、アドホックリーディングの醍醐味（だいごみ）といえるでしょう。

　その一方で、指摘の品質がインスペクタ／レビューアに大きく依存してしまう点、指摘項目が的外れになってしまう可能性がある点、インスペクション／レビュー対象、インスペクション／レビューに慣れていないメンバは何をしてよいかが明確にイメージできない点がアドホックリーディングの限界です。また、インスペクタ／レビューアと対象成果物の作成者の間でどのような指摘をすべきかの意識が異なっていると「なんでそんなところまで...」というような不協和を起こすこともあります。