ベースコーディングが完了したタイミングで、開発者とは別の第三者によるコードレビューを実施している。ベースコーディング完了後という開発序盤でレビューを実施しているのは「リスクを早い段階で検知し、影響を最小限にする」という理由からである。

コーディング内容の正否以外に、どのようなポイントでチェックしているかというと、

• 社内のコーディングルールに沿った実装になってるか
• 要件で定義した通りに動いているか
• 開発が進むと顕在化する問題はないか
• 意味のない無駄なコードやファイルが残ってないか
• 他の見ても読みやすいコードになっているか
• 各処理の影響範囲が小さく、少しの変更で大きな改修が発生する実装になってないか
• 他の案件でも流用できそうな処理は、汎用的なつくりになっているか

などである。
具体的に次のようなメリットがあった。

コードを「称賛」するルールがモチベーションアップにつながった

レビューでは問題点を指摘するだけでなく、評価すべき実装があれば、当人に伝えるようにしている。この仕組みを「称賛」と呼んでいる。良い設計や実装は本人が意識していないことが多い。他の人が伝えることで、本人が自覚しさらに応用して次へのステップへスキルアップするきっかけとなる。そしてモチベーションアップにもつながっている。

問題点の共有でエンジニア陣の知識の差が減った

他のエンジニアでも発生する可能性がある問題は、当事者間のレビューで終わらせてしまうのではなく、他のエンジニアとも共有して再発防止につとめている。また、共有することでエンジニア間の持っている知識の差を減らし、認識違いで発生する問題を回避する効果もある。

後工程で発生する問題の件数が明らかに減った

当社でコードレビューをワークフローの一部としておこなうようになってから、ちょうど一年ほど経過したが、実施する前と後では明らかに後工程で発生する問題の件数は減少した。また、以前と比べコードが洗練されたためか改修やメンテナンスもしやすくなったと思う。当初想定していた効果は見られている。

レビューの方法についてはチェックを自動化するなど、まだまだ改善の余地はあるが、確実に良い効果は見られているので、引き続き続けていくようにする。