QI（Quality Inspection）ってすごい！
QI（Quality Inspection）に興味をもった理由
Hiroyanです。こんばんは。
最近結構いろんな雑誌や会誌等が送られてきているんですけど、「忙しい」の名のもとに読むことが出来なくなっていることが多く、家のテーブルの上には、読み切れていない本や、雑誌などがてんこ盛りです。
今日はいろいろ思うところがあり（これはまた別に書いてみようと思います。）ちょっと読んでみることにしました。
読んだのは情報処理学会の学会誌（9月号）とSoftwareDesignの8月号です。で、どちらも読んで衝撃を受けました。今回は特にSoftwareDesignでとりあげられていたQI（Quality Inspection、以下QIと略します。）が従来のレビューやインスペクションと比べて現実的、かつ有効性の高い手法だと感じましたので、紹介したいと思います。
ただし、私自身は、QIを実践したわけではないので、有効性を説明できる立場ではないのですが、調べた範囲で動機付けにつながればいいかと思っています。
QIってなに？
QIとは、会議形式のレビューやインスペクションを行うというのは非常に効果はあるものの時間や労力がかかり、非常に難しいという問題に対して、レビュー実施前に各種のメトリクスデータを用いて成果物を分析し、成果物に含まれていることが予想される欠陥を想定しておき、その点を集中してレビューしていく方法ということになります。
このメトリクスについてもいろんなものがあるのですが、記事の中では測定に関する負荷の小さいものを進めています。たとえば、ファイルの更新日付が挙げられます。これを見ていくことによって、深夜の作業などであれば、コミュニケーション不全による他の成果物との整合性の不備や、ケアレスミスなどが考えられるなどがあげられるわけです。
従来のインスペクション技法とQIの違い
今まで、インスペクションについては、1999年のTom Glibによる「ソフトウェアインスペクション」を読んだきりでした。この中では、インスペクション技法が詳しく述べられています。
インスペクションはいくつかのフェーズにわけ、チェックリストに従いじっくりと成果物を検査し、欠陥の検出を中心に行っていくこと。欠陥をすべて検出することに重点が置かれていました。この内容も当時はレビューによる欠陥検出の効率には疑問を持っていた私にとっては目からうろこの内容でした。
ところがこのインスペクションというのは、どうにもコストがかかってしまうために、実際に導入しようとすると不退転の決意で強制するくらいに進めていかないと現場の理解を得にくいという問題がありました。コストがかかるというのは、たとえば1時間に1ページ程度のチェックとある程度速度に対する制限を設けていることなどに起因しています。
そのためこれを何とかするための工夫が必要になります。私の場合は、成果物は単一の観点（チェック項目）で全体を短時間に検査する。これを観点の数くり返すといったやり方にカスタマイズしています。
ここら辺は本編とはずれちゃうので、割愛しますが従来のインスペクションは効果は高いもののコストがかかり、メンバーからの理解を得にくいというのが、印象でした。
QIは事前に成果物をいくつかの測定負荷の高くないメトリクスで評価し、成果物の欠陥について傾向分析をおおないます。そののちポイントを絞った成果物評価を行うという考え方のようです。そのため、インスペクションにあるようなコストの問題についても絞り込んでいるという点でだいぶ軽減されてきます。
また、この方法の素晴らしいのは、測定結果と分析のポイントを形式知として整理することが可能な点です。これが出来ることで、直接参画している人間でなくても成果物の検証が可能です。インスペクションでも挙げられているんですけど、チェックリストによる検査と比較すると、傾向分析を含めたこのやり方は非常に効率的であることが期待できます。
最後に
Tom Glibのソフトウェアインスペクションは自分の持っている本の中でもお気に入りの一冊で、仕事の中ではこの考え方を参考にいろいろと考えていました。
やはり問題になるのは「確かにすごそうだが、現場には許容しがたい」という点が挙げられます。この中ではその点についてもいろいろかかれていて、導入推進をしようとしている人までは理解されるのでしょうが、あまねく人に理解を受けるにはもっと、現実的なやり方に工夫が必要になります。
自分なりにはいろいろと工夫をしてみたのですが、なかなかに難しいと思っていました。
QIのアプローチを見た時に、「あ、そうか！」って思ってしまいました。このノウハウを蓄積するのは大変ですし、この記事を書かれているIBMの細川氏はなみなみならない努力をされているのだろうと思いますした。
最近、自分は、将来ソフトウェアはさらに複雑性が増していであろうと確信しています。しかし、時間や人の制約はある中でこれを満たそうとするとテストなどの品質保証、および設計が相対的に大きなウェイトを占めていくようになります。
設計については効率的な再利用技術、品質保証に関しては、これらのアプローチが必須と考えており、この組み合わせは絶対に必要になると思っています。あわせて、わかりやすさや、現実的にできるかといった点が重視されるのかなって思っています。
ずいぶん長々と書いてしまいましたが、これからもQIについては追いかけていきたいし、やってみたいなと思います。
（参考）
仕様書をチェックしてソフトウェアの欠陥を予防する ――日本アイ・ビー・エム サービス事業 品質技術 細川宣啓氏に聞く｜Tech Village （テックビレッジ） ／ CQ出版株式会社
日本アイ・ビー・エムでは，ソフトウェアの欠陥を検出するために，「Quality Inspection」と名づけた手法を（組み込み機器開発の部署も含めて）実践している．これは，仕様書を熟視して矛盾や不整 …
