オフショア開発の成否

長いから折りたたみ(^^;
リスクの高いオフショア開発はたくさんありますけど、それは日本の仕事に慣れていない会社へ発注したり、ブリッジエンジニアの経験不足から来るものじゃないかと思います。日本側も中国の使い方が分からないし、中国側も日本の仕事の仕方が分からない。模索状態である事が失敗へつながるのかなと。これは数をこなすっきゃないと思っています。そういう意味では成功への過程で発生する失敗なのかもしれません。

技術面で言ったら日本の方が上って根拠は無いですし、中国の方が上って根拠も無いですが、平均すりゃ大差ないというのが私の見解です。本当に高い技術を持った集団もいます。適当に働いている集団もいます。距離とコミュニケーションの問題さえ無ければ費用で日本は有利にはならないんじゃないかなと思います。

同じ人件費で雇える人数も格段に違うので、人海戦術によって超短納期も実現できますが、それは設計書の質とプロジェクト管理者の力量が問われます。一歩間違えれば全滅です。

現在のオフショア開発で成功を収めるには、日本の仕事をこなした経験(数)、ブリッジエンジニアの力量が大きな割合を占めるのではないかと考えています。そして設計書を日本で書くかオフショアにするかも大きな関係があります。

設計書について。UI工程については2通りあって、日本側で完璧に終わらせる方法と、中国から人を呼んでしまう方法があります。プロジェクト発足〜UI設計までをオフショアに出すのはやった事が無いので想像がつきません。UI設計の段階で開発を請負う会社の人を入れておけば、次工程以降の設計もオフショアに出せる可能性があります。次工程以降の設計をオフショアに出した経験を持っていて、出してもOKの判断が出せると、開発工程もすんなり進みます。

UI工程以降の詳細な設計を日本でやる場合は、精度をかなり高くしておく必要があります。日本人が見てもいまいち分からないとか、曖昧な所があるとか、決まってない所があるなんていうのは、そのままの形で結果に反映されます。「分からなかったら聞いてくるだろう」などと推測で物を言う時点で危険です。

UI工程以降の詳細な設計を中国でやる場合は、品質のチェックをするだけで開発はスムーズに行きます。設計書を書いている人が仕様をよく理解するのでもし設計書に不備があっても、プログラム自体は動くものができます。設計書にはあらわせていないけれど、脳内にはちゃんとした設計書がある。というより、プログラムが頭の中にあるというのは、技術者なら経験があるんじゃないでしょうか。設計書を書くより、プログラムを書いたほうが早い。そんな状況に持っていくと、設計書はまあまあでも、プログラムはうまく動くものができます。

今回は2箇所に発注していますが、1箇所は初めてのお付き合いです。質問が上がってきていない時点で、少々不安を感じていますが、それはこちらからコミュニケーションを取るしかありません。コミュニケーションについては去年(2004/08/01〜の日記参照)いろいろと学んだので、よりよくするために実践する時です。

すごい話が飛び飛びで中途半端なんですけど、各工程やら実際のオフショア開発についてまとめるとかなりの量になりそうです。私も頭の中に断片が山ほどありますが、全然つながってないのでその時々頭から取り出すような感じです。だから書いた内容も飛び飛びだし、肝心な所が抜けてたりします。これをまとめて出さない限り、知識の伝達にはならないんですよね…わかっちゃいるんですが…うぐぅ。