レビュー効果はそのままに、時間と手間を大幅削減する方法：レビューがうまくいかない理由（2）（4/4 ページ）
レビューには時間がかかるものというイメージがある。しかし案外省略できる部分は多い。レビューの無駄取りの方法を紹介する。
「（2）欠陥指摘」を効率化する方法
では最後に、レビュー会議における欠陥指摘を効率化する方法を紹介しましょう。
欠陥指摘の方法を変える
「レビュー会議で発言する必要のないもの」を省き、「必要な内容を伝えるのに時間がかかっているもの」を短くするようにします。もし、時間に余裕があれば、レビュー会議の様子をビデオで撮影して振り返ってみることをお勧めします。
筆者自身も、共同研究をご一緒している企業の方に振り返りをお勧めしています。振り返りをするまでは「時間がかかりそうですね」「ビデオを見るだけで何か見つかるんですかね」といったような否定的な意見が多いのですが、実際に試してみると、「いつも見ているので何も見つからないと思っていましたが、気付きがありました」といった前向きな感想を聞くことがほとんどです。
では、会議の時間を短くするための具体的な3つの方法を見ていきましょう。3つの方法で効果が得られるかどうかをビデオを見ながら確かめると気付きが得られやすくなります。
1.欠陥の説明を事前に考えておく
説明のための準備が不十分であり、内容を説明するために時間がかかることがあります。内容を説明し始めると「あ、やっぱり違うな」を連発しているレビューアーがいないでしょうか。何度も言い直して「やっぱり最初から説明させてください」と一から説明し直しているようでは効率化につながりません。
複雑なタイミングでの処理や込み入った更新を説明している場合に、「いや、えっと。つまりですね……」と繰り返していると時間がかかります。そこに他のレビューアーが「そこに書いてごらん」「その矢印はどういう意味で使ってるの？ その箱は他の箱とは種類が違うね」といった、その場では本質ではない表記の統一などに関するやりとりが始まるとレビュー会議はどんどん長くなります。
こうしたやりとりを減らすためにも、込み入った説明が必要なものについては、説明の事前準備をしておいてもらいます。特に、レビュー会議で初めてレビュー対象を配布している場合には、事前に配布しておいて、「事前に欠陥を検出しておいて、手短に説明できるようにしてください」とレビューアーに目を通してもらってからレビュー会議に臨むようにしてもらえるよう依頼しておきます。指摘を短くするための時間をあらかじめとっておくと、ぐっと考えるようになり、より適切な指摘ができるようになるという効果もあります。
2.欠陥や問題の指摘箇所の説明を短くする
欠陥や問題の内容を説明するよりも、欠陥や問題の箇所を説明している時間の方が長い場合があります。「43ページの表5と45ページの表8と132ページの付録の表ですが、表5の2行目、表8の7行目、付録の表の24行目を見てください。ここの間の一貫性なのですが……」「ちょっと待って、43ページと何ページ？」「45ページです」といったやりとりが意外に時間がかかります。プロジェクターに映して手早く指し示すといったことができるようにしておきます。ドキュメントレビューのツールやコードレビューのツールの中には、こうした場所の指定が簡単にできるものがあります。
3.他のレビューアーの説明を助ける
通常、欠陥を検出したレビューアーがその欠陥を指摘（説明）しますが、説明している本人が混乱していると、うまく説明できない場合もあります。そうしたときに、他のレビューアーは説明が終わるまで待っていることが多いのではないでしょうか。説明を補足できそうであれば、積極的に助けましょう（図4）。
例えば、「ネットワーク障害が起きたときに、どちらを優先して実行するかがはっきりしないという意味ですよね？」「2つのリクエストが競合する場合の排他処理ができていないということですね？」「アカウント種別に対応する権限が今後の開発で変わっていく可能性があるのであれば、もっと柔軟性のある設計にしておくべきということですね？」といった具合です。
他のレビューアーを助けることでご自身の評価を落とすことはありません。助け合いの姿勢があればレビューが円滑に進みます。
いかがでしょうか。今回紹介した効率化のポイントがレビューの効率向上につながれば幸いです。次回は効率化の次のステップとして、欠陥予防のポイントや会議をスムーズにするポイントを紹介したいと思います。
著者プロフィール
森崎 修司（もりさき しゅうじ）
名古屋大学 大学院情報学研究科 准教授
実証的ソフトウェア工学を研究の基盤とし、ソフトウェアレビュー、ソフトウェア計測／メトリクスを主なフィールドとしている。情報通信企業においてインターネットサービスの企画・開発やシステムインテグレーションに従事した経験を踏まえ、研究として議論の価値があり実務としても有益なテーマ設定を追究している。
■著書：「なぜ重大な問題を見逃すのか？ 間違いだらけの設計レビュー - 改訂版」（日経BP社）
■連載：ソフトウェアレビュー入門（＠IT情報マネジメント）／設計レビューの極意（日経SYSTEMS／2012年10月〜2013年3月）／間違いだらけのドキュメントレビュー（日経SYSTEMS／2011年4月〜9月）
■ブログ：http://blogs.itmedia.co.jp/morisaki/
■Twitter:http://twitter.com/smorisaki
Copyright © ITmedia, Inc. All Rights Reserved.