昨日のエントリーいろいろな方にファボもらいました。
ついでだから、アマゾンアフィリのリンクからポチをしてください。
本題
オフショアが日本-東アジア圏ではダメだと思う理由をあげます。
日本語が特殊すぎる
日本語は特殊な言語で多分機械翻訳はほぼ無理です。
無理と言われていた将棋がプロ棋士よりも強くなるというのは、
現実化しつつありますが、
日本語を他の言語に置き換えるのはまだまだ先の話だと思います。
したがって、日本語で書かれた仕様書をオフショア先に届けても、
まあ、良い感じに解釈してくれないでしょうね。
解決策 仕様書をもっと数学的に記述すること
プログラミングの技術レベルが低い
まあ、インターネッツ様のお陰で、
プログラミングに関するhow-to的なものを検索することは可能になっています。
だけど、もっとメンテナンスしやすいプログラム、
読みやすいプログラム、安全なプログラム、
こういったプログラムを書くためにはインターネッツ様だけでは足りません。
『達人プログラマー』とか、『Thought works アンソロジー』とか、『ドメイン駆動設計』とか
こういった書籍で勉強する必要があります。
でも、インドネシアやベトナムといったオフショア先にある国で
書店を回ってみましたが、
こういった書籍が置いてあるところは皆無でした。
これが意味するのは、オフショア先で技術が向上しているといっても、
それはコピペをする能力が向上しているだけで、
プログラムを書く能力が向上しているわけではありません。
機械化に関する考え方
オフショア先というのは人件費はマジ安いです。
ベトナムだとおそらく日本人一人雇う金額で、
ベトナム人５人くらいを雇えます。
でも、ここに落とし穴があります。
マシンの値段はあまり変わらないということです。
日本でビルド専用の結構いいマシンを買うと、
人件費の５分の２くらいで購入出来ます。
でも、オフショア先では人件費の２倍かかります。
したがってなんでもかんでも機械化するということに関する情熱は、
金額的に考えて５倍の差があります。
言い換えると面倒くさくて時間のかかる作業も、
彼らは人力でやろうとするし、
機械化したら仕事取られちゃうしで、
機械化するのを嫌います。
でも、日本では機械化してないとやってられませんね。
というわけで、テストを書くとかそういう考え方がオフショアでは希薄です。
Jenkins？そんなのオレがやるから導入するなよっていう感じだと思います。
結論 オレ(オフショアのオレくん)がリアルJenkinsだ！
責任というかなんというか
これな。
僕はこれインドネシアと中国で痛い目にあっているんだけど、
なにかしらのうまくいかないことがあると、
日本人の責任にされます。
オフショア先では教えたことはやるけど、
教えたことの応用はできなく、
それをやらないことの責めは
日本人にあることになります。
結論 オフショアがうまくいかないのは日本人が悪いニダ
コスト的なこと
まあ、テストを書かないというのは前の前に書いたことですし、
コピペが多いというのは最初のあたりに書いたことですが、
ここからの結果として、こんなことになります。
不具合が発生した場合、
- 不具合箇所のきりわけ
- 不具合箇所の修正
- 不具合箇所の修正の確認
で、コピペ技術のすぐれたオフショアプログラマー、
これらの技術はありません。
そこで！日本人登場ですよ！
日本人のエンジニアがこれらプログラムの森を進み抜き、
不具合箇所を修正します。
結論 日本人がプログラム書かないためのオフショアなのになんで日本人がプログラム書いてんすか？
トータルコスト
というわけで、コストをだいたいみてみると、
こんな感じになると思います。
ちなみにウォーターフォールを前提としてます。
モデル
計画
- 工数 : 30人月
- 開発期間 : 3ヶ月
- 開発体制 :
- 日本人SE : 1人x3ヶ月(ブリッジSE兼PM) + 0.5人x1ヶ月(アーキテクトとか考える人)
- オフショア : 10人x3ヶ月
結果
- 工数 : 30人月 + 30人月(日本人による修正)
- 開発期間 : 6ヶ月(バグ取りの期間を含む)
収支(便宜上、日本人1人月100万、オフショア20万)
- 予算 : 950万円
- 費用 : 3350万円
その他
- ブリッジSEの過労による精神障害の発生
- 納期遅延による顧客との信頼関係の喪失
というわけで
オフショアするなら、オフショア人員一人あたり日本人一人つけといたほうが安全です。
あれ、それってオフショアの意味なくない？
あと、7個も理由書いてないや…(´・ω・｀)
0 件のコメント:
コメントを投稿