先日書いたコードレビューの道具、使っていますか?の森崎先生主催のhttp://se.aist-nara.ac.jp/events/siw2009.htmlに行ってきました。
日本初のインスペクションに関するセミナーということで60名枠に114人応募。かなり盛況だった。
いろんな会社の人が来ていたのだが、レビューしていない人やちゃんとレビューできていない人が多くてびっくりした。
アンケートの質問でも「レビューで指摘すると文句を言われ困ってます」とか「レビューしても自分の評価にならない」とか
そういう質問があって、みんなどうやって品質担保してるんだろうと非常に謎だった。やはりテストで品質担保ということなのか?
もしくは品質は無視なのか?そういや以前まあまあ有名な某社を第三者インスペクションしたことがあるけど結構酷かった。内部レビュー一切していないようなものだらけだった。そりゃ不安になるって。
第三者インスペクションによる品質確保と欠陥予防 日本IBM細川宣啓さん
細川さんかなり面白い。
「楽しくやる」ということと「安心」というのが私が常々思っていることと見事に一致してて非常に共感。
- インスペクションは20年前から大きく変化していない技術。
- つまり10年後も陳腐化しない息の長い技術として習得すべきもの。
- 一段高く(抽象化)することが大切。問題の本質は何かを必ず伝えること。どうしてこのようになったのかが大切。これが無い限り現象のみを捕えてて、問題の本質を捕らえていることにはならない*1
- 悪いところを明らかにする。
- インスペクションが形式的になってしまっていてよくない。もっとカジュアルに
- 開発も検査もワイワイやる
- 細かいことは気にしない。そこはツールで自働化。
- 年200のレビューをこなす
- スピードが大切*2
- 若手も早くからインスペクションに参加させる*3
- 伝える技術。
- 事実として伝える。
- XXが有る、無い。
- 抽出して伝える
- 事実として伝える。
- インスペクションは工程の早い段階で
- 事前に通知する
持ち時間がとても短く残念だった。もっとたくさん話を聞きたい。彼が話すなら是非ききにいこう。
ハンズオン
あるWEBシステムの要件定義書とソースが配布され、セキュリティ観点でそれをレビュー。
以下の様な3つの方法でおのおのレビューしその後結果を擦り合わせる内容でした。
- 観点のみを与えられやり方は各人お任せの「Adhoc」
- ツリー状の検査ロジックに従いチェックしていく「SGIT(Secure Goal Indicator Tree)」
- チェックリストに従いチェックしていく「GC(Guided Checklists)」
本来なら各やり方による指摘の差異等を議論したかったのですが、他参加者とレベルが在ってないのと議論時間がとても短く意見を交わすレベルにならなくて残念だった。
また、ハンズオンのアンケートでも「いつもより量が多い」という意見が2/3近くありインスペクションは出来る人と出来ない人の差が非常に大きいのだなと実感した。
参考
日本科学技術連盟
↑細川さんの「サービス・プロジェクトにおける品質・コスト・納期の相互相関分析」が非常に面白いので一見の価値有りです。
仕様書をチェックしてソフトウェアの欠陥を予防する ――日本アイ・ビー・エム サービス事業 品質技術 細川宣啓氏に聞く|Tech Village (テックビレッジ) / CQ出版株式会社
http://thinkit.jp/article/857/1/