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

ソフトウェア開発に従事して、開発チームや組織内でコードをレビューすることを私自身が実践したのは、ソフトウェア開発の経験の中でかなり後になってからです。実際には、1999年後半か2000年前半ぐらいだと思います。それまでは、チームとしてコードをレビューすることはありませんでした。

記憶が定かではありませんが、まず、着手したのは「Code Review Guide」を書くことでした。それと同時に、プロジェクト用に「C++ Coding Standard」を書いて、コードレビューの重要性を教育で教えて、さらに、現場でコードレビューを実践するということを日々行っていました。

コードレビューは、コーディングという行程において、できる限り品質を作り込むために行うものであり、一行一行処理内容を確認しながらレビューしていました。それにより、後工程であるテストの工数を減らすためです。当時は、テスト駆動開発ではなく、実際のハードウェアで手作業でテストせざるをえない環境でしたので、レビューで品質を作り込むというのは非常に重要でした。もちろん、すべてのバグがレビューで見つけられる訳ではありません。

開発チーム全体のスキルを上げるためには、一対一のコードレビューではなく、複数参加のレビューの方が知識の伝達には効率的です。その結果、私が当初指摘していたことを、徐々に他のメンバーも指摘するようになります。つまり、コードを見る時の視点がコードレビューを通して良い方向に変わっていくわけです。

一方、開発プロセスでコードレビューを実施することが決められていて、レビューしたことを報告しないと次のステップへ進めない場合に、レビューが形式的になっている場合があります。4、5名で数回レビューしたはずなのに、一対一で私にレビューしてもらいなさいと指示されたのでレビューをお願いしますと言われたことがあります。その時に、チームでレビューしているのになぜ私がまたレビューしないといけないのかを聞いてみると、一行一行の処理内容を確認しながらのレビューはしていないとうことでした。

このような一対一のレビューは、複数のメンバーに同時に知識を伝えることができません。スキルが十分でないメンバーが多い開発組織では、きちんとしたレビューを複数メンバーで地道に継続して、全体のレベルの向上を図っていく必要があります。しかし、そのような活動をしないと、チームメンバーのコードレビューに対する視点は全く向上しないことになります。

さらに、きちんとしたレビューを開発メンバーが受けることがないと、コードレビューはこの程度で良いと思うようになり、プロセスでレビューすることを強化しても、コードの品質は上がらないし、開発組織全体のレベルも向上しないことになります。その結果、後工程のシステム全体の結合テストで多くの不具合が発生して、その対策として、さらにプロセスが強化されて様々な報告が求められるようになるかもしれません。しかし、もともときちんとレビューできない組織では、強化しても何の役にも立たず、むしろ、報告作業のためにコードレビューにかける時間を減らすことになり、状況を悪化させるだけだったりします。