レビューを「数」だけで管理しているからコストが膨らむ：ソフトウェアレビュー入門（5）（3/3 ページ）

» 2010年08月19日 12時00分 公開
[森崎修司，奈良先端科学技術大学院大学 情報科学研究科]
前のページへ 1|2|3 　　　　　　

指摘の「質」に、進行役が常に気を配ろう

　では、「管理指標や数値目標では把握できない部分を意識しながら、管理指標や数値目標とうまく付き合う」ための具体的な対策について考えてみましょう。

　まず、検出密度や指摘件数などの数値は、「あくまで適切な指摘ができていること」を補助的に示すものであり、「その値をクリアしたからといって、適切な指摘ができていることを保証するものではない」ということをレビュー参加者全員が認識する必要があります。しかし、それ以前に「レビューを実施するそもそもの目的」を認識できていないと、これを真に理解することは難しいでしょう。よって、まずは「レビューとは問題の早期発見により、問題や不具合の修正コストを小さくする活動である」という共通認識を徹底しておくことが大切です。

　では、前のページの図 3（b）（c）のように「特定個所に指摘を集中」させることなく、「早期発見により修正コストが小さくなるような指摘」をバランス良く引き出すためにはどうすべきなのでしょうか？ 冒頭の事例のように、レビューが完了した後で「特定個所への集中」「問題の取りこぼし」に気付いたとしても、再レビューや追加レビューを実施する以外に方法がありません。

　従って、そうした事態を避けるためには、レビューの実施中に、「レビュー本来の目的を達成できているかどうか」について、レビューアや進行役が意識的に確認しながら進めていくしかないのです。

　すなわちレビューの最中は、冒頭の事例においてPMがそうしていたように、「○件指摘がなされていて、それに対するドキュメントのレビュー対象範囲は○ページだから、そろそろ次のテーマに移ってもよいかな」などと「指摘密度」を計算するのではなく、「網羅的に指摘されているか？」「レビューで指摘する価値のあるエラーが、きちんと指摘されているか？」といった質問を繰り返しながら進めていく必要があるのです（注）。そしてこれらが守られていないときには、即座に軌道修正する必要があります。また、「レビューの目的に沿った指摘」のみを指摘件数として計上する、といった方法も考えられます。

注 ：「網羅的な指摘」の方法については、第4回「ソフトウェアレビューが成功する進行役の6条件 」での「進行役が担うべき役割」で詳細に説明しています。「指摘する価値のあるエラー」については、第1回「確実な記録こそが、品質・コストに貢献する」の「“目的のない間違い探し”が一番よくある失敗」を読み返してみてください。

　とはいえ、以上を意識しながら実施した場合でも、指摘件数が計画上限、計画下限から外れてしまった場合には、組織の標準プロセスやプロジェクトの品質管理計画に従って、再レビューや追加レビューを実施することになることが多いと思います。

　そうした再レビュー、追加レビューの際には、「“再々レビュー”が必要」という展開にならないよう、「適切な指摘ができるスキルを持ったレビューアが参加できそうか」「もともとのレビュー対象の品質は、（高すぎる、低すぎる、ということなく適切な指摘ができるだけの）想定範囲に入っているものか」「レビューの目的は明確になっていて、レビューア間で共有できているか」といった項目を再確認しておく必要があります。

計測すべきは「指摘によって省略できた修正コスト」

　また、繰り返しますが、レビューの主要な目的は「エラーを早期に発見、修正することにより、修正コストを低減すること」です。その効果は、「エラー指摘によって、どのくらいの修正コストを低減できたか」によって決まります。

　つまり、指摘したエラー1件1件について「もしもこのエラーを見逃してテストで発見されたとしたら、テストでの修正コストはどの程度かかるのか」を常に意識する必要があるのです。それが保守性に関する指摘であれば、「もしもこのまま修正されずリリースされたとするならば、バージョンアップや機能拡張の際、改変やテストにどのくらい余計なコストが必要か」と考えます。

　図4は「設計レビューでエラーを発見した場合」と「結合テストで不具合として発見された場合」の修正コストの内訳を示したものです。図のように、設計フェイズで混入された欠陥を、設計フェイズで修正しなかった場合、誤った設計に基づいてコーディングが実施され、そのコードの誤りが結合テストで検出されます。結合テストでの修正には、設計書の修正だけではなくソースコードの修正も必要になります。

ALT 図4　レビューで問題を見落とすと、後の工程でより多くの修正コストがかかるものがある。そうした「後の工程でかかる修正コスト」から「レビュー直後の修正でかかるコスト」を引いた値が、そのレビューの“価値”となる

　さらに、修正個所の確認テストだけではなく、ソースコードの修正によってデグレードが発生していないか（これまで期待どおりに動作していた部分に、新たに不具合が混入されていないか）をテストする必要も生じてしまうのです。

　また、複数人で予定を合わせて同時に実施するレビューの場合、ほかのソフトウェア開発活動よりも「実施コストの高い活動」となります。従って、レビューを行った効果を実感するためには、「指摘による修正コストの低減」がレビュー実施コストを上回らなければなりません。

　図5の上の図「レビューで指摘すべきエラー」は、早期に発見されることによって修正コストが低減されるエラーです。一方、下の図「レビューで指摘しても価値のないエラー」は、早期に発見されても修正コストが変わらないエラーを表しています。

ALT 図5　以上のようなロジックで、「コスト面で効果のある指摘」をするよう心掛ける

　対象ソフトウェアに求められる品質やプロジェクトによっても異なりますが、例えば「レビューで負荷や入力サイズを明確に想定していなかったために、コーディングが一通り終わって初めて性能問題に気付く」ことがあります。このタイプの指摘は図5の上に該当します。テストにおいて性能を向上させようとすると、通常は変更個所が多くなり、テスト量も増え、その分余計な修正・確認コストが掛かります。

　一方、エラーメッセージなどの「文言の訂正」や「ドキュメント（中間成果物）の記述フォーマットの誤り」は、テストで発見されたとしても、修正コストがそれほど大きくならない傾向にあります。このタイプの指摘は図5の下に該当します。フォーマットや文言の誤りは「もっと大きな問題を含んでいる可能性を示す不吉な印」と言われることは多いのですが、その周辺を調べることと、その「印」自体をレビューで指摘することはまた別の問題です。つまり、図5の下の図のような、コスト低減に寄与しないエラーばかりが指摘されないよう、事前準備を整え、レビューの進行中も適切に誘導するよう配慮することが大切なのです。

　例えば、4人で2時間かけてレビューをすると、8人時のコストを消費します。従って「そのレビューで指摘されたエラーの修正コスト」と、「エラーが見逃されて、テストで修正された場合のコスト」を比較して、「8人時」よりも大きなコストが省かれている必要があります。このように、レビューはコスト的な観点からも適切、かつシビアに行わなければ、その意義が半減してしまうものなのです。

　加えて、前のページで紹介した図3(b)のような「指摘の偏り」があると、「省略できた修正コスト」の計算にも実態とのズレが生じてきます。「省略できた修正コスト」をより正確に計算するためにも、対象ドキュメントの品質を見極めながらまんべんなく指摘ができるよう、進行役が常にモニタリングし、必要であれば軌道修正していくことが大切なのです。

　レビューの管理指標は収集、報告の形式が組織で決まっていることもあり、どうしても指摘件数に目が奪われがちなものです。しかしレビューの本質は、「早期に問題を発見することでコスト削減に寄与できるような指摘を行う」ことにあり、それを目指して取り組んだ“結果”が管理指標に現れるに過ぎません。よって、レビューの効果を上げるためには、「管理指標をクリアする」ことを心掛けるのではなく、繰り返し説明するように、「早期に発見することによって、修正コストを小さくできるエラーを指摘する」というレビューの原理原則に徹することが重要なのです。

　次回は「早期発見による修正コストの低減」について、より具体的に考えるために、「テストとレビューの関係」について解説したいと思います。

筆者プロフィール

森崎 修司（もりさき しゅうじ）

国立大学法人 奈良先端科学技術大学院大学 情報科学研究科 助教

ソフトウェアレビュー／ソフトウェアインスペクション、ソフトウェア計測を専門とし、研究・教育活動をしている。奈良先端科学技術大学院大学にて工学博士を取得後、情報通信企業でソフトウェア開発、開発管理、レビューに従事。現在、同大学院に奉職。研究成果を業界に還元していくことをミッションの1つと位置付け、ソフトウェアレビュー研究の国際連携ワーキンググループの主導、多数の企業との共同研究、文部科学省「次世代IT基盤構築のための研究開発: StagEプロジェクト」に従事。アイティメディア オルタナティブ・ブログで「森崎修司の『どうやってはかるの？』」 を執筆中。

ソフトウェアレビュー／インスペクションの研究グループ：

http://se.aist-nara.ac.jp/html/review/

ソフトウェアレビュー／インスペクション研究の国際連携ワーキンググループ：

http://www.software-inspection-wg.org/

StagEプロジェクト：

http://www.stage-project.jp/



「ソフトウェアレビュー入門」バックナンバー
前のページへ 1|2|3 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ