ソフトウェア開発の各工程での成果物を評価し欠陥がないか確認するための会議や査読といった活動や、関係者が成果物を評価・承認するプロセス全体をソフトウェアレビューといいます。
「この設計書、明日までにレビューしておいて」といった場合のレビューは簡単な査読を意味し、プロジェクト計画書の日程表に記載されたレビューは、会議日程を示しながらも準備や評価・承認、会議での指摘事項の修正確認などのプロセス全体が意識されているのではないでしょうか。
このようにいろいろな場面において異なる意味合いで使われる「レビュー」ですが、実施方法や目的、技法などにより異なった名称で表されることもあります。
本記事ではインスペクションやウォークスルーなどソフトウェアレビューの種類・特徴を紹介します。
「実施方法」別ソフトウェアレビューの種類と特徴
ソフトウェア開発の現場では、ビジネスの競争優位性を高めることを目的に、ソフトウェアの短期開発や品質向上を目指すさまざまな取り組みが行われています。そうした取り組みの一つに「ソフトウェアレビュー」があります。
ソフトウェアレビューは中間成果物も対象にできるため、プロジェクト計画や要件書、設計書などの“検討段階”から後工程に大きく影響する欠陥を見つけ出し手戻りコストを削減することが期待できます。
このようなメリットからソフトウェアレビューは多くのソフトウェア開発プロジェクトにおいて標準プロセスの一つとして位置づけられています。
ソフトウェアレビューにはさまざまな種類がありますが、ソフトウェア開発における作業成果物のレビューについて定めた国際標準規格「ISO/IEC20246」での分類を使って次のレビューについて特徴と効果を説明します。
●最も公式性が高いレビュータイプ「インスペクション」
●技術的な観点で成果物の品質をチェックする「テクニカルレビュー」
●開発者が自主的に行う「ウォークスルー」
●形式的なプロセスに基づかない非公式レビューでよく行われる「バディチェック」、「ピアデスクチェック」、「ペアレビュー」
最も公式性が高いレビュータイプ「インスペクション」
「インスペクション」で最も特徴的なことは、事前に定めた役割と手順に従ってレビューの開催から指摘事項の修正確認までを行うということです。進んだ組織では摘出された障害の根本原因の分析と活用までをも手順に含め、効果的・効率的に組織全体の品質改善スキルを上げています。
公式性が高いと聞くと煩雑で融通が利かないイメージを抱く方もいらっしゃいますが、事前に定める役割や手順を現状に合わせたものにすることで、確実に記録を残すことができるため分析や振り返りを行いやすいというメリットがあります。
技術的な観点で成果物の品質をチェックする「テクニカルレビュー」
「テクニカルレビュー」ではレビュー対象をチェックする方（レビューア）の役割に特徴があります。レビューアは自身のスキルや知見を活かしてレビュー対象が“技術的に”正しいのか、更に良い方法がないのかといった観点で指摘を行います。
レビュー対象の作成者が思いつかないような課題や解決策を指摘・アドバイスしてもらえるメリットがあります。一方でレビューアがどの観点でレビューしているのか常に意識していないと、観点外の些末な指摘が重なったり観点漏れが発生したりするおそれがあります。
開発者が自主的に行う「ウォークスルー」
「ウォークスルー」の特徴はレビュー対象の作成者が主体となってレビューを進めていく点にあります。
レビュー対象のどこを見て欲しいか、どのタイミングで見て欲しいかといったことを作成者がコントロールできるので、作成者の問題意識に沿った指摘やアドバイスを欲しいタイミングで得やすいというメリットがあります。一方で作成者が意識できていない課題や観点に関する指摘やアドバイスは得づらいかもしれません。
また、レビューのコントロールに不慣れな作成者だとどうしてもレビュー効率が下がってしまうので、教育目的も兼ねスキルの高い方に補助に入ってもらうなどを検討するとよいでしょう。
定義されたプロセスに基づかない“非形式的レビュー”でよく行われる「バディチェック」、「ピアデスクチェック」、「ペアレビュー」
“非形式的”という言葉が示すとおり、レビュー対象も参加者も決めずにチェックが欲しいタイミングで随時行うことが多いようです。
レビュー結果をどのように残すかも決まっていないため指摘したつもりで欠陥の指摘モレが発生したり誰がいつ対応するのか曖昧なまま放置されたりすることもあります。ただ、決まってないために参加者が思いついたときに気軽に行うことができるのが利点となります。
●バディチェック
レビュー対象を作成した担当者の同僚がおこなうレビューです。
「同僚はレビュー対象の作成に関わっていない」点が特徴です。このため、第三者的観点でのチェックが期待できますが、どの範囲をどう見るか決まっていないと同僚の忙しさによってチェックにばらつきが出るなどのデメリットも生じます。
●ピアデスクチェック
レビュー対象を作成した担当者とその同僚がレビュー対象をできた順にチェックするレビューです。
「作成次第チェック」していくので即時性・即効性に優れますが、非形式的レビューのため“実施されたかどうかわからない”状態に陥ってしまうこともままあります。
●ペアレビュー
レビュー対象を作成した担当者以外の2名の適任者がおこなうレビューです。
複数の適任者がチェックすることで観点の偏りや実施モレを防ぎますが、「適任者」が「どういった観点でチェックする必要があるか」分かっていないと誤字や誤記の指摘に終始し、肝心の欠陥を見過ごしてしまうこともあります。
「実施目的」別ソフトウェアレビューの種類と特徴
ソフトウェアの短期開発や品質向上とは別の目的を併せ持った「ソフトウェアレビュー」が実施される場合もあります。
ソフトウェア開発・管理・プロセス改善領域の専門家であるKarlE.Wiegers氏は2004年に著した書籍『ピアレビュー高品質ソフトウェア開発のために』（日経BPソフトプレス刊）のなかで、欠陥の発見を目的とするソフトウェアレビュー以外にも、次のような種類があると述べています。
●チームメンバーのスキル底上げや次世代育成を目的とする「教育レビュー」
●次工程へ進むことを出席者で合意するための「ゲートレビュー」
●開催時点での状況を正確に把握するための「ステータスレビュー」
●組織全体で成長していくための「プロジェクト終了後レビュー」
これらの目的別レビューについて特徴と効果を説明します。
チームメンバーのスキル底上げや次世代育成を目的とする「教育レビュー」
「教育レビュー」は、チームメンバーのスキルを引き上げたり、レビュー対象に関係する技術的な知見をレビュー参加者と共有したりすることを目的に行うものです。
次のような教育目的で前述の「実施方法」別レビューに組み込まれて実施されます。レビューの開始前にどんな点を学んで欲しいか確認をとったり、画面に目的を写しておいたりするなどの工夫をすると参加者の意識づけになり教育効果も上がります。
●新人、新任者教育
チームに新たに参画した方や、チーム内で新たな役割を担うことになった方に向けて、チーム文化や暗黙のルールなどを共有することが目的です。
こまめに棚卸しをしないと暗黙知は「担当者しか知らない属人的な知識」になりがちなため、教育の対象者以外もオブザーバーや教師の立場で定期的に参加するよう仕掛けていくとよいでしょう。
●チームのスキルアップ
新たにチームが取り入れることにした技術や最新の業界知識などについてチームメンバー全員が把握することが目的です。最低限、「このことについては○○さんに聞けばよい（Know-Who）」程度は知っておけるようにしたいものです。
最新技術を取り入れた機能に対するレビューや要件レビューなどに組み入れることが多いと思われます。
●次世代の育成
会議進行や準備のスキル、顧客との折衝スキル、リスクに対する嗅覚や判断力を鍛えるなど、様々な目的があります。往々にしてシビアなレビューに組み込まれることが多いので、参加者はそこで取り上げられる課題や問題に目が行きがちとなります。
しかし、そのレビューでどういったことを学んで欲しいか、レビュー開催前に参加者に伝えるだけで学びの効果が大きく変わります。折角の機会ですのでレビューの場を十全に活用してください。
次工程へ進むことを出席者で合意するための「ゲートレビュー」
「ゲートレビュー」は、次の工程に進むことや、進むための条件などについて公式に合意を形成することを目的として開催されるのが特徴です。
このため「合意がとれたかはっきりしない」、「後から合意をひっくり返される」といったことがないように形式的なレビューとして行われるのが一般的です。
特に主催者は、「何について合意を得たいのか」、「合意を得られない場合はどうするのか」を明確にしておくなど開催前に万全に準備をし、レビューの場をコントロールする心構えで臨みましょう。合意事項の記録はしっかりと残し関係者に正式文書として配付します。できれば会議終了時点で参加者に確認しておくと、後日、合意事項があいまいにされることをかなり防げます。
開催時点での状況を正確に把握するための「ステータスレビュー」
「ステータスレビュー」は、プロジェクトマネージャーやマネジメントに関連する他のメンバーで、マイルストーンに対する進捗、発生した問題の概要や対応責任者、対応期日、リスクなどの確認をするために行います。
状況を正確に把握することが第一の目的のため、ゲートレビューとは異なり公式の合意形成を必ずしも必要とはしません。ただし、状況の変化を確実に捉え、深刻な状況に陥る前に対応できるよう適切なスパンで定期的に開催されます。
状況の変化に気づきやすいよう報告を定型化したりレビュー対象を定量的に捕捉するメトリクス（測定基準・尺度）を決めたりするなど効率的に開催できるような工夫が図られています。
組織全体で成長していくための「プロジェクト終了後レビュー」
「プロジェクト終了後レビュー」は、関係者の記憶が新しい内にプロジェクト全体や工程単位で振り返りを行い、将来のプロジェクトに活かすための知見を得ることを目的としています。
大きな進捗遅延につながった問題や、お客様や社会に大きな(負の)影響を与えてしまった問題を1～3件程度メインテーマとして取り上げて、根本原因を探り再発を未然に防ぐ仕組みにつなげていく活動全体を指します。
他のプロジェクトと比較し良い点は残し悪い点を改めるきっかけや学びの場として活用されることも多いようです。組織の成長に大きな効果がある取り組みのため、部門横断で継続的に開催することをお勧めします。
「技法」別ソフトウェアレビューの種類と特徴
これまで、国際標準規格「ISO/IEC20246」での分類別やレビュー実施の目的別にソフトウェアレビューをご紹介してきましたが、レビュー技法による分類でのレビュー名称もあります。
本章ではよく使われている次3技法について特徴と効果を説明します。
●「チェックリストベースドレビュー」
●「シナリオベースドレビュー」
●「パースペクティブベースドリーディング」
“どこをどう見るか”示したチェックリストを利用する「チェックリストベースドレビュー」
「チェックリストベースドレビュー」は、チェックリストに基づいてレビューします。このレビュー技法は使用するチェックリストに次の二つの特徴があります。
●チェック項目が少ないこと
チェック項目は25項目前後、使い勝手を考慮すると1ページの書類に収まる量が望ましいでしょう。
＊TomGilb,DOrothyGrahamの「ソフトウェアインスペクション」では、“必ず１ページに収まるようにする”とあります。
●各チェック項目は“どこに着目”して“どう見るか”が示されていること
チェック項目には、例えば次のようなチェック内容が記載されています。
レビュー対象のドキュメントの中でモジュールの名称は一貫して同じ名称か（同じモジュールを別名称で記載したり、異なるモジュールを同じ名称で記載したりしていないか）、チェック項目が1ページに収まっていると、レビューアはチェック項目を探したり考えたりすることなくレビューに専念できます。また、観点が具体的に示されているのでレビューアのスキルによる指摘のバラツキが少なくなります。後から何をチェックしたかを記録に残せるため、問題が発生した際に真の原因を探りやすい点もこの技法のメリットといえるでしょう。
一連の流れを確認することが出来る「シナリオベースドレビュー」
「シナリオベースドレビュー」は、あらかじめ作成されたシナリオと呼ばれる「始まりと終わりのある一連の動作を示したもの」に基づきレビューする技法です。これには大きく2つのメリットがあります。
●システムやアプリの外で発生する動作を含めることができる
例えば「ユーザーが画面から離れている間にエラーが発生する」などといったシナリオを使えば、エラー情報の出し方や復旧方法の妥当性をユーザーの立場に立ってチェックできます。
●複数のユーザーが関与した場合や複数の機能・異なるシステム間の連携が確認できる
シナリオを使うことで、例えば権限が異なるユーザーが一連の処理を行う場合の問題や受け渡しデーターの整合性やマスターの更新タイミングといった複雑な問題を検出することが出来ます。一方で、流れに分岐がある分だけシナリオが増えるため、優れたシナリオを作る難しさやレビューでどのシナリオを使うかといった判断の難しさがあります。
特定の役割が持つ観点を活かした「パースペクティブベースドリーディング」
パースペクティブベースドリーディング」でもシナリオを使いますが、一番の特徴はレビューする人（レビューア）が特定の観点を持ってレビューに臨む点にあります。
一般的に、「顧客」、「テスト担当」、「設計担当」の観点が使われます。例えば「テスト担当」としてレビューに臨む場合、「このドキュメントに記載されている情報でテスト項目が設計できるか、初期値は何？異常値はある？」などといったことをチェックします。
観点が定まっている分、特定の問題を見つけやすいメリットがありますが、レビューする人（レビューア）のスキルや知見に依存する、属人性の高いレビューとなってしまいがちなデメリットも併せ持ちます。
これらのレビュー技法で効果を上げるには、それぞれの技法に適した規模、開発プロセス、タイミングで利用する必要があります。技法を中心に据えずあくまで道具として「どの工程で、どの技法を使うと効果が高くなるか」と考えるのがよいでしょう。
参考：
開発手法ガイドブックガイドブック 2011年3月 ＩＰＡ独立行政法人情報処理推進機構
https://www.ipa.go.jp/files/000005144.pdf
情報マネジメント用語辞典 インスペクション（いんすぺくしょん）
https://www.itmedia.co.jp/im/articles/1111/07/news208.html
SQiP2017 レビュー技術動向 2015年9月 SQuBOKV3研究チーム（誉田直美）
https://www.juse.jp/sqip/symposium/archive/2017/day1/files/happyou_F1-2-2.pdf
続 定量的品質予測のススメ 2011年3月 IPAソフトウェアエンジニアリングセンター
https://www.ipa.go.jp/files/000005143.pdf
