ソフトウェアレビューの事前準備が時間切れになる理由
レビュー対象が事前に配布されていて、レビュー会議よりも前に目を通しておけるときに起こりがちな話です。インスペクションと呼んでいる場合もあると思います。事前に準備しようとして時間切れになってしまった経験は誰にでもあるのではないでしょうか。その理由はなんでしょうか。
理由の1つは、事前に大まかな計画を立てなかったからではないでしょうか。だいたいこれくらいかかるという目処がないと、途中で終わってしまうか、最初に見たところだけとても気合いが入っていて、残りはそうでもないという状態になりがちです。
では、どう計画を立てればよいでしょうか。お勧めなのは複数の観点を設定して、観点毎に大まかな所要時間の見積りを立て、読み進める方法です。もっとも大事と思われる観点から順に読み進めていきます。個人差がありますが、見る場所が異なっている複数の観点を同時に見ようとすると、うまくいかないことが多いと思います。
修正案など、欠陥の検出ではなく指摘のほうに過剰に時間をかけてしまうことも理由の1つでしょう。特に思い入れがある部分であったり、過去に苦労した経験があれば「そうでなくて、こうだろう」という具合に（欠陥を指摘するだけでなく）具体的な修正方法を考えてしまう場合があります。もちろんそれが望まれている場合にはそれでかまいません。通常、事前準備の時間は長くないはずですし、レビューの本質は欠陥の検出です。短時間で網羅的にを心がけ思い入れをぐっとガマンして欠陥の指摘のみに集中します。
他にも、作成者のことを意識しすぎて、レビュー対象ではなく作成者に対する注文や文句を考えている場合も時間切れになる典型的な理由でしょう。「この欠陥は前も同じことを指摘した。そういえばここもだ」と同じ作成者に対して思いを巡らせることは教育面で改善につながるかもしれません。しかし、結果としてレビュー対象全体をみることができなくなっては本末転倒になってしまうでしょう。
2011年9月16日のXDev2011のセッションでは、このような典型的な失敗パターンを4つとその改善策を紹介する予定です。セッション概要（XDevのページ）とセッション紹介記事（日経ITproのページ）も公開されています。場所は目黒雅叙園、招待いただいたセッションは16:00～で、無料ですので、ぜひお越しください。申込みはこちら（XDevのページ）から。
もう少し基本的な内容をという方には、ソフトウェア品質シンポジウム2011の併設チュートリアルを。部下や後輩にお勧めください。こちらは2011年9月7日13:00～17:00で早稲田大学です。チュートリアルの詳細はこちら（シンポジウムのページ）。9月5日時点でまだ申込みできるようなのでお早めにこちら（シンポジウムのページ）からどうぞ。