レビューのアウトプットは、レビューアのレベルを超えない（５）

「レビューのアウトプットは、レビューアのレベルを超えない（3）」で述べたように、ソフトウェア開発でソースコードをレビューすることを実践し始めたのでは1999年頃からです。

それから、コードレビューの重要性の教育やコードレビューを実際に実践して、一行一行コードをレビューしながら処理漏れはないか、バグはないか、読みやすくて理解しやすいかということをレビューしていきました。それは、きちんとしたレビューをしないとソフトウェアの品質が上がらないのと同時に、きちんとしたレビューを受け続けないと、レビューアが育たないからです。

そして、2000年前後から2008年までの期間で多くのコードレビューを実施し、自分自身でもコードを書き続けて、現場の若手の技術者を育成していました。そこには、レビューすることに対する開発組織全体の理解や中堅クラスのソフトウェア技術者でもレビューを受けるということで、全体で長期的に品質の底上げを行うことの重要性の理解があったと思います。

しかし、もともとコードを書くことを重要視していないソフトウェア開発組織では、コーディングは若手の仕事、あるいは、協力会社の仕事ということで、コードレビューさえしなかったり、レビューしてもいい加減なレビューだったりすることがあります。あるいは、初心者が書いたコードでさえもチームでレビューしなかったりします。

その結果、プロジェクトでは常にデスマーチを行い、体力勝負的な開発を続けることになります。そうは言っても、デスマーチ（高残業）を続けるのは若くても体力的に持たないので、コードを書く立場からできるだけ早い段階で抜けたいと思うようになり、その結果、常にソフトウェア開発の経験が浅い若手が投入されてデスマーチを続けるという悪循環を引き起こしたりします。

そもそも、そのような開発組織では、現場でコードを書いている人より上のチームリーダやグループリーダ、あるいは、組織長でさえコードの品質に興味がなかったり、コードを読んで品質を確認することさえできない、しない人ばかりだったりします。

結果的に、きちんとレビューができる人材が全く育っていなかったり、いい加減なコードでも「レビューしました」と報告されてもチェックできない組織となっていたりします。このようないい加減なレビューしか行われていなかったり、あるいは、全くコードレビューが行われていない組織で長年ソフトウェア開発をすると、コードをレビューして指摘されても、素直にコードを良くすることができない人たちが登場します。

ひどいコード（たとえば、1メソッドが3000行のコード）を書いていたとしても、「普通のプログラマーならこのくらい理解できる」と言ったり、指摘事項を無視して何もしなかったりします。レビューを素直に受けないようになるのは、初心者の頃からどのような指導を受けたかということと、所属するソフトウェア開発組織の（長年無意識に形成されてきた）性質によるものだったりします。