オフショア開発において気をつけるべき法律とは？トラブル事例も紹介
こんにちは。Wakka Inc.メディア編集部です。
オフショア開発を円滑に進める上で、法律への理解は重要です。
オフショア開発では言語や考えの違いから、認識の相違が生まれやすく、小さなトラブルが訴訟などの問題に繋がる可能性があります。
「トラブルが起こった際に、法律を扱う場合どのように対応すれば良いか？」とお考えの方もいるのではないでしょうか？
本記事では、オフショア開発における契約の種類やトラブルを回避するためのポイントを解説します。
オフショア開発の準備に必要なことが分かるので、ご参考になさってください。
●開発リソースの不足にお悩みなら●
＞＞＞Wakka.Inc独自の海外子会社設立サービスがおすすめ！
無料でサービス資料をダウンロードできますのでぜひご覧ください。
基本的な契約形態の種類と特徴
| ラボ契約 | 請負契約 | |
| 特徴 | 一定期間の人員を確保する契約 | 依頼された開発を完了させる契約 |
| 報酬の対象 | 労働時間 | 成果物、完了した仕事 |
| 適しているプロジェクト | 要件や仕様を開発しながら定めるプロジェクト 長期運用を見据えており、ノウハウを社内に蓄積したい | 仕様や要件が決まっているもの 大規模なプロジェクトなど |
ラボ型開発（ラボ契約）
ラボ型開発とは人員を自社のチームとして一定期間確保する契約です。
契約期間中は、安定的にリソースを確保できる、仕様変更に柔軟に対応できるなどのメリットがあります。
開発をしながら詳細な要件を決めていく場合に適しています。
そのため要件や機能ごとに開発をし市場でテストをする、テストの結果を基に改善するといった活用が可能です。
ただし成果物に対して責任がないので、注意が必要です。
請負契約
請負契約は、開発要件や仕様を満たす成果物を定められた期間・工数で開発を行う契約です。
依頼側に完成された成果物が納品されてから報酬が支払われる決まりです。
依頼されたものを納品する契約のため、依頼側はベンダーに対して仕事の仕方への指示はできません。
請負契約は仕様や要件が明確に定まっているものに対して向いています。
ラボ契約と請負契約の違いをより詳しく解説しているので、ご覧ください。
オフショア開発における契約締結までの流れ
オフショア開発における契約締結までの流れは次の通りです。
- 要件や仕様を決める
- パートナーを選定する
- 開発方法・契約形式を定め
- 契約を締結する
順番に解説します。
1.要件や仕様を決める
まず開発したいソフトウェアの要件や仕様を定めます。
想定するシステムを実現するには、どのような仕組み・機能が必要かを明確にします。
仕様や要件が定まっていないと、要件を基に工数を割り出したり、品質を管理したりするのが難しくなってしまうからです。
可能なら詳細な設計も自社でしておいた方が、指示が明確になるためプロジェクトが円滑に進みます。
2.パートナーを選定する
次はパートナーを選定する段階です。
策定した要件や仕様で対応できるパートナーを探しましょう。
また、オフショア開発におけるパートナー選びでは、判断基準を設定しておくのがポイントです。
自社が開発したい分野の実績がある場合は、自社が考えた仕様を実現可能かなども相談しましょう。
さらにベンダーのリソースや情報管理のセキュリティ、コミュニケーションのしやすさなどを確認するのも有効です。
パートナー選びの判断基準については、あとで詳しく解説します。
3.開発方法・契約形式を定める
開発方法・契約方式の決定は、パートナー選びと同時で進行するイメージです。
自社の開発要件に適した開発方法と契約形式を決めましょう。
開発方法と契約形式の組み合わせによって、できることや予算なども変わります。
例えば具体的な開発要件が定まっていない場合、開発を進めながら要件や機能を定めるアジャイル開発に対応したパートナー、契約形態（ラボ型開発）を選ぶなどです。
4.契約を締結する
開発方法・契約形式まで定めたら契約を締結します。
契約書は、トラブルが起きた際に重要になるので必要事項を明記しておきましょう。
具体的には次の内容を記載します。
- 作業範囲
- 納期について
- 報酬について
- 想定している成果物
- 支払い通貨とレート
- 日報の報告頻度
- エンジニアの技術要件や人数
- セキュリティに関する規定
- 準拠法に関する要件
オフショア開発を進める際に法律で注意すべき点
オフショア開発では海外企業との取引になるになるため、先述した問題に注意が必要です。
また実際に問題が起き法律に従い対応する際は、留意すべき点があります。
具体的には下記が挙げられます。
- 準拠する法律を決める
- 裁判管轄を明確にする
- 国ごとの雇用制度を理解する
- 成果物における権利の所有を決めておく
- データ保護とプライバシーに留意する
1つずつ解説します。
準拠する法律を決める
オフショア開発では多くの場合、委託契約に適用される法律や紛争の解決手段を依頼者とベンダーで合意し契約に規定すれば決められます。
国によって法律は違うため、契約の際にどちらの国の法律に準拠するかを決めましょう。
契約の履行で適用される法律を決めておくことでトラブルの際に対処しやすくなるからです。
オフショア開発では、日本の法律に準じるケースがほとんどです。
ただし海外の法律に準拠するとなった場合、実績があり海外の法律に詳しい専門家の確保が必要になり、負担が増える可能性があります。
裁判管轄を明確にする
準拠する法律の他に、紛争解決手段としてどちらの国で裁判を行うかを決めておくことも重要です。
準拠する法律と裁判所管轄は同一の国に統一しておきましょう。
海外の国の法律に準拠すると決めたのに、日本の裁判所で判決をしても執行できない可能性があるからです。
日本の法律に準拠する場合には、日本国内の裁判所管轄にしておく方がスムーズです。
国ごとの雇用制度を理解する
契約先の国で現地の人材を採用する場合は、雇用制度を十分に理解してから採用しましょう。
例えば、ベトナムでは現地人を雇用する際は、政府によって設定された最低賃金の保障や公的保険の加入が義務付けられています。
また解雇も安易に行えず、退職者には勤続1年につき半月分の退職手当を支払う責任を負う必要があります。
国によって雇用制度や関連法令が違うので、契約前に理解しておきましょう。
参考：日本貿易振興機構｜「ベトナム 外国人就業規則・在留許可、現地人の雇用」
成果物における権利の所有を決めておく
成果物に関する権利もトラブルに繋がる可能性があるため、納品された成果物の著作権や所有権などは予め明確にしておきましょう。
通常ソフトウェアの開発委託の場合、開発において作られたプログラムコードやデータは依頼者に帰属するのが一般的です。
しかし、ソフトウェアは多くのプログラムが組み合わさってできているため、ベンダーが一部のプログラムの権利を保有するケースがあります。
国によっては法律に著作権譲渡契約の記載事項が規定されている場合があり、契約書に「依頼者に権利を帰属させる」と書いてあれば大丈夫というわけではないので、注意が必要です。
データ保護とプライバシーに留意する
IT開発では企業の機密情報を扱うためやデータ保護とプライバシーへの留意も重要です。
ソフトウェアの開発では、業務の秘密情報を共有することが多いため、社内で気をつけていても情報が漏洩する可能性があります。
そしてプログラムのソースコードも重要な機密情報の1つのため、流出したり不正に解読されたりしないように注意が必要です。
機密情報の漏洩や不正利用を防ぐためには、ベンダー側の機密情報の管理体制を確認し、契約書にも機密情報の扱いに必要な事項を明記しておきましょう。
輸出管理を徹底する
輸出管理とは下記に対する取り組みを指します。
我が国の安全保障と国際的な平和及び安全の維持の観点から、大量破壊兵器や通常兵器の開発・製造等に関連する資機材並びに関連汎用品の輸出やこれらの関連技術の非居住者への提供について、外国為替及び外国貿易法（以下「外為法」（がいためほう）という。）に基づき、必要最小限の管理を実施しています。
引用：一般社団法人安全保障貿易情報センター公式サイト
ソフトウェアの開発や技術指導は、技術の提供と見なされるため輸出管理の対象です。
法律違反をしてしまうと、罰金や行政制裁などのペナルティを受けるので、遵守しましょう。
オフショア開発でよくあるトラブル
オフショア開発では海外の企業に開発を依頼するので、仕様や指示内容に対する認識の相違などトラブルが起きる可能性があります。
ここではオフショア開発でよくあるトラブルを解説します。
成果物の品質が想定を下回る
オフショア開発では、成果物に関するトラブルが発生する可能性があります。
例えば納品されたシステムやソフトウェアに多くの修正が必要だったり、要件を満たせていなかったりと品質が良くない場合です。
またインターフェースやデザインがイメージと違うケースなどもあります。
とはいえ、仕様書に書かれている以外の内容は開発しないのが基本のため、要件や要望は明確にすることが大切です。
担当者とコミュニケーションを重ね、認識の相違をなくしていけば、想定している内容に近づけられます。
オフショア開発の品質管理におけるポイントは次の記事で詳しく解説していますので、ご覧ください。
意思疎通がうまくいかない
海外の企業を相手にするので、意思疎通がうまくいかない問題はよく起こります。
例えばオフショア開発で依頼が多いアジアの国では英語が通じにくい国が少なくありません。
そのため言語の問題で要望や細かいニュアンスがうまく伝わらず、希望通りの開発ができない場合があります。
他にも価値観や考え方の違いから日本の常識が通じず、開発がスムーズに進まないこともあるので対策が必要です。
トラブルの対応に追われ損失に繋がる
コミュニケーションや品質などのトラブル対応に追われると、追加で時間やコストを使います。
例えば、想定している品質に届かない場合、自社で修正をしたり、新たに外注をして作り直したりすると計画当初より費用が増えてしまいます。
トラブルを100%防ぐのは難しいですが、打ち合わせを繰り返し行えば作業の手戻りや認識の違いを減らせるでしょう。
他にもオフショア開発で起こる可能性があるトラブルや開発の失敗事例を下記の記事で詳しく解説しています。
気になる方はご覧ください。
実際にあったIT開発の訴訟事例
先述したトラブルも許容度を超えると訴訟に繋がる可能性があります。
実際にあったIT開発の訴訟事例を紹介します。
準拠する法律によって解釈は異なりますが、オフショア開発でも起こる可能性があるので、トラブル回避のためのご参考になさってください。
検収合格の認識相違による訴訟
1つ目は成果物の検収に対する認識の違いから訴訟に繋がった事例です。
日本のベンダーが顧客から開発依頼を受け、中国のオフショアベンダーにシステム開発の一部を依頼しました。
しかし納品された成果物に多くの不具合やバグがあり、日本のベンダーが修正をしましたが不具合が解消しきらず、顧客は契約を打ち切る決断をします。
元請けのベンダーは成果物の検収が完了していないと主張し、残金の支払いを拒否しています。
残金支払い拒否に対して、オフショアベンダーは残金の支払いを求めて訴訟に繋がりました。
結果的に元請けベンダーが作業の終了後に注文書を発行していることから、検収が完了していると判断されました。
納品に関するトラブルを回避するためには契約終了、納品完了の定義を明確にする必要があります。
契約書や仕様書に細かく内容を記載して、依頼者とベンダーの両方が納得できるまで話し合いをしながら進めていくと良いでしょう。
度重なるトラブルによる訴訟
2つ目は、依頼側とベンダー側の両方でトラブルが重なり訴訟に繋がった事例です。
某証券会社が大手ベンダーに開発を依頼して、海外製パッケージソフトを利用したシステムを導入しようとしましたが失敗に終わってしまいます。
大規模なプロジェクトのため入念な準備が必要でしたが、要件定義の段階から遅延が発生していました。
要件変更が繰り返し行われ、工数の膨れ上がりを是正するため、ベンダー側から工数削減の提案を行いましたが、業務改善がされませんでした。
結果的に、度重なるトラブルとベンダー側の人員の離脱も相次いでプロジェクトが途中で終了しています。
依頼側（某証券会社）がベンダー側の責任を求め訴訟になりましたが、依頼側の協力不足が開発遅延の原因との判決結果が出ました。
成果物を納品する請負契約において、仕様確定後の仕様変更は大幅な軌道修正が必要になり、開発費用の膨大化や納期遅れの原因になります。
オフショア開発のパートナー選びの判断基準
オフショア開発では文化や価値観の違う企業と開発を進めるので、成果物の品質や仕事の進め方に心配を抱く方もいるのではないでしょうか。
そこで重要なのが、信頼できるパートナーを選べるかです。
オフショア開発におけるパートナー選びの判断基準を解説します。
具体的には次の内容を確認します。
- コミュニケーション無理なく行える
- 依頼したい分野の開発実績がある
- ベンダー側の管理体制が構築されている
コミュニケーションを無理なく行える
1つ目はコミュニケーションを無理なく行えるかを確認します。
海外の企業に開発を依頼する際は、詳細な要件や仕様が決まっている場合でも、考えや意図・要望がうまく伝わらない場合があるため、コミュニケーションを無理なく行えるかは大切です。
可能であれば、実際のプロジェクト担当者と打ち合わせを行い、確かめるのが良いでしょう。
ベンダーの日本語対応レベルや通訳の有無なども確認しましょう。
また仕様や納品物の認識違いを防ぐため、進捗確認を定期的に実施すると品質を高められます。
依頼したい分野の開発実績がある
2つ目は依頼したい分野の開発実績があるかを確認します。
実績がない企業に依頼すると、想定している品質に満たなかったり、納期に間に合わなかったりなどトラブルに繋がるケースがあるからです。
また、日本企業との開発実績があれば、日本の企業文化への理解をしているので開発を進めやすくなります。
今までの開発プロジェクトの内容や規模、業種、工期などを確認しておきましょう。
そして、可能な範囲でサンプルとして過去のプロジェクトにおけるソースコードを取得すれば、エンジニアの技術レベルの分析が可能です。
他にもプロジェクトの規模を縮小した仕様で、プロトタイプを作成してもらうのもエンジニアの技術レベルを確認するのに有効です。
ベンダー側の管理体制が構築されている
3つ目の確認項目は、ベンダー側の管理体制が構築されているかです。
これはラボ型開発の場合に当てはまります。
契約期間中に人員が稼働できるのか、メンバーが固定されるのかなどの確認をします。
メンバーが他のプロジェクトも兼務していて、自社の開発を進められないといった事態を防ぐための確認です。
ラボ型開発の場合は、一定期間リソースを確保する契約のため、メンバーが稼働しない時間があると費用を損してしまいます。
進捗管理の体制の他にもコーディング規約を守れているかチェックをし、もしコーディング規約を守れていない場合はベンダー側で修正する体制が整っているかも確認しておきましょう。
オフショア開発の成功のポイントを以下の記事で分かりやすく解説しているので、失敗を回避したい方はご参考になさってください。
オフショア開発を成功させるポイント
オフショア開発では海外の企業と開発を行うため、意思疎通や品質管理で難しい点がありますが、うまく活用できれば大きなメリットが得られます。
ここではオフショア開発を成功させるポイントを解説します。
要件や仕様・目的を明確にする
オフショア開発で成果を出すには、要件や仕様・目的の明確化が大切です。
要件や仕様が明確になっていないと、開発工数や工程・予算なども詳細に決まらないため、開発が進まないからです。
仮に開発をスタートできても指示内容が明確にできないため、想定している品質で納品されない事態に繋がる恐れがあります。
もし自社で詳細な要件定義や設計が難しい場合は、要件定義からサポートしてくれる企業を選ぶと良いでしょう。
ITシステムの設計について詳しく知りたい方は下記の記事をご覧ください。
設計の流れやうまく進めるポイントを解説しています。
コミュニケーションを綿密にする
言語の問題や価値観の違いで認識の相違が起こりやすいため、同じ日本企業に依頼するより綿密なコミュニケーションをする必要があります。
例えば、プロジェクト開始直後は仕様やUI（ユーザーインターフェース）のイメージについての認識が合うまで週に1度打ち合わせを行うなどです。
プロジェクト全体を通してコミュニケーションは重要ですが、特にプロジェクトの初期に認識の相違を減らす体制を構築できると、品質の担保にも繋がります。
また指示や意思表示は曖昧にせず明確で具体的な内容で伝えるのがポイントです。
ベンダーを慎重に選ぶ
信頼できるベンダーを選べるかも開発の成功を左右するポイントです。
例えば、見積もりの妥当性を判断するため、相場や想定される工数ともらった見積もりを比較するなどです。
他にも前述のパートナー選びの基準も参考にして、信頼できるベンダーを探しましょう。
契約前に決まりを明確にしてオフショア開発の準備を進めよう
日本の企業同士でも開発を進める際にも、仕様やインターフェースに対する認識の相違が発生する可能性があります。
海外のベンダーとは言語や考え方が違うため、より認識の相違が起こりやすいです。
そのため、入念な準備が必要です。
開発の仕様や要件のみならず、準拠する法律やトラブルが起きた際の対応方法なども契約前に企業間の決まりを明確にしておきましょう。
また、オフショア開発の準備の前にオフショア開発の事情に詳しい専門家に相談するのも、必要なことが分かるためおすすめです。
