■オフショア開発 ３（No.172）
オフショア開発にいろいろな問題点があって日本人の活用をもっと考えた方が良いのでは，と云ったことを述べた（No.148，No.149）が，今回も同じようなことを考えてみる。
オフショアの問題点
要求仕様を出して，それに基づいてソフトウェアの開発設計を依頼するが，なかなか思い通りにならないことが起こる。オフショア開発なので，開発の実態が掴めないのが一番の問題点である。どこに問題があって，それが解決できるかどうかが判れば，日本側での対応方法も考えられる。しかし，実態が掴めないので，問題点そのものが判らないことが多い。
問題点の内容として一番目は，スキル不足，こちらの要求している設計，品質確保ができないレベルにあることである。先ず，要求仕様を明確にして，そのＱＣＤが確実に対応可能かどうか，と云う判断である。一番難しいのは，品質確保で，この品質レベルは，日本では常識であっても，必ずしもそれがグローバルに常識ではないことで，国による特徴が現れやすいことが多い。ただ，日本企業を相手に仕事をしているので，ある程度の日本の品質レベルは判っている。
判っていることと実行することは別で，必要な品質が判っていても実行が伴わないようでは判っていないことと大きな違いはない。日本の品質はグローバル的には過剰な一面があることは事実だが，高品質が日本の売り物である以上，品質確保に万全を期するのは特長なので，それに応える必要がある。一面，決められたことを忠実に守ることは確実に行われる。一番の違いは，決められていない，曖昧な部分での品質に対する対応方法が，日本人と他の国の人とでは確実に違う。
日本人は，品質確保が第一と云われれば，決められていないことでもやろうとする。他の国の人は，決められていないことは，品質確保に有効だと思っても手を出さない。だから，日本人の間では確実な品質確保ができても，オフショア開発では同等な品質確保はできないことが起こる。そのことが，オフショア開発では当たり前と理解することが必要である。
技術的なスキルの問題も大きい。これは，一つには言葉の問題もあるが，それ以上に，ソフトウェアだから障害は少ないと雖も，スキルはやはり低いと言わざるを得ないのが実情である。決まった仕様を実現するために設計するレベルは，スピードの問題はあるが，そこそこ任せても十分である。しかし，その上流である要求内容を仕様に落とし込む仕様設計の部分は，言葉の問題を除いても難易度はやはり高く，仕様漏れなどミスが発生することが間々ある。これは，日本側でその実力を十分把握して，対処しないと後から手戻りと云う大きなロスになってしまう。
日本と違って，自己主張が強く，少々不安な部分があっても，素振りにもそんなことを見せようとはしない。それは，自分の出来が悪いことを自らが認めることで，日本側から指摘を受け，設計漏れなどが発覚するまで，自分の否は認めず，要求通りできあがったと主張することは当たり前である。日本人は素直に，不安な部分は正直に伝え，品質確保に対して不安な部分は事前に徴候を示す。彼らは一切そうしたことはしない。むしろ，自分は正しい。設計漏れなどのミスが発覚しても，要求仕様がはっきりしていなかったとか，そこまでは自分の範囲とは理解していなかったとか，自分の正当性を先ず主張する。それが，彼らにとっては素直な，当然の姿なのである。
ジョブホッピング（技能や賃金の向上を求めて転職を繰り返すこと）の問題は，日本ではなかなか実態が掴めない。優秀な技術者ほど，自分を高く売り込むこと，これが賃金の上がっていくシステムなのである。スキルが組織として蓄積され確実に上がって行くことは望ましいことだが，日本のように行かないことは理解しておく必要がある。これは日本人がどのようにすれば良いかと考えることよりも，そうした国民性を認めてつきあうことが必要なのである。
ブリッジエンジニアと呼ばれる，オフサイトとオンサイトを結ぶ技術者が居る。彼らは，日本語を翻訳したり，日本側の要求を現地に伝えたりする役割を担っている。彼らがしっかり日本側の要求を現地に伝え，その通りさせる力を持っていると，随分結果が違ってくる。最悪のケースは，ブリッジエンジニアが役立たない，それどころか反って弊害になるケースである。この人選もよく見ておかないと，後で取り返しがつかなくなることも起こる。
オフショア開発でつまずいていませんか？
[Reported by H.Nishimura 2010.06.07]
Copyright (C)2010 Hitoshi Nishimura
