レビューの目的

つぶやき

　
　
ここでいう「レビュー」はソフトウェア開発におけるレビューとします。それ以外のコンテキストにおける「レビュー」はここでは除外します。

レビューの分類

レビューはその目的ごとに次の５つくらいに分類できると思います。

・品質や精度を向上させるためのレビュー
・リスクを回避するためのレビュー
・納品物を受け入れるためのレビュー
・ルールに則るためのレビュー
・人を育てるためのレビュー

もちろん、それぞれの目的が排他になっているわけではなく、ひとつのレビューが上記の複数の目的をあわせ持つこともありえます。

品質や精度を向上させるためのレビュー

設計レビュー、ソースコードレビューといったものがこれにあたります。レビュワーは主にプロジェクトメンバーです。レビュワーは業務知識、システム知識を持っている必要があります。
例えると、的の中心に矢を近づけるためのレビューです。

リスクを回避するためのレビュー

第三者によるレビューはこの目的のために実施されることが多いと思います。法令や契約を遵守できているか、見積もりや開発目的が大きくぶれていないかを客観的な視点やレビュワーの経験をもとに妥当性を確認します。
例えると、的からはずさないようにするためのレビューです。

納品物を受け入れるためのレビュー

顧客レビューがこのレビューの代表です。受け入れテストはテストというカテゴリですが、一種のレビューになりますね。納品されたものが受領側として正当なものか、価値があるものか、受け入れられるものかを検証します。

ルールに則るためのレビュー

社内ルールでレビューをしなければならないと決められているなど、手続き上必要なレビューを実施する場合がこれにあたります。通過儀式化、形骸化してしまっていることもあるかと思います。
この目的だけのためにレビュー資料を作るのは非常に苦痛です。上記３つの目的とこの目的が掛け合わさっているレビューは多いです。

人を育てるためのレビュー

番外編的ですが、この目的もありだと思います。ひとりでは気づかない改善点を示唆したり、気づきを与えることができます。
ソースコードレビューでは、この要素が実は強かったりします。

レビューの目的を意識する

ひとくちにレビューといっても、その目的によって性質や結果が異なってきます。第三者によるレビューを経たからといって、レビュー対象の品質が向上するとは限らないです。また、顧客レビューが最終段階のレビューとはいえ、それが品質保証につながるわけではありません。

「レビューして意味があるのか」「レビューするだけ時間の無駄」という批判ができますが、そういうときは自分の関心事と批判対象のレビューの目的がズレていることが多いのかもしれません。

レビューの目的をはき違える

プロジェクト開始時にプロジェクト計画や見積もりのレビューをいくらしたところで、つぶつぶの機能の作業見積や潜在課題が明らかになることはまずないです。そのレビューでは、リスク、予算、要員山積みといったことが主眼点ですから。

逆に、プロジェクト計画のレビューをしようとしているのに、想定されるリスクや要員山積みといった情報整理や資料準備を被レビュー者ができていなかったりします。これまでは開発者で、新たにプロジェクトリーダーになった人がこういったミスをします。･･･かくいう自分もそうでした。これまでそんなこと考えることなんてなかったので。

下流工程のレビュー不足

一方で、下流工程や開発工程におけるレビューは実施されていない、もしくは改善の余地があると思います。その重要性は理解しつつも、時間的余裕がないのが実施されない最たる理由だと思います。
ルールによる義務かもされていないので省略しやすいです。また、プロジェクト計画にもそういったレビュー工数が見込まれていない事もあります。

その代表格である、ソースコードレビューは実施されないことが多いです。
プロジェクト管理上の数値として、費用・時間を投入するだけの効果は現れてこないです。また、昨今の短納期化もあるため、いよいよ省略される一方です。

技術的負債を取り除く、保守性の高いコードにリファクタリングする。そういった継続性のあるソフトウェアに仕上げるためには、下流工程にもきちんとしたレビューが必要だと思います。

この辺を何とかしたいと思っています。

まとめ

レビューの目的をしっかり意識することは重要です。目的に応じたレビュー準備、レビュー指摘をおこなうことで、その成果や効果はよりよいものになると思います。
はき違えて、自分の関心事の色眼鏡だけで見てしまうと、レビュー被害者やレビュー批判者になってしまいます。

このエントリーを通じて、自分自身がレビュー好きになるといいなと思いました。