オフショア開発の得意分野、苦手分野

オフショア開発への作業の切り出しには、オフショアに適している工程と、適さない工程ががあります。それらを理解ないまま、日本の開発ベンダと同じように依頼をしても、必ず失敗をします。
オフショア先の得意分野を理解して、日本側のリソースと上手に組み合わせるのが成功へのカギとなります。

1. オフショアの設計フェーズ

　設計書の作成は、オフショアとは相性が良くありません。
　オフショア先のメンバは全員が日本語を話せるわけではないので、翻訳が都度発生する為です。
　要件定義書や関連資料のベトナム語翻訳し、完成した設計書を日本側でレビューする度に日本語翻訳が発生します。
　お客様に納品する為の設計書の場合なら、正確な日本語でリリース前に手直しをする作業も発生してしまいます。
　その為、翻訳に要するコストと時間が取られて、非常に非効率と言えます。

　設計書は日本側で作成するのが望ましいですが、どうしてもオフショアで設計書を書くのであれば、日本とオフショア先との共通言語を英語にすることで翻訳の手間を無くしましょう。
　また、日本側で設計書を作成する場合でも、フローチャートやシーケンス、図表などで用いる単語は英語で書くことで翻訳時間を減らし、認識齟齬が発生しにくくなります。

　オフショア先の設計書の作成能力ですが、上記の通り翻訳の煩わしさから、多くの企業は設計を本国で行うため、オフショア先の設計書の作成能力はまだまだ不十分です。
　私がいるベトナムでは十分な品質で作成できるエンジニアが極端に少ないと感じています。
　オフショア先に設計書を書かせるには、じっくりと教育を行う必要がありそうです。

2. オフショアの製造フェーズ

　製造フェーズは、まさにオフショアに任せるべき工程です。
様々な言語で、製造スキルを持った開発者が多く居り、十分に日本の開発者の代わりとして戦力になります。場合によっては、日本よりも高スキルな人材もいます。開発のスピードが早いので、期限までの製造は任せることができます。
　注意点としては2点あります。

設計書はキチンと作成、フォロー体制は万全に

　異国の言語で質問を交わすのはそれなりにパワーと時間を要します。
　設計書の不明点を質問せずに、独自の解釈で作ってしまい、間違ったものを作ってしまったという失敗をよく聞きます。
　開発者が困らないように設計書は細部まで十分に記載すること、またオフショア先から質問を気軽に行えて、設計者がしっかりとフォローできる体制を整える必要があります。
　作る物さえ分かってしまえば、非常に早く製造を行うことができます。

コーディング規約や、プロジェクトの注意事項は文書化

　プロジェクトには、こういう方法で作らないといけないというルールがあるはずです。何も伝えないと、各自が好きなようにコーディングをして、めちゃめちゃになります。
　ルールや注意事項は導入教育資料として必ず文書化しましょう。
　日本国内なら口頭で言えることも遠隔でのコントロールになるので、伝わらないことが多くあります。
　文書化をしておくことで正確に伝わりますし、もしメンバが交代しても、新しいメンバに漏れなく伝えることができます。

3. オフショアのテストフェーズ

　オフショアへ作業依頼をする際に注意が必要なのはテストフェーズです。
　オフショア先の開発者にテストを依頼したところ、正常系しか確認をしておらず、異常系の考慮が不十分だったという話も聞きます。
　これは開発者は自身の開発能力を向上させることには興味を持ちますが、テストの実施はテスタの仕事で自身の役割ではないと考える為、真剣に不具合出しを行ってくれないことが原因です。
　日本ではプロジェクトの成功に向けて、開発者が品質を意識してテストを行うことができますが、組織よりも個人のスキルを優先する海外では勝手が違うところの一つです。

　ではオフショアでテストを行わせることは不可能なのか、という質問については、ルールを明確にして教育をすることで単体テストまでは十分な品質を出すことができますが、結合テスト以降はテスタに依頼するか、日本側で行った方がいいです。

　ラボ契約の場合は、長期間メンバを確保できるので、教育することで品質は向上します。
　ただし結合テスト以降は、開発者の役割ではないという意識がある為、それを長期間やらせることはメンバのストレスになり、最悪の場合は退職することにもなりますのでお薦めはできません。
　開発者には開発者が得意としている分野のみを任せて、テストはテスタに任せるか、日本側で行うのが良いでしょう。

単体テスト

　単体テストにはソースコードレベルの確認（ホワイトボックステスト）と、UIレベルの確認（ブラックボックステスト）が存在します。
　ホワイトボックステストは静的解析ツールを使用して行います。これは開発者の分野の為、十分に実施が行えます。
　一方、ブラックボックステストは、開発者のスキルによって品質はバラバラです。
　自分が作ったプログラムくらいはちゃんと確認してほしいのですが、基本動作のみ確認してOKとしてしまう開発者も多くいます。特に期限が短い場合はテストを疎かにする傾向があります。（気持ちは分かりますが…）
　対策としては、確認した結果の画面キャプチャをチケットにエビデンスとして張り付けるルールにしたり、チケットに確認観点を記載するルールにしたりして、どんな確認を行ったのか日本側でもわかるようにすると良いでしょう。

結合試験、総合試験

　試験の実施方法は、以下の3パターンがあります。
　①試験項目書の作成、実施は日本で行い、オフショア先では開発者が不具合修正のみを行う。
　②試験項目書の作成は日本で行い、オフショア先ではテスタが試験実施を行い、開発者が不具合修正を行う。
　③オフショア先で、テスタが試験項目書の作成と実施を行い、開発者が不具合修正を行う。

　上記の3つのうち、日本側で製造後の品質を把握できる為、もっとも多いのは①のパターンです。
　②③の場合は、開発者とテスタで役割を分担して実施してください。
　ただし③の場合は、設計書と同様で翻訳の時間とコストが発生しますので、試験項目書は英語で作成するのが良いでしょう。

4.ベストな組み合わせ

　日本側とオフショア側の得意分野を把握して、それぞれの能力が最大限に活かせる体制が望ましいです。まとめると以下の体制になります。
　まずは製造と単体試験から始めて、教育や体制見直しながら切り出す範囲を広げていくのが良いでしょう。