ソフトウェアレビューの効果を高める秘訣2つ
仕事柄、多くの方に「ソフトウェアレビューがうまくいかない。どうしたものか」という相談をいただきます。多くの場合、レビューの目的設定が不十分、参加者のマインドが醸成されていないことが原因になっています。
レビューの目的設定が明確にされていないことは多く、レビュー会議がはじまっていくつか欠陥が指摘されると「このレビューって結局どんな欠陥を検出すればいいんだっけ？」という状況になることは少なくありません。各々のレビューアが自身の経験に基づいて欠陥を指摘すると、必ずしも開発しているソフトウェアに求められるような（早期検出すべき）欠陥ばかりになるとは限りません。たとえば、ユーザ数が5ユーザ程度しかおらず、同時アクセスの可能性がほとんどないシステムに対して、同時アクセスやそのときの性能問題を指摘することは、必ずしも適切とは限りません。それよりも指摘すべき（優先順位の高い）欠陥があることが多いからです。
もう一つ、レビューがうまくいかない主要な理由はレビューアーのマインドがレビューに適していないことです。いくつかパターンがありますが、レビューをエンジニア同士がメンツをかけた戦いの場と位置づけているレビューアーは少なくありません。また、レビューがドキュメントやソースコードの作成者を助けることにつながらないと意味がないことを理解し行動にもうつせないと同様にうまくいきません。その例として、質問ばかりが挙がるレビューや思いつきで検出した欠陥しか挙がらないレビューがあります。質問をする理由はレビュー対象が意図するところがわからないからだと思いますが、「こういう意図ならば問題はない。こういう意図ならば、こういうときに問題があるから欠陥といえる」といったもう少し主体的に（突っ込んだ）指摘をする必要があります。レビューで質問して、その回答を聞いても欠陥かどうかがすぐには判断できないことがあるからです。積極的なマインドが必要です。
今のレビューを改善したいという方向けに、レビューの原理・原則、レビューの目的の必要性と設定方法、どのようなマインドが必要になるかを解説する研修を実施する機会をいただきました。9/18(水)の午後で会場は東京 田町です。 詳細はこちらから。主催はNECラーニング様です。これまで大学の演習で NECラーニングをはじめNECグループの方にお越しいただいて静岡大学情報学部の学生にロールプレイ型の密度の濃い演習をしていただきました。学生にも評判が高く、私にとっては、適切なレビューを広めていくことと同時に恩返しが少しでもできればという意味もあります。