アカウント名:
パスワード:
でしょ。 だって、文化も言語も違う人にホイと渡せば寸分違わず希望通りのモノができてくるなんて事は有り得ない。 もし有り得るとすれば、何も給料寄越せだの飯食わせろだのウルサイ人間様なんぞに渡さないで、コンパイラなりジェ
また、物理的なモノを作るのは人件費以外の(部材費など)コストもかかるが、プログラムのコンパイル/ジェネレートには電気代以外金はかからない。 だから物理的な
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
オフショアって (スコア:3, 興味深い)
なんでも、海外に外注してもいい加減な製品しか出来てこない場合が多々あったり、(時給換算でのコストは米国内よりも破格に低コストだが)開発に異様に手間取ってそれほど安くならないケースがあったりで、最近は海外の国内のどちらに出すか、ケースバイケースで考える方
Re:オフショアって (スコア:5, 参考になる)
きっちりとした外部設計書が国内で作れれば内部設計、開発、テストのフェーズを中国で行うのはわりと容易です。ちゃんと瑕疵対応も要求できるし、仕様変更にも柔軟に対応してもらいました。
日本のお客様を相手にしている以上、要件定義や外部設計作業自体は国内で行う必要があると思います。画面設計やデータ構造設計など、根本的で固まるまでに多くの打ち合わせが必要な作業は、海を越えて行う方がコスト高になるからです。
コストが安いので多くの技術者を投入して短期開発なんてことも出
Re:オフショアって (スコア:0)
つまり、オフショア開発は極めて限定的なプロジェクトを除いて
現実的ではない、ということですね。
システムは生き物であって仕様変更が無い事なんて有り得ませんから。
Re:オフショアって (スコア:1)
>つまり、オフショア開発は極めて限定的なプロジェクトを除いて
>現実的ではない、ということですね。
いや、まあ程度の問題とちゃいますかね。
海外に発注するときは、言語の壁があるからコミュニケーションが
とりにくい。それに比べれば、国内の人とやりとりするほうが、
まだやりやすい。
作業するほうからすれば、設計の変更は無いほうが良いに決まってる
けど、海外に発注するときは、そこにいっそう気を使う必要がある、
ということでしょう。
プロジェクトの作業のうち、開発中に仕様変更が発生しにくそうな
部分のみ海外の開発者に頼む、とかすれば良いんじゃないでしょうか。
Re:オフショアって (スコア:1)
安く作ろうと発注者が思わないなら、わざわざ外国で作る必要はないのですよ。
ひざを突き合せるのに比べて難のあるコミュニケーション環境で頑張ってでも安くしたいなら、そのための努力は発注者にも上流工程を請けたSIerにも必要です。
その一環としてより精度の高い設計書が必要ということです。100%完璧な設計書なんて作れないのは承知の上です。
ゆるい部分が有るなら影響範囲を限定して多めに見積るしかないのです。せっかく安くしようとしているのに高くなる要因を排除しきれないのはもったいないですよ。
Re:オフショアって (スコア:0)
ウォーターフォール型、強いて言えば上記の条件があってブリッジSEがしっかりしていればスパイル型の開発でも有効。
どちらかと言うとwebシステムを短期で仕上げる、顧客と膝詰めで毎日リリースし
Re:オフショアって (スコア:0)
>現実的ではない、ということですね。
でしょ。
だって、文化も言語も違う人にホイと渡せば寸分違わず希望通りのモノができてくるなんて事は有り得ない。
もし有り得るとすれば、何も給料寄越せだの飯食わせろだのウルサイ人間様なんぞに渡さないで、コンパイラなりジェ
Re:オフショアって (スコア:0)
客はプログラマに「フォーマット変換以外の何か」なんて期待してないよ。目的が達成できるなら安いほうがいい。
Re:オフショアって (スコア:0)
設計から寸分違わぬ物理的なモノを作るロボット技術は完成されていないが、ソースコードからオブジェクトを生成するというのは(まだまだ改良の余地はあるとしても)一定の完成をしている技術。
そういう意味では、コンピュータソフトウェアの開発作業というのは、既に図面渡したらロボットが家建ててくれる時代になってます。
また、物理的なモノを作るのは人件費以外の(部材費など)コストもかかるが、プログラムのコンパイル/ジェネレートには電気代以外金はかからない。
だから物理的な