レビューが実施されない理由（後編）
レビューが実施されない理由に関して、前回は「レビューの有効性の認知不足」について考えてみました。今回は後編として「レビューの効果的な実施手法の知識不足」と「レビューを受け入れる組織風土の不在」について考えてみたいと思います。
レビューの実施手法の知識不足
レビューには時間がかかる･･･。前回のコラムでも話題にしました。そもそもレビューとは何なのか？ どんな目的で行うのか？ どんなことが達成されればよいのか？ このらの大切なことが曖昧になったまま、レビューを行うと時間だけがかかり、効果がでないという状態に陥ります。
レビューを効率よく進めるには、それぞれのプロセスでの目的や目標（あるべき姿）を知っておく必要があります。「ピアレビュー（Karl E.Wiegers著 大久保雅一監訳）」に載っていた目的や目標（あるべき姿）は非常に参考になります。
その内容を細かく書くわけにいきませんが「レビューの５つの原則」はレビューの各プロセスを通じて参考になると思いますので、抜粋引用させていただきたいと思います。
まず、第1の原則では「始める前に自身のエゴをチェックせよ」とあります。作成者として心を広く保ち、改善の提案に対して受容的になること。また、レピュアーは作成者より頭が良いことを示すのが目的ではないことを忘れないとあります。次の組織風土でも書きますが、大切なことだと思います。
2番の原則は「レビューチームは小さくせよ」です。レビューは人数に比例して価値が増すわけではありません。むしろ高くつくだけです。更に悪いことには、グループが大きくなると私語を誘発し、容易に脱線して時間を浪費することになります。
3番の原則は「レビューでは問題の発見に努め、解決を試みるな」です。私はこの原則がレビューを効率よく進める為に最も大切なことだと思います。識別された問題点を作成者が修正するのは、レビューミーティング終了後にすべきです。ミーティングを欠陥の発見に集中し、最初のバグが発見されるや長時間の解決談議に脱線してしまうことのないようにします。人は間違いを見つけたら、それを正したくなるものですが、レビューの目的を忘れずに、ジッと我慢をして欲しいものです。
4番の原則は「レビューミーティングは約2時間に制限せよ」です。肉体的なつらさや疲労困ぱいよって気がそれるようになったら、もはや効力のあるレビュアーではありません。作業成果物を、チームが1〜2時間で調べられる程度の大きさの論理的な塊に分けることが必要です。
最後は、5番の原則で「チームの時間を有効に使うため、事前準備を要求する」です。ミーティングの参加者は事前に作業成果物を自分なりに調べ、理解して、ミーティングで提起すべき課題を見つけておくことが要求されていることを忘れてはいけません。
レビューを受け入れる組織風土の不在
まず、組織というよりも多くのヒトの特性ですが、以下のようなことがあります。
- ヒトは自分が、間違いを犯したと認めることを好まない。
- ヒトは自分が、どれほどの間違いを犯すかも気付かない。
- ヒトは好きこんで他の誰かの間違いを見つけるようとは思わない。
- ヒトは好き勝手を言われて、（品質低下の）責任を押し付けられるのは御免こうむりたいと思っている。
つまり、ヒトは好き好んでレビューに参加したいとは思わないのです。そんな中で、レビューを組織に浸透させていくには、組織の文化とメンバーの価値観を理解しておくことが必要です。特にレビュー記録にバグを載せたくないという「双方の事なかれ主義」がレビューの機能障害をもたらします。
「双方の事なかれ主義」からうまれる弊害を以下に列挙しておきます。
- 結果のせいで罰せられないようにと、作成者は成果物をレビューに提出しなくなる。レビューアは、他人を罰することに加担しなくて済むように、同僚の仕事を検査することを拒否する。
- レビューアはレビュー中に欠陥を指摘しなくなり、作成者の敵と思われないように、レビュー以外の場で作成者に伝えるようになる。あるいは、作成者は「事前レビュー」を実施して、懲罰的な公式レビューにかける前に、非公式にバグを修正してしまう。
- レビューチームは、何かがあると、それが本当にバグなのかどうか討論することになる。その理由は、バグなら作成者に不利になるし、課題や単純な質問ならそうならないからである。
- 欠陥をできるだけ表面化するよりは、むしろあまり発見しないということがチームのインスペクション文化にとって暗黙の目標となってしまう可能性がある。
レビューに関してはこれからも継続して考えていきたいと思います。
関連コラム
レビューが実施されない理由（後編） 2007年10月22日記述
レビューが実施されない理由（前編）2007年10月08日記述
レビューの基礎知識 2007年10月01日記述
レビューが必要とされる理由 2007年05月14日記述
システム運用の大切な役割 2007年04月09日記述
ドキュメントコミュニケーションのポイント 2007年04月02日記述
ドキュメントコミュニケーションの必要性 2007年03月26日記述
不満ゼロの要求定義を目指すには 2007年03月19日記述
これからＳＥになるヒトへ 2006年04月10日記述
システム統合でのトラブルについて考える 2005年09月05日記述
システム再構築の留意事項 2004年07月26日記述
2007年10月22日 宿澤直正 記