SQiPワークショップでインスペクターと化す ─ その3

　「その2」で書いた、SQiPワークショップのアフターフォローに行ってきました。「参加してよかった」の一言に尽きる充実した内容だったので、感想を書きたいと思います。

www.kzsuzuki.com

　参加者は、主催元である東洋大学の野中先生、ヤマハの小池さんと、ワークショップ参加のメンバーからわたしを含めて4人の、計6人。

　メンバーのお一人が、従来ウォークスルー型でやってきたレビューをインスペクション型で試行し、効果測定した結果を披露してくださいました。定量的に整理され、分析と考察を加えた資料です。
　普通、この手の資料は各社に秘蔵され、外には出てこないもの・・・。ソフトウェア工学の発展はこういうところから生まれるのだなあと、感動。この資料に対する議論だけでも参加したカイがあると言える、本当に有意義な時間でした。

　また、インスペクションの考え方や観点についてのチームメンバー向け資料を紹介してくださった方、関連する過去の発表資料について解説してくださった方など、みなさん議論するためのネタをお持ちであり、それぞれが白熱する議論の土台となりました。
　つまり具体的なアウトプットがないのはわたしだけという、恥の多い生涯を送って来ました。。。

　気をとりなおして・・・、
　提示いただいた資料で具体的な数字を見ても、

事前チェックとロギングミーティングを合わせると、工数（と負担感）は増大 対象とするドキュメントの規模に対する指摘の密度は向上

ということが、あらためてわかります。
　ただし前者については、事前チェックは自分の好きな時間に行えばよいという自由度があること、また「その2」で紹介したように、ロギングミーティングの時間には短縮の余地があることから、導入のハードルを下げることはできそうです。
　わたし自身、現在担当しているプロジェクトで、インスペクションめいたものを導入できそうなので、データを集めてみるつもりです。

　さて、議論の中で面白いと感じた話題として、レビュアーの思考ロジックを追ってみるというものがありました。

　ある欠陥に対する指摘がなされた際、この「欠陥-指摘」のセットに対するアプローチは2つあります。

何故その「欠陥」を作ってしまったかという、レビュイーの思考のトレース 何故その「指摘」をすることができたかという、レビュアーの思考のトレース

　テストでも同じことですが、わたしが考えるのは(1)に偏っています。
　つまり、レビューなりテストなりで出た欠陥に対し、その欠陥がたとえばドキュメントの記述の曖昧さに起因するものであれば、そこまで遡って改善するとともに、そこから派生する他の部分に同様の欠陥がないかを確認する、というプロセスを踏みます。

　(2)からは、何が得られるでしょう。
　レビュアーの指摘を分類すると、もちろん具体的な知識に基づく（CBR：Checklist-Based Reading的な）ものもあるでしょうが、一方で、優れたレビュアーの頭の中にだけある、暗黙の観点に照らした（PBR：Perspective-Based Reading的な）ものもあるのでは、と考えられます。そのような観点の収集を行うことで、PBRを充実させることができるのかも知れません。

　PBRについては、参加者のお一人に、参考となる資料をご紹介いただきました。公開されているものですので、こちらにも載せておきます。

森崎 修司 氏　『がんばるだけのレビューになっていませんか？』 （コチラからダウンロードできます）

　きちんと理解できれば感想を書きたいと思います。