こんにちは。Kaneyasuです。
みなさん、レビューはされていますか？ ソースコードレビュー、設計レビュー、手順書レビューなどがありますね。
私は最近レビュアーを務めることが多いですが、多くの場合、レビューを受けるのはしんどいですよね。
本記事では、レビューにおいて指摘された場合の対応について書いていきます。
本記事では、レビューにおいて指摘する側をレビュアー、指摘される側をレビューイと呼んでいます。
「素朴な質問なんだけど」の指摘への対策
レビューで「素朴な質問なんだけど」という言葉を使われることがあります。
この指摘は、レビュアーが現場を離れた上司や、分野の違う人の場合によく聞きます。
レビューの位置付けが承認である場合によく見られる傾向です。
鋭い指摘で答えがいのあることもありますが、的外れや心配しすぎなパターンも多く、レビューイとしては困ることもあります。
ここで黙ってしまうと、レビューが変な方向に行ってしまい、大幅な妥協を余儀なくされる可能性があります。
こういう指摘に対しては、まずは何か話しましょう。
もし他にメンバーがいる場合は、一旦他の人に振りましょう。
そして、頭を落ち着けて、今なぜこうなっているか？（＝Why）、今の内容で指摘されたことがもし起きたらどうなるか？仮に対策を打つとしたらどうするか？（＝Story）を答えましょう。
対策については、最悪今見せている内容には書かれていなくてもよいと思います。
「素朴な質問なんだけど」の指摘は、レビュアーの経験からの勘または防衛本能によるものが多いのですが、言った方もそこまで根拠のある指摘をしているわけではないので、100％の回答を求めてはいません。
したがって、毅然とした態度でそれなりの回答をすれば、それで十分です。
- 落ち着いていて、毅然とした態度である
- 柔軟性がある
- その人なりの考えが見られる
「素朴な質問なんだけど」の指摘をした側はもしかしたら気づいていないかもしれませんが、指摘をした側はこういうところを見ています。
「その人なりの考えが見られる」が一番大事で、WhyとStoryを答えることで、その人なりの筋が通っていることを示すことができます。
要は何かあってもなんとかしますよという意思を見せれば、多少内容を変更することになったとしても、大幅な妥協は回避できる可能性が高いです。
具体的ではあるが、淡白な指摘の対策
別のパターンです。
レビューにおいて、具体的には踏み込んでいるが、一言コメントのような淡白な指摘がされることがあります。
そして、このような指摘は五月雨式に来ることもあります。
一見すると冷たい指摘のように思えて、レビューイとしては不快感が溜まりますね。
これらは、レビュアーが現場の技術者で、ソースコードレビューなどでよく見られる傾向です。
この傾向も、結局のところレビュアーはWhyとStoryを求めているので、レビューイがそれらを答えることで、着地できることも多いです。
ただし、この傾向の場合、レビューイに対してのみ対策を求めるのは違うとも思います。
レビュー、特にコードレビューにおいては、一般的にレビュー内容はコードに対してであり、レビューイの人格に対してではないと言われます。
そうではあるのですが、指摘されっぱなしが面白いわけがありません。
できればレビュアーの方からも歩み寄りを見せてほしいものです。
仮定の話になってしまいますが、もしレビュアーの方がレビューばかりしているとしたら、もう少し手本となるコードを書くのに時間を割いてみてはどうでしょうか。
レビューイ側としては、手本もないのに試行錯誤して書いたものを指摘だけされては、不満が溜まりやすく成長のスピードも遅くなります。
手本を見せることで、レビューイの不満が緩和され、指摘が必要なアウトプットが減ることもあります。
それに伴い、レビュアーの負担も減るので、双方にメリットがあると思います。
遠回りになるかもしれませんが、結果的には効率が上がることもあるので、一考の価値はあると思います。