」という指摘があったりしたら、何が変なのかわからないので非常に困る。「コメントの日本語が変です。」のように指摘が曖昧な場合があって何をどう修正すればいいのかわからない。具体的に書けないという教育者としての無能さが指摘されることはない。具体的に書かずに相手を困らせるということがすごく容易に行われる。「全体的にチェックしなおしてください」という指摘範囲があいまいな場合がある。レビューする側は1行記述するだけだけど、数千行のファイル群を全体的にチェックし直すという事がどれほど負担なのかをレビューする側が考慮する事などなく、レビューされる側がひどい負担をおわせられる。レビューにレビューする人される人、相互に時間がかかる。レビューする側は、コード差分を見る。レビューされる側は、コメントを読みとく、コードを修正する。レビューする側はコードが修正されたことを確認する。一つの指摘事項に対してでも、どれだけ仕事が遅いんですか?と思います。これを数十箇所行ったりするなんて馬鹿みたいな遅さです。あるかもしれませんが、軽く考えただけでも山程デメリットあります。仕事の非効率さの真似をするのが日本の伝統芸能なのでしょう。いう、ITの分野でもすごく技術発展が遅れている会社でよく行われていた仕事スタイルを思い出します。ここでは、1時間会議を行う。1時間かけて議事録を丁寧に書く。他の人が議事録の訂正するためにしっかり読む。議事録の訂正指摘メールを書く。最初に議事録を書いた人がその指摘を受け取る。指摘通りに議事録を直して他の人にメールする。1時間の会議のために全体のチームメンバーの仕事時間を何時間無駄にすれば気が済むのでしょう。本気なんですか?と思いますが、SIerでは実際にそれが行われていました。部下がお客様あてのメールを1時間かけて書く。上司に「これで大丈夫でしょうか?」とメールで聞く。上司はメールの指摘事項をメールで書く。部下は指摘事項に従ってメールを修正する。上司に「これで大丈夫でしょうか?」とメールで聞く。お客さんに電話して15分で済むことなのに、部下と上司の仕事時間を何時間無駄にすれば気が済むのでしょう。本気なんですか?と思いますが、SIerでは実際にそれが行われていました。「証拠を残さなければならない」という馬鹿げた強迫観念がSIerの仕事だからです。指さして笑うでしょうWeb業界でやっているコードレビューとは、それと同じことです。解決方法は?最初にいった、コードの相互チェック。これは有効なので行っていいでしょう。するか?実は極めて簡単なことです。コードレビューをする人が、ブランチを受け取り、コード修正して動作確認してコードレビューされる人に手本になるコードとしてそれを渡すのです。すると日本語が介在するコミュニケーションエラーはなくなりますし、コードレビューする人がコードレビューされる人に過剰な負担を強いる事もありません。「レビューする人の負担が大きすぎる」と感じるかもしれません。その程度のことがレビューする人の負担だとすると通常のコードレビューによってレビューされる側の人の負担はどれだけ大きいものになるんだと思いますか?よく考えてみてみましょう。工数としてレビューにかかるものをレビューする側、される側で計測してみるといいでしょう。結果的に双方の負担を減らすやりかたがどのように実現できるか。ペアプログラミング手法でレビューする人がレビューされる人を近くによび、一緒に画面をみながら直してあげるのもよいでしょう。このようにしてコードレビューでの生産性の低さを解消することができます。シンプルすぎて気が付けませんか?たぶんそうでしょうね。コードレビューのほうがいいと思ってしまいますよね。中の人も会議議事録、または、お客さんとの丁寧なやり取りメールを作る、その過程が大事だと思いこんでいるんだと思いますよ。ほんとは会議で決まったことのメモ。お客さんとの意思疎通。重要なだけなんですけどね。賢い人には本質がシンプルなことを見抜けるでしょう。ない人はなんか曲解して理解したりしますよね。