シナリオによるレビューとは

これまで本ブログでもシナリオを使ったレビューを何度か紹介しています。シナリオは自然言語でレビューで検出すべき欠陥を記述したものです。チェックリストの質問と似ている点が多くありますが、以下の点で異なります。

検出方法や確認すべき箇所を指定する
シナリオには具体的な検出の方法や確認すべき箇所を指定してあることが前提となっています。これによってレビューアは何をしたらよいかが明確になります。たとえば、非常にたくさんの箇所でデータを更新するようなレビュー対象において「データ更新において不正な処理はないか？」という質問項目がチェックリストにあると、現実的にはこの質問を確認することができなくなります。シナリオでも同様の問題は起きえますが、シナリオ作成時点でそうならないよう検討しておきます。

レビューアにシナリオを割当て分担する
シナリオは1件ずつレビューアに割当てられ、通常1人のレビューアが数件のシナリオを担当します。これによってレビューアの担当範囲が明確になり、分担ができます。チェックリストの質問を個々のレビューアで分担することもできますが、あまり一般的ではありません。一般にどのような欠陥を検出するかが明確にになると集中できると言われています。

シナリオは無条件に流用しない
同一のソフトウェアの保守、拡張等、流用されることもありますが、同じ分野のソフトウェア、同じ技術要素を使っているソフトウェアといった表層的な理由ではシナリオを流用しません。チェックリストも吟味して流用するかどうかを検討することもできますが、詳細な検討なく質問項目をすべて流用しているということも少なくありません。

シナリオを用いたレビューの効果は1990年代から言われており、1995年に発表されたPorterらの論文「Comparing Detection Methods For Software Requirements Inspections: A Replicated Experiment(IEEE Transactions on Software Engineering, vol. 21, No. 6, p.563-575)」にfault-based scenarioという記述があり、どのような欠陥を検出すべきかを事前に想定してシナリオを定義しておくことを推奨しています。また、学生実験でチェックリストを使ったレビューや特に何も指定しないレビュー（アドホックレビュー）と比較してシナリオによるレビューの効果が大きかったことを報告しています。

シナリオによるレビューは際立つような新しい方法ではありませんが、レビューア同士が張り合ったり、些末な欠陥の指摘に終始する会議を自然に脱却できたりする等、効果がたくさんあります。今年もシナリオによるレビューを紹介する1日セミナを担当する機会をいただきました。今年で3年目になります。開催場所は東京（5/27）と名古屋（6/3）です。詳細はこちら。セミナーを受講される方には書籍を進呈されます。

拙著「間違いだらけの設計レビュー（日経BP）」でもシナリオを使ったレビューの方法を推奨しています。シナリオを使ったレビューを一部取り入れることもできますので、改善のために役立てていただければと思います。@ITの記事「設計レビューに私情を持ち込んでいませんか？」でも書籍の紹介をしていただいています。