レビューの手順

レビューは，主にV&V観点からのバグの早期発見，およびより良い設計方法の検討を狙 って実施する．その狙い達成のために，場面に応じて，レビューの参加者・レビュー方法・

リーディング方法を適切に選択して実行することが重要である．

図5-2は，当該組織のレビューの流れを説明したものである．上工程では，ある工程の成 果物のドラフト完成時以降，レビューの段階に入る．まず初めに，開発責任者がレビュー

表5-1 ソフトウェア開発におけるさまざまなレビュー方法

（[5-1][5-2][5-3]を参考に本著者が作成）

No. 名称 内容

公式 1 インスペクション

標準や仕様から外れた例外を発見するレビュー方法．チェックリスト を用いることが多い．最も公式なレビューであり，正式な記録が必要 である．

2 チームレビュー チームにより実施されるレビュー．インスペクションほど公式でなく，

「軽インスペクション」に分類される．

3 ウォークスルー

レビュー対象成果物の内容を確認するために，複数人のレビューア が質問やコメントする形で実行されるレビュー．インスペクションが定 められた公式な手順に基づいて実施されるのに対し，ウォークス ルーは手順化されていないため再現性に乏しいと言われている．

4 ラウンドロビンレビュー レビュー参加者全員が順に司会者とレビューアの役を持ち回りで勤 める形式のレビュー．回転式レビューとも呼ばれる．

5 ピアレビュー 同僚（ピア：peer)によるレビュー全般の呼称．

6 ペアプログラミング

２人が１つのマシンを共有して協同でプログラミングを行う方法．レ ビュー方法の１つとしても位置づけられる．eXtreme Programing（Ｘ Ｐ）の代表的なプラクティスである．

7 パスアラウンド

レビュー対象成果物を複数のレビューアへ配布（または回覧）し，レ ビューする方法．電子レビュー（電子ファイルを回覧して，レビュー アがコメントを書き込んだり結果をメールしたりするレビュー方法）は パスアラウンドの１種である．

8 ピアデスクチェック レビューアが個人でレビューし，その記録に基づいてレビュー対象 成果物の作成者とフォローアップセッションを実施する方法．

非公式 9 アドホックレビュー

目前の問題を解決するために，近くの同僚に声をかけて知恵を借り るという程度の非公式なレビュー．ピアレビューの中でも最も非公式 であり，即席レビューとも呼ばれる．

表5-2 レビュー対象成果物の確認方法（[5-4]を参考に本著者が作成）

No. 名称 内容

1 チェックリスト・リーディング

チェックリストを用いて成果物を確認する方法．チェックリスト は，過去のバグ等に基づき組織的な経験知となるよう準備され たものを使用することが多い．チェック項目が多いとすべてを確 認するのが難しくなる．また，生きたチェックリスト（常に見直され ているか，チェック項目が抽象的または具象的すぎてレビュー アが理解できないことはないか等）となっていることがポイントで ある．

2 パースペクティブ・ベースド・リーディング

レビューアが様々な利害関係者になりきって，それぞれの立 場・観点（パースペクティブ）から成果物を確認する方法．パー スペクティブの例として，ユーザ，開発者，テスト担当者等が考 えられる．

3 ユースケース・ベースド・リーディング ユーザーの利用視点で作成したシナリオ（ユースケース）を用い て成果物を確認する方法．妥当性確認に適している．

4 テストケース・ベースド・リーディング ユースケース・ベースド・リーディングの派生方法で，テストケー スを用いて成果物を確認する．

場合は差し戻しをする．レビュー可の場合は，レビューアの人選をする．レビューアの人 選は非常に重要である．プロジェクトメンバだけでなく，開発するソフトウェアと同時に 動作する可能性のあるソフトウェア製品の開発者，当該ソフトウェア領域について見識の 高い技術者，関係するハードウェア技術者，マーケティング担当などに参加してもらう．

ここで，レビューアに抜け漏れがあると，重要なバグを摘出できないままに後工程へ進ん でしまい，大きな問題に発展してしまう．実際に，必要なレビューアがレビューに参加し ないまま開発を進めたために，後から悔やむ結果になった経験は一度ならずある．このた め，特に多くのソフトウェアと関連して動作するようなソフトウェア製品開発では，イン タフェースを確認すべき相手先一覧などを準備し，レビューによる確認の抜け漏れのない ようにチェックしている．レビューアの人数が多い場合は，効率を考慮して，テーマを分 けてレビューを開催する．例えば，「商品としての価値を検討する外部仕様のレビュー」，「関 係するソフトウェアとのインタフェースを中心としたレビュー」というようにレビュー目 的を分けて設定する．

レビューアの決定 事前チェック

事前準備

レビューの実施（会議形式）

レビュー後の記録整理

バグ修正

修正内容の確認 次工程へ

バグ：0件

レビューが十分と 判断できる場合 レビュー対象物のドラフト版作成完了

図5-2 レビューの流れ

実際にレビューを実施する前に，レビュー対象物を配布し，レビューアにはできるだけ 事前チェックしてもらう．レビューは，会議形式で開催することを原則とする．オフショ ア開発の場合は，レビューのためにレビューアが出張することも当り前のように行われて

レビューアは忙しく時間が合わないので，レビュー会議が夜遅くに開催されることもある．

しかし，顔を合わせて議論する重要性には変えられない．

品質会計においては，組織的なレビューチェックリストを準備し，それを適用してレビ ューすることを原則とする．製品によっては，レビューチェックリストのレビュー項目を，

その製品向けにレビューしやすく表現を変えたり，追加したりして，その製品専用のレビ ューチェックリストを作成している．レビューアがプロジェクト内のメンバの場合は，レ ビューチェックリストを適用したレビューが多い．一方，プロジェクト外のレビューアが 中心となるレビューの場合は，各レビューアが各自の立場で気がついたことを自由に指摘 していくレビュー方法をとることが多い．

Ｒｅｖ．

所属

No. ページ/行 バグ判定 重要度 修正日付

レビュー記録表

作成者 承認

修正内容 査閲

機能名

チェック項目数

摘出バグ数

指摘事項 レビュー回数

工数（Ｈ）合計 レビューア氏名 工数（Ｈ）

日時 場所 レビュー対象物 レビュー工程

図5-3 レビュー記録表（例）

レビューでの指摘項目は，予め決められた記録者がレビュー記録表（図5-3参照）へ記録 する．その場で回答できない指摘については，レビュー対象物作成者が会議後に調査して 報告する．レビュー終了後，レビュー記録表を整理し，バグ判定をする．レビュー対象物 作成者は，レビュー記録表に従ってレビュー対象物を修正し，その修正内容および日付を レビュー記録表に記録する．すべてのバグを修正後，版数を上げてレビュー対象物を発行 する．開発責任者は，レビューの十分性を吟味し，再レビューすべきか，次工程へ進んで よいかを判断する．原則として，バグが出続けている場合は，再レビューを実施する．バ グ修正をした結果，新たなバグが作り込まれていないか，前回のレビューでは気づかなか ったバグがバグ修正によって顕在化していないか等を確認することが目的である．レビュ

ー状況の品質分析は上工程品質会計により実施する（上工程における品質会計適用方法に ついては3.3節を参照）．

設計書のレビューにおいては，バグ判定が難しいことがある．例えば，誤字脱字の間違 いをバグと判定するかどうかは人によって判断が異なるであろう．品質会計では，設計書 のバグを定義している（表2-4を参照）．この定義によると，単なる誤字脱字はバグとしな いが，その誤字脱字により仕様を誤解する可能性が高い場合はバグとする．このように，

設計書のバグについては，組織として統一した判定基準によってバグ判定できるように，

具体的な定義が必要である．