レビューの種類を知ろう

レビューと聞くと、堅苦しい印象を受けるかもしれませんが、
「人の目によるチェック」は、簡易的なものも含めて、
すべてレビューになると思ってください。

種類も、簡易的で低コストな方法から、厳密で時間をかけて行う方法まで色々あります。
レビュー対象物の性質を判断して、適切な方法を選べば、
余計なコストを掛けずに、最大の効果を得ることができます。

• アドホックなレビュー
• パスアラウンド
• ピアデスクチェック
• ウォークスルー
• インスペクション

アドホックなレビュー

ミーティングの最後に


などと、参加者全員で議事録をチェックすることがあると思います。
これも、一種のピアレビューになります。

大きな誤り、認識の間違いなどがないか、簡易的にチェックする方法です。
計画も、事前準備も、ほとんど不要なため


と言って、急遽開催することも可能です。

どんなときに使う？

最も低コストなレビューですが、
当然、厳密さがあまり要求されない文書などにしか使えません。

ただし、開発時に作成する文書には、
開発者同士でしか共有しないものが多くあると思います。

細かな間違いがあっても、訂正が素早く行える、もしくは影響範囲が小さい場合には、
このような簡易的なレビューでも十分効果を得られます。

デメリットは？

このようなレビュー方法は、「レビューされたか否か？」「誰がレビューしたのか？」
という情報を基本的に残しません。

ですので、長期的に利用される資料（引継ぎ資料など）、
顧客や部外の人に見せる資料などには、不向きであることが多いです。

パスアラウンド

多数または不特定多数の人に成果物を配布し、レビューを求める方法です。

私は、紙の文書でこの方法を行ったことはないのですが、
電子化された文書では、よく行われる方法だと思います。


といった感じの通知が、開発現場では、よく飛び交っていました。

どんなときに使う？

この方法はレビューされない可能性もあることから、
品質によるリスクが低い文書などが対象になります。

また、厳密なレビューが必須になっている組織でも、
（すでにレビュー済みで）簡易的な修正をした文書には、利用してもよいと思います。

ただし、レビュアーが不特定であることから
「誰でもレビュー出来る内容」であることが条件になります。

デメリットは？

先にも書きましたが、レビューされない可能性があるという点です。

あとから間違いが見つかっても


などと、言ってはいけません。

あくまでも成果物の品質は、製作者の責任であり、
レビュアーは時間を割いて、お手伝いをしてくれているだけですので。

ピアデスクチェック

パスアラウンドとは違い、特定の人に成果物を配布し、レビューしてもらう方法です。

この方法では、レビュアーの何人か、もしくは全員のレビュー完了を
成果物の完成の条件のひとつにすることが、よくあります。

どんなときに使う？

この方法を使うときは、確実にレビューをしてほしいとき（レビューが必須の成果物）、
そして、レビューに専門的な知識が必要な場合です。

コードレビューでは、ほとんどの場合が、この方法になると思います。

デメリットは？

特にコードレビューの場合は、レビューの量が多くなるため、
ツールの導入、レビューのプロセス化をして効率化を図る必要があります。

また、この方法は特定の人にレビュアーとしてのコストが集中してしまうことがあります。
（その人にしかレビュー出来ない成果物が多い場合）

レビュアーを育て、負荷を分散することにもコストを払わなければいけません。
※参考：『ピアレビューの勧めと注意点（レビューと投資）』

ウォークスルー

会議形式のレビュー方法です。

レビュアーからの指摘なども含めて、議事を取ることが多く、
今までの方法と比べても厳密なレビュー方式です。

どんなときに使う？

顧客、マネージャ、部外・社外の人、他職種の人など、
レビュアーが開発者でない場合に、この方法を取ることが多いです。

逆に言えば「成果物＋説明（および質疑応答）」が必要な場合に、採用される方法です。
（成果物を渡しただけでは、レビュアーがレビュー出来ない場合）

また、「レビュアーはレビューのみ行い、合否判定は行わない」というのが基本なのですが、
顧客の合意を得たいとき、マネージャの判断を仰ぎたいときなどに使われたりもします。

デメリットは？

コストがかかる方法のため、しっかり計画を立て、
レビューも進行役がしっかりと時間管理をして進める必要があります。

「事前に成果物を配布し、読んでおいてもらう」などして、
時間を余計にかけない工夫をしなければいけません。

また、他の方法に比べて、
レビュアーを長時間拘束してしまうため、何度も行うことはできません。

従って、成果物の完成度が高くないといけません。
「事前に開発者同士でピアレビューを行っておく」などの工夫が必要です。

レビュー完了後に成果物を修正する場合の手順なども定めておく必要があります。
開発者が勝手に修正してしまっては、レビューの意味がなくなってしまいます。

インスペクション

より厳格で、組織ごとに決められたプロセスに従って体系立てて行われるレビューです。

ウォークスルーは、基本的に成果物の作成者が主催者となるのに対して、
インスペクションは、専門のレビュアーたちがいて、


と、レビュアーが主催者になるのが特徴です。

指摘された欠陥数などを記録し、成果物の品質の判断をしたり、
レビュー自体の品質も、その記録をもとに判断したりします。

どんなときに・・・？

残念ながら、管理人はインスペクションを採用している組織で働いたことがないため、
経験談を話すことができません。。。m(_ _)m ｽｲﾏｾﾝ

ただし、


というくらいのモチベーションであれば、
ウォークスルーまで抑えておけば十分かと思います。

逆に言えば、インスペクションは、開発現場の活動のみで導入できるものではありません。

次回に続く

今回は、レビュー方法の紹介で終わってしまいましたが、
次回は、レビューの導入、開催、そして教育（レクチャー）に関する注意点などを
私の経験を交えて書いてみたいと思います。

⇒ ピアレビューの勧めと注意点（よくないレビュー）
⇒ ピアレビューの勧めと注意点（レビューと投資）