レビューで意識することは? - 提案されている読み方あれこれ -
設計ドキュメントやソースコードのレビューの読み方をリーディングテクニックと呼ぶ。文献[ http://portal.acm.org/citation.cfm?id=342905]では既発表のリーディングテクニックをサーベイし、以下のように分類している。
- Adhocリーディング
レビューでの読み方を特に決めない。 - Checklist-basedリーディング
チェックリストをみながらレビューする - Scenario-basedリーディング
- Defect-basedリーディング
あらかじめ決めた不具合/問題の種類に着目してレビューする - Perspective-basedリーディング
あらかじめ決められた立場(観点)にたってレビューする
- Defect-basedリーディング
AdhocとChecklist-basedが一般的によく使われている読み方だと思う。
レビューの結果は参加者のスキルに依存しやすい傾向がある中で、チェックリストベースドのものは底上げにつながる。ただし、チェックリストの内容と開発対象がうまくマッチしている必要がある。特定の年齢層の専門家しか使わないシステムのレビューに「幼児や年配の方へのユーザビリティの配慮」というチェックリストを使うと期待する効果が出ない。
アドホックは特に準備がいらないかわりに、参加者の経験に依存するところが多い。
シナリオを使ったリーディングでは、チェックリストよりも柔軟性があるが、アドホックよりも参加者の経験に依存するところが少なくなるため、2つの中間という位置づけになるだろう。シナリオベースドの1つであるPerspective-baseリーディングは観点(Perspective)を定義して、その観点に沿ってソフトウェアをレビューする。たとえば、顧客の観点、テスタの観点、運用時の観点、セキュリティの観点、が挙げられる。
複数人でレビューするとパフォーマンスを意識した指摘や境界値に着目した指摘等、各々緩やかな役割分担をしているのではないだろうか。"Scenario-based"といわれれば何だか新しい気がするがよくよく聞いてみると「それやってるよ」という感想を持たれるのではないだろうか。
ここで紹介した研修の1回目ではAdhocとDefect-basedを比較しながら実施した。3/6, 7に2回目の研修を実施する。