オフショア開発に対する期待

オフショア開発は2000年頃は中国・インドの拠点が中心となり、日本企業は委託することが主流でした。
その頃はオフショア開発が日本での開発に比べて低価格で依頼できることから注目がされました。

ところが多くの会社はオフショア開発のメリットを活かすことができず、失敗をして撤退をする企業が多かったようです。

状況は変わり、ここ数年ではオフショア開発の主流はベトナムとなっています。
近年では多くの企業がベトナムオフショア開発を活用し、コストを抑えた開発ができている会社もあります。

一方で、オフショア開発は今でも導入が難しいと言われています。
価格のメリットがある一方、利用をする難しさがあるといえます。

オフショア開発のストレスがある

オフショア開発でストレスになる要因として、考え方や文化の違いがあります。
日本式の考え方として、相手を配慮することや、丁寧な仕事をするということが当たり前となっています。

日本と異なり海外ではそのような考えは当たり前ではなく、依頼をして任せると期待したことレベルにならないことがでてきます。

海外では、品質はともかく受けた指示の通り作業をすれば仕事としては完了するという考え方があるように思います。

そのためユーザビリティを考えるとか、メンテナンス性ということは具体的な指示がなければ取り入れてくれません。

オフショア開発の実体験

これまで著者自身もオフショア開発を経験しましたが、開発者に指示をすると作業はするものの思い通りの開発にならないことが多くありました。

ロジックが合っていても画面遷移自体がユーザフレンドリィになっていなかったり、仕様に関する背景の理解がなされていないことで「ここは指示がなくてもこうしてほしい」ということができません。

また、仕様を理解していてもメンテナンスのことまでは考えられておらず、冗長なコーディングがされて結果的にバグが多発する不安定なシステムになります。

オフショア開発のストレスを取り除く対策案

上記の対策としては、下記を意識することである程度解決できます。

• プロジェクトの背景もちゃんと説明する。
• テストチームを採用する。
• テストまでやってくれるブリッジSEがいるかどうか確認する。
• 発注側もテストを行う。
• 密なコミュニケーションをとる。

仕様を理解してもらうためにブリッジエンジニアとは時間をかけて説明しましょう。
ブリッジエンジニアからメンバーへの説明は仕様をドキュメント化した上で疑問点を拾い上げるとよいでしょう。

動作確認については、仕様に従ったテスト仕様書を作成し、テスターを使ってテストをしてもらいます。

また、テストをしていても確認項目が不十分であることが考えられるので、依頼側でも最初のうちはテストを行うとよいでしょう。

対策を通して変わったこと

上記を行うことでプロジェクトの品質は改善されました。

オフショアを取り入れた最初の頃はオフショアのブリッジSEに不具合が多いことを伝えて改善をするように催促をしたのですが、状況は変わりませんでした。

内部から関わるようにしなければ大きな効果は出ません。
依頼主がチームに深く関わり、体制の中に入り込んで改善をすると効果が出やすいでしょう。

これからオフショアを検討する方へのアドバイス

オフショア開発はオフショアチームをコントロールすることが成功のポイントとなります。

優秀なエンジニアがいたとしても、プロジェクト管理がしっかりできていないとオフショア開発は失敗しがちになります。

オフショア先の文化と考え方を理解した上で対策を講じましょう。
また、テストを重視する、密なコミュニケーションにとることにコストをかけましょう。

参考→ベトナムオフショア開発の特徴