IGINブルネイ/syasudaの日記(MT版)

要求仕様にまつわるエトセトラを書き連ねた良い本があります。

これはかなり古い本なので、表現などに問題があります。たとえば、「あばずれ」などというようなコトバが出てきます。

要求仕様にあながある、もっと簡単な理由もあります。

それは要求仕様をまとめた人は、要求仕様の定義のプロではないからです。

例えばある人は、システムの要求仕様とは、ユーザが定義するものだと言います。

システムを構築する人は、要求仕様の稚拙さにうんざりし、あるいは自分のしらない業務ドメインの用語に四苦八苦し、こんなことを言います。

この要求仕様書はだめだめだ。

矛盾だらけで、意味の分からない単語が書いてある。

そもそも、なんで機能Aが必要なのかサッパリ分からない。

機能Bで機能Aをかねればいいんじゃないか？

そして膨大なQ&A表を作り、ユーザの時間を食いつぶすのです。

ある人は要求定義は、ユーザからのヒアリング結果を元に、システム開発側が定めるものだとしてこんなことを言います。

ユーザの意見はコロコロ変わる。

前の担当者が言っていたのは機能Aは必須で機能Bはオプションだった。ところが今の担当者は機能Bも必須であるという。これでは要件定義どころではない。

別の人は、要求仕様書をもとに、実装仕様書をまとめて承認を受ければよいと言います。

運用試験の段階になって、実装仕様書にない機能が実装漏れと指摘されても困る。

提出した実装仕様書をきちんとチェックしなかったユーザが悪いのだから、対応はもちろん予算は別見積もりだ。

ユーザは多くの場合、自分の競合他社と戦う前に、自分が雇った開発会社と闘うハメに陥ります。

つまづきの最初の一歩は、要件定義、つまり要求仕様を決めるところですでに始まっています。

そうかといって、移り変わる現実社会で、最初にすべてを決めて金科玉条となすのは、それも間抜けな結果をもたらします。

要件定義の本質は、ユーザと開発の価値観の共有を達成・維持するためのプロセスそのものかもしれません。

いいなりでもだめ、できない理由の大合唱でもだめ。