コードレビューの仕方と要員について

Question

コードレビューの良い方法を模索しています。こうやるといいみたいな事例が伺いたいです。
今の職場でコードレビューに決まった１人が行っているのですが、全体を見ずにコードの差分レベルでリクエストをした人を呼びつけています。レビューの観点もコーディングレベルのみといった感じで正直不明です。
また現在GitLabを利用していてMerge Requestでコードレビューを行う形式になっているのですが、これだと
「レビュー後に直せるもの < レビュー前に直せるもの」
の意識の共有ができないためやりにくさを感じているのですが良い方法は無いでしょうか。

前職ではGithubだったので小さい単位でPull Requestしていて、進める前に意見を気軽に求められていました。

Answer 1

個人的な感想です。

コードレビューの目的は、開発者のスキル向上やその会社・組織に置ける知識・文化の共有であろうと考えています。
そして、それは一方的な押し付けであっては意味がないと考えています。押し付けがしたければ、コーディング規約などガチガチにすれば良い。
そして、貴殿が経験してきたことを現組織に反映できないということは組織の損失にも繋がるであろうとも感じます。可能であれば、議論を徹底的におこない、運用ルールやポリシー・雰囲気なども含めて、メンバーが満足する方法を模索しながら進めるべきではないでしょうか。これは誰が悪いというのではなく、会社・組織の問題であり、そこに所属するメンバーが自分で課題意識を持って取り組むべき問題だと思いました。
もちろん、組織の制約もあるため、どのような方法が適切なのかは組織により異なると思います。
また、新しく参加した組織で意見を言う難しさは当然感じるとは思いますので、なかなか難しいこともあると思いますが、多くのメンバーと議論し、味方を増やしていく、積極的に勉強会を開いてリテラシを向上させていく、信頼できる人に相談するなどできるところから取り組んでみてはいかがでしょうか。

Answer 2

質問内容からあなたはリーダではなくメンバであると読み取ったのですが正しいですか？

合理的なやり方かどうかを判断するのはあなたではなくリーダです。
前職であなたがたまたま合理的だと思ったやり方は、前職場のリーダにとって合理的なやり方であったというだけのことです。
新しい職場のリーダは別のやり方を合理的であると判断しているだけです。

現状のレビュアーへの不満が大きいだけだと思いますので、なぜそのような仕組みになっているのか確認/理解するのが良いと思います。

===追記===
少し誤解を与える可能性があると指摘をもらったので追記します。

困ったレビュアーさんがそのポジションに居るのは、リーダの合理的な判断が背景にあります。
・レビュアー以外の役目も担っており、そのポジションの為にレビュアーとして必須
・過去の経緯により、「コードの差分レベルでリクエストをした人」と個別に会話する必要がある
・解雇できない中堅社員の居場所を確保するための必要悪
等々。まぁ、想像としてはちょっと弱いので、サンプルとして役に立つものではないですが、こういった背景がある時に、前職場のやり方が良かった。使ってみないか？と提案しても、リーダには困ったレビュアーさんの行動を変えるモチベーションにはなりません。なぜなら、その方法が既存環境と比べてどれほど効果的かわからないですし、困ったレビュアーさん対策に割かれる時間が、その効果を上回るとは確認出来ないからです。
新しい職場のリーダが合理的であると判断できるような提案をするためには、方法を検討するより先にまず背景を理解する必要があります。それが理解できれば、リーダに対して合理的な提案が可能となるので、是非試してみて下さい。