前回の記事では、ピアレビューの各種方法について紹介しました。
これが分かれば、あとは導入するだけです。
なんだ、簡単じゃないか（*'-'）
と、思うかもしれませんが、なかなか上手くいかないのです。
慣れてないとレビューは難しい
レビューとは
「目視によって成果物の欠陥を発見する」ことです。
ただ、人は機械ではないので、効果を上げるまでには、どうしても
「慣れ」が必要です。
また
「欠陥の発見」に集中することも難しいのです。
私の経験した
「よくないレビュー」を紹介したいと思います。
議論や評価になってしまう
よくあるのが、欠陥を発見した後、
その解決法や、欠陥が混入した原因について
議論してしまうことです。
それはレビュー以外の場所で行わなければいけません。
特に、ミーティング形式のレビューの場合は、
十分にレビューを行う時間がなくなってしまいます。
また、
製作者の評価を始めてしまうレビュアーが稀にいますが、これもよくありません。
あくまで「成果物のレビュー」に集中する必要があります。
テストの代わりにしようとする
どういうことかというと、
レビュアーがすべての欠陥を発見しようとしてしまう、という間違いです。
これは、もちろん不可能です。
以前、私が参加していたプロジェクトで、協力会社の開発者から
レビューのコストが高すぎて、作業に支障が出ている
とクレームが入ったことがあります。
よくよく話を聞いてみると、
すべてのソースコードに対して、
すべてのコーディング規約を目視でチェックする、
ということをしていたようです。
そりゃ、時間かかりますよね。。。
レビューはあくまで
次の工程に進む前に目視で欠陥が見つかれば、
手戻りコストよりも安いよね
くらいの心構えで行った方がよいです。
成果物の品質は、各所で様々なチェックを行いながら
段階的に上げていくものです。
完成品をレビューしてもらおうとする
例えば、設計書を
完全に書きあげてからレビューを行い
レビュアー「お前、これ根本的に要求から間違ってるよ」
なんて言われたら目も当てられません。すべて書き直しです。
また、分量の多い文書のレビューは、レビュアーの負担も高く、
特に
文書の後半に見落としが多く発生してしまいます。
レビューは目的を明確に
レビューは、こまめに行った方が負担が少なくて済みます。
そのときに注意したいのは、
レビューの目的（何をレビューしてほしいのか）を
明示することです。
まだ文書の体裁は整えてないので、要求漏れがないかだけ確認をお願いします。
仕様はまだ確定していないので、フォーマットが合っているかだけ確かめてください。
など、レビュアーに対して伝えることが重要です。
レビューのために成果物を作る
以前、ミーティング形式のレビューに
まだ文書が完成していないので、内容を抜粋した資料を作りました。
といって、その日のために作ったドキュメントを開き始めた人がいました。
いや、ちょっと待て。
それ、
成果物のレビューにならないじゃん！
レビューとプレゼンは異なります。
作りかけでも、成果物を見てもらいましょう。
ベテランの開発者であれば、作りかけの成果物からも、
何かしらの欠陥を見つけてくれることがあります。
次回に続く
今日は、私の経験した「よくないレビュー」を取り上げてみました。
結構あった。。。
というわけで、もう少し続きます。
記事を気に入っていただけた方は、クリックしていただけると励みになります。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
