“読み方”を知って、レビューをもっと効果的に：ソフトウェアレビュー入門（3）（2/4 ページ）

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

対象ソフトの知見が少ない場合はユーセージベースドリーディング

　ではまず、ユーセージベースドリーディングから紹介しましょう。この技法は、「ユースケース」や「ユースケースシナリオ」がすでにあるとき、それに沿って対象ドキュメントを読み進める技法です（注1）。

---

注1：ユーセージベースドリーディングは、論文「Usage-based reading――an experiment to guide reviewers with use cases」（T. Thelin、P. Runeson、B. Regnell＝著／『Journal of Information and Software Technology, Vol. 43』 Elsevier／2001年）で提案された手法です。

---

図2　ユーセージベースドリーディングのイメージ。対象ドキュメント（グレーの部分）との間に矛盾がないか、ユースケース（水色の部分）に沿ってチェックしていく

　「レビュー対象とするソフトウェアと類似したソフトウェアの開発経験が少ない」など、レビュー対象に対する知見が少ないときには、チェックすべき内容をユースケースに導いてもらえる分、特に有効です。

　ちなみに、ユースケースとは、システムの機能を“ユーザーとのインタラクション”としてとらえ、対象システムが取り得る状況に応じたさまざまな振る舞いを、表や記法などを使って簡潔にまとめたものです。一方、ユースケースシナリオとは、ユースケースを文章で記述したものとなります。以下の表2はユースケースの一例です。

ID	ユースケース	優先順位
1	商品検索 ユーザーは検索画面から検索キーワードを入力する システムは該当する商品一覧を表示する ユーザーは商品一覧の中から購入したい商品を選択し、ショッピングカートに入れる システムは現在、ショッピングカートに入っている商品のリストを表示する	2
2	パスワード変更 ユーザーは「ログインパスワード変更」メニューを選択する システムはパスワード変更画面を表示する ユーザーは旧パスワード、新パスワードを入力する システムは旧パスワードの一致をチェックし問題がなければ新パスワードをパスワードとして設定する	3
3	閲覧商品一覧 ユーザーは「これまでに閲覧した商品一覧」メニューを選択する システムは該当するユーザーの閲覧履歴を表示する	4
4	商品購入 ユーザーが「購入」ボタンを押す システムはショッピングカートに入っている商品を表示し、送付先、購入方法を入力するための画面を表示する ユーザーは必要な情報を入力する システムはユーザーの入力に不備がないかチェックし、問題がなければ入力確認画面を表示する ユーザーは入力確認画面を確認し、問題がなければ「購入ボタン」を押す システムは入力内容を確認し問題がなければ、出荷処理を実施し、ユーザーにメールを送信し、購入済み画面を表示する	1

表2　ユースケースの一例。ユーザーにとって重要なユースケースから対象ドキュメントを読み進める。なお、ユースケースの記法としてはUMLが有名だが、ユーセージベースドリーディングで使うユースケースは、このように自然言語で書いたものでもよい

　ユーセージベースドリーディングでは、こうしたユースケースとの間に矛盾がないか、要件定義書、設計書、ソースコード、テスト設計／テストケースといったレビュー対象ドキュメントをチェックすることで、定義の漏れや、得られる出力値の誤り、エラー処理の漏れなどを発見します。「エラーがあると、ユーザーにとって損失やダメージが大きいユースケース」から優先してチェックすることも、この技法の特徴です。この技法についてまとめると、以下のようになります。

■メリット

• ユースケースが作られていれば、すぐに実施できる
• ユーザー視点で、重要なものからレビューを実施できる
• 何から手を付けるべきか分からない場合に有効

■デメリット

• 機能面以外のエラー指摘が難しい
• ユースケース間で重複が多い場合に、レビュー範囲が限定的になる

経験豊富なメンバーが集まる場合はアドホックリーディング

　アドホックリーディングは、最も一般的なリーディング技法です。「エラー指摘」「保守性向上」といった大まかな目的を、最初にレビューアに伝えておくことで、「どのようなタイプの問題を指摘したいか」メンバー間で共有しておきます。レビュー対象の読み進め方に具体的な指示を出さないことも特徴です。

　「ファントム（幽霊）インスペクタ／ファントムレビューア効果」（以下、ファントム効果）（注2）と呼ばれる相乗効果が出やすいのもアドホックの特徴です。ファントム効果とは、あるレビューアが指摘したエラーをきっかけに、別のレビューアがその指摘を分析、深堀りすることで、より本質的なエラー指摘につながっていくという“相乗効果”のことです。ファントム効果は、参加しているレビューアだけではとうてい指摘できないようなエラーを“別の誰かが発見しているような感じ”がすることから付けられた名前です。

---

注2： 「An encompassing life cycle centric survey of software inspection」（O. Laitenberger、J. DeBaud＝著／『Journal of Systems and Software Vol. 50』／Elsevier／2000年）にファントム効果の有無に関するサーベイがあります。インターネットや図書館などで探してみてはいかがでしょうか。

---

　ただ、その分、対象ソフトウェアに対する知見や、自由に意見を述べ合えるチームワークが求められます。それゆえに、レビューア間で観点が重なりがち、ブレがちというデメリットもあります。特に開発メンバーだけでレビューを行う場合にその傾向が強く、人数の割に効果が上がらないこともあります。この技法については、以下のようにまとめられます。

■メリット

• 特に事前準備が必要ない
• 技法を習得するための準備コストが必要ない
• ファントム効果が得られる場合がある

■デメリット

• レビューア同士で観点が重なりがち
• 観点がブレやすく、期待したエラーが指摘されないこともある