アカウント名:
パスワード:
このコメントの人が、「仕様書」と「設計書」という言葉を混同して使っているのが気になりました。仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
あと、特定のポイントに関する仕様or設計（元コメのvalidation規則などの）は必要でしょうが、だからといって、プログラムの処理全体を網羅的に文書化することが必要かどうかは別問題でしょう。このあたりの認識の違いで、ソースのコメントで十分かどうかの意見が分かれたりしているのでは。
個人的には、仕様書は必要、設計書はテーブル設計書くらいは欲しいかな。
仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
そういうカテゴライズも、一般的かどうかは微妙ですね。 あるソフトウェアを作るための設計のアウトプットのドキュメントを「設計書」と言うなら、外部仕様書だって要件定義書だって設計書です。 「仕様書は書くけど設計書は書かない」と「要件定義書は書くけど詳細設計書は書かない」では、意味の伝わり具合にかなりの温度差があります。
あとから作られたものは「（作るための）設計書」なんかじゃなく「（できあがったものの）仕様書」なんでしょう。それはあっていいかなと思う。自動生成でもなんでも。
設計書と仕様書が別の意味の言葉であるというのは業界標準なのでしょうか。詳細仕様書という言葉はふつうに使ってそうですが…
英語で言ってみてくれ。
specificationとdesignとかそういうこと？
参考までに、どっちをどっちに割り当ててんの？
> 仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
そんなのはプロジェクト次第ですよ。しかも要件定義も請求書ベースにあるならば、仕様書に含めないですし、そのほか、画面仕様書、テスト仕様書などもあるでしょう。
> だからといって、プログラムの処理全体を網羅的に文書化することが必要かどうかは別問題でしょう。
そうですね。プロジェクト次第ですね。ソースレビューと議事録とレビュー書を納品することもありますし。
納品物としてはプロジェクト次第ではあるけど、作業工程としては、仕様と設計は分けて考えないと、責任分解や検収が難しくなる。一番困るのは、何を納品物とするかはプロジェクト次第なのに、無批判に前例踏襲されることだけど。
# COBOLを前提とした仕様書に合わせて、iOSアプリの仕様を書いても何の役にも立たない
私が関わっているプロジェクトだと 要件・要望書…………………ユーザが書く 要件定義………………………ユーザ企業SEが書いてユーザがレビューと承認 概要(外部)設計書……………ベンダSEが書いてユーザ企業SEがレビュー、ユーザ承認 詳細(内部)設計～結合試験…ユーザ側完全ノータッチですね(承認は簡略してますが）。その後の試験工程からまた関与しますが。
例えるなら寿司職人が客になに食いたいか訊いたり提案するのも彼らの仕事であるように、客の要求をきちんとまとめて要求仕様書を作るってのもエンジニアの仕事となり得るよ。そもそも客の要求が曖昧なんだと愚痴垂れるくらいなら、こちらからきちんと訊けば良い。受け身の姿勢で客の言いなりになるのは当たり前。
それでコンサル料貰えればいいんだけどね……金出してもらえない工程は端折るしかないじゃない。
受け入れテストを普通はします。外注してれば普通はします。
官公庁ですらしますよ
その為にSIerがいるんでしょ。マシな会社ではシステム部門が出してくるよ。
曖昧な仕様を明確にするのが開発側の仕事の一つと認識しております。
> 作ってくれって言われたやつを作ってるんだから、発注元が仕様書を作るべきなんだよね。
家を建てる時、発注元が仕様書は作らないでしょう？
例えばどこの業界だと発注元が仕様書を作るのが常識になってんの？
そういうレベルの話なの？設計ってのは、なぜその実装を選んだのか、なぜその状態遷移を選んだのか、なぜそのリレーション構造を選んだのかといった、要求仕様とコードの間を埋めるものだろ。
validationだったら、個々の項目なんてレベルじゃなくて、HTML5標準でやるよ、とかプラグイン使うよということと、”なぜ”そうしたのかを書くためのものだろ。
自分は設計書には何をしたかを書いて、コードには何をしていないか（添え字のチェックが緩いとか）を書いている。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
若いのう (スコア:4, 参考になる)
あと若いうちは「設計書なんかいらねぇ！」って言えるかもしれませんが、
年取ると（よぼよぼ・・）記憶力が衰えて１年前に自分の作ったものも忘れちゃう。
ヤングでもとある文字列の validation規則なんて聞いても答えられない。
なので仕様書は小さなプロジェクトでもまず「自分のために」書く。
役に立つ仕様書を速やかに書けないというのなら単に能力が不足しているだけで、それを棚に上げて仕様書という道具のせいにしちゃいけない。
Re:若いのう (スコア:3, 興味深い)
このコメントの人が、「仕様書」と「設計書」という言葉を混同して使っているのが気になりました。
仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
あと、特定のポイントに関する仕様or設計（元コメのvalidation規則などの）は必要でしょうが、
だからといって、プログラムの処理全体を網羅的に文書化することが必要かどうかは別問題でしょう。
このあたりの認識の違いで、ソースのコメントで十分かどうかの意見が分かれたりしているのでは。
個人的には、仕様書は必要、設計書はテーブル設計書くらいは欲しいかな。
Re: (スコア:0)
そういうカテゴライズも、一般的かどうかは微妙ですね。 あるソフトウェアを作るための設計のアウトプットのドキュメントを「設計書」と言うなら、外部仕様書だって要件定義書だって設計書です。 「仕様書は書くけど設計書は書かない」と「要件定義書は書くけど詳細設計書は書かない」では、意味の伝わり具合にかなりの温度差があります。
Re: (スコア:0)
あとから作られたものは「（作るための）設計書」なんかじゃなく「（できあがったものの）仕様書」なんでしょう。
それはあっていいかなと思う。自動生成でもなんでも。
Re: (スコア:0)
設計書と仕様書が別の意味の言葉であるというのは業界標準なのでしょうか。
詳細仕様書という言葉はふつうに使ってそうですが…
Re: (スコア:0)
英語で言ってみてくれ。
Re: (スコア:0)
specificationとdesignとかそういうこと？
Re: (スコア:0)
参考までに、どっちをどっちに割り当ててんの？
Re: (スコア:0)
> 仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
そんなのはプロジェクト次第ですよ。
しかも要件定義も請求書ベースにあるならば、仕様書に含めないですし、
そのほか、画面仕様書、テスト仕様書などもあるでしょう。
> だからといって、プログラムの処理全体を網羅的に文書化することが必要かどうかは別問題でしょう。
そうですね。プロジェクト次第ですね。ソースレビューと議事録とレビュー書を納品することもありますし。
Re: (スコア:0)
納品物としてはプロジェクト次第ではあるけど、
作業工程としては、仕様と設計は分けて考えないと、責任分解や検収が難しくなる。
一番困るのは、何を納品物とするかはプロジェクト次第なのに、無批判に前例踏襲されることだけど。
# COBOLを前提とした仕様書に合わせて、iOSアプリの仕様を書いても何の役にも立たない
Re:若いのう (スコア:1)
テストケースも。このテストが出来たら合格とすると。
客の要求が曖昧っていうのがこの業界の癌なんだよな。
Re:若いのう (スコア:1)
私が関わっているプロジェクトだと
要件・要望書…………………ユーザが書く
要件定義………………………ユーザ企業SEが書いてユーザがレビューと承認
概要(外部)設計書……………ベンダSEが書いてユーザ企業SEがレビュー、ユーザ承認
詳細(内部)設計～結合試験…ユーザ側完全ノータッチ
ですね(承認は簡略してますが）。
その後の試験工程からまた関与しますが。
Re:若いのう (スコア:1)
タレコミみたいな問題も起きなそう。
Re: (スコア:0)
例えるなら寿司職人が客になに食いたいか訊いたり提案するのも彼らの仕事であるように、
客の要求をきちんとまとめて要求仕様書を作るってのもエンジニアの仕事となり得るよ。
そもそも客の要求が曖昧なんだと愚痴垂れるくらいなら、こちらからきちんと訊けば良い。
受け身の姿勢で客の言いなりになるのは当たり前。
Re: (スコア:0)
それでコンサル料貰えればいいんだけどね……
金出してもらえない工程は端折るしかないじゃない。
Re: (スコア:0)
受け入れテストを普通はします。
外注してれば普通はします。
官公庁ですらしますよ
Re: (スコア:0)
その為にSIerがいるんでしょ。マシな会社ではシステム部門が出してくるよ。
Re: (スコア:0)
曖昧な仕様を明確にするのが開発側の仕事の一つと認識しております。
Re: (スコア:0)
> 作ってくれって言われたやつを作ってるんだから、発注元が仕様書を作るべきなんだよね。
家を建てる時、発注元が仕様書は作らないでしょう？
Re: (スコア:0)
例えばどこの業界だと発注元が仕様書を作るのが常識になってんの？
Re: (スコア:0)
そういうレベルの話なの？
設計ってのは、なぜその実装を選んだのか、なぜその状態遷移を選んだのか、なぜそのリレーション構造を選んだのか
といった、要求仕様とコードの間を埋めるものだろ。
validationだったら、個々の項目なんてレベルじゃなくて、HTML5標準でやるよ、とかプラグイン使うよということと、
”なぜ”そうしたのかを書くためのものだろ。
自分は設計書には何をしたかを書いて、コードには何をしていないか（添え字のチェックが緩いとか）を書いている。
Re:若いのう (スコア:2)