“読み方”を知って、レビューをもっと効果的に：ソフトウェアレビュー入門（3）（4/4 ページ）
ソフトウェアレビューは、ただ漫然と行うだけでは期待する成果を得られない。ソフトウェアの品質向上に寄与する効果的な“指摘”をもっと効率的に行うためには、“それなりの読み方”がある
異なる立場でレビューするパースペクティブべースドリーディング
さて、最後に紹介するパースペクティブベースドリーディングは、各レビューアがそれぞれ異なる立場・観点からレビューを行う方法です（注5）。
具体的には、異なる立場（観点）に基づいたチェック項目を用意し、1人1人のレビューアに割り振ります。これにより、指摘の重複を減らし、網羅的なエラー指摘を狙う方法です。
前のページで紹介したディフェクトベースドリーディングと似ていますが、ディフェクトベースドリーディングは「エラーのタイプ」でシナリオ、すなわちチェック項目をまとめるのに対し、こちらは、ユーザー、テストエンジニアといった「開発にかかわる立場（視点）」でまとめる点が特徴です。
以下の表5はパースペクティブべースドリーディングによる要件定義書のチェック項目例です。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
この立場（視点）は、必ずしも実際の開発における各レビューアの立場と一致している必要はありません。例えば、プロジェクトリーダーがソフトウェアのユーザーの立場でレビューしてもいいわけです。
また、この観点を、プロジェクトの状況に合わせて設定するのもお勧めです。例えば、開発完了後、ソフトウェアの保守を別のメンバーに引き渡す場合には「保守エンジニア」、オフショア開発の場合には「オフショア開発でのブリッジエンジニア」といった立場（視点）によるチェック項目を設定してレビューしておくと効果的です。
なお、これを応用して、立場（視点）を「役割」で設定するのではなく、以下の表6のように「スキル」という軸で細分化する方法もあります。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このパースペクティブベースドリーディングについても簡単にまとめておきましょう。
■メリット
- 多様な立場（視点）からエラー指摘できるため、指摘内容が重複しにくく、網羅的にエラーを指摘ができる
- プロジェクトメンバーのスキルや役割に合わせて立場（視点）を設定できるため、より具体的な指摘ができる
■デメリット
- 立場（視点）だけでは検出できないエラーも存在する
- 割り当てられた立場（視点）になじみがない場合、エラー指摘が難しい場合がある
なお、認知度が高いアドホック、チェックリスト、パースペクティブベースドリーディングについては、私が所属する奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア工学講座のWebサイトから記録様式をダウンロードできます。ぜひ、お試しください。
無意識のうちにリーディング技法を使っている？
さて、今回は5つのリーディング技法を紹介しましたが、中には普段皆さんが行っているやり方に近いものもあったのではないでしょうか。何事も、人が集まって何か1つのことを行う以上、そこには“ルール”が必要になります。レビューについても、「技法」として認識していなくても、半ば自然発生的なルールが確立されている例が多いのではないでしょうか。
実際、日本における一般的な開発関連組織においては、パースペクティブベースドリーディングに近いレビューが多く行われているようです。例えば、皆さんのレビューにおけるメンバーは、技術系のベテラン、顧客対応のベテラン、中堅、若手といった陣容で構成されていないでしょうか？ そうした「立場」に応じて、自然とそれぞれが異なる観点で、レビューをしているはずだと思うのです。
実際、筆者の研究グループで実施したレビューの実験においても、そうした“役割分担”が自然と行われるケースが数多く認められました。特にリーディング技法や観点を指定しなかったにもかかわらず、普段プロジェクトマネージャやリーダーとして活動しているレビューアは、「仕様との整合性」「顧客へのコミットメントとの整合性」に注目し、組織の中堅として働いている人は「例外処理」をチェックし、若手は「正常系を順に追う」といった傾向が確認できたのです。
ただ、これはパースペクティブベースドリーディングに限ったことではありません。日本の場合はこの技法になじみがあるかもしれませんが、実はほかの技法についても同じなのです。すなわち、リーディング技法とは、決して難解で複雑なやり方を押し付けるようなものではなく、世界中でレビューにたずさわっている人たちが、自然と行っている読み方を明文化し、さらに効果的・効率的に行えるよう、形式化したものなのです。
それだけに、これらの技法にはレビューの真の目的「ソフトウェアの品質向上」に寄与する数々のエッセンスが凝縮されています。また、各技法にメリット、デメリットの両方があることからも分かるように、これらを使ううえで最も大切かつ効果的なのは、技法をそのまま踏襲するのではなく、自身の開発プロジェクト、メンバー、対象ソフトウェア、ソフトウェアに求められる要件などに応じてアレンジしたり、継続的に変えたりと、そのエッセンスを取り入れることなのです。
「技法」だからといって変に構える必要はありません。「使える」と思った部分を取り出して、ぜひ皆さんのチームや組織にマッチする形にアレンジして使ってみてください。普段行っているやり方に、意識的に“エッセンス”を取り入れることで、レビューの手応えが大きく変わってくると思います。
筆者プロフィール
森崎 修司（もりさき しゅうじ）
国立大学法人 奈良先端科学技術大学院大学 情報科学研究科 助教
ソフトウェアレビュー／ソフトウェアインスペクション、ソフトウェア計測を専門とし、研究・教育活動をしている。奈良先端科学技術大学院大学にて工学博士を取得後、情報通信企業でソフトウェア開発、開発管理、レビューに従事。現在、同大学院に奉職。研究成果を業界に還元していくことをミッションの1つと位置付け、ソフトウェアレビュー研究の国際連携ワーキンググループの主導、多数の企業との共同研究、文部科学省「次世代IT基盤構築のための研究開発: StagEプロジェクト」に従事。アイティメディア オルタナティブ・ブログで「森崎修司の『どうやってはかるの？』」 を執筆中。
ソフトウェアレビュー／インスペクションの研究グループ：
http://se.aist-nara.ac.jp/html/review/
ソフトウェアレビュー／インスペクション研究の国際連携ワーキンググループ：
http://www.software-inspection-wg.org/
StagEプロジェクト：
Copyright © ITmedia, Inc. All Rights Reserved.