DevLOVE関西主催の勉強会にまたまた参加してみました。というわけで遅くなりましたが書き起こしを。
個人的なメモかつだいぶ忘れてしまっている内容なので変なところも多々あると思いますがご了承ください。

シナリオレビューの紹介

登壇者：森崎修司(@smorisaki)
名古屋大学大学院情報科学研究科准教授

レビューの効果

テストのタイミングで確認して修正するとなると遅い
なのでレビューのタイミングで確認したほうがもちろんいいよね

ただし…
テストの工数が削減できるという観点のレビューでないと意味ない

じゃあどういうレビュー内容がテストの工数を削減できるのか？

レビューのアンチパターン

一部だけしか見ない
インデントはスペース4つで統一してください。とか
人格攻撃
こんなのもわからないなんてエンジニアとしてどうなんですか？とか
説明会とか進行がおかしい
ではこれから説明会レビュー会を始めます。お手元の資料を…とか

ではどうしたらいいか

レビューの準備

レビューの準備に必要なことは、レビュー前に適切な目的を設定し合意しておくということ
具体的には「問題種別の抽出する」と「検出シナリオを決めておく」（後述）
これらをみんなで合意することが一番大事！

レビューによる問題の検出

事前に設定した問題種別に沿って検出する
→どこをどうチェックしたかは予めチェックリストを作ることで明らかにしておく

レビュー技法

Defect-based reading Perspective-based reading

Defect-based readingとは

漏れ・曖昧・誤りの3つの観点でレビューを実施する技法
ちなみに漏れ（一番難しい）

漏れ
検討漏れ
→そもそも検討ができていない場合がある
あなたにとっての「常識」とは？
→使う人にとっての常識を定義する
ドキュメントを読んでしまうと先入観が入ってしまう
→ドキュメントを読む前にソフトウェアのあるべき姿を想像して望む
曖昧
読み手にとって複数の解釈ができてしまうものは、読み手の想定や定義が必要となる
誤り
外部や内部で定義されたドキュメントやコードの不整合が原因であることが多い

Perspective-based reading

そもそもテスターはテストを実施できるのか？
のようににテスター・発注者・利用部門・プログラマそれぞれの立場で考えてレビューを実施する技法