SQiPワークショップでインスペクターと化す ─ その1 - ソフトウェアの品質を学びまくる

　インスペクション。SQuBOKガイドにはこう書かれている。

『SQuBOKガイド』P.231
インスペクションは、標準や仕様から外れた例外（文書化された標準からの逸脱や文書化された要求仕様からみた障害等）を発見するレビュー方法の一つであり、最も公式なレビューである。

　この太字部分に気をとられ、仕様や設計の誤りを見つけるというよりは、「文書として標準に則っているか」をやたらと丁寧に確認する、どちらかといえばセレモニー的なレビュー形態だと思い込んでいた。

　まったく違った。
　先日記事を書いたSQiPワークショップで、それを学んできた。

　インスペクションのパワーを、長くなるので次の3点に分けて書きたい。
　（そんなに長く読みたくないでしょうが・・・！）

　このワークショップは、1つのドキュメントに対して「普通の」レビュー（アドホックレビュー）とインスペクションを行い、身を持ってその差を実感する、という流れで進められた。

　実際やってみると、アドホックでそれなりに指摘を出したと思っていても、その後に行ったインスペクションで、さらに多くの指摘が追加される。これはなかなか不思議な体験だ。

　ただ、注意すべき点として、単純に効率だけ見ると、インスペクションの効率は必ずしも高くなかった。はっきりいって、時間あたりの指摘件数は、アドホックの方が高く出がちだろう。

　では、効率を追求するために、インスペクションをやめて、その時間をアドホックの延長に使えば、同じ効率で指摘が挙がるか？というところがポイントだ。
　ある時間枠での効率は、あくまでもその時点でのもの。一般には、時間を重ねればそれだけ効率は下がり、0に漸近するだろう。

　インスペクションに期待されるのは、効果の方。Efficiency Vs Effectivenessってヤツだ。実際、インスペクションで挙がった指摘は、アドホックのものとは切り口の違うものが多くなる。

　一方で、とにかく忙しくなりがちな現場で受け入れられ難い理由も、ここにあるのだと思う。効率が、やはり先に立つ。
　アドホックもインスペクションも、ともに長所があって、それを組み合わせることが肝要なのだろう。インスペクションの導入には、その「効果」の側面を理解してもらう必要がありそうだ。