　ソフトウェア開発活動におけるレビューには、大きく分けて2つあります。1つは「進捗（しんちょく）レビュー」「マイルストーンレビュー」などの“管理面のレビュー”です。もう1つは「設計レビュー」などの、“エンジニアリング面のレビュー”になります。今回の勉強会では、エンジニアリング面のレビューに限定して議論を行いました。

　参加者の皆さんの組織では「開発フェイズの複数のタイミングで必ずレビューを実施している」とのことでした。レビューは、テスト工程と併せて“品質を確保する活動”として、重要な位置付けを担っています。しかし、実際の活動の中では、レビューに関連するさまざまな問題を抱え、レビュー効果もなかなか定量的に把握できていないのが現状のようです。

　今回の勉強会では、それらの問題点を解決するヒントを得るために、以下の3つのテーマに沿ってレビュー活動を深掘りしてみました。

レビューをどのようなルールで実施するか？
レビューでのチェックはどのような観点で行っているか？
レビューの状況をどのようにして見えるようにするか？

　読者の皆さんの組織でもレビュー活動には大変関心があることでしょう。ぜひ、本稿を参考に自分の組織で深掘りを行い、レビュー活動をさらに効果的なものに改善していただきたいと思います。

　なお、今回お届けする「効果的なレビューとそのフォロー」の議論については、前編・後編の2回に分けて詳しく紹介していきます。今回は前編として、「レビューに関する問題点と、レビューの準備、進め方などのルール」に関して見ていきたいと思います。

レビューに関する問題点の掘り起こし

　まず、レビューに関して議論するに当たり、参加者の皆さんが抱えているレビューに関連する問題点を整理してみました。以下のように“レビュー自体の品質”を中心としたさまざまな問題点が上がってきました。


			・参加者によってレビューの品質が異なる・レビューで適切に指摘できるスキルをどう向上させるか・議事録の記録レベルが担当者によってバラバラになっている・あまり細かい部分まで指摘するとモチベーションが下がってしまう。どこまで指摘すればいいかの線引きが難しい・レビューされる側は“時間を取られた”という意識があり、前向きになりにくい・レビューがセレモニーと化している・レビュー効果を実感できない

　読者の皆さんも同じような悩みを抱えられているのではないでしょうか。問題点を大枠でとらえると、以下の2点に集約できるかと思います。

担当者のスキルがバラバラで、適切なタイミングで不具合を取り除くことができていない場合がある
レビュー活動の見える化が適切に行われていなく、レビューの必要性の認識が低下している可能性がある

　品質の良いソフトウェアを少ないコストで作り上げるためには、それぞれの工程内で確実に不具合を取り除き、手戻りを最小限に抑えることがどうしても必要になります。そのための手段として、一番大きな効果が得られるのがレビューです。

　これらの問題点を解決するヒントを得るために、ルール、レビュー観点、レビューの見える化に関して、考えていきたいと思います。

レビューの実施と事前準備に関するルール

　読者の皆さんの組織では、設計のガイドライン、コーディングルールなどと同様に、レビューに関しても何らかのルールが存在しているでしょうか。組織にマッチしたレビューのルールを決め、それを確実に実施することは、レビューの品質を高めることになり、その結果、製品の品質を向上させることにもつながります。

　参加者の皆さんに確認したところ、ほとんどの組織で明確に定義されたルールは存在しておらず、開発者自身がレビューを実施する適切なタイミングを見いだし、必要な参加者を選定して実施しているようです。以下で、その実態を見てみましょう。

　まず、レビューを実施するタイミングです。組織ごとに工程の切り方、工程の呼び方などは異なりますが、以下のようなレビューを実施しているようです。

要求レビュー
仕様（機能）レビュー
設計レビュー（基本／詳細）
コートレビュー
各テストの項目レビュー
テスト結果レビュー
変更時レビュー（要求／仕様／設計）

　このように、開発のV字工程全般にわたって実施されているのが分かります。この中でも要求レビューを実施している組織は少なく、コードレビューは多くの組織で実施されているようです。その理由としては、仕様または設計と、ソースコードとの間に“人間の検討余地”が大きく介在し、成果物の形を大きく変える部分になっているからでしょう。一方、詳細設計書をしっかりと記述している組織やモデルベースでのコード作成を行っている組織では、コードレビューは実施していないようです。

　次に参加者の皆さんがどのように各レビューを進めているかを、時系列に沿って見てみましょう。まず、レビューの実施判断についてです。


			組織や社内規定として、最大限に実施するレビューを定義している


			実施するレビューの定義の中から今回のプロジェクトで実施するレビューを選定し、プロジェクト計画として定義している

　担当者自らが「レビューが必要」と認識して、実施することが多いようですが、組織としてレビューを実施するタイミングをきちんと定義することが望ましいです。その定義に沿って、プロジェクトマネージャやリーダーが、プロジェクトの計画時に製品の種類、難易度、スキルレベル、期間、委託形態などの多くのパラメータを考慮し、実施するレビューを取捨選択するとよいでしょう。

　この取捨選択に関してはリーダーの経験を基に、メンバーの特性、顧客のワガママ度などの危険要素を敏感に察知し、判断を行います。

　成熟度が高い組織になってくると、判断のパラメータを過去のデータから定量的に評価して、その結果でレビューの実施／未実施の判断を行います。リーダーの経験も当然重要な要素ですが、組織全体で品質を向上させるためには、このような根拠のある判断をするように改善していくことが望ましいでしょう。

　では、レビューの実施に対しては、どのような準備をしているのでしょうか。


			実施するレビューごとにチェックリストを作成している


			設計書などのレビュー対象成果物はテンプレート化して、記述内容をできる限り標準化している


			コードレビューの実施前には、チェックツール（静的解析）を実施し、基本的な不具合はない状態にしておく