辛いレビューをハックする3つの方法

プロジェクトメンバが文書レビューを受けているのを見ると、レビューを受けること自体が嫌そうだし、受けている最中も苦痛のようだし、終わった後の憔悴感といったら不憫でなりません。

じゃあ、お前はと言われれば、

「はいはい、どうぞどうぞ。一番目でも辛辣なご指摘でも言ってください」

など口には出して言いませんが、内心もそれほど差はないくらいの軽やかにレビューを受けております。

何せ、レビューをしてくれる方が偉い人が多いので、このくらいの心持ちでないとやっていられません。

レビューのハックの記事やテクニックを読む限り、「○○すること」「△△禁止」的な書きっぷりが多いです。もしからしたら、過去記事にそんなのがあるかも。

＃あるとすれば、フォーマルなレビューのやり方があったかもしれない…。

実際のレビューを受けている際には、あれこれしなければならない系は身につくまでは全く役に立たないです。振る舞いが自然と身につくまではレビューでの説明で目一杯だし、目一杯なところに質問や指摘やマサカリが飛んでくるのでそれを避けるのだけで精一杯なんですから。

なので、今日の文書レビューでつらいなーと思っているエンジニアや普通の会社員の方は、この方法でお試ししてみてはどうでしょうか。

【その１】レビューは気がつかなかったことを教えてくれる場

レビューの出席人数が多ければ多いほど、組織としてはコストをかけていることになります。

つまり、大事なレビューであるということです。

＃実際はそうじゃなくて暇…

なので、指摘してくれてありがとうという気持ちで行きましょう。

よく見かけるのが、手間を惜しまず完成度を高めて期限ギリギリに持ってきてレビューを受けて玉砕するエンジニアです。

間抜けとしか言いようがありません。学習機能はないのでしょうか。

完成イメージ、レビューをパスするイメージさえ持っていないのに、そんなに手間を掛けてどうするの。レビューで最初からやり直しになったらただのゴミですよ。昭和なら、印刷して持って行った資料がそのままゴミ箱行きですよ。

資料をどう作っても期限までにレビューを通さないといけないのですから、サクッと作って、サクッとパスするのが目指す姿です。

なので手間を掛けないというより、自分　“が”　やった手間を頭の中から無くすことです。

これだけ時間をかけたのに、と思うから指摘されて頭に来るのですから。

実は、この２番目が一番大事です。

レビューアは、レビューが終わって例え条件付きでも合意したら、文書を書いたあなたの共犯です。

さらに上のレビューや他から指摘されたとしても、その前でレビューアだった人たちは共犯なのです。

＃だって合意したのだから。

だからそれ以降の場でコメントし始めたら、

「お前、合意したよな」

とねじ込んで構いません。

ということでこの3点は、しなければならない系とは違って、心軽やかにレビューにのぞためのハックです。

ご活用ください。