アカウント名:
パスワード:
でしょ。 だって、文化も言語も違う人にホイと渡せば寸分違わず希望通りのモノができてくるなんて事は有り得ない。 もし有り得るとすれば、何も給料寄越せだの飯食わせろだのウルサイ人間様なんぞに渡さないで、コンパイラなりジェ
また、物理的なモノを作るのは人件費以外の（部材費など）コストもかかるが、プログラムのコンパイル／ジェネレートには電気代以外金はかからない。 だから物理的な
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
オフショアって (スコア:3, 興味深い)
なんでも、海外に外注してもいい加減な製品しか出来てこない場合が多々あったり、（時給換算でのコストは米国内よりも破格に低コストだが）開発に異様に手間取ってそれほど安くならないケースがあったりで、最近は海外の国内のどちらに出すか、ケースバイケースで考える方
Re:オフショアって (スコア:5, 参考になる)
きっちりとした外部設計書が国内で作れれば内部設計、開発、テストのフェーズを中国で行うのはわりと容易です。ちゃんと瑕疵対応も要求できるし、仕様変更にも柔軟に対応してもらいました。
日本のお客様を相手にしている以上、要件定義や外部設計作業自体は国内で行う必要があると思います。画面設計やデータ構造設計など、根本的で固まるまでに多くの打ち合わせが必要な作業は、海を越えて行う方がコスト高になるからです。
コストが安いので多くの技術者を投入して短期開発なんてことも出来るのですが、この場合、品質管理には細心の注意を払う必要があります。
多くの場合、全てを設計書に書ききれないので、開発中にQ&Aが発生しますが、その対応をきちんとしないとモノが出来てから手戻りが発生します。
また、仕様を理解する際のデフォルトが違うので、質問すら発生しないことがあります。少しでも不安を感じたら、すぐに日本側から質問してはっきりさせる必要があります。
オフショア開発の失敗の原因は、多くの場合「丸投げ」に有ります。一時請けであるSIerが品質管理や進捗管理をきちんとしなかった場合、ものすごい勢いで、微妙に違う成果物が上がってきます。これを後で収拾つけるのはなかなか容易ではありません。
国内での開発でありがちな「いい加減な設計書」ではそもそも開発できませんのでオフショア開発は出来ません。逆に言うと「ちゃんとした設計書」が成果物として残るので、品質は均質化できるし保守性も上がります。
とにかく重要なのは上流工程のSIerやコンサルタントです。お客様の要求をきれいにまとめて、開発開始後に手戻りが発生しないような設計書を起こす能力が求められます。これさえ出来れば安価なソフトウェア工場は高品質な製品を納品してくれるでしょう。
Re:オフショアって (スコア:1)
解りにくい。要するに、日本でシステム設計をして、支那で開発するというオフショア開発をやっているわけですね？
＃というQ&Aが大切、と(笑)。
> 仕様を理解する際のデフォルトが違うので
文化の差、ってやつですね。別のコメントにもあったけど、言葉は通じるんですよね。でも、相手がこっちの文化まで細かく理解しているとは限らない。設計書に書いて、あるいは、話して通じたと思っても実は両者の理解は微妙に違っている、ということがある(国内でもあるけど)。そのあたりが難しいんでしょうね。
Re:オフショアって (スコア:1)
その通りです。日本人なのでブリッジSEというと誤解を招きそうですし、オフショア・コーディネーターというとブローカーみたいでイヤなのです。システム開発を理解していないピンハネ・ブローカーにオフショア開発のコーディネートは無理です。
> 話して通じたと思っても実は両者の理解は微妙に違っている
これに気づくのが大変なんですよ。心配だったら根掘り葉掘り質問するのですが、そもそも理解が違っている事に気づかなければどうしようもないですから。
Re:オフショアって (スコア:1)
解る気がします。むしろ、日本語じゃなくて英語を使ったほうが誤解が少ないんじゃないかと思ったり..... ちがうか、やっぱり。
Re:オフショアって (スコア:1)
部分的にはありますよ。私は英語が得意なわけではないですが、英語の方が説明しやすいことは多々ありました。(実話)
Re:オフショアって (スコア:1)
とすると、開発経験のない人が設計するという状況になってくるわけですが、そうなってしまうとマトモに設計できないでしょうね。
まあ、海外で開発というやり方にはいろんな条件や環境などが前提となるので、海外で開発できる案件はごく少数でしょうけど。
Re:オフショアって (スコア:0)
いや、もうそうなっています。
* UTとSTの区別がついていない人
* レスポンスとスループットの区別がついていない人
* 再現手順を示さずに「修正しろ」と言う人
* 性能要件無しに「チュー
Re:オフショアって (スコア:0)
超・激しく同意します！
個人的には「スコア:5, すばらしい洞察」を差し上げたい。
＃ ただいま実際にオフショアコーディネート中なのでAC
結局は (スコア:0)
＃「お願い、せめて画面遷移図だけでも頂戴」な下請けなのでA.C.
Re:オフショアって (スコア:0)
つまり、オフショア開発は極めて限定的なプロジェクトを除いて
現実的ではない、ということですね。
システムは生き物であって仕様変更が無い事なんて有り得ませんから。
Re:オフショアって (スコア:1)
>つまり、オフショア開発は極めて限定的なプロジェクトを除いて
>現実的ではない、ということですね。
いや、まあ程度の問題とちゃいますかね。
海外に発注するときは、言語の壁があるからコミュニケーションが
とりにくい。それに比べれば、国内の人とやりとりするほうが、
まだやりやすい。
作業するほうからすれば、設計の変更は無いほうが良いに決まってる
けど、海外に発注するときは、そこにいっそう気を使う必要がある、
ということでしょう。
プロジェクトの作業のうち、開発中に仕様変更が発生しにくそうな
部分のみ海外の開発者に頼む、とかすれば良いんじゃないでしょうか。
Re:オフショアって (スコア:1)
安く作ろうと発注者が思わないなら、わざわざ外国で作る必要はないのですよ。
ひざを突き合せるのに比べて難のあるコミュニケーション環境で頑張ってでも安くしたいなら、そのための努力は発注者にも上流工程を請けたSIerにも必要です。
その一環としてより精度の高い設計書が必要ということです。100%完璧な設計書なんて作れないのは承知の上です。
ゆるい部分が有るなら影響範囲を限定して多めに見積るしかないのです。せっかく安くしようとしているのに高くなる要因を排除しきれないのはもったいないですよ。
Re:オフショアって (スコア:0)
ウォーターフォール型、強いて言えば上記の条件があってブリッジSEがしっかりしていればスパイル型の開発でも有効。
どちらかと言うとwebシステムを短期で仕上げる、顧客と膝詰めで毎日リリースし
Re:オフショアって (スコア:0)
＞現実的ではない、ということですね。
でしょ。
だって、文化も言語も違う人にホイと渡せば寸分違わず希望通りのモノができてくるなんて事は有り得ない。
もし有り得るとすれば、何も給料寄越せだの飯食わせろだのウルサイ人間様なんぞに渡さないで、コンパイラなりジェ
Re:オフショアって (スコア:0)
客はプログラマに「フォーマット変換以外の何か」なんて期待してないよ。目的が達成できるなら安いほうがいい。
Re:オフショアって (スコア:0)
設計から寸分違わぬ物理的なモノを作るロボット技術は完成されていないが、ソースコードからオブジェクトを生成するというのは（まだまだ改良の余地はあるとしても）一定の完成をしている技術。
そういう意味では、コンピュータソフトウェアの開発作業というのは、既に図面渡したらロボットが家建ててくれる時代になってます。
また、物理的なモノを作るのは人件費以外の（部材費など）コストもかかるが、プログラムのコンパイル／ジェネレートには電気代以外金はかからない。
だから物理的な
Re:オフショアって (スコア:0)
しっかりとした外部設計書が国内で作れれば、孫〃請けでも国内でやったほうがましです。内部設計、開発、テストのフェーズを中国で行うもリスクが大き過ぎます。仕様変更なんて仕様書とか最初から説明し直す必要があります。
親コメントみたいなプログラムがそのまま組める仕様書を提出させられた場合もありましたが、あれではコスト計算なんか金を握っている営業とプロジェクトマネージャは出来ていないので上流設計者の自己満足の世界です。
Re:オフショアって (スコア:0)
初回：こちら側が出したPG仕様書と結合テスト仕様があいまいとかなり突っ込まれた。特に例外条件などはっきり定義しておかないとかなりしつこく食い下がられた（当事者談）。
一番情けないのはこちらの文章があいまいな部分や変な日本語を指摘された所。聞くところによると品質管理組織の中に「日本語としておかしな表現は無いか」とチェックする部門があるらしく、そこが渡された仕様で意味不明なところを確認して指摘されたとの事。