その「プログラム設計書」が何を指してるのかわからないから土壇場で混乱する

上の方々の記事を読んで、その「プログラム設計書」って何なんだろうと思ったわけで…。

例えば、契約が「プログラム設計書一式によりプログラムを製造する」みたいなのだとしますよね。

でも、そのプログラム設計書はクラス図+シーケンス図みたいなものなのか、一つのまとまった処理…バッチ処理とかユーザイベントとかgetリクエストとかの入力に対するDBとか画面への出力を示したものなのか、内部変数とか内部ループのブレイク条件とかも示したものなのか、よくわからない*1。だから、受け取る段階になって混乱する。よくある話じゃないですか。

正直なところ、「プログラム設計書」と呼ぶそれらの書類が何でもいいんですよ。どーせ古今東西千差万別何でもありだし。ただし、その書類の記載内容によって仕事の責任範囲…つまり時間と金とモノが左右されることだけは、皆さんにわかって頂きたいです。

荒い記述なら細部を詰める仕事がある、細かい記述なら細部は詰めなくてもいいが、構造が限定されて効率が落ちるかもしれない。読解に時間がかかったり…つまり意味不明だったり、矛盾があれば付き返す。もちろん、返ってくるまでは別の仕事を埋めなきゃならない。だから、どんな呼び名の書類だろうと、現物を見ないと見積もりも出来ないんです。本当は。

ただ、システム設計者ならソースくらい読め、とは思いますけどね。書かなくてもいい、せめて読んでくれるようになれば…。読み方くらい、幾らでも説明するのになぁ。

いやしかし、

元請さんがどの位の手厚さで仕事をしようと、どちらでもいいってのが正直なところです。レビューが面倒なら、レビュー対応工数を積むまでです。本当は。
後手に「アレもやる、コレも必要」っての、いい加減にやめてほしいですけどね。

…って、毎度愚痴っぽくてすいません＞＜

結局、○○設計書ってなんなの？

(,,ﾟДﾟ)＜ドキュメントで何とかしようとしているのはみんな要求定義の一部だ。
　　　　　システム開発の設計書はソースコードである。
■ - ( ・ω・)ノ＜しすてむ開発。

設計書という書類はシステムの実装のために存在する、それなら要件定義じゃないか。という意見。これが一番しっくりくる意見です。

*1:「ほとんどプログラムと対応するようなロジックが記述されているようなもの」と言われても、俺としては「よくわからない、見せてほしい」と聞きたいところです。