「リーンソフトウェア開発」P219から。
システムが、顧客の意図どおり動くことを確認するテストは「顧客テスト」という名前で呼んだ方がよい。それは、テストの目的が、顧客がシステムに期待したとおりシステムが動くことを確かめるためだからである。
そう。そのとおりだ。そして、本書ではその顧客テストを短いサイクルタイムで複数回を行うことでリスクを軽減するというアプローチを取る。
その主張も正しい。一つの解決策として非常に参考になる。
だけど、ここで一つ大きな疑問がある。顧客はなぜ「顧客テスト」をするとしっかり仕様の漏れ、ミスを発見できるんだろう？
ちょうど今日もそうだった。すでにシステムはリリース間近。まさに「顧客テスト」が行われていた。そして発覚した仕様の漏れ。
その対応自体はけっきょく事なきを得たのでここで話題にはしないけれど、不思議なのはその仕様はけして「ビジネス環境の変化」で昨日今日浮上したなんてものではなくて、当初にレビューをしている時点で分かっていて然るべき内容だった。
これは結論から言ってしまえば仕様のヒアリング漏れであり、端的には「しっかりやれ自分」てところに反省点は行き着く。それはデブサミの羽生さんの名言「仕様変更なんてないんです」を持ち出すまでもなく、そのとおり。そう考えないと前進しないし。
ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている（だからテストでは指摘ができる）のにそれを完全に正確に伝えられないのだろう？」というもの。言い換えると、「顧客は欲しいシステムの必要な動作を本当は知っている。仕様を決めている時点でそれを正確に引き出すにはどんなサポートができるのだろう？」という疑問だ。
さらに質問形式を続けると、「顧客テストにはあって、仕様決めのときにはないものはなんだろう？」「その本質的な違いはどこにあるんだろう？」
リーンソフトウェア開発で述べられている「動くものを提供する」というのもたしかに「顧客テスト」を早めるという意味で有効なサポートになりそうだ。
でも、目下抱いている疑問への直接の解答にはならないんだよな。
自分の今の仮説も明日さらすつもりだけど、まずは読んでくれた方、ご意見など頂けるととてもうれしいです。
ちなみに「仕様変更なんてないんです」の意味については、こことかこことか参照。
日経BP社 (2004/07/23)
売り上げランキング: 59630
