久しぶりにエンドユーザから業務アプリケーションの直受けのオフショア案件が出てきました。
　ウェブ系は比較的多いんですが、業務アプリケーションの直受けは少ないです。
　弊社だけというわけではなく、中国オフショア開発業界全般にその傾向にあると思います。
　理由としては、オフショア開発でエンドユーザと仕様固めするのが難しいという事と、単純に営業出来ないという事があります。

　正直言うと、エンドユーザにまで営業出来ないというのが最大の理由だと思います。
　エンドユーザとの仕様決めをオフショア、つまり、メールと電話（Skype含む）で完結させるポイントを一つ挙げるとすると
　・先方の業務、ビジネスを正しく理解している
　に尽きると思います。従って、直受けが出来る案件は、設計にあたるエンジニアが幅広い経験を持っているかどうかという事に左右されます。
　もちろん、オフショア系SEでなくとも、オンサイト系SEにおいても幅広い経験が必要です。技術的な部分は当然としても、ビジネス的な部分、人としての全体的な経験も必要です。
　オンサイトでは多少隠せる部分はあるものの、オフショアでは明確に差が出ます。そういう意味でもオフショアでエンドユーザから直受けが出来る（そして成功させる）というのは、社内に、一定のレベルにある優秀なSEが存在する事の証明にもなりえます。
　もちろん、発注側にもある一定のコンピュータリテラシー、仕様書は無理にしても、書面で相手に意思を伝える事が出来る能力が求められます。
　一見、クライアントにとっては、非常に面倒な気もしますが、書面に落とす事で、最終の仕様固めのところでの誤解、言った言わない問題等を避ける事が出来るメリットもあります。また、関係者に一斉通知する事が出来るので、クライアント社内においての情報共有にもメリットがあります。
　口頭で言った方が早いケースがあるのは否定しませんが、口頭のみに頼ると、全ての人に同じ内容を何度も伝えなくてはならなくなりますし、聞き手の理解力によっては、ズレが生じます。ドキュメントにする事で、逆に、時間を消費出来るという場合も多々あります。
　また、受注側がクライアントに仕様を説明する場合も、面と向かってやる場合と違って、かなり詳細な落とし込み、分かりやすい説明資料を作る必要が出てきます。これも上記と同様に、誤解を少なくする事が可能ですし、資料を作る担当者の上司の閲覧が可能になります。加えて、詳細仕様書を作ってプログラマーに開発を発注する段になっても非常に有効で、プログラマーの理解を助ける事も出来ます。
　Face2Faceに頼ると、作成するドキュメントの詰めの甘さが目立つのと、担当者に情報が集中し、プロジェクトのリスクが高まります。
　オフショア開発というのは、短期的には非常に面倒な面がありますが、長期的な視点に立った場合、発注者、受注者双方にとって、将来的な効率化、ドキュメント化による暗黙知の形式知化というメリットを生み出します。