プログラムの品質は問われるが仕様書の品質が問題になることは、ない。
なぜか?
仕様書は発注側が書き、プログラムは受注側が作るから。
そもそも、どんなシステムを作りたいのかが(仕様)が曖昧なら、それを受けて作る側は途方に暮れてしまう。それでも納期があるから、何とか形を整える。しかし魂の入っていないシステムは使いにくい。その結果プログラムの問題にされる。プログラムは仕様書を具現化したものだから、本来の責めは仕様書を書いた発注側が追わねばならないと思うのだが。
プログラムの品質は問われるが仕様書の品質が問題になることは、ない。
なぜか?
仕様書は発注側が書き、プログラムは受注側が作るから。
そもそも、どんなシステムを作りたいのかが(仕様)が曖昧なら、それを受けて作る側は途方に暮れてしまう。それでも納期があるから、何とか形を整える。しかし魂の入っていないシステムは使いにくい。その結果プログラムの問題にされる。プログラムは仕様書を具現化したものだから、本来の責めは仕様書を書いた発注側が追わねばならないと思うのだが。
①やりたいことが不明確のまま、付和雷同でブームに乗って無理矢理纏めた仕様
②要不要、軽重問わず、アレもコレもと何時誰がどんな場面で使うか分からない機能のてんこ盛りの仕様
③時間がないので走りながら考えれば良いというもっともらしい論法で適当に纏めた仕様
④現場を知らないエリートがお座なりのヒアリングを元に机上で纏めた仕様
⑤社長の鶴の一声で決まった仕様
⑥全体のシナリオなく局所的に最適化された仕様
・・・・まだ沢山ありますが、いずれも仕様とは言えないものです。ま、しようがない?
しかし、この様なことは現実の世界で沢山経験しています。特に、自治体(特に電子自治体関係)、病院(特に電子カルテ)はヒドイとこれらを経験してきた私は思います。
もちろん客のためを思ってする喧嘩ですから、正々堂々とやりたいですね。
私もsugiさんを見習いたいです。