さあ、SQiPワークショップの感想の続きだ！
その1では、「インスペクションでは、効率より効果が期待される」というお話を書いた。その2では、欠陥を除去するという直接的な効果とはまた別のメリットの話と、インスペクションの本質とは・・・という話をしたい。
レビューの終わりって、何だ？
アドホックの後にグループのメンバーから出た感想に、「どうも終わりが見えない」「やりきった感がない」というものがある。それなりに指摘を挙げているのに、指針がないからゴールが分からない。また、思いついたことを整理せずに挙げていくことから、指摘の内容も粒度も入り乱れている。
インスペクションでは、レビュアごとに特定の切り口を割り当てることで、それを解消しようとする。切り口とはたとえば、そのソフトウェアに対する立場。立場ごとに、こんな視点があるだろう。
| - ユーザの立場 「このドキュメントから、使い方をイメージできるか、操作のバリエーションが漏れていないか」 - コーディング担当者の立場 「このドキュメントから、内部設計に落とし込めるか」 - テスティング担当者の立場 「このドキュメントから、網羅的なテストケースを作れるか」 |
各立場における観点が、チェックリストとして用意されていると、なおいい。レビュアがそれぞれ異なる立場・観点でチェックすることで、性質の違う指摘が、より網羅的に現れることになる。
もちろんこのチェックリストは完璧であるはずもなく、これに従って確認したからといって、すべての欠陥が除去できるわけではない。
が、少なくとも「この観点についてはチェックが終わっている」というクサビとなる。このクサビは、新たに欠陥が見つかってしまったときの品質向上の方針にもなるし、野中先生のおっしゃる通り、「お客さんに説明しやすい」というメリットももたらすのだ。
逆にアドホックレビューは、テストでいうと、「テスト設計は特にしていませんが、一通りテストしたつもりです」といっているようなものなのだろう。
が、少なくとも「この観点についてはチェックが終わっている」というクサビとなる。このクサビは、新たに欠陥が見つかってしまったときの品質向上の方針にもなるし、野中先生のおっしゃる通り、「お客さんに説明しやすい」というメリットももたらすのだ。
逆にアドホックレビューは、テストでいうと、「テスト設計は特にしていませんが、一通りテストしたつもりです」といっているようなものなのだろう。
インスペクションの本質とは？
考えを整理すると、インスペクションの本質とは次の2点だと結論づけた。（あくまでもわたしの捉え方です）
|
これ以外にも、「全ての指摘が記録されていること」「チェック・ロギング・フォローアップといった一連のプロセスが明確に定義されていること」「メトリクスが測定され、プロジェクトおよび組織にフィードバックされること」など、たくさんの要素がある。
が、わざわざ全員で集まり、持ち寄った指摘事項を1件1件書き留めていくという「ロギング」の作業は省略し、個々人が共有サーバ上で済ませてしまうといった、ヤマハの小池さんの工夫などをお聞きしていると、「最も公式なレビュー」であることがインスペクションの本質ではないと考えている。
が、わざわざ全員で集まり、持ち寄った指摘事項を1件1件書き留めていくという「ロギング」の作業は省略し、個々人が共有サーバ上で済ませてしまうといった、ヤマハの小池さんの工夫などをお聞きしていると、「最も公式なレビュー」であることがインスペクションの本質ではないと考えている。
おわりに
5時間という短時間のイベントなので、様々な制約や条件はあるが、それを差し引いても、インスペクションは取り組むだけの価値がある手法だと実感した。
東洋大学の野中先生、ヤマハの小池さん、インテックの藤井さん。グループでともにレビューしてくださったみなさま。貴重な機会をどうもありがとうございました。
3ヶ月後のアフターフォローを楽しみにしております。今度こそは、高円寺駅の佐世保バーガーの味をインスペクションできますように・・・。
