“読み方”を知って、レビューをもっと効果的に

森崎 修司
奈良先端科学技術大学院大学
情報科学研究科

2009/11/19

第2回｜1　2　3　4｜次のページ

なぜリーディング技法を使うか？

　第1回『“確実な記録”こそが、品質・コストに貢献する』では、「何のためにレビューを行うのか、そのために何を重視するのか」といった“観点”を持つこと、すなわち「目的を明確化すること」がレビューを成功させるポイントだと解説しました。

　今回解説するリーディング技法とは、そうした「目的」を達成するために、レビューアが「ドキュメント類をどう読み進めていくか」を具体化したものです。一方、プロジェクトマネージャや品質管理担当者など、レビューを管理するメンバーにとっては、技法の種類が「レビューでどんな問題を発見できるのか」大まかに推測する手掛かりとなります。すなわち、「目的」に応じてどのリーディング技法を選ぶかが、レビューを効率的に進め、望んだ成果を得るための重要なポイントの1つとなるのです。

　例えば、ただ漫然とレビューを行うと次のようなことが起こりがちです。

──ある日のこと……

リーダー	「では詳細設計のレビューを始めます。設計書を読んで疑問に思ったことや不明な部分を挙げていきましょう」

設計担当A	「32ページの『ファイル数の最大値』が不明な点が気になりました。この値によっては既存のソースコードを流用できない可能性がありますから、最大値を明確にしておくべきです。41ページの『文字列の長さ』も100文字程度に制限しておき、将来的にも200文字を超えないようにすべきでしょう。あと、86ページの誤字が多いのが気になります」

設計担当B	「私もAさんと同じような点が気になります。例えば33ページの『ディレクトリ数の最大値』が不明ですが、16bitで十分なのか、32bitにすべきなのか、明確にしておきたいです。86ページの誤字は私も気になりました」

リーダー	「12ページにも最大値が明示されていないものがある。できれば、推奨値と許容値の2段階で設定しておきたいですね」

──その後、プロジェクトマネージャへのレビュー結果報告時に……

リーダー	「レビューを終えました。指摘された課題はファイル数、ディレクトリ数の最大値です。ほかにも最大値が設定されていない項目が8つありました。これらを設定する必要があります」

プロジェクトマネージャ	「なるほど、それは大事だね。ところでほかにはどんな課題が指摘されたんだい？ 例えば、X機能のタイムアウト時、Y機能の呼び出し失敗時など、異常系のフロー定義がきちんと詰められていないように思うんだけど」

リーダー	「……」

プロジェクトマネージャ	「それにこの設定だと、Z機能のユーザーからたくさん問い合わせが来てしまいそうだ。あと、プログラムをアップデートする必要が出てきたら、どのプログラムや機能を停止させなければならないのか、明示してほしいな」

リーダー	「確かに……。最大値の議論ばかりでその辺りは詰めていませんでした。レビュー指摘の視野が狭くて、意見の重複が多かったように思います。再レビューしてきます」

◇

　これは、「レビューアのエラー指摘が特定の問題に集中してしまい、広範で網羅的な指摘ができなかった」という事例です。以下の図1は、水色の部分がレビュー対象のドキュメント、丸い円が個々のレビューアが対象ドキュメントをチェックした範囲や観点を模式的に表したものですが、皆さんも左の図のように、意見が重なってしまう、偏ってしまう、といった経験があるのではないでしょうか？

図1　漫然とレビューを行うだけでは、左のイメージ図のように指摘内容が重なりがちだが、レビューする対象や、メンバーの陣容に適したリーディング技法を選ぶことで、右の図のようにまんべんなく指摘することができる

　レビューでは「何を重視してチェックするか」という目的を決めたら、その範囲内で、できる限りさまざまな視点からチェックすることが大切です。その点、リーディング技法を適切に選べば、右の図のように重なりを減らし、より広い視点でチェックすることが可能になるのです。

対象ソフトウェア、メンバーの特性で技法を選ぶ

　ではリーディング技法にはどんなものがあるのでしょうか。以下は公開事例の多い技法の一覧です。どのようなプロジェクトでも優れた効果を発揮する「これが最良」といったものはなく、どのようなレビューを行うかという目的、参加するレビューアの特性など、“チームを取り巻く状況”に最適なものを選びます。

リーディング技法	適している場面	進行方法
ユーセージベースド	・ユースケースが定義されているとき ・ユーザーが典型的なユースケースに沿って 　ソフトウェアを利用する場合	ユースケースの内容に応じて優先順位を付けて読み進める
アドホック	・経験豊富なレビューアが多く参加するとき ・なじみのあるレビューア同士が参加するとき	各レビューアが自身のペースで読み進める
チェックリスト	・担当者による観点のブレを抑えたいとき ・レビュー対象となるソフトウェアの作成担当者に 　チェック項目を事前に知らせておきたいとき	レビューア全員が同じペースでチェックしながら読み進める
ディフェクトベースド	・“典型的なエラー”のタイプが推測できるとき	各レビューアが、異なるシナリオを使い、異なるペースで読み進める
パースペクティブベースド	・手分けをして複数の観点から網羅的にエラーを 　指摘したい場合 ・「チェックに必要なスキル」差が大きい 　複数の観点を設定したい場合	各レビューアが、異なる観点、異なるペースで読み進める

表1　リーディング技法の種類。そのレビューで求める効果や、メンバーの特性などを考慮して、最適なものを選ぶ

　アドホックやチェックリストなどは、開発にたずさわる多くの人がご存じと思いますが、中には初めて聞く技法もあるのではないでしょうか？ 今回は、レビューを効率的に進めるために、これらの技法について詳しく紹介したいと思います。

第2回｜1　2　3　4｜次のページ

	Page1 なぜリーディング技法を使うか？ 対象ソフトウェア、メンバーの特性で技法を選ぶ
	Page2 対象ソフトの知見が少ないときはユーセージベースドリーディング 経験豊富なメンバーが集まる場合はアドホック
	Page3 レビューアによる“観点のブレ”を抑制するならチェックリスト ディフェクトベースドリーディングで、エラーをタイプ別にキャッチ
	Page4 異なる立場でレビューするパースペクティブべースドリーディング 無意識のうちにリーディング技法が確立されている？

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）