3/9の話の続き。
ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている（だからテストでは指摘ができる）のにそれを完全に正確に伝えられないのだろう？」というもの。（略）「顧客テストにはあって、仕様決めのときにはないものはなんだろう？」「その本質的な違いはどこにあるんだろう？」
顧客テストと仕様決めでの本質的な違いは「網羅性」なんじゃないか。そう思ってる。
仕様決めのときはお互い想定で進んでいる部分があって、要は詰めが甘い。顧客テストになると実際に動くものができているので、隅から隅まで動かせる。わかってるようでわかってない部分とか、なんとなくこれで大丈夫と思ってたような部分での問題が全部表面化するのではないか？
その視点だと Goya の UI スケッチだとか、あるいは他の宗派の同系統手法でもいいけど、手法を真似るだけじゃなくてそれによって何をやらないといけないかが明確に見えてくる気がする。
たとえば、こんなものが見落とされているはずなので重点的にチェックする。
- 状態によって変わる動作（想定されるすべての状態について検討したか）
- そのあり得る組み合わせとしての操作ストーリー
- 条件が false の場合のすべての動作
- 条件の網羅性（条件を満たさないものにはどんなものがあって、それらは本当に条件に含まれなくても正しいのか）
上記を見ると当然確認しているべきものでもあって、レベルの低い話になってしまっているのだけど、それでも実際漏れるのは「当然であるはずのところ」から抜け漏れが出てしまっている。当然のことをより意識して都度気にしながら確認できる仕組みが必要。（少なくともぼくには）
上記を考えるにあたって、顧客テストと仕様決めの時点で何が違うかを考えてみたので併せて公開しておく。
| 仕様決め | 顧客テスト | |
|---|---|---|
| (時間軸上の)タイミング | 情報少ない（？） | 情報多い（？） |
| 顧客の求められる役割 | ”お客さん” | 最後の門番 |
| 検証物 | 仕様書（定型ドキュメント、図、モデルなど） | 動作するプログラムそのもの |
それぞれに少しずつ意見があって、結局網羅性に行き着いている。
- (時間軸上の)タイミング
本当に顧客の得られる情報量が変化しているケースは仕方がないが、そうでもないケースもよく見かける。これは仕様決めの時点では顧客は何らかの理由での細部まで調査確認をする必要がないと判断しているのでは？では、その理由は？ - 顧客の求められる役割
そもそもの顧客の態度自体が違う？だとすればなぜ？それは私がコントロールできる？また、仕様決め時点なりに真剣に検討しているようでも、顧客の頭の中では想定外の（望んでいる動作と違う）動きが顧客テスト時に発見されることもある。なぜ想定外の動きだったんだろう？ - 検証物
仕様書が「顧客の想定している使い方のケース」をすべて網羅していれば、理屈上プログラムはそれを実装しただけのはず。プログラムが顧客に見せられるものと同じものを仕様書として見せられるのでは？今仕様書からは漏れ、プログラムでは顧客が気が付けるものがあるとすれば、それは単に仕様書がそれについて正確に言及していないか、顧客がそれを見落としているのではないか？
最後の方は思考過程を丸投げしているようなエントリになってしまったけれど、「いかに仕様化するか？」というのが最近のテーマだったので良い機会だし文章にしてみた。
