ソフトウェアの開発を外部に発注する場合、その発注先が国内にせよ、海外にせよ、機能を記述した仕様書というものを作成して、受注した側は、その仕様書に基づいて設計開発を行う。しかし、よほど簡単な機能のものでない限り、仕様書にその機能についてすべてを書き出すことは不可能であるということは認識しておかなければならない。特にユーザインタフェースについては、あらかじめ想定しての記述が非常に難しいということに加えて、発注側の好みや慣れまでを含めると、まず完全に合意するものを記述することはできない。そのため、特にユーザインタフェースにおいて、開発終了後に問題がでることが多い。

この問題の原因は、仕様書に開発に必要なすべての機能が書かれているべきだ（書かれていない部分は、希望するやり方がないのでまかされている）と思っている受注側と、プロなのだから仕様書に細かく書かなくても、それなりにやってくれて当然と思っている発注側の意識の差があるように思う。

ここまでの話はソフトウェア開発と一般的に書いたが、これをソフトウェアプロダクト（製品や自社で提供するサービス）に置き換えて考えると事情が変わってくる。まず、製品を開発するときに最初からすべての仕様がそろっていることは非常に少ない。これは、仕様の検討に時間をかけないというのではなく、最初に考えて細かく記述したものを実装しても、競争力のある製品やサービスを提供できないということが、わかっているからである。最初に、お客様からいただける受注金額が明確になって、渡される仕様書の機能を漏れなく実装すれば、とりあえず代金をいただける受託生産では、極端な話、中のコードがどうなっていても動作に問題がなければ良い。しかし、プロダクト開発の場合は、良いものを作らなければ予定した売り上げを上げることはできないので、その目的を達成するためには、仕様変更、仕様追加などをリアルタイムに判断しながら行う必要があるからである。

上記の特徴を持つプロダクト開発の場合でも、コストや技術の問題で海外でのオフショア開発の重要性が高まっている。しかし、通常の受託開発で行われているオフショアリングのプロセスをそのまま使って「仕様書通りで」というようなコミュニケーションを行ったのでは、失敗することは明らかである。仕様書ベースの開発は、そもそもプロダクト開発にはなじまないのに、何らかの契約が必要ということで、仕様書ですましてしまうからである。

プロダクト開発のオフショアリングを成功させるためには以下の要素が非常に重要と言える。

1. 途中の仕様変更にも柔軟に対応できるプロセス
2. 仕様書ベースでの情報伝達ではなく、発注側と受注側の密なコミュニケーション
3. 受注側のエンジニアのパッション

簡単に言うと、発注側と受注側が契約書で結ばれた関係ではなく、一つのチームとして動くことが必要だということである。しかし、このような関係を築くためには、次のような契約ができるかどうかが鍵となる。

1. 時間ベースの契約（開発委任）
仕様書が存在しないので、成果物が最初から定義できない。そのため必然的に、特定のスキルを持ったエンジニアをどの期間必要とするという契約形態になる。

2. プロジェクト全体の責任は、発注側
プロダクトを開発する場合、グローバルには「プロダクトマネージャ」と呼ばれる人が責任を持つことが多い。たとえ、契約で外部に発注するとしても、それも含めて発注側が責任を持つ必要がある。途中で、オフショア先のパフォーマンスが悪いときには、オフショア先を入れ替える可能性も含めて、リスクをコントロールしておく必要がある。

3. プロダクトリリース後の保守作業も含めた契約
ソフトウェアプロダクトは、リリース後も継続して品質を上げたり、機能を拡張することで、その価値を上げていく。その時の保守作業は、開発したチームが行うことが望ましい。こうすることが、保守性も考慮に入れた開発に結びつき、長期的な品質向上、コスト削減に結びつく。

プロダクト開発のオフショアリングを、ここに書いたように実施することの大きなメリットは、小規模のプロジェクトから始めることができということである。責任が発注側にあるので、プロジェクトのモニタリングを行い、細かい指示を出すことも受け入れられやすい。

プロダクト開発のオフショアリングでは、仕様書ベースではなく、コミュニケーションベースのオフショアリングをお勧めする。