ソフトウェアレビューが成功する進行役の6条件：ソフトウェアレビュー入門（4）（2/3 ページ）

[森崎修司，奈良先端科学技術大学院大学 情報科学研究科]

レビューの効果は、進行役のスキルで決まる

　以下の表1に典型的な役割分担と人数を示しました。一般に、レビュー参加者の人数は2〜6名程度が良いとされています。人数が多いとコストが掛かることに加え、意見が集約されにくくなったり、話が横道にそれやすくなったりして効率が下がるからです。

役割	典型的な人数
進行役	1名
レビューア	1〜4名
記録役	1名
作成者	1名〜（レビュー対象による）
オーガナイザ	1名
リーダー、プレゼンター	1名〜（インスペクションの場合。レビュー対象による）
表1　ソフトウェアレビューで設定すべき役割と、それぞれの人数

　では、それぞれの役割について解説していきます。

進行役（モデレータ）

　進行役は司会進行を務め円滑にレビューを進めます。そもそも時間が限られた中で効率的なレビューを行うためには、進行役による適切な進行が不可欠といえるのです。レビューア同士の面識が少なく、活発な指摘が期待しにくい場合でも、進行役の配慮次第でレビューの効果を高めることができます。教育、育成目的の場合を除き、進行役は十分に経験を積んだ人が担当することをお勧めします。

　進行役が担うべきことは多岐にわたり、いずれも大事です。しかしながら、現実には進行役の役割に対してあまり注意を払われていないのではないでしょうか。ここでは、進行役が配慮すべき6つのポイントを解説します。

・レビューアがエラー発見に集中できているか

レビューアがエラー発見に集中できていないようであれば、集中できるように配慮します。例えば、エラー発見とは関係のない仕事をしようとしていないか、エラーの指摘を二の次にして、自身の知識や経験をアピールしようとしていないか、作成者やほかのレビューアへの個人攻撃をしようとしていないか、など、レビューアらの様子にしっかりと目を配る必要があります。そのような状況に気付いたら、エラー発見を促す質問をしたり、エラー指摘とそうでない部分を切り分けて「レビューの場ではエラー指摘に重点をおく」ように伝えたりしましょう。

・レビューアがエラー発見の手掛かりを得られているか

レビューアが着眼点を持てているか様子を見ます。エラーが発見できていない場合や、本質的でない指摘が多い場合には、エラー発見のきっかけとなるような質問を投げ掛けるなどして着眼点を持てるように支援します。例えば「例外処理は定義されていますか？」「タイミングに矛盾はありませんか？」「競合が起きたり、リソースがなくなったりすることはありませんか？」「（2名以上が担当する部分で）お互いに『自分の担当ではない』と思っていそうなところはありませんか？」など、レビューアが問題点をイメージできるよう具体的に質問をします。

・遠慮して発言していないレビューアがいないか

組織文化によっては、目上の作成者やレビューアへの指摘を遠慮してしまうことがあります。しかしながら目上の人自身も、そのような理由でエラーが指摘されないことを本心から望んでいることはまれでしょう。進行役は、「エラー指摘やそれに伴う質問は、レビュー対象の品質を上げるためのものであり、目上の方を敬わない心の表れではない」ことを、参加者全員に認識させる必要があります。

図1　レビューア1人1人の様子に気を配り、適切な指摘を引き出そう

・適切なエラー指摘がなされているか

指摘のたびに、「レビューの目的にあったエラー指摘がなされているか」をチェックします。第2回『 全関係者の“納得”が、レビュー成功の大前提』で紹介したように、レビュー開始前に参加者の間でレビューの目的を確認しておきます。もし参加者が途中で目的を忘れているようであれば、進行中であっても目的を再確認します。例えば、「誤字脱字の指摘ばかり」になっていたり、「長期間、保守する予定がないソフトウェアなのに、保守性や拡張性に関する指摘をしたり」していないかに留意します。

・進行のペース（時間配分）は適切か

限られた時間でレビュー対象を漏れなく検証できるよう、適切なスピードで進められているか時間配分を勘案しながら進行します。時間制限があるレビュー会議の場合、レビュー対象の前半部分や冒頭部分で時間切れになってしまわないか、後半部分のレビューがおろそかになってしまわないかを予測しながらペースを考えて進めます。逆に、時間制限がゆるやかなレビュー会議でも、レビュー時間が長くなり過ぎて会議後半でレビューアの集中力が切れてしまわないかを考えながら進めます。また、一度に集中して指摘が挙がっているときには、記録係が1つ1つの指摘をきちんと記録できているかにも配慮します。

・作成者は指摘を受け入れているか

自身の作成したものに非があることを認めるのを極端に嫌がる作成者もいます。指摘されたエラーをエラーとして認めないばかりでなく、ほかのエラーを引き合いに出して、その作成者を責めることもあります。しかし進行役は、作成者がエラーを認め、修正するよう確実に伝えなければなりません。エラーを認めない理由の1つは、レビューを個人の力量やスキルを評価する場と考え、自身の評価が下がるのではないかと考えているからです。進行役は、レビューの目的はエラーの早期検出であり、作成者を評価する場ではないことを参加者全員にはっきりと認識させることが大切です。

図2　時間配分や指摘の質、記録の進ちょくにも目を配る

　いかがでしょう？ 進行役を務めたことがある、あるいは普段務めている人は、こうした数々の配慮を認識できていたでしょうか？ 普段はレビューアとして参加している方も、ぜひこれらのポイントを基に、普段の活動を振り返ってみてください。

各メンバーは自分の役割をしっかり自覚しよう

　では続いて、進行役以外の役割も紹介しておきましょう。

レビューア

　エラーを指摘します。ほとんどの参加者がレビューアの役割を担当します。第1回『“確実な記録”こそが、品質・コストに貢献する』で説明したように、「レビューで見逃され、テストで発見された場合と比較して、修正、確認するコストが低減されるような指摘」「対象ソフトウェアやプロジェクトにとって重要な（レビューで見逃すと致命的な欠陥の）指摘」を行えるよう常に心掛けます。

記録役

　レビューアの指摘を書き留めていきます。通常1人で担当します。漏れ、誤りなく指摘を記録するには経験が必要です。経験の少ない参加者に任せる場合には、全員で確認しながら進めるといった配慮が必要です。電子メールでレビュー対象を配布し、会議を開催せずに指摘を集める場合には、指摘の重複を削除し、内容を整理することも大切な仕事となります。

オーガナイザ

　開発計画全体とレビューの関係を明確にし、整合性を取ります。通常1人で担当します。レビューのための工数の確保から、「レビューがどのタイミング（工程、局面）でどのように実施されるか」「レビューの結果を、どのように開発全体の品質計画に反映するか」「工程移行の判定として使う場合には、どのような判定方法とするか」などを計画します。オーガナイザはプロジェクトリーダーやマネージャが担当することもあります。また、ほかのレビューのオーガナイザも兼任し、個々のレビュー会議には参加しないこともあります。

作成者(オーサ)

　レビュー対象の作成者です。必要に応じてレビュー対象の説明をします。レビュー終了後、指摘されたエラー記録に沿ってレビュー対象を修正します。

リーダー／プレゼンター

　フォーマルインスペクションなど、「第三者が作成者になり代わってレビュー対象を説明することで問題を発見しようとする形態のレビュー」における、説明者の役割です。レビュー対象の説明を省略し、エラー指摘から始めるタイプのレビューの場合、この役割は必要ありません。