アジャイルインスペクション
本エントリはオルタナティブブログの2008/9/8で公開したものを一部改変したものである。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
インスペクション、レビューの大家Tom Gilb氏による基調講演"Agile Inspections: reviews by sampling and measuring defects"を、9/4, 5に東洋大で開催されたソフトウェア品質シンポジウム2008で聞いた。詳細はSQiPコミュニティのWebページの「SQiPシンポジウム」をご覧いただきたい。
通常、インスペクションの目的はドキュメントやソースコード等の（中間）成果物を精査することにより、テストよりも早い段階（プログラムが動きはじめる前）で欠陥や矛盾をみつけることにある。一般には早い段階でみつけられた不具合のほうが修正にかかるコストが低いといわれており、工期の短縮やコスト低減につながる。
アジャイルインスペクションの目的は、インスペクションの目的である欠陥の早期発見とは異なり、サンプリングによる品質推定にあるそうだ。ドキュメントやコードの一部をインスペクションし、その一部に含まれる欠陥を計測することで、全体の品質を推測する。その際、欠陥をいくつかに分類する。計測対象はmajor defectという分類で、プログラムの不具合の原因となり得るものである。単純な誤字脱字などはmajor defectに入らない。
また、出荷時の品質を"exit level"とし、要求仕様1ページあたり1件のmajor defectをexit levelを参考値として説明されていた。また、曖昧な要求仕様を書くことを防ぐためにGilb氏が推進しているplanguageについても言及があり、これによりexit levelを高めることができることを事例を用いて説明されていた。
講演を聞く限りでは、"1ページ"、"1件"、"major defect"とかなり曖昧なので計測方法によっては結果が大きく異なってしまいそうな気がした。また、要求仕様1ページあたりで1件の欠陥は実感としてなんとも大きな値のような気がする。ここでの要求仕様は要求の中でも比較的設計よりのドキュメントではないかと推測している。おそらく外部設計のほうが適切なのではないかと思っている（講演や講演資料には"requirements"とある）。
プロジェクトの早い段階で品質が推測できれば、プロジェクトのスコープ変更やスケジュール変更ができる。早い段階で多くの欠陥をみつけるのと同じくらい価値があるだろう。
