「設計者の発言」さんの「ユーザがなかなか仕様を決めてくれないって？」をとても興味深く読みました。
「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。（略）問題はどちらかといえば設計者の側にある。
で始まるこのエントリでは、設計者がユーザの反応を見ながら提案内容をどんどん修正し最終案としてまとめるという、「インタラクティブなやりとり」が必要という主張がされています。
ただ、この話は仕様決めと要件定義をごちゃまぜにしている部分があるように思います。たしかに実際に作業を進める上では、この二つがフェーズとして重なることもよくあります。ただ、少なくともエンジニアの頭の中では明確に切り分ける必要があると思っています。
そして、このエントリで言われる「インタラクティブなやりとり」が必要になるのはどちらかというと要件定義の時です。ユーザの目的に沿ったシステムをイメージしてもらうためにラフなシステムのイメージを描いては捨てながら、だんだんと具体化していくのはたしかに要件定義で有効な方法だと思います。
一方で、仕様決めでは実は答えは決まっています。仕様決めの最終的なアウトプットとして必要なのはシステムが作れるレベルまで具体化されたスペックです。
「オンラインで支払いまで完了できるようにしたい」というのが要件で、「OKを押したら支払い画面へ行きます」「キャンセルのときはTop画面へ戻ります」「入力不備の際は再度入力画面へ移動します。入力不備の条件はhogehogeです」というのが仕様です。そして、これをやるにはMVCでこうやってhogeって・・・というのが設計です。
なので、実は仕様のアウトプットの正確な姿を一番よく知っているのはエンジニアなのです。お客さんは何がわかればシステムが作れるのかは知りません。だからこそエンジニアが必要なわけです。
この辺りの課題を解決するのには「仕様の仕様」を提示するのがいいかなと思っています。「自分が必要としているアウトプットはこのレベルです。」というのをユーザーに提示して穴埋め問題式で仕様を決めてもらうのです。「○○のときは××である」というのをずらーっと並べて一つ一つ詰めていくことになるのですが、この一覧をそのままユーザーに突きつけるのは不親切なので、頭の中の一覧を一つ一つわかりやすい表現で確認していくのがいいようです。
「○○が××になるのはどんなときですか？」「じゃあ、△△のときはこうなるんでしょうか？」「□□のときは●●ですかね？」といったかんじで実装できるレベルまで仕様を詰めていくわけです。（繰り返しになりますが、話の中では要件と仕様と設計の話が行ったり来たりしがちなので、自分の頭の中ではきっちりとラベルを貼って今どんな話をしているか判別する必要があります。）
これをやらずに「ユーザーが仕様をきっちり出してこない！」と憤慨するのはエンジニアの怠慢かスキル不足なのだと思うのですよ。（誰に言ってんだか）
