「要求仕様の探検学」その２

フィーリングが事実であり、しかも重要な事実である、とあなたが考えないなら、次のような質問を自分に投げかけてみるとよい。なぜ顧客は、しばしば、訴えられたり、違約金を支払うリスクを冒してまで、不満足な製品に対する契約を破棄するのか？そして、なぜ将来の製品の供給業者を変更するのか？

ブラックボックス作業は延期してはならない。目標を達成するメカニズムを考え始めてしまうと、その効力はなくなってしまうからだ。このような場合、システム試験は、そのメカニズムが物事を正しく行っているかどうか（設計及び実装の試験）を試験するという罠に陥ってしまい、メカニズムが正しい物事を行っているかどうか（要件の試験）には目が向かなくなってしまう。

そうではなくて、解を与える段階でではなく、問題を定義する段階で、ブラックボックス試験をしなければならない。特に、クライアントが何をしたいのかということを、どのようにしてそれを行うかということにかかわりなく、理解しようとしなければならない。

”チームは日曜日も休まずに働くが、要件作業は決して終わらない。”ある種の仮定の定義は、設計者、構築者、及び顧客に残されるのがつねである。しかし、あなたは、ある仮定は他の人が定義するように残しておくという、メタ仮定を文書化しておくことができる。

全ての仮定を意識に上らせること。そうすれば、開発プロセスが進むにつれてそれらを制御できるようになる。

凍結というアイディアは、幕引きの恐れを手なづけるために考案された幻想にすぎない。しかし、私たちは、必要なら再交渉プロセスがあるということを知っていなければ、恐怖を覚えることなしに要件フェーズを閉めることはできない。

不完全であるというおそれによって、無限サイクルに陥ることがあるから、要件プロセスを終了させることに特に注意を払うこと。

作業に参画した人すべてから終了したことの合意を取り付けること。そうしなければ、彼らはいつまでも変更することを止めない。再交渉プロセスを約束すれば、彼らは合意するだろう。

要件作業を終わらせることは本を終わらせること、特に要件定義のような開かれた主題の本を終わらせることに似ている。あなたはもっと言うことを持っているが、朝にコンマをとり、夕べにそれを戻すようなことをしているのに、自分で気づくときがくる。その時点で、あるアイディアを不完全のまま残し、ある啓示は見えないまま残しておきリスクをただ受け入れるのだ。文書化された資料が失われていないことを確認し、勇気を集め、そして止めるのである。