要求と仕様と実装

要求はふわっとしている。時間とともに変わりすらする。顧客もよく理解していない。
仕様はカチッとしている。曖昧さがあるべきではない。更新しないかぎり変わらない。ただし解釈は人により変わりうる。
実装は動かない。その挙動がバグか機能かはユーザーが決める。解釈系によって挙動が変わるかもしれないが、解釈系が決まれば挙動は決まる。

仕様そして実装は、ふわっとしていて、絶えず変化する要求に柔軟に対応しなければならない。要求のうち変化しうるものはなるべく実装の上で吸収されるべきであろう。
当初のユーザーが1名だったからといって、1名と決め打ちした仕様にしてしまうと、2名以上のユーザーが発生したときに大幅な仕様変更を伴うかもしれない。
決めるべきは、どこが変化するか。どのように変化するか。
自由変数が多く、自由度が高いほど、工数は増えるであろう。

ファミコンのゲームなどは、一旦発売したら変更は容易ではない。バグはそのままバグあるいは裏技あるいは機能としてゲームの一部となってしまう。
なんでもできるようにすると、パターンが爆発的に増え、デバッグが困難になる。いかにユーザーの行動を制限するかが勝負かもしれない。パッケージソフトには特定の(うるさい)顧客がいるわけではないので、ユーザーの行動をある意味好きなように制限できる。特定の顧客に向けたソフトではそうはいかない。顧客はなるべく安いコストで、なるべく多くのことができるよう要求する。ここをいかにコントロールできるかが、優れたSEの能力ということになろう。

仕様の必要性

仕様とはなにか。

1. 顧客の要求をヒアリングし、メモしたノート
2. 1.を分析し、必要な機能を書き下した書類
3. 2.をさらに分析し、機能を実装するための詳細な仕様を記述した書類
4. 3.をもとにした実装

1.の場合、これをもとに実装したら人によっていろいろなものができうる。顧客が満足するものもあれば、幻滅するものもあろう。少なくとも、「こういうものを作ります」といったもう少し詳細な書類が必要そうだ。おそらくこれは要求定義書のこと。
2.の場合、顧客にとってわかりやすい書類でなければならない。全てを詳細に記述することはできないので、なるべく顧客との齟齬が生じないように、かつ簡潔に記述しなければならない。おそらくこれは要件定義書と呼ばれるもの。
3.は基本設計書から詳細設計書に相当するものであろう。原則ここからは社内文書。複数人数開発や引き継ぎのことを考えると、このレベルの設計書はやはり必要なのであろう。
4.は言うまでもないが、これ以上ない仕様とも言えよう。挙動が知りたければソースを見ればよい。

仕様は顧客の要求と実装をつなぐもの。1.＜仕様＜4.であろうことは間違いない。ここには要件定義書、基本設計書、詳細設計書などといった、複数の候補が存在する。これらをまとめて仕様というのだろうか？顧客の要求は変化する。実装は動かない。仕様そして実装は、顧客の変化しうる要求を全て吸収しなければならないか？そんなことができるとすれば、その仕様には「人間」が含まれているかもしれない。

要求そのものが変化すれば、要件定義書以下の仕様、実装はすべて変化または拡張する。要求は変わらず、顧客が受け入れないとしたらそれは、要求を正しく分析できていないか、実装が要件を満たしていない。あるいは、要件が要求を満たしていない。要件定義を顧客が受け入れているのに実装を受け入れない場合、実装が要件を満たしているのであれば、要件と要求の関連を顧客が理解していない。

プログラマーにできること

プログラマー(私)は、仕様書のようなものを作るのを嫌がる。仕様書は本来プログラマーの作るものではないと考えているからだ。顧客の要求や不完全な要件定義を見て、自分なりに解釈し、自分の都合のいいように実装し、突き返す。そうなるのは、そこに曖昧さがあるからだ。
プログラマーが求めるのは、曖昧さのない、誰かがメンテナンスしてくれる仕様書である。ある意味、本当のソースコードはその仕様書である。
そんなものは、見たことがない。近いものはあるが、詳細は決めなければいけないことも多い。そこで我々プログラマーができるのは、テストを書くことだ。仕様書のごとくテストを書く。これは実装と剥離することがない。
お気づきだろうか。本当のソースコード＝テストなのである。テストをいかにわかりやすく書けるか、なんならSE、営業、顧客の人間が読めるかによっては、テスト＝仕様書＝ソースコードという理想の形に近づくのではないか。

結論。あなたの言語のテストフレームワークを完全に理解し、テストを書け（はい）。