[事務所TOP] [上へ戻る]

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

レビューが実施されない理由(前編)


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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連コラム
レビュー技法におけるチェックリストの役割 2015年11月01日記述
レビューを行う際の3つのポイント(4)〜意識(後編)〜 2015年06月01日記述
レビューを行う際の3つのポイント(3)〜意識(前編)〜 2015年04月01日記述
レビューを行う際の3つのポイント(2)〜技法〜 2015年03月02日記述
レビューを行う際の3つのポイント(1)〜視点〜 2015年02月02日記述
レビューミーティングでやってはいけない五つのこと(後編) 2014年02月17日記述
レビューミーティングでやってはいけない五つのこと(前編) 2014年02月10日記述
ITプロジェクトでの怖いもの〜担当者の抱え込みと放りっぱなし 2013年09月30日記述
レビュー技法のメリット・問題点(後編) 2013年09月23日記述
レビュー技法のメリット・問題点(前編) 2013年09月17日記述
なぜレビュー技法の種類を知るとよいのか 2012年11月15日記述
レビューが実施されない理由(後編) 2007年10月22日記述
レビューが実施されない理由(前編) 2007年10月08日記述
レビューの基礎知識 2007年10月01日記述
レビューが必要とされる理由 2007年05月14日記述

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

2007年10月08日 宿澤直正


[事務所TOP] [上へ戻る]

Copyright (C) 2007 宿澤経営情報事務所