アカウント名:
パスワード:
コレまで見た仕様書は大抵異常系の動作仕様が不完全でかなりの量が未定義なんだよね。まぁ、全挙動を自然言語で書くくらいなら俺が書くってのはその通りかもしれんけど。
いや、海外どころか近所に出すときでもそのすべての定義は必要なのだが、実際には空気を呼んでくれって感じの仕様書で出してしまう会社が多い。そうなるとどうなるか、って言えば、一項目ごとに確認をしないと実装の方向が決められない。つまり全然仕様としては纏まっていないって事が多々あるって事。
そういうのが、全てを指示しないといけないって思いになるのだろうが、そりゃ大抵発注側の問題。
だいたい、仕様で全てを網羅すれば実装するよりも時間がかかるのって当たり前の話じゃないか。ちゃんとしたプロジェクトなら仕様策定は全段階から入
そうなんだよねー、別にオフショアに限った話じゃなくて、外部に発注するなら本当はそれ相応の仕様書(または権限)を渡すべきなのに、日本企業は(この事例だとアメリカでも?)発注側も受注側もなあなあの仕様書でどうにかやっちゃうから、それでなんとなくOKなように勘違いしちゃうんだよねぇ。
「いちいち説明するなら自分で作った方が早い」なんて当たり前の事で言い訳となると思っているのなら、 相当にまともな仕様策定が出来ていないのだろうな、としか思えない。
ただ、昨今ウォーターフォールで全部の仕様を出し切るのは無理だ、という理論でアジャイルがもてはやされていることから判るとおり、実際に何かしら作ってみないと、万全の仕様書なんてそうそう用意できないと思うのですよね。 (小さなプログラムや、同じようなものを大量生産するならともかく。) そういう風に考えると、事前にきちんとした仕様書を用意して後はアウトソース、ってビジネスモデル自体がソフトウェア開発には向いて無いんじゃないかなぁ、という気がします。
# Skypeとかで要件定義からアジャイル的に参加してもらえば成り立つのかな?でも距離的密接さも重要なポイントだったような・・・?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
1~10まで書いてない仕様書が悪い (スコア:0)
コレまで見た仕様書は大抵異常系の動作仕様が不完全でかなりの量が未定義なんだよね。まぁ、全挙動を自然言語で書くくらいなら俺が書くってのはその通りかもしれんけど。
Re: (スコア:0)
いや、海外どころか近所に出すときでもそのすべての定義は必要なのだが、実際には空気を呼んでくれって感じの仕様書で出してしまう会社が多い。
そうなるとどうなるか、って言えば、一項目ごとに確認をしないと実装の方向が決められない。
つまり全然仕様としては纏まっていないって事が多々あるって事。
そういうのが、全てを指示しないといけないって思いになるのだろうが、そりゃ大抵発注側の問題。
だいたい、仕様で全てを網羅すれば実装するよりも時間がかかるのって当たり前の話じゃないか。
ちゃんとしたプロジェクトなら仕様策定は全段階から入
Re:1~10まで書いてない仕様書が悪い (スコア:0)
そうなんだよねー、別にオフショアに限った話じゃなくて、外部に発注するなら本当はそれ相応の仕様書(または権限)を渡すべきなのに、日本企業は(この事例だとアメリカでも?)発注側も受注側もなあなあの仕様書でどうにかやっちゃうから、それでなんとなくOKなように勘違いしちゃうんだよねぇ。
「いちいち説明するなら自分で作った方が早い」なんて当たり前の事で言い訳となると思っているのなら、 相当にまともな仕様策定が出来ていないのだろうな、としか思えない。
ただ、昨今ウォーターフォールで全部の仕様を出し切るのは無理だ、という理論でアジャイルがもてはやされていることから判るとおり、実際に何かしら作ってみないと、万全の仕様書なんてそうそう用意できないと思うのですよね。
(小さなプログラムや、同じようなものを大量生産するならともかく。)
そういう風に考えると、事前にきちんとした仕様書を用意して後はアウトソース、ってビジネスモデル自体がソフトウェア開発には向いて無いんじゃないかなぁ、という気がします。
# Skypeとかで要件定義からアジャイル的に参加してもらえば成り立つのかな?でも距離的密接さも重要なポイントだったような・・・?