手戻りを防ぐには

「変化ヲ抱擁」できないこともある。
テストが完璧に終わったと思ってた後の変更は実に痛い。要件や仕様の変更は仕方ないとして、こちらの勘違い、ヒアリング漏れや想定が甘かった場合には、対応しないわけにはいかないからだ。
手戻りを100％防ぐ方法はないが、なるべく手戻りを防ぐようなヒアリングやレビューのテクニックというかやり方の肝はある。

目に見えるたたき台が必要

良く仕様がわかってないうちは、いろいろ細かい質問点はあるだろうけど、まずは全体感を掴むためにたたき台となるものが必要。それはモックアップだったり、UIスケッチだったりする。当たり前の話をしているようだけど、土台となるものがないと話が細かくなりすぎて、脳みそ置いてけぼり状態になることがある。細かいQAを繰り返す前にしっかり土台を作っておくこと。

事前に細かく考えておくこと

同時に、内部の振る舞いについてはできるだけ細かく考えておく、特に状態の遷移が複雑な機能に関しては、荒めのシーケンス図やステートチャート図を書くこと。パターンが多い機能の場合は、分類するためにクラス図を簡単に書く。（ただしこれらをお客さまに見せる必要はない。ざっと書けば良い）
そして、結果的にこれらの分析結果がお客様が求める仕様とはずれてしまっても別に構わない。事前に細かく考えておくだけで議論が随分かみ合う。

期待する結果で聞く

画面の振る舞いをレビューする時は、お客さまが「期待する値や動き」はこれですよね？といった質問をしよう。要はテスト駆動だ。
また、質問内容やたとえ話は、できるだけ具体的にべたべたな用語を使うと良い。

項目単位に目的を確認する

画面や帳票全体に関しては当たり前の話だが、それぞれの項目単位でも目的（どのようにその項目を使いますか？）を確認しよう。
例えば、「期中累計」という項目があったとして、その項目の仕様はいくらかパターンがあって、例えば期初からの累計全てなのか、期初から当月までの累計なのか、期初からの特定の月までの累計なのか、、などといった具合。これを最終的に決めるのはシステムを利用するお客さまであって、聞き方としては「この累計は、期初から例えば今だったら6月までの合計額を見たいですか？」などといってお話をする。項目なんて単にテーブルの1フィールドだ、なんて考えていると後で痛い目にあう。

忘れないうちに議事録

別に「言った・言わない」を防ぐためだけではない、お客さまも含め人間って忘れっぽいものなのだ。議事録でも仕様書でもなんでも構わないが、レビュー結果はすぐに2次記録に退避しよう。

また、以下は手戻りを招く不吉な匂い。

例外ケースが多すぎる

正常ケースはあらかた理解したなと思っていても例外ケースにつまずくケースも多い。例外ケースが多すぎる仕様・設計は、そもそもの目的をはずしていると思ったほうがよい。「通常はありえないんだけど、これこれ、こういう場合は、こんな感じにして欲しい」などといった要求が多すぎる場合、そのうちいくつかの例外的な仕様は漏れて結果的に手戻りになる可能性が高い。最初から別の機能として実現したほうが良い場合もある。

何でもできる機能の追加

時として、「root権限だからなんでも出来る機能を追加しよう」なんてこともあるが、これは複雑で結果的に手戻りが多い仕様を招くことがある。なんでもできる、ということは状態遷移モデルを壊してしまうことであり、ある機能で存在を前提としているデータを変更・削除してしまうことである。このような機能が必要なら、最初っからその前提でしっかり検討しなくてはいけない。