ODCモデルとは？オフショア開発の専属拠点方式と発注者の契約条件

オフショアベンダーから「ODCモデルで専属チームを組みませんか」と提案され、10名規模・12ヶ月といった契約書ドラフトを受け取ったものの、どこを確認すればよいのか分からないまま止まっている。そんな状況は珍しくありません。金額の妥当性は比較検討できても、「稼働が埋まらない月も満額を払うのか」「慣れた頃にメンバーを別案件へ異動させられないか」「うまくいかなかったときに途中で抜けられるのか」といった問いには、提案書のどこにも答えが書かれていないからです。

用語の揺れも判断を難しくしています。あるベンダーは「ODC」と呼び、別のベンダーは同じ体制を「ラボ型開発」「ラボ契約」「専属チーム」と表現します。検索して出てくる解説記事の多くはオフショアベンダー自身が書いたもので、定義とメリット・デメリットの紹介までは丁寧でも、契約書のどの条項を確認すべきかという実務の話には踏み込んでいません。結果として、稟議に必要な「このリスクはこの条項で潰した」という説明材料が手に入らないまま、判断だけを迫られることになります。

ODCモデルは、案件ではなく「体制」を一定期間買う契約です。だからこそ、成否を左右するのは技術力の見極めよりも先に、契約条件の設計にあります。専任性・契約期間・増減員・稼働時間の定義・知的財産権・セキュリティ・準拠法という7つの論点をどう書いてもらうかで、同じ人数・同じ単価の提案でも発注者が負うリスクは大きく変わります。

本記事では、ODCモデルの定義と仕組みを整理したうえで、ラボ型開発・請負契約との違い、メリットと引き換えに発注者が負う責任、契約締結前に確認すべき7つの契約条件、見落とされやすい撤退・移管の設計、そして向き不向きの判断基準と導入手順までを、発注者の視点で解説します。契約書ドラフトを手元に置きながら読み進められる構成にしています。

なお、専属チームを月額で確保するという契約形態そのものの仕組み・費用相場・成果KPIによるコスト管理といった、国内外に共通する基礎はラボ型開発契約とはとラボ型開発の費用相場と判断軸で扱っています。本記事はそれらを前提としたうえで、拠点が海外にあることで追加される契約上の論点に重心を置いて掘り下げます。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

ODCモデルとは？オフショア開発における専属拠点方式の仕組み

ODCモデルとは、海外のベンダー拠点内に発注者専属の開発チームと開発環境を一定期間確保し、その体制に対して月額で対価を支払うオフショア開発の方式です。ODC は Offshore Development Center（オフショア開発センター）の略で、日本語では「オフショア開発センター」「海外開発拠点」などと表記されます。

請負契約との最も大きな違いは、契約の単位が「案件」ではなく「体制」であることです。請負契約では「この機能をいくらで、いつまでに」という案件単位の合意を都度結びますが、ODCモデルでは「この人数の専属チームを何ヶ月確保するか」を合意します。開発するテーマは契約期間中に変わってもよく、優先度の入れ替えも発注者の裁量で行えます。その代わり、何を作らせるかを決めて供給し続ける責任は発注者側に残ります。

ODC（オフショア開発センター）の定義と、契約が成り立つ3つの条件

ODCが単なる海外への業務委託と区別されるのは、次の3つの条件が揃っているからです。

• 要員の専任: 割り当てられたメンバーが、契約期間中は発注者の業務に専従する。他社案件との掛け持ちを前提としない
• 拠点・環境の確保: ベンダー拠点内に作業スペース・開発環境・必要に応じて物理的に区画されたエリアを確保する
• 期間のコミット: 数ヶ月から1年といった一定期間、その体制を維持することを双方が約束する

この3条件のうちどれか一つでも契約書に書かれていない場合、実態は「必要なときに人を出す」通常の業務委託と変わらなくなります。提案書に「専属」「専任」と書かれていても、契約書の条文に落ちていなければ拘束力は生まれません。まずはドラフト内でこの3点がどのように表現されているかを確認するところから始めるとよいでしょう。

「専属」が実務上何を意味するのか

「専属」という言葉は、実務では次の3つの論点に分解できます。

第一に、誰の指示で日々の作業が決まるのかです。発注者が優先度とタスクを提示し、ベンダー側のリーダー（プロジェクトマネージャーやブリッジSE）がチーム内に展開する形が一般的です。発注者が現地メンバー個人へ直接的・具体的な業務命令を出す運用は、後述するとおり契約形態によっては別の論点を生みます。

第二に、他案件との兼務が許されるのかです。「専任」と書かれていても、稼働率80%といった但し書きが入っていれば残りは他案件に充てられる可能性があります。100%専従なのか、一定の稼働率を保証する形なのかを確認してください。

第三に、チームの入れ替わりをどこまで抑えられるのかです。ODCの価値の中心は、同じメンバーが業務ドメインを理解し続けることにあります。要員の交代が自由にできる契約では、その価値が担保されません。この点は契約条件の確認項目としてあらためて詳述します。

同じ略語で呼ばれる別概念との混同を避ける

技術情報を検索していると、ODC という略語がまったく別の意味で使われている場面に出会うことがあります。ローコード開発プラットフォームである OutSystems のクラウド製品「OutSystems Developer Cloud」も ODC と略されるためです。

本記事で扱う ODC はオフショア開発センター（Offshore Development Center）を指し、開発プラットフォームの名称とは無関係です。ベンダーとの会話や社内資料で誤解が生じないよう、初出時は「ODC（オフショア開発センター）」と正式名称を併記しておくと安全です。

ODCとラボ型開発・請負契約の違いを契約形態から整理する

複数のベンダーから提案を受けている場合、最初に立ちはだかるのが「A社のODCとB社のラボ型開発は同じものなのか」という問題です。ここを整理しないと、提案を同じ土俵で比較できません。

ラボ型開発（ラボ契約）との違いは「拠点」か「人」か

結論から言えば、ODCとラボ型開発（ラボ契約）は実務上ほぼ同義として使われています。オフショア開発の情報プラットフォームでも、ラボ型開発は「ラボ契約」または「ODC（オフショア開発センター）」とも呼ばれる開発形態として説明されています（オフショア開発.com「ラボ型開発（ラボ契約・ODC）とは」）。

違いがあるとすれば、語の重心です。「ODC」は拠点・設備・組織としての開発センターに軸足があり、専用エリアやセキュリティ区画を含む体制を指して使われる傾向があります。一方「ラボ型開発」は人的リソースの確保に軸足があり、1名からでも成立する契約として紹介されることが増えています。同じ言葉でもベンダーによって含まれる範囲が異なるため、比較検討の場では語の定義ではなく、提供される内容（人数・専任度・拠点・環境・管理体制）を項目ごとに揃えて確認することが実務的です。

なお国内前提の契約形態との対比については、SES・受託開発・ラボ型開発の違いで詳しく整理しています。また、受託開発（請負）・準委任・ラボ型の3方式を責任範囲の観点から比較した整理と、成果KPIによるコスト管理・月次レビューの組み込み方はラボ型開発契約とはで解説しています。本記事はこれらの基礎を前提としたうえで、拠点が海外にあることで追加される論点（現地の稼働カレンダー・越境でのデータ取り扱い・準拠法と裁判管轄・為替）に絞って掘り下げます。

請負契約・準委任契約とのリスク配分の違い

ODC・ラボ型開発は、法的には準委任契約として整理されるのが一般的です。準委任契約は業務の遂行を目的とする契約で、成果物の完成義務を負わない点が請負契約との決定的な違いになります。

この違いは、そのままリスク配分の違いになります。請負契約では、仕様どおりのものが完成しなかった場合や契約内容に適合しない不具合があった場合、ベンダーが契約不適合責任を負います。一方、準委任契約では善良な管理者の注意をもって業務を遂行していれば義務を果たしたことになり、成果物が想定に届かないリスクは発注者側に残ります。

つまりODCモデルを選ぶということは、「柔軟性と継続性を得る代わりに、完成に対する責任を自社で引き受ける」という取引をすることを意味します。仕様の提示、優先度の決定、受け入れ判断を自社で行える体制があるかどうかが、契約形態を選ぶ前提条件になります。

契約形態別の比較表と、選択の目安

選択の目安はシンプルです。要件が固まっていて一度作れば終わりなら請負契約、継続的に作り続けるテーマがあり仕様変更も見込まれるならODC、特定スキルを短期間だけ補いたいなら個別要員型という整理になります。

国内のSES・受託との位置づけの違い

ODCは「契約形態」と「拠点の立地」という2つの軸が重なった呼称です。ラボ型開発という契約形態を、海外拠点で実施したものがODCだと考えると整理しやすくなります。国内のニアショア拠点で同じ形態を組めば、ラボ型ではあってもODCとは呼ばれないのが一般的です。

したがって、国内のSES・受託開発と比較する際は、契約形態の違い（完成義務の有無・指揮命令の在り方）と、拠点が海外であることによる違い（時差・言語・法制度・為替）を分けて評価する必要があります。オフショア開発そのものの全体像や費用の考え方については、オフショア開発とはで解説しています。

ODCモデルのメリットと、発注者が引き受けることになるデメリット

ODCモデルの評価は、メリットだけを並べても稟議には通りません。得られるものと、引き換えに負うものを対にして把握しておくことが重要です。

継続契約だから得られる3つのメリット

ドメイン知識が蓄積する。同じメンバーが継続して関わるため、業務仕様・既存コードの経緯・過去の意思決定といった暗黙知がチームに残ります。案件ごとに要員が入れ替わる体制では、この蓄積が毎回リセットされます。

都度見積もり・都度立ち上げのオーバーヘッドが減る。請負契約では、機能追加のたびに要件定義・見積もり・発注手続き・キックオフというサイクルを回す必要があります。ODCでは体制がすでに動いているため、優先度を決めてバックログに積むだけで着手できます。バックログが滞留している組織ほど、この差は大きく効いてきます。

優先度の変更に追従しやすい。市場の反応を見て開発テーマを入れ替える、緊急の不具合対応を割り込ませるといった判断を、契約変更なしに実行できます。プロダクト開発のように仕様が動くことを前提とした開発と相性がよいのは、この柔軟性によるものです。

発注者側に移るコストと責任

一方で、ODCモデルでは次の負担が発注者側に移ります。

タスクを切らさず供給する責任。体制は月額で確保されているため、渡すタスクがなくてもコストは発生します。10名の体制を組んだのに社内の要件定義が追いつかず、実質的に稼働していない月が生じれば、その分は回収できません。事前に「半年分のバックログがあるか」を棚卸ししておく必要があります。

仕様提示と受け入れ判断の工数。完成義務がベンダー側にない以上、何を作るかの決定と、できあがったものの受け入れ判断は発注者が行います。プロダクトオーナーに相当する役割を社内に置けるかどうかが実行可能性を左右します。

マネジメント工数の内製化。進捗の可視化、品質基準の設定、コミュニケーション設計を発注者側でも担う必要があります。ブリッジSEやベンダー側PMが介在しても、最終的な優先度判断は自社で行うことになります。加えて海外拠点では、時差により指示と成果物の往復に1日単位のラグが生じます。仕様の曖昧さがそのまま待機時間に変わるため、国内ベンダーに同じ役割を求める場合より、文書で明示する負荷は高くなります。

「安くなる」前提が崩れる条件

かつてオフショア開発の主な動機はコスト削減でしたが、その前提は近年変化しています。オフショア開発.com が発行する『オフショア開発白書 2025年版』では、委託先国の人月単価が上昇傾向にあり、円安の影響もあってコスト削減を目的に挙げる企業が前年より減少していることが示されています（出典: オフショア開発.com『オフショア開発白書 2025年版』）。

とくに次の条件が重なる場合、コスト面の優位は生まれにくくなります。

• 為替が円安に振れている局面: 外貨建て契約では、契約時点の想定レートから乖離した分がそのまま円建てコストの増加になります
• 規模が小さい: 数名月規模では、ブリッジSEや管理コストの固定費が相対的に重くなります
• 期間が短い: 立ち上げ期間中はチームの生産性が本来値に届かないため、短期契約では立ち上げコストを回収し切れません

コスト削減だけを稟議の根拠にすると、為替や単価の変動で前提が崩れたときに説明が成り立たなくなります。「開発リソースの継続的な確保」「バックログの消化速度の改善」といった、金額以外の効果も併せて評価軸に入れておくことをおすすめします。なお、国内エンジニアの採用難という背景については、経済産業省の試算で2030年時点のIT人材不足が最大約79万人と見込まれていることが一つの参考になります（出典: 経済産業省「IT人材需給に関する調査」2019年）。

体制人数別の月額の目安や役割別の人月単価といった費用相場はラボ型開発の費用相場と判断軸で整理しているため、本記事では契約条件がコストに与える影響に絞って解説します。

発注者が確認すべきODCの契約条件7項目

ここからが本題です。ODCの契約書ドラフトを受け取ったら、次の7項目がどう書かれているかを順に確認していきます。まず全体像をチェックリストとして示します。

以下、それぞれについて「なぜ争点になるか」「契約書で確認する文言」「ベンダーへの確認質問」の3点で整理します。なお、以下は契約書を読む際の観点を示すものであり、個別の契約に対する法的判断については弁護士等の専門家にご相談ください。

専任性と要員交代

なぜ争点になるか: ODCの価値はメンバーの継続性にあります。ところが契約書には「所定の人数を確保する」とだけ書かれ、誰がその人数を構成するかには触れていないことが少なくありません。この状態では、業務に習熟したメンバーがより単価の高い別案件へ異動しても契約違反にはならず、発注者は毎回ゼロから教育し直すことになります。海外拠点では現地の転職市場が活発な地域も多く、要員の入れ替わりは国内より起きやすい前提で条項を設計しておくほうが安全です。

契約書で確認する文言: 要員の氏名または識別子と役割を別紙（要員一覧・体制図）で特定し、契約本文から参照する形になっているか。交代を行う場合の事前通知期間（例: 30日前）、後任のスキル要件（同等以上であること）、引き継ぎ期間中の並行稼働と、その期間の費用負担が誰にあるかが定められているか。

ベンダーへの確認質問:

• 提案書に記載のメンバーは契約開始時点で確定していますか。確定していない場合、いつ確定しますか
• 要員を交代する場合、事前通知は何日前になりますか。後任のスキルはどのように担保されますか
• 引き継ぎのための並行稼働期間は設けられますか。その期間の費用はどちらの負担ですか

契約期間・最低契約期間・自動更新と解約予告

なぜ争点になるか: ラボ契約は従来、半年から1年程度の期間を想定するのが一般的でしたが、近年は1ヶ月単位や最小1名からの契約を提供するベンダーも増えています（オフショア開発.com）。つまり期間の条件は交渉可能な余地があります。にもかかわらず「12ヶ月・自動更新・解約予告6ヶ月前」といった条件をそのまま受け入れると、うまくいかないと判明してから解約が成立するまでに長い時間がかかります。

最低契約期間・解約通知期間・違約金という3点の基本的な確認観点は、国内のラボ型開発契約でも共通します（ラボ型開発契約の解約条項）。海外ベンダーとの契約で追加になるのは、通知が有効に届いたことをどう証明するかという手続きの問題です。国際郵便の到達に日数を要する一方、電子メールでの通知を有効と認めない条項になっていると、予告期間の起算日がずれて解約時期が後ろにずれる可能性があります。

契約書で確認する文言: 最低契約期間（ミニマムコミットメント）の有無と長さ。自動更新条項の有無と、更新を止める場合の申し出期限。中途解約が可能かどうか、可能な場合の予告期間と違約金の算定方法。トライアル期間や初期の見直し時点（例: 3ヶ月後に継続可否を判断できる条項）を設けられるか。解約通知の手段（書面・電子メール）と、通知の効力が発生する時点（発信時か到達時か）、通知に使用する言語。

ベンダーへの確認質問:

• 最低契約期間は何ヶ月ですか。3ヶ月や6ヶ月に短縮する選択肢はありますか
• 自動更新は何ヶ月単位ですか。更新を止める場合、いつまでに申し出る必要がありますか
• 中途解約する場合の違約金はどのように計算されますか
• 解約通知は電子メールでも有効ですか。通知の効力はいつ発生する扱いになりますか

増員／減員（ランプアップ・ランプダウン）の通知期間と単価の扱い

なぜ争点になるか: ODCの魅力として「柔軟にスケールできる」と説明されることが多い一方、運用上は増員が歓迎されても減員には条件が付くのが通例です。減員の通知期間が長い、減員後に残る要員の単価が上がる、一度減らすと元の人数に戻す際に再度立ち上げ費用がかかる、といった条件は契約書を読まないと分かりません。

契約書で確認する文言: 増員・減員それぞれの事前通知期間（非対称になっていないか）。減員できる下限人数。減員に伴う違約金・調整金の有無。人数変動時に単価が再計算される条件（例: 5名未満になった場合は単価改定）。増員時のリードタイムと、要員が確保できなかった場合の扱い。

ベンダーへの確認質問:

• 減員する場合の通知期間は何日前ですか。増員の通知期間と差がありますか
• 人数を減らした場合、残るメンバーの単価は変わりますか
• 増員を依頼してから稼働開始までのリードタイムはどの程度を見込めばよいですか

稼働時間・工数の定義

なぜ争点になるか: 月額固定に見える契約でも、実態は「1人あたり月○時間」を前提とした計算になっていることがあります。この前提時間の定義が曖昧だと、現地の祝日が多い月に実稼働が減っても満額を請求される、逆に繁忙期に超過した分が追加請求される、といった認識のずれが生じます。ベトナムの旧正月（テト）のように、現地特有の長期休暇がある地域では特に注意が必要です。日本の祝日カレンダーとも一致しないため、どちらの休日に合わせるのかを明示しておかないと、稼働日数の前提が双方で食い違います。

契約書で確認する文言: 1人月あたりの標準稼働時間（例: 160時間/月）の定義。現地の祝日・休暇が標準時間にどう反映されるか。未消化分を翌月へ繰り越せるか、繰り越せる場合の上限と有効期限。超過稼働が発生した場合の事前承認プロセスと精算単価。稼働報告（タイムシート）の提出頻度と形式。

ベンダーへの確認質問:

• 1人月の標準稼働時間は何時間ですか。現地の祝日はどのように扱われますか
• 稼働が標準時間に届かなかった月、その差分は翌月に繰り越せますか
• 超過稼働が必要になった場合、事前承認の手続きと精算単価はどうなりますか

知的財産権の帰属とソースコード・ドキュメントの引き渡し

なぜ争点になるか: 開発した成果物の著作権が発注者に帰属することを契約書に明記していない場合、権利が制作者側に残るリスクがあります。将来的に内製化する、別のベンダーへ移管する、事業譲渡やデューデリジェンスの対象になるといった局面で、権利関係が整理されていないと大きな障害になります。またベンダーが持ち込んだ既存ライブラリやフレームワーク、利用したOSSのライセンス条件も、成果物の再利用可能性に影響します。

国内契約であれば帰属を明記すれば足りる場面でも、海外法人との契約ではどの国の法律に基づいて権利が移転するのかが別途論点になります。準拠法が相手国法である場合、職務著作（従業員が業務で作成した著作物の権利が誰に発生するか）の扱いや、権利譲渡が有効に成立する要件が日本法と異なることがあります。帰属条項は、後述する準拠法の条項とセットで確認してください。

契約書で確認する文言: 著作権（著作権法第27条・第28条の権利を含む）の譲渡が明記されているか、譲渡の時期は検収時か対価支払時か。著作者人格権の不行使に関する定めがあるか。ベンダー持込資産（既存ライブラリ・共通基盤）の有無と、それらの利用許諾範囲・期間。使用するOSSのライセンス条件を報告する義務。ソースコード・設計書・環境構築手順書の引き渡し時期と形式。

ベンダーへの確認質問:

• 成果物の著作権は、いつの時点で当社に移転しますか
• 開発にあたって貴社の既存資産を使用する予定はありますか。ある場合、契約終了後も継続利用できますか
• 使用するOSSのライセンス一覧は提出いただけますか

秘密保持・再委託禁止・拠点セキュリティ

なぜ争点になるか: 海外拠点に自社のソースコードや、場合によっては顧客データを扱わせることになります。秘密保持契約（NDA）を結んでいても、再委託が無制限に認められていれば情報が接触する範囲は契約相手を越えて広がります。また物理的なセキュリティ（専用エリアの施錠、私物デバイスの持ち込み制限、記録媒体の使用制限）は、契約書ではなくセキュリティ規程や覚書で定めることが多く、契約書だけを読んでいると見落としやすい領域です。

契約書で確認する文言: 秘密保持義務の対象範囲と存続期間（契約終了後何年か）。再委託の可否と、認める場合の事前承諾の要否・再委託先への義務の承継。開発拠点の物理的な区画（他社案件と同一フロアか、施錠されたエリアか）。デバイス・記録媒体の持ち込み制限。本番データを開発環境で扱う場合の匿名化・マスキングの取り決め。アクセス権限の付与・削除の手順と、契約終了時のアカウント無効化。個人情報を扱う場合の越境移転に関する取り決め。

ベンダーへの確認質問:

• 当社案件の開発エリアは他社案件と物理的に分離されていますか
• 再委託を行う予定はありますか。ある場合、事前承諾を必要とする条項を入れられますか
• メンバーの入退場管理、デバイス持ち込み制限はどのように運用されていますか

準拠法・裁判管轄・紛争解決手段

なぜ争点になるか: 海外ベンダーとの契約では、紛争が生じた際にどの国の法律が適用され、どこで争うのかが実務上の大きな分かれ目になります。相手国の裁判所が管轄となる契約では、言語・費用・時間のいずれの面でも発注者側の負担が重くなります。また、日本の判決が相手国で執行できるとは限らないため、仲裁による解決を選択肢に入れる考え方もあります。

契約書で確認する文言: 準拠法（日本法か、ベンダー所在国法か）。裁判管轄（専属的合意管轄か、非専属か）。仲裁条項がある場合、仲裁機関・仲裁地・使用言語。契約書の正文が日本語か英語か（翻訳版との齟齬が生じた場合にどちらが優先するか）。日本法人を介した契約なのか、海外法人と直接契約するのか。

ベンダーへの確認質問:

• 契約の当事者は日本法人ですか、海外法人ですか
• 準拠法と裁判管轄はどのように定められていますか。日本法・日本の裁判所とすることは可能ですか
• 契約書の正文はどちらの言語ですか。日英で内容に相違があった場合、どちらが優先しますか

準拠法や知的財産権、NDAといったオフショア開発全般に共通する契約の基礎については、オフショア開発の進め方でより広く扱っています。本記事の7項目と併せて確認すると、契約書レビューの抜け漏れを減らせます。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

契約書で見落とされやすいODC特有の論点（撤退・移管・指揮命令）

前の章で挙げた7項目は、ベンダー側が用意する契約書ドラフトにも何らかの形で条項が存在することが多い領域です。一方、ここで扱う3つの論点は、そもそも条項自体が用意されていないことが珍しくありません。稟議で最も鋭く質問されるのもこの領域です。

撤退・移管を想定したExit条項の設計

「うまくいかなかったらどうするのか」は、稟議において必ず問われます。ところが契約書に書かれているのは解約の手続きだけで、解約後に自社の開発が継続できる状態をどう確保するかは定められていないことが大半です。

Exit（撤退・移管）を想定するなら、少なくとも次の点を契約書または覚書に落としておくと安全です。

• 引き渡し対象の特定: ソースコード、設計書、テストケース、環境構築手順、CI/CD設定、運用手順書、未解決の課題一覧
• 引き渡しの形式と期限: リポジトリの移管方法、解約通知から何日以内に引き渡すか
• アカウント・権限の返還: クラウド環境、リポジトリ、チケット管理ツール、外部サービスの管理者権限の移譲手順
• 知識移転期間: 後続の体制（自社または別ベンダー）へ引き継ぐための期間を確保できるか。その期間の稼働をどう精算するか
• 並行稼働の可否: 移管先チームと一定期間並走できるか。できる場合の人数と期間

海外拠点からの移管では、引き渡し物が現地語や英語で作成されている可能性もあります。ドキュメントの記述言語と、引き渡し後に自社または国内ベンダーが読める状態かどうかも、引き渡し対象の定義と併せて確認しておくとよいでしょう。

契約締結の段階でExitの話を持ち出すことに気後れする方もいますが、これは「疑っている」のではなく「事業継続性を担保する」ための実務であり、長期契約では双方にとって合理的な取り決めです。むしろ、この議論に応じるかどうかがベンダーの姿勢を測る材料にもなります。

指揮命令と偽装請負リスクの境界

ODCモデルでは、発注者がタスクの優先度を決め、日々の進捗を確認します。この運用が「指揮命令」に当たるのではないかという懸念を持つ方は少なくありません。

日本の労働者派遣法では、契約の形式にかかわらず、実態として発注者が受注者の雇用する労働者に対して直接具体的な指揮命令を行っている場合、労働者派遣に該当すると判断されます。この区分の基準は「労働者派遣事業と請負により行われる事業との区分に関する基準」（いわゆる37号告示）に示されており、厚生労働省が疑義応答集を公開しています。準委任契約であっても、実態に指揮命令関係があれば形式を問わず派遣法の適用を受ける点が明記されています。

海外拠点で海外法人に雇用されているメンバーに対する業務依頼は、日本の労働者派遣法が直接適用される場面とは前提が異なります。一方で、国内常駐を伴う場合や、日本法人を介して国内で作業が行われる場合には、この区分の議論が現実的な論点になります。ブリッジSEが日本国内の発注者オフィスに常駐するといった体制を検討している場合は、次の点を整理しておくとよいでしょう。

• 契約の当事者と、作業を担うメンバーの雇用主が誰か
• 作業場所はどこか（発注者オフィスか、ベンダー拠点か）
• 業務の割り当て・勤怠管理・作業手順の指示を誰が行う建て付けか
• 契約書上の指示系統と、実際の運用が一致しているか

契約形態と実運用が乖離していると、契約書がどう書かれていてもリスクは残ります。判断に迷う体制を検討する場合は、社内法務や専門家に確認したうえで設計してください。

為替変動・単価改定条項の確認ポイント

長期契約では、為替と現地人件費の変動をどう扱うかが金額に直結します。前述のとおり、近年は委託先国の人月単価が上昇傾向にあり、円安も重なってコスト面の優位は縮小しています。この状況で単価改定条項が一方的な内容になっていると、契約期間中に想定外のコスト増を受け入れざるを得なくなります。

確認すべきは次の点です。

• 契約通貨: 円建てか、外貨（米ドル等）建てか。外貨建ての場合、為替リスクは発注者が負う
• 改定の頻度と上限: 単価改定が可能な時期（年1回など）と、1回あたりの改定率の上限が設けられているか
• 改定の手続き: 一方的な通知で改定できるのか、双方協議のうえ合意が必要なのか
• 改定の根拠: 現地物価指数・法定最低賃金の改定など、客観的な指標に紐づいているか
• 改定に応じない場合の扱い: 合意に至らなかった場合に契約を終了できるか、その際の予告期間

改定条項そのものを拒否する必要はありません。上限と手続きを明確にし、想定される最大コストを事前に見積もれる状態にしておくことが目的です。

ODCが向く発注者・向かない発注者の判断基準

ここまで契約条件を確認してきましたが、そもそも自社にODCが適しているかを見極めることも同じくらい重要です。契約条件をどれだけ精緻に詰めても、前提が合っていなければ成果は出ません。

継続的な開発需要があるか、社内にプロダクトオーナー役を置けるかといった、専属チーム型の契約全般に共通する判断軸はラボ型開発の費用相場と判断軸で3つの軸として整理しています。以下では、それらを満たしていることを確認したうえで、拠点が海外にあることで追加される判断材料を重ねていきます。

ODCが機能する4つの条件

次の4条件が揃っているとき、ODCモデルは効果を発揮しやすくなります。

1. 開発テーマが継続的に存在する。半年から1年先まで、着手すべき機能追加・改善のバックログが積み上がっている状態です。「今ある案件が終わったら次は未定」という状況では、体制を維持するコストが無駄になります。海外拠点では時差により指示と成果物の往復に1日単位のラグが生じるため、バックログが薄いとそのラグがそのまま待機時間に変わります。

2. 仕様が動くことを前提としている。市場の反応や利用データを見ながら開発内容を調整するプロダクト開発では、都度見積もりの請負契約よりODCのほうが機動的です。ただし口頭での軌道修正が難しい分、変更内容を文書化して伝える運用に耐えられるかも併せて確認します。

3. 社内に仕様提示と受け入れ判断ができる人がいる。完成義務がベンダーにない以上、この役割を欠くと開発が空回りします。海外拠点では、国内ベンダーに同じ役割を求める場合より仕様を明文化する負荷が高くなるため、その工数を織り込んだうえで担当者を確保できるかが分かれ目です。

4. 一定以上の規模と期間を確保できる。少人数・短期間では立ち上げコストと管理コストが相対的に重くなります。言語・商習慣の違いを吸収する期間も加わるため、立ち上げは国内より長く見積もるのが安全です。何名・何ヶ月なら投資が回収できるかを事前に試算しておくとよいでしょう。

見送るべきケースと代替手段

反対に、次のようなケースではODC以外の選択肢のほうが適しています。

最後のケースは特に重要です。社内体制が整っていない状態でODCを立ち上げると、稼働しないチームに月額を払い続ける事態になりかねません。「体制を作れば開発が進む」のではなく、「進めるべき開発が明確だから体制が活きる」という順序を確認してください。

判断フロー（チェック順序）

導入可否は、次の順序で確認していくと整理しやすくなります。

1. タスクの継続性: 今後6ヶ月以上、継続的に開発すべきテーマがあるか → なければ請負契約を検討
2. 契約期間: 最低3〜6ヶ月以上コミットできるか → できなければスポット調達を検討
3. 規模: 3名以上の体制を必要とするか → 下回るなら管理コストとの見合いを再計算
4. 社内体制: 仕様提示と受け入れ判断を担う担当者を置けるか → 置けなければ体制整備が先
5. コスト前提: 為替変動を織り込んでも投資に見合うか → 見合わなければ国内・ニアショアと再比較
6. 海外拠点固有の前提: 時差・言語・現地の長期休暇・データの越境移転を運用に織り込めるか → 織り込めなければ国内のラボ型開発・ニアショアを再検討

このうち1つでも「いいえ」があれば、いきなり大規模な契約を結ぶのではなく、小規模なトライアルから始める判断が現実的です。

ODC導入の進め方と契約締結前に社内で決めておくこと

導入可否の判断がついたら、契約締結までの進め方を設計します。契約条件の交渉は、社内の準備が整っていて初めて具体的に行えます。

契約前に社内で確定させる4項目

スコープ: ODCに任せる開発領域と、社内に残す領域を線引きします。要件定義は社内、実装とテストはODC、といった分担を明示しておくと、後の役割の押し付け合いを防げます。

体制: 発注者側の窓口、意思決定者、レビュー担当を明確にします。ベンダー側についても、ブリッジSE・PM・QAがそれぞれ誰の費用で配置されるのか（体制人数に含まれるのか、別建てか）を確認します。ブリッジSEが体制人数にカウントされる場合、開発を担当する人数は提案書の数字より少なくなります。

意思決定者: 仕様の最終判断を誰が行うかを1名に定めます。複数人の合議になると、時差のある体制では判断待ちが積み上がります。

予算枠: 月額のほか、立ち上げ費用、増員時の追加費用、為替変動の許容幅、超過稼働の上限額を含めた年間の上限を決めておきます。契約交渉の場で「いくらまでなら合意できるか」が定まっていないと、条件面での譲歩を求められた際に判断できません。

小規模トライアルで検証すること

いきなり10名・12ヶ月の契約を結ぶ前に、2〜3名・1〜3ヶ月といった小規模なトライアルを設定できないか交渉する価値があります。近年は1ヶ月単位や少人数からの契約に応じるベンダーも増えているため、交渉の余地はあります。

トライアルで確認すべきは、技術力そのものよりも次の項目です。

• コミュニケーションの実効性: 質問への返答速度、認識のずれが起きたときの解消プロセス、日本語または英語での意思疎通の精度
• 開発プロセスの適合性: レビュー・テスト・リリースのフローが自社の基準に合うか
• 見積もり精度: 提示された工数と実績の乖離がどの程度か
• ドキュメントの粒度: 引き継ぎ可能な水準の記録が残るか
• 問題発生時の対応: 不具合や遅延が起きたときの報告のタイミングと内容

トライアルの結果を本契約の条件に反映できるよう、トライアル契約の段階で「本契約への移行判断の基準」と「移行しない場合の成果物の扱い」を決めておくと、判断がスムーズになります。

KPI・評価基準の設計と契約書への落とし込み

ODCの評価を稼働時間や人数で行うと、「時間は消化されているが成果が見えない」という状態に陥りやすくなります。評価指標は、次のようなアウトプット・アウトカムに近い項目で設計します。

そのうえで、合意したKPIを契約書のどこに書くかまで決めることが実務上の分かれ目です。提案書やキックオフ資料に書かれただけのKPIは、契約上の意味を持ちません。少なくとも次のいずれかの形で位置づけを明確にしておきます。

• 契約書の別紙（サービスレベルに関する覚書）として添付し、契約本文から参照する
• 月次報告書の記載項目として契約書に定め、報告義務を課す
• 一定水準を下回った場合の協議義務・改善計画の提出義務を定める

KPIに違約金を紐づけるかどうかは、準委任契約の性質上、慎重な検討が必要です。まずは「測定して報告する義務」と「基準を下回った場合に協議する義務」を定めるところから始めるのが現実的でしょう。

まとめ：ODCモデルは契約条件の設計で成否が決まる

ODCモデルは、海外拠点に発注者専属の開発チームと環境を一定期間確保し、案件ではなく体制に対して対価を支払うオフショア開発の方式です。ラボ型開発・ラボ契約とほぼ同義で使われ、法的には準委任契約として整理されるのが一般的です。成果物の完成義務がベンダー側にない代わりに、柔軟性と継続性が得られる取引だと理解しておくことが出発点になります。

契約書ドラフトを受け取ったら、次の7項目を順に確認してください。専任性と要員交代、契約期間と解約条件、増員・減員の条件、稼働時間の定義、知的財産権の帰属、秘密保持とセキュリティ、準拠法と裁判管轄です。さらに、条項自体が用意されていないことの多いExit条項（撤退・移管の設計）、国内常駐を伴う場合の指揮命令の整理、為替変動と単価改定条項の3点を加えると、稟議で問われる論点はおおむねカバーできます。

導入可否そのものについては、開発テーマの継続性・契約期間・規模・社内体制・コスト前提の5点を順に確認し、加えて時差・言語・越境データという海外拠点固有の前提を運用に織り込めるかを確かめます。いずれかに不安が残る場合は、小規模なトライアルから始めるか、国内のラボ型開発・ニアショアと比較し直す判断が現実的です。「体制を作れば開発が進む」のではなく、「進めるべき開発が明確だから体制が活きる」という順序は変わりません。

次のアクションとしては、本記事のチェックリストを手元の契約書ドラフトに当てはめ、記載が見当たらない項目・記載が曖昧な項目を洗い出すことをおすすめします。そのうえで各項目の確認質問をベンダーへ送れば、回答の内容と姿勢の両方から、長期のパートナーとして組める相手かどうかを判断する材料が得られます。

関連情報

オフショア開発の発注条件や契約内容の検討を進めている方向けに、判断材料をまとめたお役立ち資料をご用意しています。お役立ち資料一覧からご覧いただけます。

提示された契約条件の妥当性や、自社に合う開発体制の組み方についてご相談されたい場合は、お問い合わせフォームよりご連絡ください。要件の整理段階からご相談いただけます。

—Free Download / 資料ダウンロード

フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

• フリーランス新法への対応状況を社内で点検したい企業担当者
• 業務委託契約書・NDAの記載事項を確認したい法務担当者
• 偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。