なぜ、レビューをするか？
現場によって異なるのがレビュー、特にプログラミングのレビューです。特に中～大規模なシステム開発では、画面数が膨大になり、かつPG工程に遅延が発生しやすいため、適切なレビューが行われないというのを私は多く見てきました。
その結果、やはりコード品質は低くなり、一貫性のない保守しにくいコード群を納品する結果になっています。私はその度に、「莫大なお金をシステムにつぎ込んだお客さんがかわいそうだ・・・」と思いながら、自分の画面だけは読みやすく理解しやすいコードになるよう勤めてきました。
なぜ、適切なレビューが行われないかというと、現実的で効果のある（実践可能な）レビュー観点が提供されていないからです。その結果、現場ごとに統一された基準や観点がなく、なんとなく上のポジションの人が見てOKを出したり、レビュー戦略の整備が行われないままテスト工程に流れ、結合テスト以降でバグ続出し、デスマーチ化します。（身に覚えありませんか？）
そこでこの記事では、たまたまこの記事を読んでくれた開発チームが実戦可能なレビュー観点の提供と、開発工程全体から見たレビューの位置付けを検討していきます。
この記事に書いてあることを実行するだけで、あなたの開発チームは意味のあるレビューを実施することができ、プロパーには自信を持って「レビューをした」と伝えることができるでしょう。
レビュー観点を決めておく必要性
レビューは観点を決めてやっていかないと、全く意味がないと思っています。
観点を決めておかないと、レビュアーも指摘渋りしたり、根拠のない指摘になってしまいうからです。
観点がないと、レビューした証として1個か2個ぐらい指摘して、OKしてしまう。
そんな感じになりがちです。
また、指摘された側も「何でそうなの？」と指摘に対して前向きに取り組むモチベーションが生まれず、時間が無駄になります。
「○○の観点から、ここは○○ではないでしょうか」と言われると、説得力がありますし、素直に受け入れることができます。
レビューをする際は観点や守るべきルールを決めておきましょう。
レビュー観点
誰がレビューをするべきか？
中～大規模な業務システム開発では画面数が膨大になるため、チームリーダーがコードレビューをするのは現実的ではありません。
チームが３～４人のサブチームに分かれていれば、サブチームのリーダー（サブリーダー）が行うのが適切でしょう。サブリーダーもいない場合は、そのチームの中の上級PGがコードレビューを行います。
仕様を知っているか否か
レビューの観点
コーディングの観点から（仕様外の観点）
仕様の観点から
現実的な業務システム開発のレビュー戦略
レビューする前の前提
レビューの前提として、各画面／機能の担当者の中では「よし、プログラミング完了！」と言える状態になっている必要があります。レビュー後にソースを変更することは全然あるのですが、せっかくレビューした意味が薄れてしまいます。レビュー後にバグを仕込んだら元も子もないですからね。
ということで、レビュー者が画面／機能を動かして容易に動作確認ができる環境であるべきだと考えます。ソースコードレビューをする前に、レビュアーが簡単に自分のPCで動かすことができるのが理想なのです。