みなさんこんにちは。ohbaです。
今回は各レビューの簡単な説明と効果について書いていきます。
すべての種類に説明すると長くなりますので、チーム内でお手軽にできるオススメレビューに絞らさせて頂きます。
- ピアデスクチェック
通常のデスクチェックを同僚にしてもらう事です。通常作成者が１名のレビュアに頼んで行うためコストが安価で済みます。また手順も簡単な為、プロジェクト内にレビュー文化を根付かせるには良い手法です。ただしレビュア１人のため、レビュアがいい加減な場合、品質の向上は期待できません。
- パスアラウンド
ピアデスクチェックの拡張版です。作成成果物を複数名に配付してレビューを行う方法です。スケジュールや物理的に集まれない人に対してもレビューをしてもらうことが可能です。ただし複数のレビュアから重複した指摘による無駄が発生し、直接集まってレビューをするときの様な相乗効果は生まれません。
- ウォークスルー
３人から７人程度が集まり、成果物に対してレビューを行う方法です。主に作成者がモデレータを行う為、レビュー対象の観点が絞りやすい反面、作成者の意図しない場所の欠陥が漏れる可能性があります。レビュー中は欠陥の検出を目的とし、その対処法については簡単に導きだせるもの以外は議論しなようにします。
- チームレビュー
３人から７名程度で集まりレビューを行います。ウォークスルーと異なり、作成者以外がモデレータを担当し、モデレータ以外にも書記、読み手を設定しレビュー進行を潤滑にします。またレビューで発見できた問題を記録し、レビュー後の修正結果が適当であることをチェックします。
ピアレビューを行うことにより、開発者・開発管理者に以下のような効果と利益があります。
- 開発者が得られる利益
・手戻り実施時間の減少
・プログラミング生産性の向上
・要求が正しく実装されているという自信
・他の開発者から学ぶより良いテクニック
・単体テストおよび、組み合わせテストでのデバッグ減少
・コンポーネントやシステム全体に関する他チームメンバーとの情報交換
- 開発管理者が得られる利益
・製品開発サイクルタイムの短縮
・フィールドサービスと顧客サポートのコスト減少
・メンテナンスコストの減少と新規開発プロジェクトへのリソース解放
・チームワーク、共同開発、開発効率の改善
・プロジェクトリスクと品質課題に対するより良く、より早くの洞察
私は、テストより製造、製造より設計でバグを発見することが、手戻りが少なく高品質を保てると思っていますので、みなさんも是非ピアレビューの実践をオススメします。（もちろん製造、テストもしっかりやった上ですが…）
Adios!
