続：顧客テストにはあって、仕様決めのときにはないもの

はい。ちょっと説明があいまいでした。補足します。

「受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。」の部分がちょっと理解しきれなかったのですが、仕様と実装アプリの動作にずれが出ているという内容かな。そして、それをコミュニケーションですり合せている。と。（違うかも）文脈的に「この仕様は正しいと判断できるのだと思う。」の部分に掛かる理由にもなっているはずですし、もうちょっと突っ込んで聞いてみたい内容です。

お客さまといえども、受け入れテストを仕様書だけから落とし込もうとすることは稀で、開発チームとのコミュニケーションで決めたアンドキュメントな細かい仕様や、開発途中のアプリケーションをさわって気が付いた、UIの仕様などがトータルで盛り込まれる。お客さまにとって、システムのトータルな満足度は、こういう細かい仕様も含めて判断される。ぼくはそういう仕様が最終的には正しいと評価される思っている。(とはいっても、仕様書を真面目に書かなくてもいい、とか、ビジネスの基幹部分ですら簡単に変更して良い、とは思わない。それではプロマネとして進捗やリスクを管理できない。)
そもそも、新規のプロジェクトの場合（特に新サービスの場合）は、お客様からして、「どんどん走りながら徐々に仕様をブラッシュアップしていこう」という戦略を採ってくる。つまり、最初から本気なんだけども、あえて詳細化を避けている。要求はそんなにぶれてはまずいけど、細かい仕様はぶれても、というか変わっても良い。という考えを持っている。
繰り返し型の開発プロセスは、そもそもこのような考え方を認め、さらに加速する。

最後に、ぼくもtanabeさんと同様、仕様決め時に意識すると効果的だと思っているのは網羅性だ。
仕様というのは、クラス的な（構造的な）記述になりがちだが、受け入れテストはインスタンス的に（べたに、泥臭く）実施される（結果的に網羅性が高くなる）だから、仕様決めの段階でも、できるだけ具体的にインスタンスベースの話をできるとより良い。テストのパターンを網羅することを意識しながら仕様を詰めている。