ソフトウェア開発におけるレビューには様々な種類がありますが、レビューの種類を意識して開催することは少ないと思います。
ですが、実はレビューは種類ごとに参加者や目的が異なり、実施するレビューによって成果物やプロダクトへの貢献度も変わってきます。
本記事では、ソフトウェア開発におけるレビューの概要、関係者（役割）、種類、レビュー対象の成果物について詳しく解説します。
レビューとは？
レビューは直訳で「批評」「見直し」という意味を持ち、システム開発・ソフトウェア開発などのIT分野では成果物の品質を検証・討論する場の事を指します。
JSTQBでは、静的テストのレビュープロセスとして、プログラムやシステムを動かさずにできる品質検証方法の一つとして解説されています。
一口にレビューと言っても様々な形式があり、開発の現場で頻繁に行われる下記の行動もレビューに該当します。
- 隣の同僚に仕様について確認する
- 開発者で集まって認識違いがないか確認する
- 関係者全員が集まって成果物について確認する
レビューの関係者（役割）
レビューに参加する関係者には下記のような役割があります。
- レビューイ（作成者）
成果物を確認してもらう人。基本的には成果物の作成者の事を指す。 - レビュアー（レビューア）
成果物を確認する人。 - モデレータ（ファシリテーター）
レビューの進行管理を行い、場をとりまとめる人。 - 書記
レビューにおける議事録やとりあげられた事項を記録する人。 - マネージャ
レビューの管理や開催に伴う参加者の招集を行い、ドキュメントの受領などを行う人。
上記の通り、レビューに参加する関係者はおおまかに5種類に分類されます。
レビューの際には全ての関係者が必要という事はなく、レビューの種類に応じて必要な関係者は変わります。
レビューの種類
レビューには下記のような種類があります。
- 非形式的レビュー
- ウォークスルー
- テクニカルレビュー
- インスペクション
非形式的レビュー
決まったプロセスは存在せず「隣の席の同僚に確認してもらう」「メールで連絡をして空いた時間に確認をしてもらう」などの方法で手軽に行えるレビュー形式が非形式レビューとなります。
コストや時間を最小限に抑えて欠陥を検出する事を目的としています。
参加者はレビューイ、レビュアーの2種類となり、他のレビューと比べて最も参加者の少ないレビュー形式となります。
ウォークスルー
レビューイがレビューの進行を主導し、運用シナリオなどを基に処理内容の確認や欠陥の検出を行うレビュー形式がウォークスルーとなります。
レビューイは予めレビューしてほしいポイントなどを資料として用意し、レビュアーと協議します。
基本的には成果物の欠陥の検出を目的としていますが、参加者にソフトウェアの処理などに関する内容を学習させ、仕様を理解してもらう事も目的としています。
また、運営の仕方によっては潜在的な欠陥の検出やレポートの作成なども行う場合があるため、非形式的なレビューになる場合もあれば、形式的なレビューになる場合もあります。
参加者は基本的にレビューイ、レビュアー、書記の3種類ですが、状況に応じて書記はレビューイが兼任したり、関係者が増える場合もあります。
テクニカルレビュー
同僚や技術のエキスパートがレビュアーとして参加し、欠陥の検出だけでなく代替案、解決案の掲示も行うレビュー形式がテクニカルレビューとなります。
比較的参加者が多く、事前の準備が必要なレビューとなるため、レビューの進行は経験を積んだモデレータが行う場合が多いです。
レビューにて作成した議事録、チェックリスト、欠陥検出のドキュメント、レポートなどをマネージャへ報告するまでがテクニカルレビューの一連の流れとなります。
参加者はレビューイ、レビュアー（技術エキスパート）、モデレータ、書記の4種類ですが、モデレータ不在で技術エキスパートとのみ行う場合もあります。
インスペクション
成果物の欠陥を見つけるだけでなく、潜在的な欠陥の検出、品質の評価、関係者の学習、根本原因分析による将来的な類似欠陥の防止など、様々な効果が期待できる最も公式性の高いレビュー形式がインスペクションとなります。
レビューを行う際には、事前にドキュメントを用意して関係者に配布し、関係者は懸念事項を予め洗い出しておく必要があります。
レビューの進行は経験を積んだモデレータが行い、書記も兼任ではなく専任で用意してレビューを行います。
レビューにて作成した議事録、チェックリスト、欠陥検出のドキュメント、レポートなどは、マネージャへ報告するまでがインスペクションの一連の流れとなります。
参加者はレビューイ、レビュアー（技術エキスパート含む）、モデレータ、書記の4種類ですが、各々の役割が厳格に決まっていて兼任ができないため、レビューの際の成果物を読み上げる「読み手」を用意する場合もあります。
ウォークスルーとインスペクションの違いとは？
非形式的レビューとテクニカルレビューは専門家の参加の有無という違いがあるため、レビューの違いもわかりやすくなっています。
一方で、ウォークスルーは参加者や作成するドキュメントによってインスペクションと似たような形式的なレビューとなる場合があり、違いがわかりにくいと感じることがあります。
形式的なウォークスルーとインスペクションの違いについては、下記3点で判断することができます。
1. モデレータに求められるスキル
- ウォークスルー
レビューイがモデレータを兼任して行うことがあり、モデレータにスキルを求められることはない。 - インスペクション
開始基準と終了基準を厳格に定めてレビューの進行を行うため、モデレータには進行役としてのスキルを求められる。
2. 担当兼任の有無
- ウォークスルー
担当を兼任する場合がある。 - インスペクション
担当者が明確に分かれていて、基本的に担当を兼任することはない。
3. レビュー目的の違い
- ウォークスルー
一般的に開発中の確認のために行い、仕様の抜け漏れ・処理内容の解釈などが問題ないか確認することが主なレビュー内容となる。 - インスペクション
開発を一通り行った後に行い、成果物の欠陥を見つける事が主なレビュー内容となる。
また、インスペクションは成果物の欠陥の検出だけでなく、成果物を評価することで作成者の学習に貢献したり、根本原因分析を行うことで将来的な類似欠陥の防止に貢献することも目的としている。
レビューを行う成果物の種類
レビューはエンジニアが作成する詳細設計書やコードを対象にして行うものと思われることが多いですが、レビューは全ての成果物に対して実施する事が理想とされています。
具体的な例としては、下記のようなドキュメントや情報は全てレビュー対象となります。
- 要求分析
- 要件定義
- 仕様書
- アーキテクチャー
- ユーザーストーリー
- テストケース
- テストウェア
成果物のレビューは一見余計な工数をかけているように思われることもありますが、故障や欠陥を検出した際の原因の特定や修正のコストを最小限に抑える事が可能となりますので、できる限りコストをかけたい工程となります。
例えばですが、完成後のソフトウェアと完成前のソフトウェアで故障が発生したとして、どちらがより軽微なコストで対応可能となるでしょうか。
完成後のソフトウェアの場合は、故障の原因を特定するためにプログラムの処理を調査するだけでなく、原因が仕様書にある場合も疑って仕様書を再確認する必要があり、修正コストが大きくなります。
完成前のソフトウェアの場合は、対応範囲は単体レベルや結合レベルの修正に留まり、故障を検出したタイミングが早ければ早いほど修正コストも軽微になります。
このように、成果物をレビューする事はリスクヘッジという観点でも大きな意味を持っていますので、可能な限り成果物のレビューはコストをかけたい工程になります。
まとめ
本記事のまとめは下記の通りとなります。
- レビューは成果物の品質を検証・討論する場の事を指す
- レビューの関係者には5種類の担当者がいる
- レビューの形式によって4種類のレビューに分類できる
- レビューは故障や欠陥を検出した際の原因の特定や修正のコストを最小限に抑える事も目的としている
ソフトウェア開発を行う際には、レビューの重要性を理解したうえで適切な工数を割けるように調整することも重要な作業の一つとなります。
レビューの意味や種類、目的を理解し、適切なレビューを行うことで、健全な開発となるように心がけましょう。
