ソフトウェア開発において、成果物のレビューは重要なポイントの1つです。効率よいレビューを行うことは、品質はもちろん、以降の作業効率も向上させてくれます。
今回はソフトウェア開発におけるレビューの目的や、よく用いられる種類についてご紹介します。
ソフトウェアレビューとは？
ソフトウェアレビューとは、ソフトウェア開発工程において作られる成果物の品質についての批評を行うことを指します。
対象の成果物に対して「問題点や曖昧な点が見当たらないか」や「事前の打ち合わせで決めた仕様が過不足なく盛り込まれているか」といった確認したり、品質向上のための意見を出し合ったりします。ここでいう成果物とは、次のようなものが該当します。
- 要件定義書
- 機能設計書
- 詳細設計書
- ソースコード
- テスト報告書など
基本的には仕様漏れや手戻りを防止するためにも、レビューは各工程毎に行われ、指摘事項や問題点を解消した後に次工程へ作業を進めます。
プロジェクトで作成した成果物に対してのレビューは、成果物の作成担当者、マネージャーなどの内部の人員だけでなく、顧客やユーザーの代表なども参加する場合があります。
ソフトウェアレビューは成果物を確認するための重要な工程ですが、一方で、時間の長さや回数の多さがかえって作業効率を悪くしてしまうケースも少なくありません。
打ち合わせ内容をレビュー対象だけに絞ったり、事前に成果物を共有しておき、レビュー時に円滑な話し合いが出来るよう努めるのが大切です。また、レビューにおいて、レビューする人を「レビュアー」レビューを受ける人を「レビューイ」とも呼ぶ場合があるので、覚えておきましょう。
ソフトウェアレビューの目的
ソフトウェアレビューは、主に以下の目的で行われます。
成果物の改善
顧客やユーザーも交えたレビューの場合、要件定義書や機能設計書に記載された内容が要求仕様を満たしているかを改めて確認してもらえます。
その上で「この機能はこういった仕様にすればさらに使いやすくなるのではないか」「この画面のボタンはもう少し大きくしてほしい」などの改善点を提案してもらえるため、成果物の改善につながります。
問題の早期発見による、修正コストの低減
レビューによって問題点や修正点が早期に見つかれば、後から仕様変更や手戻りが発生するよりも修正コストは低減出来ます。
限られた開発工数でスムーズに作業を進めていくためにも、効率のよいレビューが求められます。
顧客やユーザーとの進捗状況の共有
工程毎にレビューを挟むことで、顧客やユーザーと進捗状況を逐次共有出来ます。
遅れている作業はないかを確認したり、レビュー時に新たな作業方針が決まった場合はその合意を取るなど、レビューの場があることで意思疎通を円滑に図れます。
よく用いられるレビューの種類
ソフトウェアレビューは、さまざまなレビュー技法で行われます。ここでは、よく用いられるレビュー技法をご紹介します。
教育レビュー
レビューを受ける側である、レビューイの教育を目的に行われるレビューです。
ソフトウェアに対しての理解が深いレビュアーがレビュー対象の成果物に対してコメントを行い、レビューイや参加者に知識を共有します。
マネジメントレビュー、準備レビュー、ゲートレビュー
プロジェクトの管理や開発工程の進捗管理に対して、開催するレビューです。
主にプロジェクトマネージャーが中心となって、プロジェクトの進め方について話し合い、各開発工程の方針決定、プロジェクト内の工数の配分などを行います。
ピアレビュー
プロジェクトメンバー同士で成果物に対して公式・非公式問わずレビューを行う、最も簡易的なレビュー技法です。
簡易的なレビューではありますが、少ない工数で成果物の問題を検出可能な技法でもあります。
プロジェクト終了レビュー
完了したプロジェクトに対して、プロジェクト全体の総評をまとめるレビューです。
良かった点や改善点などを話し合い、出てきた意見は今後のプロジェクトに活用するための改善案として記録されます。
ステータスレビュー
プロジェクトのマイルストーンに対する進捗や、各工程で発生している問題の識別、リスクの発生状況や対応策の実施について検討するレビューです。
主に、プロジェクトマネージャーを含めた、プロジェクトメンバー全体で行われる場合が多いです。
ウォーク・スルー
成果物作成者(レビューイ)が主導となって、レビュー対象の成果物の内容を説明しながら実施するレビューです。
資料だけでは理解が難しい内容について直接説明して、レビュアーに内容を把握してもらいたい場合などに効果的です。
インスペクション
レビューの各参加者に特定の役割を与えて、チェックリストの使用や分析の実施なども行う、最も体系的なレビューです。
精度が高いレビュー技法であるため、成果物に対する問題点の検出率も高くなりますが、実施には工数が掛かります。
チームレビュー
チームで実施するレビュー方式で、前述のインスペクションほど公式的には行われないレビューです。
設計者、テスター、顧客など、それぞれの視点でレビューをしてくれるレビュアーを複数人用意することで、効率良い問題検出が期待できます。
ペアレビュー
レビューイとレビュアーが2人で行うレビューです。会議室などは利用せず、机上でそのまま実施されるレビューで、先輩社員が新人の教育を兼ねて行われるケースが多いです。
指摘内容がレビュアーの力量に委ねられるため、チェックリストなどを用意して、より指摘の精度を上げることが推奨されます。
パスアラウンド
レビュー時に参加者が集合せず、メールやグループウェアなどを活用して資料を配布して、レビュアーにコメントを依頼するレビュー技法です。
レビュアーからもらったコメントに適切に対応出来る技量が求められますが、多少の時間が掛かっても構わないレビューの場合は、実際に集まるためのコストが低減されるため効果的です。
アドホックレビュー
必要に応じて、ピンポイントで開催されるレビューです。対応出来るプロジェクトメンバーが手すきの時間に、即席で成果物のレビューをお願いします。
思いつきで都度行われるレビューであるため、網羅的な確認には向きませんが、アドホックレビューが頻繁に行われる組織は、協力的な関係を築けているといえます。
【まとめ】レビューの種類を理解しよう
ソフトウェアレビューは、品質向上や作業効率化、無駄なコスト削減の面でも非常に重要な工程です。
レビュー技法には、顧客やユーザーを交えたレビュー、メンバー内だけで行うレビューなど、規模や実施内容に違いがあります。
用途や状況によって使い分けられるため、代表的なレビュー技法については方法を押さえておきましょう。
必要なレビュー観点を明確化して、作成した成果物にどのレビューが最適かを見極めましょう。
