ソフトウェア開発のレビューにおいて「不意打ち指摘にがっかり」を示す実験結果
本エントリは2008/7/31にここ(オルタナティブブログの私のエントリ)で公開済みのものを加筆・修正したものである。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
オープンな(守秘義務のない)レビュー技術の適用評価実験をしていて感じたこと。このエントリとも関連する話だ。
レビュー指摘で「その指摘は本質的でない」あるいは「今回の対象ではあまり気にしなくてよい指摘では?」という内容に作成者(成果物の開発担当者)が、がっかりしてしまうことが多いようだ。もちろん、どんな指摘をも受け付けないような完璧なものを用意することが理想ではあるのだが。。時間の制約がある中ではなかなか難しい。
ここで、早水氏のモデル検査の不具合指摘によるモチベーション低下について触れたが、これらも言わば不意打ち指摘の一種と考えることができ、レビュー指摘にも同様のことがいえるのではないかと思う。
レビュー指摘内容のコンセンサスをとってから開始すると不意打ち指摘を減らすことができるように思う。その結果、効率化につながる可能性があるように思う。チェックリストを使ったレビューは、まず学習コストが小さいこと、そして手軽にコンセンサスがとれスキルの底上げにもつながるためにメジャーになったのではないかと思う。レビュー対象作成前にチェックリストがあれば、それを配布することにより事前のコンセンサスにつながるからだ。
ビジネスなんだからそんな考えは甘い、どんな指摘にも耐えうる(中間)成果物をもってこい、という意見もあると思うが、疲弊の多い開発プロジェクトにおいてコンセンサスのあるレビュー指摘には、疲弊軽減の効果があるかもしれない。もしまだであれば、検討されてはいかがだろうか。