技法の分類とテンプレート（応用編）

パースペクティブベースドリーディングの記録テンプレート

　図3はシナリオ定義のテンプレートです。エクセル形式のテンプレートがここからダウンロードできます（205_1.zip/15.2 KB）。また、筆者の研究グループのWebサイト（http://se.aist-nara.ac.jp/html/review/formats.html）からも入手できます。

　図3-1の「シナリオ記述例」テンプレートの最上部はシナリオ自体の管理情報です。「シナリオリストID」はシナリオ一覧を区別するためのIDです。「シナリオバージョン」には修正、削除、追加に伴う改版数を記入します。「シナリオ作成者」は新規作成、あるいは、改版した担当の名前を記入します。

　最上部の管理情報よりも下がシナリオを定義するためのテンプレートです。1シナリオを1行として記述します。「シナリオID」列は個々のシナリオを区別するためのものです。記述例では1、2、3と連番をつけていますが、関連するシナリオがあれば、1-1、1-2のように整理するほうがわかりやすくなります。「立場（シナリオ名）」列には、どのような立場を想定したシナリオかを記述します。例えば、図2に示した「設計者」「顧客」「テストエンジニア」が該当します。

　「シナリオの導入説明」列には「立場（シナリオ名）」列の補足を書きます。そのシナリオがどのようなスキルをもった誰を対象としているかを記入します。

　「具体的な読み方の手順」列には、どのようにインスペクションの対象となるドキュメントを読んでいくかを書きます。例えば「立場」が「顧客」であれば、「具体的な読み方の手順」には「もっとも頻繁に使うユースケースを想定して読んでください」のようになります。

　「質問（複数可）」列には、チェックリストと同様にYes/Noで答えられるものを記入します。例えば、先の例では「ユースケースの中で起こりうる例外機能やキャンセル（アンドゥ）機能の定義はありますか？」といった質問になります。質問は複数書いてもかまいません。

　図3-2の「指摘記録例」はパースペクティブベースドリーディングでの指摘記録のテンプレートです。前回紹介したチェックリストの指摘記録テンプレートと同様に、最上部の「利用したシナリオリストID」の記入を忘れないでください。中央の「担当」欄には、どのシナリオを誰が担当したか、シナリオNo.と氏名を記入します「シナリオNo」は「シナリオ記述例」の「シナリオNo」列から対応するものを記入します。

パースペクティブベースドリーディングの効果と限界

　立場や観点を漏れなく列挙できれば、指摘の網羅性があがります。特に、開発の早期に確認しておきたい内容（どのようなテストを実施するか、保守・拡張のためにどのような仕組みが必要か等）をシナリオとして定義しておけば効果的です。

　また、チェックリストよりも抽象的な立場、観点を定義するだけで、インスペクタが重複して欠陥を指摘する可能性が減ります。チェックリストと同様に作成者に事前にシナリオを渡しておくことで「不意打ち指摘」を減らすことができます。それほど経験が多くないインスペクタが参加するときには、その人たち向けのシナリオを準備することで、効果が得られやすくなります。また、副次的な効果ですが、異なる立場から同じインスペクション対象の欠陥を指摘しているとチームとしての一体感が醸成されます。

　パースペクティブベースドリーディングの限界は、シナリオの定義とシナリオの維持管理のコストと難しさにあります。単純に過去の不具合から質問を書きおこして積み上げていくチェックリストと異なり、シナリオ定義の作成にはそれなりに時間と手間がかかります。また、インスペクタが必ずしもシナリオ作成者が想定したように質問や立場を解釈してくれるとは限りません。

[参考文献］
Basili V., Green S., Laitenberger O., Lanubile F. , Shull F. , Sorumgard S. and Zelkowitz V. M. 『The Empirical Investigation of Perspective-Based Reading』「Empirical Software Engineering. (An International Journal), Vol. 1, No. 2, pp. 133-164. (1996)」