レビューは３回やれ？
『日経SYSTEMS』２０１０年３月号に、「設計ミスをなくそう」という特集が組まれています。
その中で、「Part3−３回に分け実施すれば重大な欠陥を検出できる」（日本IBM 細川 宣啓氏）という記事を読んでみて、色々と思うところがありましたので、自分なりにまとめてみようと思います。
※見出しは細川氏のものを、詳細部は私の意見も交えたものとしています。
１．レビューが失敗する原因
細川氏は、レビューが失敗しがちな理由として、３つの理由をあげています。
（１）レビュー目的を明確にしないこと
欠陥を抽出したいのか、制御フローの改善案を決めたいのかなどの目的をはっきりさせずにレビューを開始してしまうと、レビューアの観点がブレるため、レビューが収束しなくなりがちです。
過去に私が経験したプロジェクトでは、「ひとまずレビューしよう」ということで始めたら、各人が自分の意見を言いっぱなしになり、また欠陥指摘が収束しなくなり、結果チームがバラバラになってしまったという苦い経験があります。
（２）時間的なプレッシャー下で行うこと
レビューはよく、工程の終盤に１回だけなど、時間が厳しいときに行うことが多いです。
そもそもレビューに割く時間が厳しいと、適切な指摘を行う余裕がなくなります。
また、レビューアがレビューイを慮り、今指摘しても対応できないなと考えてしまい、指摘が十分でなくなるということもよくあります。
そもそも、工程の最後に１回だけレビューして収束するわけがないんですよね。
（３）喧嘩になってしまうこと
レビューアの中には、「正しいことを言う」ことに集中しすぎて、
相手の気持ちを尊重しない物言いをしてしまう人がいますよね。
例えば、「それはおかしい」とか「その方法はダメだ」など、まず相手を否定するような物言いをする人たちです。
（個人的な意見ですが、自分に自信がある人や、「技術寄り」な人にそういう傾向が強いような…）
人間、まず否定されると頭に来るものです。
そうしてしまうと、いくら指摘が正しいものであっても、感情的なしこりができたり、喧嘩になったりします。
２．レビューを成功させる工夫
上記のような失敗原因を踏まえ、細川氏は次のような工夫が必要だと説きます。
（１）計画・準備・実施のプロセスを踏むこと
- 計画：無理のないレビュー計画を織り込み、レビューアをアサインする。
- 準備：レビューの観点を統一し、また指摘事項を事前にまとめておく。
- 実施：観点に基づき指摘を行い、それを縦・横へ展開する。
レビューイではなく、レビューアにより多くの準備を求めているところが、示唆に富んでいると思います。
（２）レビューを３回（３段階）に分けて実施すること
- 初回 ：上記のプロセスに基づくレビューに、メンバーを慣れさせる。
- ２回目：統一した観点で欠陥を抽出し、それを縦・横へ展開する。
- ３回目：漏れをなくし、成果物を完成させる。
３．所感
細川氏の意見、および『日経SYSTEMS』の特集全般を読んでみて、レビューの観点がブレがちという共通認識が業界でまだできていないことと、レビューの観点を統一することの重要性を考えさせられました。
私は以前、レビューの観点を統一しようとすることは、レビューの視点を狭めてしまうので良くないのでは？と考えていたことがありました。
また、事前にレビューの方向性を決めることは卑怯なのではないか？という風に思っていたこともあります。
ですが、これまでの自身の失敗の経験から、私も最近のプロジェクトでは、事前にレビューの観点を伝えるようにしていました。
お互いに時間の余裕がないことが多いので、焦点・議論を収束させるには、この方が実務上良いんですよね。
また、時間のない相手を慮るということにもなるので、決して卑怯ではなく、むしろ好ましいことだったりするんですよね。
また、「事前に観点を伝え統一しておく」という手法は、要件定義などでも使えます。
実際にやっていますが、短時間で意見を集約できるので、ユーザにも好評です。
自分の考え方・やり方を裏付けする情報を見つけると、自信になりますね。
