レビューの基礎知識
レビューに関しての誤解
レビューに関しての講習会を行う予定なので、レビューに関しての知識の再整理を行っています。自分の知識を再整理することで、自分のレビューに関しての甘い認識も見えてきています。
まずレビューですが、一般的には「基本計画〜プログラミングの各フェーズにおいて、それぞれ複数の関係者が集まり、成果物(各種設計書やソースコード)の曖昧な点や問題点を洗い出すための討議や評論のこと」と言われます。
多くある誤解で代表的なものは「レビューは会議のようなもの」ではないかと思います。その背景のとなる考えには「時間だけかかって成果が無い」「結局は無駄な時間を使うだけ」「レビューよりテストの方が効果的」等があります。見た目としては「レビュー」と「会議」は似ているように感じます。しかし、レビューはもっと目的や手段が明確になっているものなのです。
レビューの種類
まず、レビューに関しての種類ですが、これが意外と分かりにくいです。プロジェクトレビュー、ドキュメントレビュー、コードレビュー、ピアレビュー、インスペクション、ウォークスルー、ラウンドロビン・・・等など。切り口を曖昧にしたままのレビューの分類が世に横行してわけがわからなくなっています。(少なくとも私には・・・)
「ピアレビュー(Karl E.Wiegers著 大久保雅一監訳)」という本にレビューが分かりやすく分類されています。それによると次のように分類されえています。
- 教育レビュー
プロジェクトに関連する技術的トピックスについて他のステークホルダーの知識レベルを引き上げる。
- マネジメントレビュー、準備レビュー、ゲートレビュー
上級管理者に情報を提供することにより、製品のリリース、開発プロジェクトの継続(または中止)、提案の採用(または却下)、プロジェクトスコープの変更、リソースの調整、コミットメントの変更を決定する。
- ピアレビュー
作業成果物の欠陥と改善の機会を探す。
- プロジェクト終了レビュー
完了直後のプロジェクトまたはフェーズの反省を行い、将来のプロジェクトのための教訓を得る。
- ステータスレビュー
プロジェクトマネージャおよび他のチームメンバーで、マイルストーンに対する進捗、発生した問題、識別または制御されたリスクを確認する。
また、作業成果物の欠陥と改善の機会を探すレビュー(代表的なのはピアレビュー)では、インスペクション、チームレビュー、ウォークスルー、パスアラウンド、アドホックレビュー・・・等のレビュー手法の考え方があります。
-
インスペクション
最も体系的で、各参加者に特定の役割を与え、多段階のプロセスが存在など厳格なレビュー。作成者以外の参加者が会議を主導し、チェックリストの使用、分析の実施なども行う。
-
チームレビュー
複数のメンバーが参加し確認。計画され、定義された手順に従って実施される。
-
ウォークスルー
作成者が作業成果物をグループ員へ説明し、コメントを求める。
-
ペアレビュー
作成者とレビューア(1人)がペアを組み作業成果物を確認。
-
パスアラウンド
多重且つ同時進行型のチェック。電子メールなどを活用し、作成成果物のコピーを何人かに配布し、複数のフィードバック(コメント)を依頼。
-
アドホックレビュー
計画的なレビューというよりも、必要に応じて対応できる同僚などへ確認してもらう即席レビュー。特に記録を作成するなど管理的機能はない。
私は、レビューを分類するときにその効果という視点で、レビューが「公式か、非公式か」でわけるとよいと思っています。そのような観点では最も公式的なレビューである「インスペクション」が、組織的にも、品質的にも最も効果があるレビュー技法だと考えます。
インスペクションに潜む罠
インスペクションは最も公式なレビューです。その公式であることが、レビューを組織的に阻む要因になることがあります。
インスペクションは公式なレビューのため、そのプロセスが明確です。そして記録も確実に残す事になります。この記録が皮肉なことに組織でのインスペクションの浸透を阻害しています。つまり、摘出バク数などが記録に残るため、能力不足というレッテルを貼られるのではないかという意識が働くのです。また、レビューでバグを見つけたことを必要以上に自分の功績としてPRをする人がいる場合もインスペクションは組織に浸透しないでしょう。
また、機会があったら、今度ははレビューを阻害するものを、様々な視点で考えてみたいと思います
関連コラム
レビューが実施されない理由(後編) 2007年10月22日記述
レビューが実施されない理由(前編) 2007年10月08日記述
レビューの基礎知識 2007年10月01日記述
レビューが必要とされる理由 2007年05月14日記述
システム運用の大切な役割 2007年04月09日記述
ドキュメントコミュニケーションのポイント 2007年04月02日記述
ドキュメントコミュニケーションの必要性 2007年03月26日記述
不満ゼロの要求定義を目指すには 2007年03月19日記述
これからSEになるヒトへ 2006年04月10日記述
システム統合でのトラブルについて考える 2005年09月05日記述
システム再構築の留意事項 2004年07月26日記述
2007年10月01日 宿澤直正 記
|