レビュー会議が失敗する背景に，典型的な三つの原因がある。それらを回避し効果を高めるには，プロセスを踏み，3回に分けて実施するとよい。レビューの専門家に，その方法とコツを解説してもらう。

細川 宣啓　　日本IBM

　みなさんの現場では，こんなレビュー会議をしていないだろうか。議論が発散して時間が掛かる割に，重大な欠陥を検出できない。議論が活性化せず，みんな下を向いている。なじり合いやケンカの場になっている─。

　そもそもレビュー会議には，スキルの高いITエンジニアが参加するはず。それなのに，どうして冒頭のようなレビュー会議になってしまうのか。

　筆者は現場の開発リーダーや品質保証部門という立場で，数多くのレビュー会議を見てきた。その経験からいえるのは，レビューが失敗に終わる背景には典型的な原因が存在し，それらを回避するための工夫やコツがある，ということだ。

　以下では，組織的なレビューの要といえる「レビュー会議」に焦点を当て，失敗に終わるレビュー会議の典型例と，その主要な原因を探る。さらにその主要な原因を踏まえて，効果的なレビューの実現に役立つ考え方，方法，コツを紹介する。

レビューが失敗する三つの原因

　まずレビューが失敗する原因から考えてみよう。筆者が考える主要な原因は三つある。

　一つ目は，レビューの目的をあいまいにしたまま，レビューアを招集することだ。その場合，「どんな欠陥を重点的に検出するか」という判断が各レビューアにゆだねられ，それぞれの観点で思い付いたことを指摘するようになる。

　そうしてレビューの観点がぶれると，どうなるか。例えば，ベテランや声の大きいレビューアの意見ばかりが重視される。彼らは往々にして上からものを言うので，レビュー会議は，設計担当者が「怒られる場」と化す。

　もっとひどいケースもある。例えば，レビューアとして参加している画面の開発担当者は，利用者に見える欠陥をつぶしたいと考え，データベースの開発担当者はデータベース項目の制御区分における処理の抜けや漏れを確認したいと思う。テスト担当者は，テスト・ケースを導き出せるかどうか，テストを実施しやすいかどうかを考える。こうしたバラバラの観点で検出した欠陥が一気に噴出すると，レビューを受ける設計担当者は，一種のサンドバッグ状態にさらされる。

　さらに悲惨な，設計担当者が「レビュー麻痺」になるケースをご存じだろうか。これは，レビュー会議を何日にもわたり実施する場合に起こりやすい。会議の場で，「何を目指して設計すればよいのか」「どんな品質を確保すべきか」という共通認識もないまま，ひたすら設計書をダメ出しされ続けると，最終的に設計担当者は「私は何をすれば許してもらえるのですか？言われたとおりに修正しますから，全部指摘してください」という心理状態に陥る。これが，レビュー麻痺である。