レビュー技法の使い分け

レビューが手戻り防止の要になる理由

組み込みソフト開発では、仕様の解釈違いや設計段階の考慮漏れが、実装後やテスト段階で発覚することがあります。下流工程で欠陥が見つかるほど、修正にかかるコストと時間は大きくなります。要求仕様書や設計書の段階で欠陥を検出するレビューは、テストや実機検証より前に着手できる、最も基本的な手戻り防止の手段です。

レビューは、開発プロセス全体において上流工程での品質作り込みの中心的な活動として位置づけられます（「開発の全体像と手戻りを防ぐ設計」参照）。レビューを軽視して先の工程に進むと、後になるほど修正の影響範囲が広がり、スケジュールへの影響も大きくなります。

V字モデルでは、要件定義や設計といった開発工程と、それに対応するテスト工程が並べて示されます。レビューは、各開発工程の成果物が完成した直後に実施し、対応する下流のテスト工程が始まる前に欠陥を取り除く役割を担います。V字モデルの工程対応は別記事で整理していますが（「V字モデルで学ぶテスト工程と品質保証」参照）、レビューはその中でも最も早いタイミングで実施できる検証活動です。

レビュー技法の分類 - IEEE 1028とJSTQBの定義

レビュー技法の分類には複数の出所があり、呼び方や定義に細かな差があります。本記事では、規格として定義されたIEEE Std 1028-2008「IEEE Standard for Software Reviews and Audits」と、テスト技術者資格制度JSTQBのFoundation Levelシラバス(2023年版)の定義を軸に整理します。なおIEEE 1028は2019年に非アクティブ化されていますが、レビュー種別の定義として現在も広く参照されています。

• インスペクションは、IEEE 1028において、訓練を受けた進行役が主導する公式なピアレビューと定義されます。JSTQBでも最も形式度が高い技法とされ、目的は潜在的な欠陥の検出、作業成果物の品質向上、欠陥の未然防止です。
• ウォークスルーは、成果物の作成者自身が参加者を導きながら内容を説明する技法です。IEEE 1028では、欠陥の発見に加えて、プロダクトの改善や仕様・標準への準拠評価も目的に含まれます。
• テクニカルレビューは、専門知識を持つ関係者が、成果物と仕様や標準との整合性を評価する技法です。JSTQBでは、関係者間の合意形成と、潜在的な欠陥の検出が主な目的とされています。
• マネジメントレビューは、IEEE 1028が定義する技法で、プロジェクトの進捗や状態を管理層が監督する目的で実施されます。技術的な欠陥の検出よりも、計画との整合や意思決定が中心になります。
• パスアラウンドは、成果物を複数のレビューアへ配布または回覧し、個別にコメントを集める技法です。会議を開かずに進められるため、参加者の招集が難しい場合にも実施できます。
• ピアデスクチェックは、作成者とレビューア1名の2人だけでおこなう簡易な技法です。公式・非公式のどちらでも運用でき、コストは低い一方、検出できる欠陥の範囲はレビューア1名の視点に限られます。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

技法を比較する5つの軸

技法を選ぶ際は、次の5つの軸で整理すると判断しやすくなります。なお、テスト設計書そのものをレビューする観点は別記事で扱っており（「テスト設計レビューの基礎知識」参照）、本記事では開発プロセス全体に共通するレビュー技法を中心に扱います。

• 公式性です。インスペクションが最も公式で、手順と役割があらかじめ規定されます。テクニカルレビュー、ウォークスルーの順に公式性は下がり、パスアラウンドとピアデスクチェックは非公式な運用が一般的です。
• 参加者と役割です。インスペクションは、モデレータ、作成者、レビューア、記録係の役割を分担して実施します。ウォークスルーは作成者が進行役を兼ね、パスアラウンドとピアデスクチェックは役割分担をほとんど設けません。
• 事前準備の要否です。インスペクションとテクニカルレビューは、参加者が事前に成果物を読み込み、指摘事項を用意してから臨みます。ウォークスルーは準備を求めない運用も多く、パスアラウンドは各自のペースで確認します。
• 記録と指摘の扱いです。インスペクションでは、記録係が指摘事項を文書化し、対応状況を追跡します。テクニカルレビューも議事録を残しますが、ウォークスルーやパスアラウンドは記録が任意になりやすい点に注意が必要です。
• かかる工数です。インスペクションは、準備から是正の確認まで含めると、工数が最も大きくなります。ピアデスクチェックとパスアラウンドは工数が小さく、日常的な確認業務に向いています。

成果物別の技法の使い分け

要求仕様書や基本設計書のように、後工程への影響範囲が広い成果物は、複数の視点で欠陥を洗い出す必要があるため、インスペクションやテクニカルレビューが適しています。関係部署をまたぐ仕様の合意が必要な場面では、テクニカルレビューを選び、関係者間の認識をそろえることも有効です。

コードレビューは、コーディング規約への準拠確認を含む場合、ウォークスルーやピアデスクチェックで日常的に実施し、影響範囲の大きいモジュールに限ってインスペクションを併用する運用が現実的です。コーディング規約の運用は、別記事でも取り上げています（「MISRA Cの形骸化を防ぐためのルール設計と運用」参照）。

テスト設計書のレビューは、テストケースの網羅性や期待値の妥当性を確認する専用の観点が必要になります。テスト設計物のレビューは、専用の観点を整理した進め方に沿って実施することを推奨します（「テスト設計レビューの基礎知識」参照）。

レビューで見つかった指摘は、その場で修正するか、正式に不具合として起票するかを判断します。設計段階の指摘であっても、対応状況を追跡する必要がある場合は、不具合起票の手順に沿って記録します（「不具合起票の方法と修正フロー」参照）。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

レビューが形骸化する典型パターンと対策

レビューを制度として導入しても、運用が崩れると形骸化し、欠陥を検出できなくなります。形骸化したレビューは、会議の時間だけを消費し、開発チームの負担ばかりが増える結果になります。代表的な失敗パターンと対策は次の通りです。

• 人数を集めすぎて意見が出ないパターンです。参加者が増えるほど発言が特定の人に偏り、指摘が出にくくなります。対策として、成果物1件あたりのレビューアは3〜5名程度に絞り、担当領域ごとに責任を明確にします。
• その場で読み始めるため、指摘が浅くなるパターンです。対策として、資料の事前配布を徹底し、各レビューアが指摘候補を用意してから会議に臨む運用に変えます。
• 作成者を責める場になるパターンです。レビューの目的は成果物に含まれる欠陥を指摘することであり、作成者本人を評価することではありません。冒頭でこの原則を共有し、指摘は成果物に対する表現に統一します。
• 指摘が記録されず、改善につながらないパターンです。対策として、記録係を明確に置き、指摘事項と対応状況を一覧化して追跡します。是正が実施されたかどうかを継続的に確認する仕組みも必要です。

レビューで潰せるものと実機がないと分からないもの

レビューは、成果物を実際に動かさずに欠陥を見つける静的な確認手法です。要求仕様との矛盾、設計の考慮漏れ、コーディング規約違反など、読んで判断できる欠陥の除去には高い効果を発揮します。

一方で、組み込みソフト特有の問題には、レビューだけでは見つけにくいものがあります。ハード仕様との整合性は設計書上である程度確認できますが、実際のタイミングやリアルタイム性は、動かしてはじめてわかる場合が多くあります。割り込み処理と排他制御の設計も、論理的な整合性はレビューで確認できても、実際のタイミング競合は記述だけでは判断しきれません。

センサやアクチュエータからの応答時間、通信の遅延といった時間的な制約も、設計書の記述を読むだけでは体感しにくい要素です。

ROMやRAMといったリソース制約、異常系の網羅性についても、設計段階のレビューである程度は確認できますが、実機での動作確認と組み合わせてはじめて十分な検証になります。組み込み固有の制約事項は、別記事で詳しく整理しています（「組み込み開発における制約事項」参照）。

つまりレビューは万能ではありません。動かしてはじめてわかる問題を早期に見つけるには、実機の完成を待たずに動作を模擬できる検証環境が必要です。設計段階から検証環境の整備を並行して進めておくと、レビューでは見つからなかった欠陥も、早いタイミングで検出できます。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

まとめ

レビュー技法には、公式性や参加者の役割、工数が異なるインスペクション、ウォークスルー、テクニカルレビュー、パスアラウンド、ピアデスクチェックがあります。成果物の重要度に応じて技法を使い分け、形骸化を防ぐ運用を徹底することが、上流工程での手戻り防止につながります。ただしレビューだけでは、動かしてはじめてわかる問題までは検出できません。