前回に続き、品質を確保するうえで重要な役割を果たすレビューについて考える。レビューは、設計内容を見て、先輩が若い設計者に設計のあるべき姿を教える絶好の場でもある。また顧客からレビューを受け、ベンダー側の誤解を指摘してもらうことが是非必要だ。
 |
レビュー時に何もコメントしないレビュアーがいるのは問題であるが、座って聞いていてくれるだけでも効果があるという一面がある。被レビュー者（説明者）は、レビュアーの前で説明しながら、自分自身で自分のミスやまずさに気付くからである。
他人に分かりやすく説明するためには、内容が論理的にすっきりしていることが一番大事である。美しく、論理的に整然としていない資料では説明につまずいてしまうため、説明の過程で自分の設計のまずさに気付かされるのだ。まさに最高のレビュアーは説明者自身なのである。
 |
レビューはSEや設計者の設計内容を審査し、間違いを事前に発見・修正する場であると同時に、担当者に先輩の知識や知恵を伝承する場でもある。
先輩や上司は、自分の持っている知識や知恵を体系的にまとめて文書化し、後輩に伝えるべきである。日ごろ多忙な先輩にすれば、まとめるのはなかなか大変だ。だからこそ、せっかく参加したレビューという場を最大限に使い、知恵を後輩に伝えたい。
後輩にとっても、文書で読めるほど体系的でなくても、先輩から生々しく教えられた知恵は記憶に残りやすく、身に付きやすい。何よりも先輩の良さ、有り難さを体感できることは、先輩やリーダーに対する尊敬の念も生まれ、チームワークの強化にもつながる。
 |
『ソフトウエア開発プロフェッショナル』（スチーブ・マコネル著）によれば、プログラマの10％は、全く仕事を完成できない「負の生産性プログラマ」に相当するという。
筆者の経験では、ここまで多数の負の生産性プログラマとは付き合っていないが、何人かの不適格者は確かに存在した。大きなプロジェクトで、かき集めた要員の中には不適格者もいると覚悟し、できるだけ初期段階でこういう設計者を見つけ、他の設計者に替えて、当人を別の作業に回すとか、開発範囲を狭めるようなことを考えるべきだろう。
デバッグやテストの段階になって初めて負の設計者に気付き、やり直すことになっては、工程的にもコスト的にも大問題になってしまう。そのためにもレビューの場を有効に活用すべきである。
 |
レビューは、部厚い文書が出来上がってから実施するのでなく、ある程度まとまれば少しずつ実施し、だんだんとレビューの質を高めるほうが効果的である。人間の注意力が持続する限界と思われる２時間以内に１回のレビューを終わらせためにも有効だろう。
ロバート・L・グラス氏はコード・インスペクションに参加した際、「集中力を１時間持続させるのが限界だった」と述べている。レビューに効果があっても、効果があるレビューを実施するのも楽ではないということだ。やはり、少しずつ何回かに分けてレビューせよと言うことである。
また、レビューのためにはレビュー対象ドキュメントが必要だが、ドキュメントがそろわずレビューが遅れるのが一般的である。そのため、日程が遅れている部分を優先して無理にでもレビューするのが肝心である。もちろん、ドキュメントがそろった時の再レビューは必要だ。
