今期は、上流工程におけるレビュー強化が重点課題なので、以前読んだ記事を再読。

ソフトウェア・テスト PRESS Vol.2
	技術評論社 技術評論社 2005-12-01 売り上げランキング : 12054 おすすめ平均 今さら・・・・・、の知識 Amazonで詳しく見る by G-Tools

 この記事は、本当に良いと思うんですよね。

欠陥の分類方法として、「IEEE Std. 1044, IEEE Standard Classification for Software Anomalies」というのがあるそうですが、ググってみても本文まではなかなか見つかりませんでした。残念。

一番センスを感じたのが、品質を健康に例えたくだり。
・どちらも単位がない
・どちらも複数の代替特性で表現（例：血糖値の値だけで健康とは言えない）
・追求しすぎはない（健康すぎるという完全な状況はない。普遍の完了基準はない）
・・・

さて、インスペクションとは何か。記事にはわかりやすい図が載っていますが、www.rsch.tuis.ac.jp/~tamaki/software_engineering/Chap_18.pdf
にやや近い図があります。
ようするに、一番フォーマルで一番コストもかかるが、一番欠陥検出効果が高いレビュー方法ということです。
その他の解説としては、
ウォークスルーの進め方
もよいでしょうか。

そしてその中でも手法はいろいろあるようで、「パースペクティブ・ベース・インスペクション」（参加者が利害関係者になりきって、それぞれの立場・観点から検証する）、「パスアラウンド法」（招集するのではなく、成果物を複数担当者に送付・回覧して、複数のフィードバックを受ける）が紹介されています。

最後にテクニックもいくつか挙げられていますが、これらも納得です。
・事実を指摘
・まず全体像を把握せよ、微細欠陥にこだわるな
・欠陥数を追跡しない、欠陥の種類を追跡する
など。

なお、別記事「三色ボールペンで読む仕様書」も活用したらよいかもですね。
・赤：客観的に見て、最も重要な箇所
・青：客観的に見て、まあ重要な箇所
・緑：主観的に見て、おかしいと感じた個所