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

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

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

1.レビューの効果を理解できているか？

　仕様変更の場になっているレビュー、参加者がドキュメントやソースコードを介して攻撃し合っているレビュー、雑談や昔話を語り合う場になっているレビューなど、レビューが正常に機能していない状況は枚挙にいとまがありません。本質的でない欠陥指摘が繰り返されているなど、レビューが機能していない場面を何度か見ていれば、「レビューで品質向上ができる」という実感を持ちにくくなるのも当たり前です。

　「どうせレビュー会議なんて一定時間座っていれば実施したことになる。準備する時間がもったいない。今のメンバーだと本質的でない指摘によって余計な修正が増えるだけだ。有識者にレビューに参加してもらえる予定にはなっているけど、この分野の有識者の加藤さんの指摘なんて、レビュー計画書の欄以外で見たことがない」というような、「レビューの効果をそもそも期待していない」という思いがあっても不思議ではありません。

　しかしながら、このような思いがあるとレビューの効果は期待できません。リリース後やプロジェクト完了後の振り返りにおいて、レビューで検出できていた可能性のある欠陥について、「もし見逃さなかった場合に、どれくらいの作業を削減できていたか」を話し合ったり、レビューで指摘できた欠陥について、「レビューで指摘、修正することによって、どのくらいの作業をしなくてよかったか」を話し合ったりして、レビューの効果をメンバーが考え、理解する機会を増やしましょう。

　効果があると分かれば、メンバーの多くはレビューに積極的に取り組んでくれるでしょう。筆者が携わったレビュー改善の相談や共同研究では、レビューの効果が最初に現われるのは「テスト工数の低減」でした。テストでの大きな手戻りが減るからです。レビューの効果が出始めると、開発に携わるメンバーの多くがそのことを実感します。そして、ひとたび効果的なレビューが実施できれば、あとは自律的に改善していきます。

　本連載で解説する内容は、そういった改善に役立ちます。そのためには、まずレビューの効果を信じて、方法やマインドを変えることが最初のステップになります。次の前提は、欠陥の検出やレビュー会議にかける時間です。意外と気に掛けていないことが多いのですが、大切です。

2.レビューを短く終わらせるという意識があるか？

　レビューの効果を得るためには、レビューを短く終わらせる必要があります。といっても、ただ単に途中で切り上げるのではなく、密度を高めます。レビューのメリットの一つは、欠陥や問題の早期発見による修正コストの低減です。長時間かけていては、レビューの実施コストが大きくなったり、レビューアーの集中力が下がったりして、効果が得にくくなります。

　本連載では、「欠陥や問題の検出は、レビュー会議に先立って個人で実施すること」をお勧めしていきます。その欠陥や問題の検出作業の密度を高めることと、検出した欠陥や問題を会議形式で指摘するときのレビュー会議でも、同じように短時間で密度を高め、網羅的に問題や欠陥の有無を確認することを意識します。

　欠陥検出において、レビューアーは「時間をかければ何か想定していない欠陥が見つかるかも」とつい考えてしまうのですが、単に時間をかければ欠陥が見つかるかというと、必ずしもそうではありません。まずはレビュー対象に「存在すると困る欠陥や問題」を想定し、存在しそうな部分を一通り確認します。そのための方法を、「検出シナリオ」を使ったレビューとして連載2回目以降で紹介していきます。

　「時間をかけてじっくり読み込めば、何か見つかりそうな気がする」という直感をレビューアーが感じることがありますが、そういうときでも最初に一通り確認し、その上でさらに時間をかけて欠陥や問題を探すようレビューアーに伝えます。「じっくり読み込めば」という部分に時間をかけすぎて、結果としてレビュー対象の一部しか確認できていないというレビューアーは多くいます。

　決して手を抜くことをお勧めしているのではありません。まずは一通りの確認を短時間で終わらせることを優先しましょう。レビューアーには、その後、必要に応じてじっくり読み込むようにしてもらいます。

　レビュー会議でも同様に時間の感覚をしっかり持ちます。気が付いたら、これといって目的がない雑談や議論をしていたということはないでしょうか。レビュー会議も進行を工夫し、参加者が意識を変えることで、十分な効果を得つつ、素早く終わらせることができます。「話が横道にそれないようにする」「発言は最小限にする」「短時間で説明できるよう説明のイメージを持っておく」といった簡単な工夫で密度を高めることができます。

3.レビューに携わるメンバーの相互理解や信頼感があるか？

　レビューに携わるメンバーの相互理解や信頼感が足りないことが原因となり、レビューに必要以上に時間がかかったり、本質的でない指摘が増えたりすることがあります。典型的な例は、「作成者がウソをついているかもしれない」とレビューアーが疑うことです。些末な部分に関しても必要以上に根拠やデータを示すよう求めたり、追求しても明らかにならないことを延々と聞いたりします。

　例えば、「このデータ定義は、本当にコード表を確認した上で定義したのか？」「確認したといっても方法があやふやだ」といった具合に具体的に誤りや問題が見つからない場合であっても、作成者の手順や方法を執拗に聞き出し、あら探しをしようとします。こういった指摘に必要以上に時間がかかり、本質的な指摘がなされにくくなります（図1）。

図1　レビューがあら探しに陥ってしまうと本質的な指摘を見逃してしまう

　この他、「別のレビューアーの指摘を自分も検出できていたこと」を参加者全員に知らせようとする場合も同様に、本質的な指摘を妨げたり、時間がかかったりします。

　これは知識やスキルに自信のあるレビューアーが、自分の知識やスキルを他の参加者に分かってもらえていないと感じたときに起こりがちです。関連する欠陥や問題を補足したり、追加の指摘があれば価値があるのですが、他のレビューアーが指摘した欠陥や問題とまったく同じ内容を繰り返すだけの指摘が増えれば、本質的な指摘を得られにくくなり、レビュー会議の時間が長くなっていきます。他のレビューアーが指摘した欠陥や問題を「それは指摘しておくべき欠陥だね」と割り込み、なぜそう思ったか、理由を延々と発言することも同様です。

　参加者同士の相互理解が進み信頼感が醸成されるにつれ、こうした指摘や発言は減っていきます。当事者はすぐには変わらないことが多いので、しばらくの間は静観しておくのも一つの手です。しかし、レビューに先立って相互理解や信頼感を増す場を作ることができれば効率は上がります。食事を一緒に取る、定例会議の開始前後で雑談を積極的に促し、レビュー参加者のバックグラウンドや得意分野の共有を促す、といった工夫が考えられます。

◇

　以上3つのポイントは全体的な「レビューの効果を得るための前提」となるものです。以降は、レビューの役割分担別に「レビューの効果を得るための前提」を紹介します。

　まずはリーダーです。リーダーはレビューを主導する役割であり、計画、実行、必要に応じてレビュー会議の司会進行、指摘された欠陥や問題の修正確認を担当します。