3/9のエントリについて、いくつか言及を頂いたので紹介。ちなみに私自身の考えはこちら。
違いは何か。実ははっきりしています。「本気度」です。いつでも変更できますよ、というステータスだと、必死で詳細まで見ないのです。ここで決めたことがリリースされるのだ、となった途端に急に詳細まで考え抜くようになります。〆切重要。
もうすぐ春だよはぶにっき [仕事]仕様の確認方法
僕はもともと、ドキュメントじゃ確認できる内容には限界あるから、使ってもらって判断してもらう、ということには同意できたんだけど、使ってもらってであっても、本気度が足りないと全然フィードバックが受けられないというのも現実で。
m_pixyの読書日記 [dev][RD]お客様の本気度
いきなり真打登場という感があるのですが、「本気度」。たしかにこれはあります。なんで本気にならないんでしょうね？やっぱり締切りなんでしょうか。
一方で「本気になって仕様を検討するときに何をどう見ればわからない」というのはある気がしています。ユーザーの人は業務のプロではあるけれどシステム仕様を書くプロではないので。じゃ、誰がプロかっていうとやっぱりシステム作る人になるんじゃないかと。
ユーザーが本気になって仕様を確認したときに、動作するプログラムと紙の仕様書（ガチガチのもアジャイルなのも含めて広い意味での仕様を記した何かしらのもの）のギャップはどこに残るのか？（残らないのか？）が新たな疑問。
スタロジ流だと限りなく「残らない」に近いスタンスですね。残るけど、それは紙では実現不可能な部分という。
そうか。たしかにここまで割り切ってしまえば残りの部分（見えてないと仮定できる部分）の見通しはかなりよくなるなぁ。少し前進した感あり。ありがとうございます。
このズレが重いな。だから、ユーザを巻き込めという話になるのか。XPやなんかでも言われてるけど、このこと自体は開発方法論には関係しないはず。ただ、方法論としてユーザを巻き込むということを明示しているからアジャイルはイイ！って話になってるのかと思ったり。
m_pixyの読書日記 [dev][job]ユーザが本気になるタイミングと、開発側が本気になるタイミング
「リーンソフトウェア開発」を読んでいて私もこれを感じました。単純に開発サイクルが短いというのは強制的に巻き込む機会が増えるな、と。（厳密には「方法論としてユーザを巻き込むということを明示」の指されている話とは少し違いますが、言いたいところは近い。はず。）
最後に頂いたトラックバックから。
ぼくは「仕様決めのときになくて、顧客テストのときにある」のは「動くアプリケーション」と「それまでのコミュニケーションで培ってきた信頼関係」だと思う。受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。その上で、実際に動くアプリケーションを使って検証するから、この仕様は正しいと判断できるのだと思う。
TECH-moratorium ： テクモラトリアム [SD]顧客テストにはあって、仕様決めのときにはないもの
なるほど。たしかに丸っきり初対面から始めたようなプロジェクトだと仕様決めるにしても「空気を読みつつ」みたいなところはありますね。（身に覚えあり。その態度を反省した覚えもあり。）
「受け入れテストといえど、純粋に仕様から落とし込むというよりは、できあがってきたアプリケーションの動作を開発チームとのコミュニケーションを通じてすり合わせられている。」の部分がちょっと理解しきれなかったのですが、仕様と実装アプリの動作にずれが出ているという内容かな。そして、それをコミュニケーションですり合せている。と。（違うかも）文脈的に「この仕様は正しいと判断できるのだと思う。」の部分に掛かる理由にもなっているはずですし、もうちょっと突っ込んで聞いてみたい内容です。
あと、「動くアプリケーション」というのはなんだかんだ言ってやっぱり強いですね。Ruby まつもとさんの「ソースがドキュメントだ。 バグも完全に記述されている」ではないですが、たしかに仕様の誤り・漏れも含めてすべて実装されているというのは強いです。あとはそれを作るのはタダじゃないというコストの問題ですか。
最後のオチとしては、
逆に、お付き合いが長かったり、そのシステムに専念できるお客さまだったり、既存システムのリプレース案件の場合は、仕様決めの段階できっちりと詰めるアプローチが有効だと思う。特に、仕様のほとんどが計算式な金融系のシステムなんかはそうだろう。重要な仕様は事前に十分に検証でき、結果的にリスクも下がると思う。
にど真ん中で当てはまる案件をやっているにも関わらず、こんな問題提起をしている自分が居たり。やっぱ単なる本人の力不足か！
