“読み方”を知って、レビューをもっと効果的に：ソフトウェアレビュー入門（3）（4/4 ページ）
異なる立場でレビューするパースペクティブべースドリーディング
さて、最後に紹介するパースペクティブベースドリーディングは、各レビューアがそれぞれ異なる立場・観点からレビューを行う方法です（注5）。
図5 パースペクティブべースドリーディングのイメージ。「開発にかかわる立場（視点）」別にエラー発見のためのチェック項目を作り、焦点を絞ってレビューする具体的には、異なる立場（観点）に基づいたチェック項目を用意し、1人1人のレビューアに割り振ります。これにより、指摘の重複を減らし、網羅的なエラー指摘を狙う方法です。
前のページで紹介したディフェクトベースドリーディングと似ていますが、ディフェクトベースドリーディングは「エラーのタイプ」でシナリオ、すなわちチェック項目をまとめるのに対し、こちらは、ユーザー、テストエンジニアといった「開発にかかわる立場（視点）」でまとめる点が特徴です。
以下の表5はパースペクティブべースドリーディングによる要件定義書のチェック項目例です。
立場（視点） |
チェック項目の例 |
| 設計者 |
|
| 利用者 |
|
| テストエンジニア |
|
表5 パースペクティブベースドリーディングによる要件定義書のチェック項目例。開発にかかわる立場（視点）ごとにチェック項目を用意し、各レビューアの観点を絞り込むことで、チーム全体で網羅的なチェックを狙う
この立場（視点）は、必ずしも実際の開発における各レビューアの立場と一致している必要はありません。例えば、プロジェクトリーダーがソフトウェアのユーザーの立場でレビューしてもいいわけです。
また、この観点を、プロジェクトの状況に合わせて設定するのもお勧めです。例えば、開発完了後、ソフトウェアの保守を別のメンバーに引き渡す場合には「保守エンジニア」、オフショア開発の場合には「オフショア開発でのブリッジエンジニア」といった立場（視点）によるチェック項目を設定してレビューしておくと効果的です。
なお、これを応用して、立場（視点）を「役割」で設定するのではなく、以下の表6のように「スキル」という軸で細分化する方法もあります。
初級プログラマ |
エキスパートプログラマ |
|
| 1 | ユースケースを中心に読み進めてください。ユーザーの操作が関与するすべての条件分岐において、エラー処理や例外処理は定義されていましたか？ | 最も重要、または、最も複雑なクラスから読み進めてください。データ構造は実行速度やメモリ使用量とのトレードオフが考慮されていますか？ 再利用性を高めるために追加コストを投じる価値がありそうですか？ |
表6 パースペクティブベースドリーディングは「スキル」という軸で立場を設定する方法もある。表6は「A Practical Approach for Quality-Driven Inspections」（C. Denger、F. Shull＝著／『IEEE Software Vol. 24』／IEEE computer society press／2007年）を基に筆者が1部抜粋、要約したもの
このパースペクティブベースドリーディングについても簡単にまとめておきましょう。
■メリット
- 多様な立場（視点）からエラー指摘できるため、指摘内容が重複しにくく、網羅的にエラーを指摘ができる
- プロジェクトメンバーのスキルや役割に合わせて立場（視点）を設定できるため、より具体的な指摘ができる
■デメリット
- 立場（視点）だけでは検出できないエラーも存在する
- 割り当てられた立場（視点）になじみがない場合、エラー指摘が難しい場合がある
なお、認知度が高いアドホック、チェックリスト、パースペクティブベースドリーディングについては、私が所属する奈良先端科学技術大学院大学 情報科学研究科 ソフトウェア工学講座の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.
注目のテーマ
人気記事ランキング
- 生成AIは2025年には“オワコン”か？ 投資の先細りを後押しする「ある問題」
- 江崎グリコ、基幹システムの切り替え失敗によって出荷や業務が一時停止
- 「Copilot for Securityを使ってみた」 セキュリティ担当者が感じた4つのメリットと課題
- Microsoft DefenderとKaspersky EDRに“完全解決困難”な脆弱性 マルウェア検出機能を悪用
- ｢欧州 AI法」がついに成立 罰金「50億円超」を回避するためのポイントは？
- 「プロセスマイニング」が社内システムのポテンシャルを引き出す理由
- 「SAPのUXをガラッと変える」 AIアシスタントJouleの全体像とは？
- “生成AI依存”が問題になり始めている 活用できないどころか顧客離れになるかも？
- 日本企業は従業員を“信頼しすぎ”？ 情報漏えいのリスクと現状をProofpointが調査
- 検出回避を狙う攻撃者の動きは加速、防御者がやるべきことは Mandiantが調査を公開
ITmediaはアイティメディア株式会社の登録商標です。