公式レビューのマネジメント

TM-3.5.1 （K2）公式レビューの特徴を、例を使用して説明する。

3.1 イントロダクション

ISTQB Foundation Levelシラバスでは、レビューをプロダクトに対する静的テスト活動として紹介をした。監査

とマネジメントレビューは、ソフトウェア成果物ではなくソフトウェアプロセスに、より重点を置いている。

レビューは静的テストの一種であるので、テストマネージャは全体的な成功、特にテストウェアプロダクトに関す る成功に対して責任を持つ。ただし、ソフトウェアプロジェクトのさまざまな状況において、この責任は、組織的 なポリシーと関係する。テストマネージャ、品質保証マネージャ、または訓練を受けたレビューコーディネータは、

公式レビューを多くの領域にわたって広範に適用する可能性があるので、ソフトウェアプロジェクトの開始前お よび実行中の両方において責任を持つ。本シラバスでは、責任を持つ人は、それが誰であっても、レビューリ ーダと呼ぶ。

レビューリーダは、ISTQB Foundation Levelシラバスで定義している成功要因の実現を推進する環境を確保 する必要がある。さらに、レビューリーダは、レビューが効果的な価値をもたらすように、測定計画を作成する。

テスト担当者は運用での動作とソフトウェアシステムに求められる特徴を深く理解しているので、レビュープロセ スに関与させることが重要である。

レビュー参加者は、レビューのトレーニングを受け、レビュープロセスにおけるそれぞれの役割についてよく理 解していなければならない。すべてのレビュー参加者は、円滑なレビューとなるように寄与しなければならない。

レビューを正しく実施すると、全体の品質に最大限寄与する、もっともコスト効率の高い手段になる。このため、

レビューリーダがプロジェクトの効果的なレビューを実施し、これらのレビューのメリットを示すことは、非常に重 要である。

プロジェクト内のレビューとしては、次のようなものがある。

 契約レビュー。プロジェクトの開始時および主要なプロジェクトマイルストンで開始する。

 要件レビュー。要件がレビューのために準備できた際に開始する。理想的には機能要件と非機能要 件を網羅する。

 基本設計レビュー。全体的なアーキテクチャ設計がレビューのために準備できた際に開始する。

 詳細設計レビュー。詳細設計がレビューのために準備できた際に開始する。

 コードレビュー。ソフトウェアの各モジュールが作成された際に実行する。ユニットテスト、その結果、お よびコード自身を含むことがある。

 テスト成果物レビュー。テスト計画、テスト条件、品質リスク分析結果、テスト、テストデータ、テスト環境、

およびテスト結果を含むことがある。

 各テストレベルのテスト開始（テスト準備）レビューとテスト終了レビュー。前者は、テスト実行を開始す る前にテスト開始基準をチェックし、後者は、テストを終了する前にテスト終了基準をチェックする。

 受け入れレビュー。システムに対する顧客またはステークホルダの承認を得るために使用する。

レビューリーダは、1 つのプロダクトに複数の種類のレビューを適用できる。さらに、レビューは静的ドキュメント の欠陥を見つける手段として使用できるだけでなく、静的テストの他の方法（静的解析など）やコードの動的テ ストを補完するものになることを、認識する必要がある。これらの技法を組み合わせて使用することにより、テスト カバレッジが向上し、より多くの欠陥を検出できるようになる。

技法ごとに重点は異なる。たとえば、レビューを行うことにより、コードに問題を実装する前に、要件レベルで問 題を除去できる。静的解析を行うことにより、コーディング標準に準拠させることができ、成果物の精査では工

数がかかりすぎて見つけることのできない問題をチェックできる。インスペクションは、欠陥の検出と除去に役立 つだけでなく、成果物に欠陥を作りこまないように開発者をトレーニングできる。

ISTQB Foundation Levelシラバスでは、次のレビュータイプを規定している。

 非公式レビュー

 ウォークスルー

 テクニカルレビュー

 インスペクション

これらに加えて、テストマネージャは、次のレビューにも関与することがある。

 マネジメントレビュー

 監査

3.2 マネジメントレビューと監査

マネジメントレビューは、進捗状況のモニタリング、ステータスの評価、将来の対応の決定を行うために実施す る。これらのレビューにより、適用するリソースの度合い、是正措置の実行、またはプロジェクトの対象範囲の変 更など、プロジェクトの将来に関する決定が行えるようになる。

マネジメントレビューの主な特徴には、次のようなものがある。

 プロジェクトまたはシステムに直接責任を持つマネージャまたはその代理によって実施する。

 ステークホルダや意思決定者、またはその代理によって実施する。たとえば、上位マネージャまたは 部門長など。

 計画との整合性および逸脱をチェックする。

 マネジメント手順の妥当性をチェックする。

 プロジェクトリスクを評価する。

 アクションの影響と、これらの影響を測定する方法を評価する。

 アクションアイテム、解決すべき課題および行うべき意思決定のリストを作成する。

プロジェクトの振り返り（学習した教訓）などプロセスのマネジメントレビューは、プロセス改善活動の重要な構成 要素である。

テストマネージャは、テスト進捗のマネジメントレビューに参加すべきであり、レビューを推進することもある。

監査は、通常、一定の基準（多くの場合、適用される標準、規制、または契約義務）に対する準拠を示すため に実行する。このため、監査は、プロセス、規制、標準などへの準拠について独立した評価を提供することを目 的としている。監査の主な特徴には、次のようなものがある。

 監査リーダが管理、モデレートする。

 準拠のエビデンスを、ヒアリング、観察、ドキュメントの検査などを通じて収集する。

 ドキュメントとしての成果には、観察事項、勧告、是正措置、合否アセスメントを含む。

3.3 レビューのマネジメント

レビューは、ソフトウェアプロジェクトの適切な区切り、またはマイルストンで実施する。通常、レビューは、要件と 設計を定義した後に実施する。関連するレビューは、ビジネスの目的に対するところから始まり、詳細設計段階 に対してまで行う。マネジメントレビューは、主要なプロジェクトマイルストンで、通常、テスト実行およびその他 の重大なプロジェクトフェーズの前、途中、後の検証活動の一環として行う。レビュー戦略は、テストポリシーと 全体的なテスト戦略とに適合させなければならない。

プロジェクトレベルでの全体的なレビュー計画を作成する前に、レビューリーダ（テストマネージャが兼ねること もある）は、次の点を考慮する。

 レビュー対象は何か（プロダクトおよびプロセス）

 特定のレビューに誰が関与するか

 カバーすべき関連リスク要因はどれか

プロジェクト計画フェーズの初期において、レビューリーダはレビュー対象となるアイテムを特定し、適切なレビ ュータイプ（非公式レビュー、ウォークスルー、テクニカルレビュー、インスペクション、または 2つか 3つのタイ プの組み合わせ）と公式度合いを決定する。この時点で、追加のレビューのトレーニングを推奨することがある。

ここから、レビュープロセスの予算（時間とリソース）を割り当てることができる。予算を決定する際には、リスク評 価と投資効果の計算を行う。

レビューの投資効果は、レビューを行うためにかかるコストと、レビューを行わずに以降の段階で検出した場合

（または、まったく検出できなかった場合）に同じ欠陥に対処するためにかかるコストとの差である。2.7 節で説 明する品質コストの計算が、この数値を決定するために使用できる。

レビューを実行するための最適なタイミングは、次の要素で決定される。

 レビュー対象のアイテムの、体裁面での完成度合い。

 レビューを行うのに適している担当者の参加可能性。

 アイテムの最終版が利用できるタイミング。

 その特定のアイテムのレビュープロセスにかかる時間。

レビュー評価を行うための適切なメトリクスを、テスト計画時にレビューリーダによって定義する。インスペクショ ンを使用する場合には、ドキュメントの細分化（たとえば、個々の要件単位、または節単位など）が完了したとき に、開発者の要求に応じて簡易的なインスペクションを実施するべきである。

レビュープロセスの目的を、テスト計画時に定義する。これには、効果的で効率的なレビューの実施、およびレ ビューのフィードバックに関する合意した意思決定を行うことを含む。

プロジェクトレビューは、システム全体に対して繰り返し行い、サブシステムおよび個々のソフトウェア要素に対 して、必要に応じて行う。レビューの回数、レビューのタイプ、レビューの編成、および関与する人々といったも のはすべて、プロジェクトの規模や複雑さ、およびプロダクトリスクに依存する。

レビューの参加者は、効率を高めるために、技術と手順の両方に関して、適切な知識を有している必要がある。

レビューを効果的に行うために、他のスキルとしてレビューアに求められるものとしては、細部に対する完全さと 注意力がある。良いレビューコメントには、明確かつ優先度付けが正しいという特徴がある。手順に関する知識 が必要であり、レビューアが自分の役割と責任を確実に理解するために、レビューアに対して適切なトレーニン グが必要になることがある。

レビュー計画では、技術的要因、組織的要因、およびレビュー実行時の人的問題に関するリスクに対処する。

レビューが成功するためには、十分な技術的知識を持ち合わせているレビューアの参加がきわめて重要であ る。プロジェクトのすべてのチームをレビュー計画に参加させ、各チームにレビュープロセスの成功の責任を持 たせる。計画では、各組織において、必要とされるレビューアがプロジェクトスケジュールの適切な時点でレビ ューの準備を行い、それらに参加するための時間を、十分に割り当てていることを保証しなければならない。必 要とされるテクニカルトレーニングまたはプロセストレーニングをレビューアが受講する時間も計画する。人的計 画またはビジネス計画の変更により主要なレビューアが参加できなくなった場合に備えて、バックアップのレビ ューアを決めておく。