ポイント：レビュー、レビューの種類、インスペクション、チームレビュー、ウォークスルー、パスアラウンド、アドホックレビュー

レビューの基礎知識

レビューに関しての誤解

　レビューに関しての講習会を行う予定なので、レビューに関しての知識の再整理を行っています。自分の知識を再整理することで、自分のレビューに関しての甘い認識も見えてきています。

　まずレビューですが、一般的には「基本計画～プログラミングの各フェーズにおいて、それぞれ複数の関係者が集まり、成果物（各種設計書やソースコード）の曖昧な点や問題点を洗い出すための討議や評論のこと」と言われます。

　多くある誤解で代表的なものは「レビューは会議のようなもの」ではないかと思います。その背景のとなる考えには「時間だけかかって成果が無い」「結局は無駄な時間を使うだけ」「レビューよりテストの方が効果的」等があります。見た目としては「レビュー」と「会議」は似ているように感じます。しかし、レビューはもっと目的や手段が明確になっているものなのです。

レビューの種類

　まず、レビューに関しての種類ですが、これが意外と分かりにくいです。プロジェクトレビュー、ドキュメントレビュー、コードレビュー、ピアレビュー、インスペクション、ウォークスルー、ラウンドロビン・・・等など。切り口を曖昧にしたままのレビューの分類が世に横行してわけがわからなくなっています。（少なくとも私には・・・）

　「ピアレビュー（Karl E.Wiegers著　大久保雅一監訳）」という本にレビューが分かりやすく分類されています。それによると次のように分類されえています。

教育レビュー

プロジェクトに関連する技術的トピックスについて他のステークホルダーの知識レベルを引き上げる。

マネジメントレビュー、準備レビュー、ゲートレビュー

上級管理者に情報を提供することにより、製品のリリース、開発プロジェクトの継続（または中止）、提案の採用（または却下）、プロジェクトスコープの変更、リソースの調整、コミットメントの変更を決定する。

ピアレビュー

作業成果物の欠陥と改善の機会を探す。

プロジェクト終了レビュー

完了直後のプロジェクトまたはフェーズの反省を行い、将来のプロジェクトのための教訓を得る。

ステータスレビュー

プロジェクトマネージャおよび他のチームメンバーで、マイルストーンに対する進捗、発生した問題、識別または制御されたリスクを確認する。

　また、作業成果物の欠陥と改善の機会を探すレビュー（代表的なのはピアレビュー）では、インスペクション、チームレビュー、ウォークスルー、パスアラウンド、アドホックレビュー･･･等のレビュー手法の考え方があります。

インスペクション

最も体系的で、各参加者に特定の役割を与え、多段階のプロセスが存在など厳格なレビュー。作成者（レビューイ）以外の参加者が会議を主導し、チェックリストの使用、分析の実施なども行う。バクの摘出率は高くなるが、工数もかかる。

チームレビュー

複数のメンバーが参加し確認。計画され、定義された手順に従って実施される。あらかじめ課題が提示され、その課題に対して問題解決、および、メンバー間での合意を行う。

ウォークスルー

作成者（レビューイ）が作業成果物を指摘者（レビューア）へ説明し、コメントを求める。作成者が指摘者を分離させるインスペクションと対照的である。作成者がレビュー全体にわたって作業の中心となるため「作成者のためのレビュー」という印象を与えることがある。

ペアレビュー

作成者（レビューイ）と１人の指摘者（レビューア）がペアを組み作業成果物を確認する。よく先輩が新人を育成する際に行われる。指摘内容が１人の指摘者の技量によってしまうところがあるが、チェックリストの活用などで、より指摘の精度を上げるようにする。

パスアラウンド

多重且つ同時進行型のチェック。電子メール、グループウェアなどを活用し、作成成果物のコピーを何人かに配布し、複数のフィードバック（コメント）を依頼する。ミーティングを行わないという特徴があり、それはメリットでもあり、デメリットでもある。

アドホックレビュー

計画的なレビューというよりも、必要に応じて対応できる同僚などへ確認してもらう即席レビュー。特に記録を作成するなど管理的機能はない。アドホックレビューが日常的に行われる組織・プロジェクトは、お互いが信頼をし、強い組織・プロジェクトであるといえる。

　私は、レビューを分類するときにその効果という視点で、レビューが「公式か、非公式か」でわけるとよいと思っています。そのような観点では最も公式的なレビューである「インスペクション」が、組織的にも、品質的にも最も効果があるレビュー技法だと考えます。

インスペクションに潜む罠

　インスペクションは最も公式なレビューです。その公式であることが、レビューを組織的に阻む要因になることがあります。

　インスペクションは公式なレビューのため、そのプロセスが明確です。そして記録も確実に残す事になります。この記録が皮肉なことに組織でのインスペクションの浸透を阻害しています。つまり、摘出バク数などが記録に残るため、能力不足というレッテルを貼られるのではないかという意識が働くのです。また、レビューでバグを見つけたことを必要以上に自分の功績としてPRをする人がいる場合もインスペクションは組織に浸透しないでしょう。

　また、機会があったら、今度ははレビューを阻害するものを、様々な視点で考えてみたいと思います

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

2007年10月01日
2012年11月13日改
宿澤直正記

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