態度が悪いレビュー参加者を欠陥指摘の集中砲火で改めさせようとしても・・・
ソフトウェアレビューの会議（欠陥指摘会議）でこんなシーンを一度は経験されたことはないでしょうか。
レビューアA「エラーコードの統一性がないので、少し整理して方針を決めないと・・」
作成者「エラーコードを統一しないといけないという話は聞いてないです。少なくとも私が直す必要はないはず」
レビューアB「エラーコードを統一するのは担当者として当たり前のことだ。エンジニアとして一貫性がないことを恥ずかしく思わないのか」
作成者「そういう時代もあったのかもしれませんが今は違います。」
レビューアA, B, C: （作成者の態度に怒り始める）
レビューアA「23ページにある"有限の"は結局いくつくらいを想定しているんだい？いい加減な感じがするなぁ」
レビューアB「12ページの図の書き方だけど実線矢印と点線矢印に違いはあるの？適当に使い分けているならば、細やかさが足りないなぁ」
レビューアC「10ページから15ページの間に"など"が20回も出てくるけど、こんな風に"など"って書くと他にどのようなものがあるのかが気になって実装しにくいと思うんだよね。読む人の立場に立ててないなぁ」
作成者が新人だったり、プロジェクトに参加して間もない段階のときにレビューアA, B, Cが作成者の態度を改めさせようとして、上述のような「お前の作ったドキュメントはアラだらけだ」というような指摘をしてしまうことがあります。
しかし、レビューアの間ではその思いが共通していても、上述のような集中砲火だけでは、作成者に「態度を改めてほしい」というふうに伝わることは少ないでしょう。ドキュメントの問題は問題として指摘し、「もっとレビューアの言うことも真摯に受け止めてほしい。この組織の一員として組織の文化にも敬意を払ってほしい」と直接伝えるほうが効果が望めます。
上の例では、直接的にお願いをしていない点だけでなく、揚げ足を取るために貴重なレビュー時間が浪費されている点にも注意をしなければなりません。本来検出すべき欠陥は他にもあるはずで、作成者の態度を改めさせるためにレビュー時間を浪費しているというふうに解釈することもできます。その意識を持っているのとそうでないのとでは、全然違ってきます。
「あれ、これは本当にソフトウェアの品質を向上するために指摘したいことなのかな？」と思うだけでも状況は改善します。
このようなソフトウェアレビューにおける典型的な間違いとその対策をまとめた「間違いだらけのドキュメントレビュー」という連載記事を2011年4月号から日経SYSTEMSに寄稿しています。毎月4ページずつで、現在5回目まで発行されており次の6回目で最終回になります。第1回目の最初のページがPDFで公開されています（ここから）。記事はここからPDFでも購入できます。
その内容の一部は、ソフトウェア品質シンポジウム2011の併設講座「おさえておきたい ソフトウェアレビューの原理・原則と欠陥検出の基本」でも紹介します。2011/9/7(水) 13:00～ 早稲田大学で。申込みはこちらから。