アカウント名:
パスワード:
この手の議論は昔からあるが、設計書になにをどう記載すべきかの統一的な基準がない。基本設計書、概要設計書、外部設計書など同じレイヤのドキュメントの呼び名すら統一されていない。
プログラムとはプログラミング言語で表現された数式である。ドキュメントとして数式を自然言語で表現する必要性は本質的にはない。なぜなら自然言語には解釈の余地が存在するので、厳密に数式へ変換することは困難だからだ。ドキュメントに厳密さや正確さを求めるのは、不完全性定理への挑戦にも似ている気がする。
しかし現実にはドキュメントは必要だ。IT業界には数式で思考できないダメなプログラマや、そもそもプログラムの書けないエスイーまで、本来そこにいるべきでない多くの人と協調して働く必要がある。注文主であるエンドユーザも技術には無縁であることが多い。これらの関係者を納得させ、プロジェクトを回していくためにドキュメントが役立つのだ。たいていのIT屋やプロジェクトでは、良くてもこのレベルでしかドキュメントを使用していない。そういうわけでドキュメントは、必要を満たす程度のものを最小限の手間で作成することが重要である。
タレコミ主がもっと大きなプロジェクトを統括する立場になれば、要件定義から試験までを紐づけることで、機能や試験の網羅性を(ある程度)担保できるようになるだろう。本来、ドキュメントはこうした使い方をすべきである。そのためには各レベルのドキュメントの定義と一貫性を担保し、マネジメントしていく必要があるが、残念ながらマジメにこれに取り組んでいるところを私は知らない。私自身もそこまでできていない。せめてプロジェクトに文書管理担当をおければ…
このストーリーについたコメントを読むと設計書要らない派の人は「自分には不要なドキュメント」のことを「設計書」と呼んでいるのではないかという気がしてきました……。
設計書=プログラム設計書って思っている人が不要っていってる様に思えるね。
必要って言ってる人は、基本設計書や詳細設計書が必要って言っていて(自分もその立場)、目的としている物が違うんだからかみ合わないのが当たり前。
後、関わっているプロジェクトの規模もあると思うけど、1千万程度ぐらいまでのプロジェクトだったら、個人レベルでどうにでもなるから設計書を書かなくてもなんとなく回るけど、数千万とか億単位の規模になってくると関わってくる人員も多くなってくるし、タスクの割り当てとかも考えないとならないから設計書を書かなくて進めるなんてありえないんだけどね。
不要って言っている人は「設計書は不要だが要求仕様書は必要」と言っていてさらに「要求仕様は客が作るもの」とも言っているんで、基本設計書や詳細設計書は客が作るものとは考えにくいのでもっと意識の乖離があるように思えます。
直前の見積もりのストーリーといい、これといい、ソフトウェア業界のお粗末さを表してますなぁ。設計書とは何かと言うことすら統一できていないのに、ユーザがまともな仕様書を出さないって愚痴っても無駄だよね。そういうのは自分たちの業界で定義して、ユーザにこれこれを出して下さいってフォーマットを提供しなきゃ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
"設計書"の定義があいまいなのだ (スコア:2)
この手の議論は昔からあるが、設計書になにをどう記載すべきかの統一的な基準がない。
基本設計書、概要設計書、外部設計書など同じレイヤのドキュメントの呼び名すら統一されていない。
プログラムとはプログラミング言語で表現された数式である。
ドキュメントとして数式を自然言語で表現する必要性は本質的にはない。
なぜなら自然言語には解釈の余地が存在するので、厳密に数式へ変換することは困難だからだ。
ドキュメントに厳密さや正確さを求めるのは、不完全性定理への挑戦にも似ている気がする。
しかし現実にはドキュメントは必要だ。
IT業界には数式で思考できないダメなプログラマや、そもそもプログラムの書けないエスイーまで、
本来そこにいるべきでない多くの人と協調して働く必要がある。
注文主であるエンドユーザも技術には無縁であることが多い。
これらの関係者を納得させ、プロジェクトを回していくためにドキュメントが役立つのだ。
たいていのIT屋やプロジェクトでは、良くてもこのレベルでしかドキュメントを使用していない。
そういうわけでドキュメントは、必要を満たす程度のものを最小限の手間で作成することが重要である。
タレコミ主がもっと大きなプロジェクトを統括する立場になれば、要件定義から試験までを紐づけることで、
機能や試験の網羅性を(ある程度)担保できるようになるだろう。
本来、ドキュメントはこうした使い方をすべきである。
そのためには各レベルのドキュメントの定義と一貫性を担保し、マネジメントしていく必要があるが、
残念ながらマジメにこれに取り組んでいるところを私は知らない。
私自身もそこまでできていない。せめてプロジェクトに文書管理担当をおければ…
Re: (スコア:0)
このストーリーについたコメントを読むと設計書要らない派の人は「自分には不要なドキュメント」のことを「設計書」と呼んでいるのではないかという気がしてきました……。
Re: (スコア:0)
設計書=プログラム設計書って思っている人が不要っていってる様に思えるね。
必要って言ってる人は、基本設計書や詳細設計書が必要って言っていて(自分もその立場)、目的としている物が違うんだからかみ合わないのが当たり前。
後、関わっているプロジェクトの規模もあると思うけど、1千万程度ぐらいまでのプロジェクトだったら、個人レベルでどうにでもなるから設計書を書かなくてもなんとなく回るけど、数千万とか億単位の規模になってくると関わってくる人員も多くなってくるし、タスクの割り当てとかも考えないとならないから設計書を書かなくて進めるなんてありえないんだけどね。
Re: (スコア:0)
不要って言っている人は「設計書は不要だが要求仕様書は必要」と言っていてさらに「要求仕様は客が作るもの」とも言っているんで、
基本設計書や詳細設計書は客が作るものとは考えにくいのでもっと意識の乖離があるように思えます。
Re: (スコア:0)
直前の見積もりのストーリーといい、これといい、ソフトウェア業界のお粗末さを表してますなぁ。
設計書とは何かと言うことすら統一できていないのに、ユーザがまともな仕様書を出さないって愚痴っても無駄だよね。
そういうのは自分たちの業界で定義して、ユーザにこれこれを出して下さいってフォーマットを提供しなきゃ。