アカウント名:
パスワード:
でしょ。 だって、文化も言語も違う人にホイと渡せば寸分違わず希望通りのモノができてくるなんて事は有り得ない。 もし有り得るとすれば、何も給料寄越せだの飯食わせろだのウルサイ人間様なんぞに渡さないで、コンパイラなりジェ
また、物理的なモノを作るのは人件費以外の（部材費など）コストもかかるが、プログラムのコンパイル／ジェネレートには電気代以外金はかからない。 だから物理的な
同じ条件で国内に発注してうまくいくかといわれると疑問です。
うまくいかない原因がどこにあるかを分析しないといけないのですが、ダメな原因の1つは「あいまいな設計」とか「無茶なスケジュール」ってのもあると思いますよ。「オフショアでダメならば国内で」ってのは、単にデスマーチを輸出するかしないかだけの違いにしか見えないことがあるのですが、それは気のせいですかね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
オフショアって (スコア: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仕様書と結合テスト仕様があいまいとかなり突っ込まれた。特に例外条件などはっきり定義しておかないとかなりしつこく食い下がられた（当事者談）。
一番情けないのはこちらの文章があいまいな部分や変な日本語を指摘された所。聞くところによると品質管理組織の中に「日本語としておかしな表現は無いか」とチェックする部門があるらしく、そこが渡された仕様で意味不明なところを確認して指摘されたとの事。
海外に外注していい結果が出ないからといって (スコア:2, すばらしい洞察)
同じ条件で国内に発注してうまくいくかといわれると疑問です。
うまくいかない原因がどこにあるかを分析しないといけないのですが、ダメな原因の1つは「あいまいな設計」とか「無茶なスケジュール」ってのもあると思いますよ。「オフショアでダメならば国内で」ってのは、単にデスマーチを輸出するかしないかだけの違いにしか見えないことがあるのですが、それは気のせいですかね？
wakatono
Re:海外に外注していい結果が出ないからといって (スコア:0)
英語が話せるといってもやはり壁はあります。
Re:海外に外注していい結果が出ないからといって (スコア:2, 興味深い)
日本を相手に商売している中国のシステム開発会社の技術者は日本語コミュニケーションできます。
設計書も成果物も質疑応答も全部日本語。電話をかけても日本語で会話できます。IP電話のおかげで国際電話のコストは気にならないし、中国なら時差も少ないです。
Re:海外に外注していい結果が出ないからといって (スコア:2, 興味深い)
わしのとこも、似たような状況ですが、細かなニアンスが通じないので苦労しています。特に、障害の発生したタイミングの説明なんか。「言葉の壁がない」といえるとは羨ましい。
まー、当初の日本語でメールするとあっちでは、日本語を中国語に翻訳して英語で返事して、それを日本語に訳して・・・なんてことはなくなりましたので良くはなってきているのは確かですが。（苦笑）
-------- izyu
Re:海外に外注していい結果が出ないからといって (スコア:1)
そういう人もいた、というだけでしょう。
日本人も、英語を話せて外国とのやり取りをしてる人はいても、
日本人が全員そうではありませんよね。
Re:海外に外注していい結果が出ないからといって (スコア:1)
ただ、壁というよりは、もうちょっと低い柵くらいですかねぇ。
つまづく程度の石かもしれない。転んだら結構痛いのです。
Re:海外に外注していい結果が出ないからといって (スコア:1)
転ぶ原因になる様な石がゴロゴロしているところは、壁で囲んでしまえ..
といったこともあったりするわけなんですね。
Re:海外に外注していい結果が出ないからといって (スコア:0)
確かに打ち合わせに来る方は日本語に堪能でした。
仕様書も日本語で作成しましたが、特に問題なく理解してもらえました。
……が。
あがってきた成果物はボロボロでした。
いや、テストに引っかかるとかそういうのはしょうがないんでしょうけど、驚いたのは
Re:海外に外注していい結果が出ないからといって (スコア:2, すばらしい洞察)
むしろ問題になるとすれば、お互いに不可侵の城壁や濠を作って、どちらにも属さない部分が広くなる（責任を放棄しあう）こと、かな？
# 実際には海外の壁は生活習慣等ありそうですけどね
# 遠隔開発の出先側だけどあえてID
---- 何ぃ！ザシャー
Re:オフショアって (スコア:0)