定量的な品質評価が難しいので、特定状況でのみ動作確認
品質評価が難しいオフショア開発
定量的な品質評価が難しいソフトを扱っています。それでもオフショア発注できますか?
(よくある質問)
定量的な品質評価が難しいソフトであっても、オフショア開発は可能である。ただし、次のような失敗例があるので、該当する方は参考にして欲しい。
かつて、私は定量的な品質評価が難しいソフトウェアと5年間つきあってきた。OCRと呼ばれる画像認識技術である。一般に、検索や画像認識といった技術には正解があってないようなモノ。すなわち、定量評価がとても難しい(※)。
※人の笑顔を自動認識する技術に絶対的な正解はない
※文字認識技術で"ー","-","―"を区別する正解algorismはない
中国オフショア開発では、特定の状況下でのみ正しく動作する、いわゆる「お化粧プログラミング」の弊害が多数報告されている。オフショア開発PRESS でも、「直すのではなく隠す」と「テストの地獄スパイラル」といった事例を紹介している。
参考1:オフショア開発PRESS p31「直すのではなく隠す」
参考2:オフショア開発PRESS p105「テストの地獄スパイラル」
http://amazon.co.jp/exec/obidos/ASIN/4774134430/aicoach-22/ref=nosim
以下、余談。
長い目で見たとき、オフショア開発を失敗させる最大の要因は、無計画で継続性のない発注形態だと思う。
例えば、お試し発注と称して3ヶ月間のオフショア開発を実施する。その後、評価に2ヶ月間を要する。さらに1ヶ月の準備期間を経て、再び製造&単体試験を依頼する。これは、失敗するオフショア開発の典型例である。
■成功の勘所
中国オフショア開発では、特定の状況下でのみ正しく動作する、いわゆる「お化粧プログラミング」の弊害が多数報告されている。「納期遵守」絶対主義が招いた弊害だと指摘する声もある。
間接オフショア開発では、安全のために納期の前倒しが要求されるため、品質を犠牲にした”仮納品”が後を絶たないという。
The comments to this entry are closed.
Comments