はじめる前に頭に入れておきたいこと！

レビューの種類

　今までの説明から、ソフトウェア開発において、レビューがどれだけ大事な活動なのかは、理解していただけたと思います。原理98には、「Fagan流の審査」という言葉が出ていました。これは、いくつもあるレビューの方法のうちの1つです。「ソフトウェア品質知識体系ガイド－SQuBOK Guide－」（詳細は参考文献）には、以下のようなレビュー方法が載っています。

・ピアレビュー
・インスペクション
・チームレビュー
・ペアプログラミング
・ピアデスクチェック
・パスアラウンド
・ラウンドロビンレビュー
・ウォークスルー
・アドホックレビュー

　レビューにもいろいろな種類があることがわかりますね。レビュー活動の定着化を目指すには、あれもこれもと手を広げてはうまくいきません。まずは、何を目的にレビュー活動を推進するのかを明確にしてから進めていきましょう。

どのレビューから始めたらよいか？

　ソフトウエアCMM（SW-CMM）は、成長するソフトウエア能力の5段階を記述したものです。図3に示すように、1番目を除く各レベルは、キープロセスエリア（KPA）を定義しています（「ソフトウェア能力成熟度モデル 1.1版（公式日本語版）」詳細は参考文献）。

　成熟度レベル3のKPAに、「ピアレビュー」があります。ピアというのは「仲間」という意味です。1ページで、「ルールに基づいたレビューが実践され、結果的にレビュー活動が組織文化として根付かせる必要があります」と書きました。ルールに基づいたレビューを実践するために、このピアレビューの導入から始めることをお勧めします。なぜかというと、内容を理解しやすいということです（実践するのと内容を理解するのとでは大きな違いがありますが…）。また、ピアレビューに関する参考図書や論文はいろいろ出ていますので、導入時のヒントを得ることもできます。

　ピアレビューの注意点を以下に示します。

　1つ目は「対象を計画」することです。プロジェクトごとに計画を立てるべきです。

　2つ目は「基本は同僚同士」で行うことです。レビューの結果を人事評価に影響させてはいけません。

　3つ目が「作業成果物が対象」であるということを認識することです。手ぶらで集まっても意味がありません。

　4つ目が「欠陥や改善を洗い出すことが目的」であるということです。説明会や勉強会、解決策の検討会ではありません。仕様や技術についての議論の深みにはまることを防止するために、各自が認識しておかなければなりません。

　5つ目が「手順があること」です。開催方法や記録方法などのルールに従って行うべきですし、手順に従ったやり方であれば、記録したデータの一貫性が確保できます。これらは品質データとして使えます。

　上流工程の成果物の品質を確認することが難しい、とよく言われます。まずは、「早期に効率よくソフトウエア作業成果物から欠陥を取り除く」ことができるピアレビューを導入し、品質の作り込みを実現し、効果が実感できるようにチャレンジしてみましょう。

　次週は、このピアレビューを組織的に導入するために、どのような教育（トレーニング）が効果的なのかを考えてみたいと思います。

【参考文献】

アランデービス著、松原訳『ソフトウェア開発201の鉄則』日経BP（1996）

QuBOK策定部会『ソフトウェア品質知識体系ガイド－SQuBOK Guide－』オーム社（2007）

Mark C. Paulk,他、ソフトウェア技術者協会CMM研究会訳『ソフトウェア能力成熟度モデル 1.1版（公式日本語版）』（http://www.sea.jp/CMM/publish/CMM-J99.html）CMU/SEI-93-TR24（1993）

Karl E. Wiegers、大久保雅一（監訳）『ピアレビュー』日経BPプレス（2004）

Tom Gilb, Dorothy Graham、井土誠一・富野壽（監訳）『ソフトウェアインスペクション』共立出版（1999）