要求と仕様と理由

清水吉男さんというコンサルの受け売りなのだが、要求と仕様と理由は3点セットとして仕様書に記述するべきだと思う。
まず、要求と仕様がごっちゃになっている仕様書が結構多い。
3点セットにすることによって要求と仕様が明確に区別されるようになる。
で、重要なのは理由である。
ステップとしてはまず要求をヒアリングし、なぜそのようにしたいかという理由をヒアリングし、それをもとに仕様を決める。
理由が真の要求であることが多いため、理由をヒアリングすることによって仕様もれを防ぐことができる。
設計者にとっても理由を知ることによって仕様の行間がつかめて設計、実装ミスを防ぐことができる。

実際に私が遭遇した例をあげてみる。
データ更新画面の更新ボタンにチェック機能を追加し、引っかかった場合は警告ダイアログを出すことになった。で、OKボタンをクリックした場合は更新するということになった。
この画面は元々、他にもチェック機能があり、それに引っかかった場合は警告ではなくエラーダイアログを出して処理を終了させるようになっている。
チェックをパスした場合のみ、「更新しますか？」という確認ダイアログが出てくる。
なので、てっきり警告ダイアログも確認ダイアログの前に出すものだと思っていたら、仕様は確認ダイアログの後に出すというものだった。
理由を聞いたところ、オペレータが現在のオペレーションに慣れてしまっており、かつ確認ダイアログでキャンセルすることもほとんどない。
そのため、警告ダイアログを先に出しても条件反射的にOKボタンをクリックしてしまう。それから確認ダイアログが出てくると「え、さっきのは何？」となってしまう。
よって、確認ダイアログ後に警告ダイアログを出せば「お、なんだ？」と気づいてもらえる。
とのことだった。
「なるほどなあ」と思った。
実は、ダイアログの順番も、もちろんその理由も仕様書には記載されていなかった。
念のためと思ってSEに確認したところ、順番の間違いとその理由を教えてもらった。
「理由を書く」という意識を持っていれば、順番の仕様も明確に書いたかも知れない。
残念ながらその意識がないためにあいまいな仕様となりそこに行間が生まれ、設計、実装ミスにつながる。
腹立たしいのがそのようなケースでお客の要望を満たせなかった場合、設計、実装側のバグとみなされることが非常に多いということ。
お客からすれば原因が仕様だろうと実装だろうとバグはバグだろうが、SIerにとってみれば本来反省するべき人が反省しないわけで根本原因は解決されず、また同じ問題を引き起こすことになってしまう。
で、「プログラマーのみなさん、あいまいな箇所はSEにきちんと確認しましょう」ってことになるのだろうが、あいまいなことを書いている方に問題があるわけであって、プログラマー側の問題ではない。
また、SEに確認するということは当のSEも自分の作業を中断されるわけだし、確認する側も余計な時間を使うということでお互いにとって不幸である。

どんどん話がずれていったが、ようは書くべきものは適切な時にきちんと書きましょうということ。
書くべきときに書かないと、そのことが借金になってしまい利子がふくらんでいき、いざ返済（対応）しようとするととても払えない（対応できない）ことになる。