なぜレビューに注目するのか
同じ成果物をレビューしてもらったとして、｢レビュアーによって指摘事項が違うな｣と思ったことはありませんか？
どうやら、レビュアーによって観点(目の付け所)は違うようです。
(レビューに限ったことではないですが)
だとしたら、体系化されたレビュー観点があれば、Aさんのような経験がなくても、Bさんのような知識がなくても、彼らと同じ指摘が自分にも出来るかもしれない。
という夢のようなことを思いつきました。
…で、実はかなり前からそれについてSQiP分科会で検討されていることを最近になって知りました。
この記事のスコープ
JaSST Review'22に参加し、しっかり考えたことのなかったレビュー観点に出会ったので、簡単にまとめてみました。
いろいろと調べるうちにJaSST Tokyo 22で行われたワークショップの資料に行きつきましたので、そこでも取り上げられたらしき手法も合わせて簡単にまとめました。
- SQiPのレビュー分科会で検討されているらしい手法のうち、ごく一部のご紹介となります
作成者コンテキストアプローチ
- 誰がどういう状況で作った成果物か
- 徹夜明けとか、類似プロダクトをかけ持ちしてるとか
- 類似プロダクトのコピペで、今回には関係ない記述がないか
- 異常系まで検討されているか
- このアプローチは、個人攻撃になる可能性があるのであまり使いたくない
- 徹夜明けとか、類似プロダクトをかけ持ちしてるとか
利害関係者の関心事アプローチ
SAKE法(Stakeholder Action KanshingotoExtraction)
- ステークホルダーのアクションに着目したレビュー観点導出手法
- 保守運用フェーズで不都合が生じないか…etc,
- ｢運用でカバー｣は本当に実現可能か
対象成果物に求められることアプローチ
SBR法(Stealth Based Review)
- プロジェクト特性によるステルス潜在事項推測手法
- 成果物に記載されていないが、前提との齟齬がないか確認する
- ｢記載されていないこと｣を明示する
対象成果物によくある欠陥アプローチ
DCC法(Defect Chain Chart)
- 欠陥知識（欠陥連鎖チャート）を有効活用したレビュー方法
- 類似プロダクトで検出された指摘事項について、該当プロダクトではどうなっているか
プロダクトリスクアプローチ
RDT法(Risk Defect Tree)
- リスクに着目したリスク欠陥ツリーによるレビューポイント導出方法
- 発生したら影響の大きい問題に対して、どんな手を打っているか
利用シナリオアプローチ
HDR法(Hypothesis Driven Review)
- 仮説駆動型レビュー手法
- ユーザーがどのような流れで利用するか想像する
- 正常系だけではないことに注意する
CR法(手法というよりレビュー戦略：レビュー観点を用いた手法を適用する)
- 重大欠陥を効率よく検出する観点の段階的設定によるレビュー実践手法
- 複数人がアドホック的にレビューした場合、指摘が重複するのを防ぐ
- 漫然と成果物を読み、アドホック的に思いつきで指摘することを防ぐ
- あらかじめレビュアーの観点を指定することで、検出したい指摘を狙い撃ちできる
まとめ
つらつらとレビュー観点を記載しました。
賢明なる読者諸氏の中には｢おや？｣と思われた方も多いと思います。
(こう書かれた時に｢おや？｣と思ったことのない私です)
そうです、
レビュー観点はテスト観点としても充分に使える
逆に、テスト観点をレビュー観点にしても充分に使えそうです。
要件定義や仕様ドキュメント(wikiやBacklogでもいい)を、上述の観点で眺める。
それはもう立派な静的テストです。
JSTQB FLのシラバスにもレビュー＝テスト手法として記載されています。
レビュー観点を自分のものにすれば、プロダクトだろうがドキュメントだろうが、同じ質でチェックできるようになりますね。
こうした共有知を自分のものにできれば、ベテランとの数十年の差を縮めることができます！(かもしれない)
あと、レビュー後にレビュアー同士で感想戦をしましょう。
きっと別の新たなプロジェクトリスクへの気づきがあるはず！