ポイント：レビュー、レビューの有効性、定性的なメリット、レビューとテスト

レビューが実施されない理由（前編）

レビューが実施されない理由はいろいろあると思います。いろいろ調べていると以下の３つに集約される気がします。

レビューの有効性の認知不足
レビューの効果的な実施手法の知識不足
レビューを受け入れる組織風土の不在

レビューの有効性の認知不足

　このように書くとピンとこないかもしれませんが、「レビューは時間がもったいない」「レビューよりテストの方がバグつぶしに有効だ」と言えば、一度はそのような言葉を言ったことがあるのではないでしょうか。私もSEをしていたときにはよく同じことを言っていました…。ただ、レビューの有効性を知ることができたので、今なら同じことは言わないと思います。

　まず、レビューに時間をかけるとプロジェクト遅らせると多く認識されていますが、プロジェクトを遅らせるのは「欠陥」なのです。そして、レビューとは「欠陥」を見つける行為です。つまり、レビューで早期に「欠陥」を見つけることができてば、その「欠陥」が後々で見つかった時に比べて大幅な工数の削減ができます。

　どのフェーズでのレビューかにもよりますが、レビューでの欠陥の発見にて、修正にかかるコストは、顧客から報告された欠陥の修正に比べておよそ十分の一にコスト削減が可能であるという報告があります。

　これには２つの理由があります。一つは欠陥が大きく波及する前の修正することにより、修正箇所、時間が少なくてすむのです。もう一つは顧客に指摘されてた際の対応（謝罪、報告書作成など）にかかる直接欠陥を修正する以外のコストを無くせるのです。

レビューによる定性的なメリット

　他にも、定量化がしにくい定性的なメリットもあります。上記に列挙します。

作業成果物に対するフィードバックを他人に出してもらうことによって各人が知識を得る。
レビューの実施者がおのずとシンプルで理解しやすい作業成果物を作るようになる。
ひとつのプロジェクトに共同で関与しているというチームの意識が醸成されていく。
レビューによるプロジェクトの成功体験が、次のプロジェクト成功への自信につながる。

　つまり、レビューによってチームメンバーは積極的に知識を共有し合い、お互いから学ぶという共同作業的発想を醸成するという大きなメリットがあります。次回「レビューを受け入れる組織風土の不在」について書きたいと思いますが、そこに通じるメリットです。

テストの方がバグに有効…

　これも、大きな誤解です。レビューの大きな特徴はレビューは作業成果物が完了する前の改善に使用できる検証方法なのです。

　テストは、実際にプログラムを動かしながらするので、気持ち的には確実にバグを見つけていると感じます。実際にそうなのかもしれません。しかしテストは基本的に一人でやります。また、一つもバグが見つかった場合にそのバグを直した後に発生する関連バグは全く見つけることができません。

　つまり、効率性や網羅性という観点でレビューはテストに勝ります。修正してはテスト、テストしては修正を行っていると、「もぐらたたき、賽の河原のような作業」になりモチベーションを低下させてしまいます。レビューにてその状況を回避するのです。

　次回は、レビューを阻害するものとして「組織風土」に目をやりたいと思います。

関連提供サービス
セミナー「システム開発におけるレビュー技法」

2007年10月08日宿澤直正記

[事務所TOP] [コラム一覧へ]