前の記事はこちら
レビューする側がレビューされる側よりも常に仕事ができる、というわけではないです。
仕事ができない人は「俺は仕事ができる」といいはったりする傾向があるので、そういうのと同じように私は「そいつらより仕事ができる！」といいたいだけのようにも見えるかもしれません。
でも、そういう事がいいたいのではなくて、その仕事の現場で私が感じたのは「俺は仕事ができる！」と思い込んでいる人がレビューする側にたってしまうと、ひどいことが起きるという事例だったな、ということです。
多くの優れた開発者は大した実力もない開発者によるコードレビューでつぶされたのではないだろうかと思っています。
開発者というのは分業しておけば、優れた開発者は優れた結果を残し、そして、大した実力もない開発者はそれなりの結果を残し、チーム全体としてみれば傷つけあうこともできずに成果を出し続けることができます。
ですがそこに「コードレビュー」が持ち込まれることでチームワークを破壊することができる道具が大した実力もない開発者に与えられて優れた開発者をつぶす権利を与えられてしまって成果をあげることができなくなります。
レビューする側が優れた教育者である場合には、レビューされる側が無能でも有能でも関係なく適切にレビューは行われます。
しかしレビューする側が教育者として致命的ならば、レビューされる側が無能でも有能でも関係なく潰されますよ。ということです。
これが最も致命的なコードレビューの問題点です。
まだまだあるぞ、コードレビューのメリットを大きくうわまわるデメリット！どんどん見つけていこう！
よーし、もっとコードレビューのデメリットをみつけていくぞーーー！！
- コードを見るだけで動作確認をともなわないレビューをする人がほとんどなので実際には適用できない指摘になる可能性がある。というか多い。
指摘されたことをその指摘は筋違いですよ。と見せなければいけないのも面倒。
- レビューで記述された日本語があいまいで理解できない。
例えば「変数名が変です。修正してください。」という指摘があったりしたら、何が変なのかわからないので非常に困る。
例えば「コメントの日本語が変です。直してください。」のように指摘が曖昧な場合があって何をどう修正すればいいのかわからない。
具体的に書けないという教育者としての無能さが指摘されることはない。そして、具体的に書かずに相手を困らせるということがすごく容易に行われる。
- 「全体的にチェックしなおしてください」という指摘範囲があいまいな場合がある。
レビューする側は1行記述するだけだけど、数千行のファイル群を全体的にチェックし直すという事がどれほど負担なのかをレビューする側が考慮する事などなく、レビューされる側がひどい負担をおわせられる。
- レビューにレビューする人される人、相互に時間がかかる。
レビューする側は、コード差分を見る。コメントを書く。
レビューされる側は、コメントを読みとく、コードを修正する。動作確認する。
レビューする側はコードが修正されたことを確認する。
一つの指摘事項に対してでも、どれだけ仕事が遅いんですか？と思います。
これを数十箇所行ったりするなんて馬鹿みたいな遅さです。
もっとあるかもしれませんが、軽く考えただけでも山程デメリットあります。
古臭い SIer の仕事の非効率さの真似をするのが日本の伝統芸能なのでしょう。
昔々の日本古来の SIer という、ITの分野でもすごく技術発展が遅れている会社でよく行われていた仕事スタイルを思い出します。
ここでは、1時間会議を行う。1時間かけて議事録を丁寧に書く。他の人にメールする。他の人が議事録の訂正するためにしっかり読む。議事録の訂正指摘メールを書く。最初に議事録を書いた人がその指摘を受け取る。指摘通りに議事録を直して他の人にメールする。そしてそれを数回繰り返す。
1時間の会議のために全体のチームメンバーの仕事時間を何時間無駄にすれば気が済むのでしょう。
本気なんですか？と思いますが、SIerでは実際にそれが行われていました。
あるいはこうでしょうか。
部下がお客様あてのメールを1時間かけて書く。上司に「これで大丈夫でしょうか？」とメールで聞く。上司はメールの指摘事項をメールで書く。部下は指摘事項に従ってメールを修正する。上司に「これで大丈夫でしょうか？」とメールで聞く。繰り返し。
お客さんに電話して15分で済むことなのに、部下と上司の仕事時間を何時間無駄にすれば気が済むのでしょう。
本気なんですか？と思いますが、SIerでは実際にそれが行われていました。
「証拠を残さなければならない」という馬鹿げた強迫観念がSIerの仕事だからです。
本気なんですか？
という非効率さをたぶんWeb業界の人は SIer を指さして笑うでしょう
Web業界でやっているコードレビューとは、それと同じことです。
じゃあ解決方法は？
最初にいった、コードの相互チェック。これは有効なので行っていいでしょう。
ではどうするか？
実は極めて簡単なことです。
コードレビューをする人が、ブランチを受け取り、コード修正して動作確認してコードレビューされる人に手本になるコードとしてそれを渡すのです。
そうすると日本語が介在するコミュニケーションエラーはなくなりますし、コードレビューする人がコードレビューされる人に過剰な負担を強いる事もありません。
「レビューする人の負担が大きすぎる」と感じるかもしれません。
おいおい。
その程度のことがレビューする人の負担だとすると通常のコードレビューによってレビューされる側の人の負担はどれだけ大きいものになるんだと思いますか？よく考えてみてみましょう。
工数としてレビューにかかるものをレビューする側、される側で計測してみるといいでしょう。
結果的に双方の負担を減らすやりかたがどのように実現できるか。ということです。
あるいは、ペアプログラミング手法でレビューする人がレビューされる人を近くによび、一緒に画面をみながら直してあげるのもよいでしょう。
このようにしてコードレビューでの生産性の低さを解消することができます。
シンプルすぎて気が付けませんか？
たぶんそうでしょうね。コードレビューのほうがいいと思ってしまいますよね。
SIer の中の人も会議議事録、または、お客さんとの丁寧なやり取りメールを作る、その過程が大事だと思いこんでいるんだと思いますよ。ほんとは会議で決まったことのメモ。とか、お客さんとの意思疎通。などが重要なだけなんですけどね。
賢い人には本質がシンプルなことを見抜けるでしょう。そうではない人はなんか曲解して理解したりしますよね。よくあることです。気にしません。
「コードレビュー」推進する人はどうぞご自由に。私は邪魔しませんよ。
というわけで
このブログはフィクションです。実在する人物とは関連があるように見えて全然関連がないと思いますので心当たりのある人は心当たりがないことにしておいてください。（ｗ
コードレビューされる時にひどい人格否定される気分になることがありますが、よく「人格否定ではない」と言われますよね。
私のこのブログも同じです。「コードレビュー」を推進する人や「コードレビュー」をする人について人格否定はしていません。「コードレビューシステム」についての否定なので勘違いしないようにしてください。
途中、不適切な表現がありましたらそれは人格否定ではありませんよ。（ｗ
最後に
コードレビューは否定の文化なので相手をほめて伸ばすのとは真逆のことが行われます。
なのでコードレビューがメンバー間の仲がよくなる事は全く期待できず、仲悪くなる方向にしか作用しないです。
仕事は協力関係が大切だと思いますがそれを見事にだめにする開発手法です。
「メリットがある」と見せかけていて実はメリットなどなく破壊的であり、人をつぶしにかかる人が上手に利用できるという意味で見事に仕組まれた開発手法といえるでしょう。多くの企業が「コードレビュー」を比較的よい開発手法だと思いこんで採用しているのをみかけます。残念なことですね。
その事が学べない見抜けない「コードレビューを重視する」企業や開発チームには将来的には勝ち目がないので参加しないように心がけています。
日本の会社ってIT技術力がないなあ、ということを SIer などでたくさんの見てきましたが、結局のところWeb開発の最先端をいくようなベンチャーいけいけ的な会社でも、技術力がないところは「コードレビューの悪い面」などを分析して理解することはできないだろうな。というのが自分の評価です。
ぼちぼち苦労しますが、私はマウンティングなんかには全く興味がないのですが変なエンジニアにマウンティングとられないようにある程度は防御しなきゃいけないよな。という教訓になったよ。という自分の備忘録です。
繰り返しますが、フィクションですからね。（ｗ