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

» 2014年04月07日 18時00分公開

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

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

6.レビューアーがレビュー会議を実力を認めさせる場と勘違いしていないか？

　エンジニアであれば、自身の知識や経験を他のエンジニアに認めてもらいたいと思うことがあるのは自然です。しかしながら、レビュー会議をその場と捉えると、レビュー会議の効率が極端に下がります。

　特になじみの無いメンバー同士のような、お互いのバックグラウンドが分からない状況では、通常の会話、メールのやりとり、そしてレビュー会議も自身のアピールの場と捉え、本質的でないやりとりが増える傾向にあります。レビュー会議は参加者全員の時間を拘束して、欠陥や問題を指摘しようとするものです。チームやプロジェクトのキックオフ時や負荷が低い時期に、開発メンバー同士のバックグラウンドを知る機会を増やしておくことで、レビュー会議を知識や経験を誇示する場として捉えるレビューアーは減ります。

7.指摘に辛辣（しんらつ）な表現がないか？

　必要のない厳しい言い回しや表現があると作成者を傷つけます。「まったく」「一切」「かけらもない」といった表現を使った指摘はほとんどの場合、そうした表現がなくても、欠陥指摘、問題指摘として意図が伝わります（図3）。

図3　必要のない辛辣（しんらつ）な表現での指摘（「一切」が無くても指摘は伝わる）

　そういった表現を減らすようレビューアーに依頼しておき、辛辣（しんらつ）な表現があれば、やわらげて言い換えたり、適切な表現を賞賛したりして、厳しい指摘を減らしましょう。辛辣な表現は言葉の応酬となって効率を下げるなど、レビュー参加者の信頼感を損なっていきます。作成者が繰り返し同じような間違いをしていたとしても、感情的にならず淡々とそれらを指摘できることは、レビューの効果を得るための前提の一つです。

　最後に、レビューの効果を得るために必要な作成者の前提を見ましょう。「作成者」とは「レビュー対象の作成を担当している人」のことです。本連載では、複数人のエンジニアが同一のドキュメントやソースコードを分担して作成するようなレビューを想定しています。そのような形態では1回のレビューに作成者が複数おり、レビュー会議の進行とともに担当の作成者が変わっていきます。

8.指摘が少ない場合に「突っ込まれなくてよかった」と思っていないか？

　多くのエンジニアに、「今日のレビューでは、あんまり突っ込まれなくてよかった」と胸をなで下ろした経験はあるでしょう。特に若手のエンジニアにとって、レビュー会議は「自分自身を試されている場」であると感じてしまうことが多いのでなおさらです。

　しかし、レビューの本来の目的は、欠陥や問題の早期の検出です。指摘すべき欠陥や問題がないのであればそれで十分ですが、それらが見逃されているならば、後で困ることになることを知っておいてもらわなければなりません。

　また、若手でなくてもたくさん指摘があると、「修正箇所が増えるから」という理由で、レビュー会議での指摘を無かったことにするよう仕向けるといったことが起こることがあります。しかし、それではレビューの効果は得られません。必要な修正であれば、レビューで検出し修正しておくことを理解してもらわなければなりません。同時に、レビューの効果が得られる本質的な指摘をレビュー会議ですることを、レビューアーの間で合意しておかなければなりません。

　もちろん指摘の中には「今さら言われても」といった内容や、「本質とかなりずれている」と思うような内容のものもあります。そのような指摘はレビュー会議で指摘されるのを防いだり、修正しなくても済むように指摘を取り下げてもらったりするのではなく、そもそも欠陥や問題として検出されないようにする必要があります。検出シナリオを事前に設定するのはこのためです。

　本連載では指摘と検出を区別します。検出はレビューアーが発見したものを指し、そのうち作成者に伝えられたものを指摘と呼びます。本質的でない指摘は指摘を減らすよりも検出自体を減らす方が効率的といえます。その方法を本連載で解説していきます。

終わりに

　筆者は10年ほど前に、エンジニアとしてチームメンバーのドキュメントやソースコードをレビューしたり、システムインテグレーション案件の要素技術に関して、有識者として第三者レビューを担当したりしていました。

　大学研究者に転職してからもレビューに問題意識を感じており、エンジニアの方に協力いただいた試行、エンジニアコミュニティでのディスカッション、NDA（秘密保持契約）締結下での共同研究、エンジニア向けアンケートの実施といった活動を通じて、レビューの課題を明らかにしたり、課題解決に向けて検討したりしています。課題や課題解決に向けた論文発表や国際会議で海外の研究者と意見交換して、テーマの洗練にも努めています。

　そういった活動の中で強く感じていることは、「レビューは組織文化にも影響を受けやすく、ある組織では正しいレビューのやり方が別の組織では効果を発揮しないということも少なくない」ということです。

　例えば、「欠陥や問題を指摘されることは恥と考え、エンジニア同士が牽制し合う」という共通認識の上で、より高い品質を目指していくタイプのレビューもあれば、心配な部分を共有したりアドバイスを与え合ったりして、お互いの考え方ややり方を認め合い助け合うタイプのレビューもあります。どちらか一方が正しいということはなく、組織文化に合ったものを主軸に、局面に合わせて使い分けていくことが大切です。

　本連載では、さまざまな組織文化に対応するために、パターン、テンプレートといえるような典型的な方法を紹介していきます。第1回目である本稿では、レビューで効果を出すために欠かせない項目を挙げました。既に実現できている項目もあればそうでないものもあると思います。いかがだったでしょうか。