« マイル使っちゃおうかな | Main | 議論白熱 »

ソースコードのコピペ爆弾

中国オフショア開発の受け入れで苦労しています。
不具合を指摘しても修正されません。何度も何度も同じ繰り返しです。はっきり言って自分で直した方が早いです。

・いざとなれば自分で修正します(12票)67%
・根気よく指摘し続けます   ( 3票)17%
・不具合はすぐ修正されます  ( 2票)11%
・その他 (1票)6%


(読者アンケート中間結果)

性能、例外処理、排他制御・・・、これらは経験不足のプログラマが苦手な作業であり、中国オフショア開発では常に関係者を悩ませる関門である。

日系メーカーの中国現地法人で働くある日本人上司は、中国人社員がバグを「直す」のではなく「隠す」ことに苛立ちを覚えるという。例外処理を無視するだけならまだしも、バグ発生確率を抑えるお化粧プログラミング技法には、開いた口がふさがらない。

中国オフショア開発では、今でも製造工程で単純なバグが発生しているのだろうか。さっそく、現場からこんな声が寄せられた。


・会社的にオフショアメインに移行し、社内の開発力をあまり必要としない前提に立っているはずなのに、実は修正工数が相当量必要なため、社内のPG要員不足という問題が最近露呈してきています。(Sさん)


・最近は不具合を直してもらえないということはなくなってきています。3~5年前はよくあった事ですが。ただ、本当に緊急を要するものや、どうもレスポンスが悪いものに関しては、日本側でやってしまうこともあります。(Hさん)


■成功の勘所

一般に、中国人若手プログラマは同年代の日本人プログラマと比べて手が早い。その反面、不具合の対処療法に全力投球してしまいがちである。

無駄を嫌い、合理性を重んじる一方で、ソースコードのコピペ爆弾、汎用性のない例外処理、手続き型でコーディングされたJavaプログラムが大量発生する。あなたなら、この修羅場をどう乗り切るか。

|

« マイル使っちゃおうかな | Main | 議論白熱 »

Comments

「コピペ爆弾」「Javaを手続き型で書く」も満載です^^;
思わず笑ってしまいました。普通なんですね。

今回は新規分が8万STEP弱ありますが、たぶん1/2~1/3くらいで済むかと。
継承とかイベントとかスレッド、GDI+、Win32など器用に使って、機能を実現していますが、
(ソースと性能の)無駄をとること、再現性が低い不具合の対応には全く関心がないようです。(ちなみ言語はC#)

何に起因しているかを考えてみましたが、
先日、勉強会で教わった「常識(=変えられない)」によるものが大きいと思いました。

ただ、問題を見つけた直後は『こういうのは、中堅レベルでも無理なんだな・・・』と情けなくなりましたが、その後のやりとりで資質・意欲がある人なら教え方と環境を工夫すればいける(=できるようになる)と再認識しました。

ただ、個人のスキルアップが教育・経験で可能だとしても、次は離職が待っているので、結局、解決になっていないのですが・・・。

ちなみに、中国人技術者に批判的な内容に思われるかもしれませんが、そうではありません。

本社側で「日本の協力会社と比較した生産性は何対何だ?」とよく話題になっているようですが、
『得意分野(機能開発)なら1:1は充分に可能』だと回答できます。(それ以上も!)

メーリングリストでも何度か取り上げられていますが、パッケージのカスタマイズ案件のように基盤が出来上がっているものが一番向いていると思います。(最先端技術はうちでは対応できない)

# ちなみに今回は全面的に中国で新規開発という案件だったので、久々の大火事になりました。

それ以外の記事で取り上げられているような部分は、丸投げすれば確実に失敗すると断言できます。

高品質プロジェクトでの開発経験をもつ中堅以上の日本人技術者がコードレビューするしかないと思います。
レイコさんに裏技として教わりましたが、中国人は「メンツ」がとても大事なので、コードレビューされるとわかっていれば、日本人以上にレビュー効果を期待できるそうです。

長々と申し訳ありません。アンケートの答えはもちろん、、、、、、

「いざとなれば自分で修正します」

です。

Posted by: かつ | December 01, 2007 10:12 PM

かつさん、いつもマニアックな情報提供ありがとうございます。コスト削減額と生産性の他にオフショア開発の業績を評価する指標があれば教えてください。

Posted by: 幸地 司 | December 04, 2007 10:18 PM

幸知さま、コメントありがとうございます。

業績指標ですが、完了報告書の項目だと、まずはQCD+CS(顧客満足度)になります。

Q(品質)の指標は、試行錯誤中(件/KSTEP、件/人日、件/FPなど)ですが、先日のプロジェクトでは、不具合レベルというのを使いました。
『納品後の検収でSレベル=0、Aレベル=0を実現したら、顧客満足度の品質評価は5(最高)』と委託元のPMと合意して、メンバ全員で共有しました。事あるごとに、
「エス・ゼロ、エス・ゼロ」
「まだ実現したことないけど、きっとできる」
「頼むぞぉ。」
と言ってました。

C(コスト)は、工数の予実績、D(納期)は納期遵守率です。

CS(顧客満足度)は、過去1年3ヶ月でサンプルが30件になったこともあり、管理者は結果に一喜一憂するようになりました。(憂えるというか逆ギレしてますが…(^_^;)

あと、、、、、
これは本社側の取り組みですが、オフショア委託率(工数ベース)も指標の1つになっているようです。(コスト削減の次は人材確保という流れです。)

内部的には、、、、
人材育成率みたいなのも欲しいのですが、完了時にスキルマップ・経歴書を更新して達成感を感じてもらう程度に留まっています。
教訓抽出数とかチェックリスト強化数とかも面白そう。と、今思いました。

Posted by: かつ | December 07, 2007 09:39 PM

すいません・・・。また間違えました。
業績だから、委託元の指標ですね。

オフショア関連では委託率だけです。
(原価予実績や納期遵守率等も指標化されていますが、オフショアというくくりはないですね。)

Posted by: かつ | December 08, 2007 07:28 PM

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



TrackBack


Listed below are links to weblogs that reference ソースコードのコピペ爆弾:

« マイル使っちゃおうかな | Main | 議論白熱 »