ソフトウェアレビューの種類と手法について解説

全てのソフトウェアレビューには目的があります。レビューと聞くと品質の向上のため、という印象を持つことが多いかもしれませんが、レビューの目的は品質の向上だけとは限りません。

開発工程におけるレビューの効果を最大限発揮することで、限られた開発工数を有効活用できます。そのためには各レビューの目的を理解することが重要です。

形式的なレビューの実施は関係者の工数の無駄遣いにつながります。参加者全員が開発プロセスにおけるレビューの位置付けを理解し、各々が必要な役割を果たせるようにしましょう。

2．ソフトウェアレビューの分類とレビューの種類

ソフトウェアレビューは主に「IEEE（※1）に準拠した分類」と「カール・ウィーガーズ（※2）による分類」に分けることができます。

※1　IEEE（アイ・トリプル・イー）。米国電気電子学会「Institute of Electrical and Electronics Engineersの略」の略で、標準規格の策定などに関わる国際的な学会です。

※2　Karl E.Wiegers。Process Impact社のコンサルタント責任者。「ピアレビュー」「ソフトウェア要求」などソフトウェア・プロセスにおける品質改善の著書あり。

IEEEに準拠した分類

ソフトウェア品質に係る考え方はもともとISO9001（品質マネジメントシステムの国際規格）に端を発しており、品質管理マネジメントの視点からレビューを役割別に分類しています。

ウォーク・スルー

開発工程において公式なレビューではありますが、開発者が自主的に行うカジュアルなレビューです。開発者は自分の担当する開発の成果物を用意し、自分で選定したレビュアーに内容を説明します。レビュアーは、説明された内容から抜け漏れがないか、問題点がないかを指摘します。

開発チームや企業によって証跡の提出方法などは異なりますが、基本的に指摘内容のリストアップのみ必須で、指摘内容を改善するかどうかは開発者に委ねられます。

テクニカル・レビュー

技術的な観点で確認を行う公式レビューです。仕様書・要件書などの資料、および社内開発ルールなどに基づき、求められる構造や仕様になっているのかをチェックします。

公式レビューですので、求められる技術仕様で開発が行われていることを証明する証拠を提出し、記録を行います。

マネジメント・レビュー

開発工程においては必須ではない、非公式なレビューです。開発内容よりも、プロジェクト全体の中での進捗を確認し、必要なリソースを配分して納期までの開発をサポートする指摘・フォローを行います。開発チームのリーダーなどがレビュアーとなり、開発工程において複数回実施される場合があります。

インスペクション

ソフトウェアレビューの中でも、最も公式で大きなレビューです。事前に開発工程に組み込まれており、仕様書や要件書などのドキュメント・確認事項のリストなどを元に、レビュアーやモデレーターなど各役割を担う関係者を参加させてレビューを行います。

レビュー結果は記録され、レビュー対象の開発に反映されるのはもちろん、チームや組織全体にフィードバックしてさらなる改善を図るような取り組みまでを総じて、インスペクションと定義しています。

監査（プロセス保証監査、プロダクト保証監査）

開発内容が、国際的な基準や法規制、社内外の開発ルール・ガイドラインにしたがっているかどうかをレビューします。全ての開発において必ずしも行われませんが、必須となる事項においては有識者をレビュアーとして開発内容と諸規則を照らし合わせて確認する必要があります。

カール・ウィーガーズによる分類

教育レビュー

その名の通り、レビュイーの教育を目的に行われます。レビュアーとなる有識者がレビュー対象のテストケースやテスト計画に対してコメントを行うことで、レビュイーおよび参加者全体が知識をつけることができるようになります。

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

プロジェクトの管理や開発工程の進捗管理上、開催するレビューです。プロジェクトの管理者が中心となって、開発メンバーが提供した情報をもとに、製品リリースへのプロジェクトの進め方を決断・変更したり、各開発の続行・中断の判断、プロジェクト内の工数配分などを行います。

ピアレビュー

「ピア」とは「同僚」を意味しますが、その名の通りチームメンバーと公式・非公式に開発した内容をレビューしあって改善につなげるような取り組みを指します。ピアレビューはいくつかの種類に分類されることがありますが、分類方法は主にピアレビューの公式度合いや事前準備・レビュー内容の報告の仕方に応じて異なります。

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

完了した開発プロジェクトについて、プロジェクト全体を通じた改善点や良かった点などをまとめるレビューです。指摘された事項は今後のプロジェクト進行のために記録されたり、改善案の作成・実施につなげたりすします。

ステータスレビュー

プロジェクト全体において、各開発の進捗状況をプロジェクト内のマイルストーンに照らし合わせて確認したり、各工程で発生した問題や考えうるリスクを検知するためのレビューです。プロジェクトマネージャー含め、プロジェクトメンバー全体で行うことが多いでしょう。

おわりに

今回の記事では、ソフトウェアレビューとはどのようなものなのか、その種類や分類の考え方をベースにご説明しました。

レビューを行う目的は品質改善のみならず、開発計画と実際の成果物との比較検証、成果物の審査、開発目的との相応など多岐にわたることから、各レビューから導き出される結果も異なります。

ソフトウェアレビューを開発プロセスに導入する際は今回ご紹介した内容を活用し、ぜひ開発体制に適したレビュープロセスを検討・採用してみてください。