レビューで失敗しない8つのポイント：レビューがうまくいかない理由（3/4 ページ）

[森崎修司，名古屋大学]

※本記事はアフィリエイトプログラムによる収益を得ています

4.レビューの目的が合意されているか？

　最初はレビューにありがちな典型的なミスである「目的を決めていないレビュー」から紹介します。レビューでどのような欠陥や問題を検出するかを決めていることは、レビューの効果を得るための重要な前提の一つです。では具体的に見ていきましょう。

　レビュー会議が進行するにつれて、レビューアーが思い思いの欠陥や問題を指摘していることにふと気が付き、「このレビューではどのような欠陥を指摘すべきなんだろうか」と思ったことはないでしょうか。

　レビューを始める前に、どのような欠陥や問題を検出すべきかを決めておかなければなりません。決めていなくても、ある程度は効果が得られますが、指摘された欠陥や問題をよく見てみると、個々のレビューアーの好みが指摘の形で挙がってきているということも少なくありません。そこで、ここではあらかじめ目的を設定するための方法として「検出シナリオ」を紹介しておきましょう。

検出シナリオとは？

　これは「何を、どのような方法で確認するか」を明示することによって、どのような欠陥や問題を検出すべきかを事前に決めておく方法です。検出シナリオによるレビューの効果は、海外を含め数多く報告されています。先に紹介した拙著でも検出シナリオを紹介しています。

　しかし、大切なことは「検出シナリオを作成すること」自体ではありません。検出すべき欠陥や問題が暗黙の了解として合意されていればそれでかまいません。形式はチェックリストでもかまいません。ただし、網羅的になることを目指してチェックリストをたくさん用意すればするほど効果は薄まり、形骸化しやすくなります。

　誰も使っていない長大なチェックリストを見た経験は、多くのエンジニアにあると思います。対象ソフトウェアやシステムの特性、求められる品質によるので一概には言えませんが、多くの場合「レビューで何を検出するか」は絞り込んで決める必要があります。組織で定義された既存の標準プロセスがある場合でも絞り込むことはできます。チェックリストが既に形骸化しているならば、チェックリストの質問の中で特に重要なのは何かを選び、足りないものは何かを考えることから始めます。

　「レビューで何を検出すべきかを決めること」と、「レビューアーの知識やスキルによって、どのような欠陥や問題が検出できそうかを想像すること」は、合わせて考えるべき内容です。

　まずは、レビューに参加する人たちのレビュー会議での指摘をイメージして、「ベテランの片山さんは、契約との整合性に関する指摘と、運用時のトラブル対策や運用手順に関する指摘」「データベースやミドルウェアの性能に詳しい松本さんは、スループットに関する指摘」といった具合に想像していき、「何が検出できるか」をイメージします。その上で、「今回のレビュー対象で何を検出すべきか」想定します。

　例えば、「利用規約や個人情報の取り扱いに関する部分は片山さん」「月次の集計とバックアップに関する部分は松本さん」「トラブルが起こった場合の原因究明のために必要となるログの確認は坂本さん」「リソース解放漏れの可能性やその対策は、専門ではないが期待できそうな加藤さんに任せる」といった具合です。

　もし、どのレビューアーにも検出できそうにない問題や欠陥があれば、「有識者として、プロジェクト外のメンバーの応援を要請する」「レビューでの検出は諦めて、プロトタイプによる検証やテストで検出する」といった対策を検討します。

　例えば、特定の通信の電文形式の例外処理の詳細が分からない、脆弱性対策の詳細が分からない、文字コードの特殊パターンが分からないといったものは、レビューでみんなで考えれば分かるというものではありません。

　もし検出すべき欠陥や問題が明らかになっていないままだったり、検出すべき重大な欠陥や問題が挙げられていないと感じたりしたら、早い段階でリーダーに問い合わせるよう、レビューアーに依頼しておきましょう。

　さて、次はリーダーとレビューアーの両方に関係するポイントです。

5.レビュー会議の前に欠陥や問題の検出ができているか？

　レビュー会議で初めてレビュー対象が配布され、レビュー対象に目を通しながら進めていないでしょうか。会議で検出と指摘を同時に進めるものです。事前に目を通していないと、気になった部分や目立つ欠陥や問題が指摘されがちです（図2）。

図2　その場で初めて目を通しても有効な指摘をするのは難しい

　レビューアーが事前に目を通しておかなければ、「ドキュメント全体を通じて一貫性が無い部分」や「抜け」に関する指摘といった、本質的な指摘を網羅的に挙げるのは難しいでしょう。まずは個々のレビューアーが、事前に欠陥や問題を検出するための時間が作れるよう、レビュー対象の配布とレビュー会議の間に半日〜1日程度の時間を確保できるよう変えていきます。作成者がレビュー対象を完成する期限の日を設定したら、レビューはその次の日の午後からにするといった工夫から始めます。

　現状、事前検出の期間を設けていなければ、「ただでさえスケジュールが厳しいのにこれ以上どうやって前倒しするのか？」と、疑問に感じるのは当然です。しかし、レビューの目的の一つは修正コストの低減です。テストでの工数削減といった効果を関係者が肌で感じるようになれば、それほど難しいことではありません。私が相談を受けたり共同研究をご一緒したりしている企業でも、会議の前に欠陥や問題を検出できているところがたくさんあります。

　事前検出しておくことを「インスペクション」と呼ぶこともありますが、欠陥や問題をレビュー会議に先立って実施しておくだけで、メトリクス収集や司会進行役であるモデレータのトレーニングをはじめとした、インスペクションで決められているプロセスに従う必要は必ずしもありません。

　既にレビュー対象の配布がレビュー会議に先立って実施されているにもかかわらず、レビューアーが事前に欠陥や問題を検出してこない場合も同様です。レビューアーが事前に検出してこない場合には、レビュー会議の時間を少し長めに取ります。レビュー会議の最初の時間を、個々のレビューアーに欠陥や問題を検出してもらう時間とします。その後レビュー会議を実施します。

　筆者の講演やセミナーなどで事前検出をお勧めすると、「現場ではレビュー会議に先だって欠陥検出する時間はない」と反論をいただくことがあります。仕事柄、現場を無視して無理難題をお勧めしているように見えてしまうのかもしれないのですが、感触や理想論ではなく、さまざまなレビューを見て、会議に先立って欠陥や問題を検出しておくと、効果が高まることを確認した上でお勧めしています。

　次の前提もありがちなものですが、レビューアーとしてできていないとレビューの効果が得られにくいポイントです。