全関係者の“納得”が、レビュー成功の大前提：ソフトウェアレビュー入門（2）（2/3 ページ）
いかにレビューが有益なものであろうと、また、実践のための合理的な準備・計画があろうと、それだけでは効果は望めない。レビューにかかわる全関係者にその有用性を理解してもらうことが、成功の前提条件となる。
「誰が」「いつ」「どのように行うか」を明確化する
レビューの計画段階では、以下の図1のようなチェックシートを作ります。レビューする対象から、レビューの方法、参加するメンバー、対象ドキュメントの保管方法まで、レビューに関係するすべての項目を定め、今回の計画で適用する項目については、項目名の左側にある□を■に塗りつぶす、あるいはチェックを入れることで、計画内容を明確化するのです。
こうしたチェックシートを使ったレビュー計画は、ソフトウェア／システム開発全体の計画時に決めておきます。どのようなタイミングで何度レビューを実施するのか、どれくらいのコストが掛かるか、すなわち「レビュー計画」を最初に決めておかないと、「時間がない」「コストを計上していない」といった理由でスキップされてしまうためです。
では、レビュー計画に必要な図1のチェックシートの各項目について、順に解説していきます。
レビュー対象
レビュー対象とするドキュメントを明示する項目です。ソフトウェア開発で作成する成果物、中間成果物のすべてをレビュー対象と考えます。
レビュー対象は、最初はあまり欲張らず、「過去にレビューを行って効果が出たもの」「過去に問題を見逃した結果、修正インパクトが大きくなってしまったもの」を優先するのがコツです。
修正インパクトが大きかった不具合については、過去のプロジェクトのバグ票を見れば比較的短時間でみつけることができるでしょう。また、レビュー対象は、参加予定メンバーの意見を取り入れて選択することも大切です。
レビュー結果の利用方法
レビュー結果をどのように使うかを決めておくものです。最も一般的な利用方法は「エラー修正」で、指摘エラーを修正することで成果物の品質を高めることを狙います。「進行判定、計画変更」は、レビュー結果を用いた全体の見直し、スケジュールの立て直し、テスト計画の修正などを指します。「代替案検討」とは、設計や実装の方式変更や、パッケージ、既成ライブラリの利用など、別の実現方法を考えたり、「品質が極端に低い場合には前のバージョンを使う」など、代替案を考えることを指します。
このほか、規格・法令・標準への準拠度合いを調べたり、今後の拡張やバージョンアップ時の保守性を高めたりするためにレビューを実施します。「結果をどう使うか」を計画しておけば、「目的」を把握できているわけですから、おのずと有用な指摘が増えるのです。
レビュー回数
「1つの成果物に対するレビューは1回」が一般的ですが、完成した部分を対象に、何度かに分けてレビューを実施したり、目的を絞って目的ごとに複数回実施したりすることもあります。ここでは、そうしたレビューを行うタイミングと回数を明記しておきます。
1回で済ませるメリットは、全体を見ながらエラーを指摘できること、参加メンバーの日程調整が少なくて済むことです。複数回に分けるメリットは、早期にエラーを指摘できる、修正する順番によって別のエラーが発生するムダを最小限に抑えられる、指摘の時期を分散させられる（すなわち、成果物の完成後、大量のエラーが一度に指摘されることがない）といったことが挙げられます。
予定所要時間
レビュー工数確保のために記入する項目です。「準備」と「実施」に分けて、所要時間や所要工数を明らかにしておきます。レビューに対する心理的抵抗が大きい組織では、少ない時間・工数にしたくなるのが人情ですが、現実に近い値を書いておかなければ、レビューの定着にはつながりません。
実施形態
参加メンバーが集まり、会議形式でエラー指摘する場合は「会議」に、締め切りを設定し、それまでに各参加メンバーがエラーを指摘し、メールや支援ツールを使って結果を集める場合は「非同期」にチェックを入れます。「会議」の場合は「●●拠点の会議室」といった実施場所の情報を、非同期の場合は「結果を集める方法」を明記することで、現実的な計画が立てられます。
これにより、例えば分散した拠点で開発している場合、この一覧表であらかじめ「会議」とチェックしておけば、スケジュールを組む際、参加メンバーの移動時間を考慮しなければならないことも忘れずにすむわけです。
参加必須メンバー
適切な指摘ができるメンバーを記入します。例えば、障害発生時の復旧手順や、それにかかわる設計・実装がレビュー対象であれば「運用担当者」を入れておく必要があります。セキュリティに関するレビューを行いたいときには、セキュリティの知識を持った参加者が必要になります。
参加者を選定しようとすると、ついつい自分の知っている個人の顔や名前が浮かんでくるものです。しかし個人的な人脈だけを基準に選んでしまうと、仮にその人の負荷が上がったり、体調が悪くなったりするなど、レビューに参加してもらえなかったとき、適切な代理メンバーをすぐに確保できなくなる可能性が高まります。できるだけ「部門」や「スキル」を基準に選定するようにしましょう。
レビュー開始条件
レビューを必ず実施するのか、条件がそろったときだけ実施（条件付き実施）するのかを決めます。必ず実施する場合も「どのような条件がそろえば開始するのか」を決めておきます。ポイントは「事前チェック」の設定です。これによって、「まだレビューできる状態にない」といった認識違いを大幅に減らすことができます。
事前チェックには、ドキュメントの作成担当者自身で、完成後にチェックリストなどを使って実施する「成果物のセルフチェック」、品質保証部門をはじめとする「第三者部門による検査」、「ツールによるチェック」などがあります。特に、ソースコードやUMLなど、機械的に解釈できる記法に沿ったドキュメントの場合には、事前に「ツールによるチェック」を済ませておくと、その後のレビューが効率的に行えます。
レビュー終了条件
どのような状態になれば、「レビューが終了した」と判断するかを明確にする基準です。「参加者によって指摘がひととおりなされたと判断した時点で終了」が最も一般的です。プロジェクト予算などの制約によっては、時間または工数に上限を設けなければならないときもあります。そうしたときは「時間または工数」にもチェックを入れ、上限を明記します。
レビューの実施時間や指摘内容を基に、品質保証部門をはじめとする第三者の承認によって完了する場合は、「第三者による承認」にチェックを入れます。「そのほかの条件」には「チェックリストに掲載されている項目を網羅」「要件トレーサビリティとの突き合わせ確認」「ほかの成果物との不整合チェック」などを指定します。終了条件を明らかにしておけば、レビューで何をすべきかが自ずと明らかになります。
事前準備
このチェック項目によって、参加者が「事前にレビュー対象に目をとおしておくかどうか」を指定します。会議形式でレビューを実施する際には、エラー指摘から開始するのか、成果物を読み合わせるところから開始するのかによって、必要な会議時間が大きく変わってきます。「事前に読んでいる参加者もいれば、そうでない参加者もいる」という状況を作らないことが大切です。
また、成果物を読むだけでは指摘できないような問題も存在します。そこで、関連する規約や文書などに、あらかじめ目をとおしておいてほしいときには、「関連資料に目をとおしておく」にチェックを入れます。ただ、参加者への負担が増えるため、関連資料は必要最低限にするよう配慮してください。資料やレビュー対象は、ファイルサーバで共有したり（ファイルサーバやリポジトリに保管する場合には、その保管場所も記入します）、メールで送付するなど、作成者が閲覧しやすいよう配慮しましょう。
図1の計画と実績を比較するためのExcelシートを、私が所属する奈良先端科学技術大学院大学のソフトウェア工学講座のWebサイトからダウンロードすることができます。計画立案とプロジェクト終了後の振り返りのために、ぜひ使ってみてはいかがでしょうか。
Copyright © ITmedia, Inc. All Rights Reserved.