なぜ顧客は受入テストで仕様変更に気がつけるのか？
ただ、ここで最近の興味の対象となるのは、「なぜ顧客は仕様を分かっている（だからテストでは指摘ができる）のにそれを完全に正確に伝えられないのだろう？」というもの。言い換えると、「顧客は欲しいシステムの必要な動作を本当は知っている。仕様を決めている時点でそれを正確に引き出すにはどんなサポートができるのだろう？」という疑問だ。
http://blog.hacklife.net/archives/50737557.html
これに対して「本気度の違い」「ドキュメントで書けることの限界」「網羅性の違い」といった答えが、何人かの方から返されていて、僕もこれらの答えには基本的に賛成だということを言っておく。その上で、普段から感じている、もう少し「テクニカル」な要因について、ちょっと書いてみたい。
僕がなんらかの画面を設計して、ユーザーを招いて検証のためのワークショップを開くとしよう。プロジェクト進行上、今回のワークショップが仕様確定のデッドラインであることが周知されている。そのため、ユーザーも本気だ。僕のナイスな人柄のおかげでユーザーとの信頼関係もバッチリだ。僕は技術者として最大限の誠意をもって、画面の各項目の意味、チェック条件、画面の流れ、業務処理の条件（入力した請求書にもとづく支払がいつ実行されるのか）などを詳細に説明する。ユーザーはシステムの動作についてわからない点は念入りに質問し、十分理解できた。さて、これで、ユーザーはそのシステム仕様が適切かどうか判断できるだろうか。あるいは判断できるとすれば、何を根拠に判断できるのだろうか。
あたりまえの話だが、そのシステム仕様で業務がうまく回るならシステム仕様は適切といえるし、その判断がつかなければ、システム仕様がそれで良いのかわからないということになる。つまり、ユーザーが実際に良し悪しを判断できる対象は、システム仕様そのものではなく、そのシステム仕様をもとにして予想される業務の仕組みだ。
状況を整理しよう。ユーザーはシステム仕様を検証することを求められている。一方、彼女が本当に検証できるのは業務の仕組みでしかない。
ところが、システム仕様は明確に定義されていても、そのシステム機能を適用する業務の仕様はモヤッとしている、という状況が結構ふつうにあるのだ。
たとえば、僕が設計しているのが、支払処理のための「請求書入力」画面だとしよう。しかし、請求書と一口に言っても、試作用の部品の購入に関する請求書、事務用品の購入に関する請求書、接待に使った飲み屋からの請求書、等色々あって、起票担当部署や請求のタイミング、会計処理上の必要項目も一通りではすまない（たとえば、源泉徴収対象の取引なら源泉徴収額が必要だとか）。また、同じ取引であっても業務分担の仕方に依存して、必要なシステム機能は異なる。たとえば請求書を入力するのが、外勤者か内勤者か、一般事務職か経理担当者か、といった違いで、望ましい画面設計は異なるかもしれない。
だから、システム仕様を検証するには、まずは、そのシステム機能をどの業務（取引）に対して適用するのかを明確にしなければならない。さらに、それらの業務ごとに、必要データや、取引件数、タイミング、役割分担、といったことを整理する。その上ではじめて、そのシステム仕様で本当に業務が回るのか判定することができる。
すなわち、システム仕様の検証は、業務の設計に関するこうした検証の一環として行なうべきものだ。請求書の例でわかるように、システム機能と業務は必ずしも一対一に対応しないので、両者を区別して考えることがなおさら重要だ（逆に、特定の「業務」にしか適用されないシステム機能であれば、そんなに厳格に両者を区別する必要は無い）。
問題は、多くのプロジェクトで、こうした業務設計検証が不十分にしか行なわれていない点にある。開発側としては、検証はユーザー側の責任だと考え、作業の中身には立ち入らずに、答え（承認）だけを要求する。ユーザー側はこういった作業に慣れていないので、秩序だった検証作業を実行する代わりに、何人かのキーパーソンに確認しただけでOKを出す。尋ねられたキーパーソンも実は自分が何についてOKを出したのか、正確にはわかっていなかったりする（「そういう意味でOKしたんじゃないよ！」）。結果として業務設計にはもやもやとした部分が残ったままだが、システム仕様は明確なので、開発は問題なく進んでいく。受入れテストの段階で実データを使って実業務をシミュレートしようとすると、問題が露見する。
僕としては、解決の糸口は、業務設計検証のプロセスを「見える化」することだと考えている。ユーザー視点から、業務（取引）を何パターンかに分類し、表を作ってみる。表には、業務（取引）ごとに担当部署や必要データ、業務の流れや、その他、役立ちそうなことを何でも書き込んでみる。現行業務に不明な点があれば洗い出し、わかる人に問い合わせる（「すべてを知っているユーザー」はふつう存在しないので、これは特に重要だ）。表のたたき台ができたら、開発側もユーザー側も参加するウォークスルーで検討し、疑問点をつぶしていく。業務のパターンの分け方もどんどん見直していく。
業務はユーザーにしかわからないし口を出せないと考えるのは大きな誤りで、こういった形で見える化すれば、それほど業務に詳しくない開発側のメンバーも「健全な素人」の視点から異見を提起し、新業務の設計に貢献できる。また業務の内容はともあれ知識を整理（見える化）することにかけては、プロジェクトタイプの仕事の経験を積んだ開発側メンバーの方が手馴れているものだ。
だから、このプロセスはユーザー側と開発側の共同作業として実行することが適切なのだ。もちろん最後に仕様を承認する責任はユーザー側にある。しかし、だからといって、そこに到る過程が共同作業であっていけない理由はない。
すべての業務について四角四面にこんなやり方を適用する必要は無いが、仕様決定にあたってユーザー側に迷いや戸惑いが見えたら、試してみてはどうだろうか。
実際に効果があるし、何よりもユーザー側と開発側の間に仲間意識が育まれ、仕事が楽しくなる（あるいはつらさが少しましになる）。
