【第3回】[#5]レビューの終わり方～レビュー評価・ふりかえり（1/2）｜ソフトウェアレビューをエンジニアリングっぽく語ってみる

みなさんこんにちは。

「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”きたのしろくま”です。

次の話題は「#5レビューの終わり方～レビュー評価・ふりかえり」です。

前回うれっしーさんが書いてくれた「#1レビューとは？」の次に#5・・・かなり飛んだテーマではありますが、準備できた順に投稿していくと宣言して始めた連載ですのでご容赦ください。

（すべてのテーマ投稿が出揃った際にこの連載の価値がわかるはず・・・です）

今回のテーマは少し長くなりますので2回に分けてお伝えします。

今回は「#5レビューの終わり方～レビュー評価・ふりかえり(1/2)」です。

レビューのよりよい終わり方を一緒に考える機会になるとうれしいです。ではスタートです！

＜ソフトウェアレビューをエンジニアリングっぽく語ってみる　記事一覧＞※クリックで開きます

レビューってどうしたら終わる？

みなさんのレビューはどうなれば終了しますか？

例えば、

・予定していた時間が来たら終了～まだ途中だけど、残りの内容でこれまでの指摘と同様の箇所があれば同じように直しておいてね（ハート）

・レビューアから指摘事項が出揃ったら／それを作成者に伝えたら終了 

・声の大きな人が「終わり」と言ったら終了

・正式なレビュー記録が承認されたら終了（QMS的）

など、いろいろありそうです。

これは「レビューの終了基準」の話題ですが、（「開始基準」と同様）特に決まりがないまま、いや「慣習になっている暗黙のやり方」に従って運営している、という状態が意外と多い気がしています。

”やりっぱなしレビュー”の影響

先ほど示した4例ですが、どれをとっても「レビュー計画」や「レビューの実施方法」「レビュー結果」の良し悪しをふりかえらず、集まった人たちでレビュー指摘さえ出せば、あるいはそれを申し渡したら終わり、という状態になっている可能性があります。

この状態を「やりっぱなしレビュー」と呼ぶことにします。

やりっぱなしレビューがもたらす主な影響は以下の通りです。

・レビューに費やす工数や時間が最小限で済むので、実務に早めに戻ることができる。（これは良い影響）

・レビューで新たな経験や気づきを獲得した特定の個人にのみ、その分の学習効果が得られる。
　しかし、あくまでも個人の話であり、かつレビュー能力の向上は非常に小さく、組織としてのレビュー能力向上には長い年月が必要になる。

 ※有識者がいないとレビュー結果が伴わない状態はこのように作られる

 ・（一度のレビューで各自が獲得するノウハウはそう多くはないため）次回以降のレビューでも同じような結果になることを繰り返す可能性が高い。 

例1：検出すべき欠陥や不備を見逃しがちなレビューになっているチームは、以降も同様に見逃す結果になりやすい。

例2：集合レビュー時に話題が横道に逸れてもそのまま放置される（ムダな時間、工数が多くなる）運営になっているチームは、以降も同じ状態になりやすい。

以上のように、メリットよりもデメリットが目立つのが実態だと思います。

さらに、業務やプロジェクトのメンバーは、自分が割り当てられているタスクを遅延なく進めることでさえも簡単ではなく、多忙な中で依頼されたレビューを何とかして行っている場合も多いと推察します。

多忙な中、何とかやりくりしてレビューを実施しているのに、その効果が実感できないと、レビューに対するモチベーションが低下し、前向きにレビューが実施できなくなってしまいます。

このような「やりっぱなしレビューの悪影響や負の連鎖」はどのように打開すればよいでしょうか？