Charlie's volatile short

うちの会社はモックを作って顧客に仕様レビューをお願いしてますが、仕様バグを「ほとんどなくす」ことはできてないです。

極力ユニットテストを書かずに品質を確保する方法 @ ひがやすを blog

また、最初にユーザに実際に動かしてもらっているので、開発者が、仕様を勘違いするという「仕様バグ」をほとんどなくすことができます。

(2009-01-12追記) 以下、モックレビューでは問題が生じる原因を分析。「Programming First Development」はモックレビューとは似て非なる良いもののようですが、導入にはいろいろとハードルがあるようです。

...

大きめのシステムだと、顧客側のレビュアが自分達で決めた仕様を忘れていることがある → チェック洩れが発生

自主事業用のWebアプリ的な開発スタンスだと「レビューで使っているうちに思い出せないようなマイナー機能は後付けで構わない。当初の仕様と違っても影響は小さい。」といった感じで優先順位を付ける。
一方、請負開発だと顧客側の価値基準の軸がしっかりしてない・共有されてないことも多い。欲しい機能はたくさん、でもそれはニーズ分析の結果ではなくて開発依頼主の思い付きが並べてあるだけ。そうすると優先順位が付けられない、あるいは客観的には奇妙に思える順位付けをする。そういう開発プロジェクトも何度か経験した。
「Programming First Development」だと、実装しながら仕様を固めていくことになっている。理想ではあるが、これに対応できる契約形態を顧客が許してくれるかという根本で疑問が残る。細かい仕様を決める前段階で相見積りとか可能なのか? 契約時に確定していない、後から出てきた仕様は全部対応しないと契約違反なのか? 拒否できる（拒否しても裁判で認められるような客観的な）基準は存在するのか? 詳しい人、教えてちょ。

モックでは、一般的でないケースのチェックができない

モックは本物の「代表的なケース」を真似ているハリボテ。問題が起こるのは一般的でないケースの方が多く、モックでは検証できない。だから、本番コードで動くシステムを顧客にレビューしてもらって初めて判明する仕様の問題が結構あって、その時点で仕様を修正すると設計のコアな部分に手戻りが発生したりする。
残念ながらこれはProgramming Firstでも根本的な解消にはならないだろう。メリットがあるとしたら、Test Firstより少し早く顧客レビューが始められるので、手戻りへの許容度が若干増すこと。
Programming Firstから外れるが、うちの開発で考慮が足りないと思ったのは「本番コードを書き始めた時の仕様では例外的なケースまで考慮されていないことが多い＝本番システムをレビューして仕様確定するまでは、見えているルールだけでモデルを単純化してはダメ」とい う点。
でも、完全に汎用に作っていったら最後にどんなにリファクタしても性能要件を満たさなくなる恐れがあるので、モデル化が不要という話ではない。例外的なケースが仕様に盛りこまれていなかったら、単純化出来る方に都合よく思い込まず、むしろ逆にできるだけ突飛で共通化しにくいケースまで想定してすぐに顧客に確認すべき。幾つかのケースを想定して、対応にかかるコストを見積もっておけば、顧客と仕様を詰める時にお互いのためになる（顧客は、仕様とコストの対応を提示してもらった方が妥当な判断をしやすい）。