導入

オフショア開発の契約形態は、大きく「ラボ型開発（準委任）」と「請負開発（成果物基準/固定）」の二つに大別されます。 契約の枠組み自体は日本国内の準委任運用に近いものはあるもののそのニュアンスは若干異なります。

このコラムではそれぞれの開発手法・契約の違いやプロジェクトごとにどちらの進め方をしたらいいのかを実際にベトナムで20年にわたりオフショア開発を行ってきた知見を元に説明していきます。

なお、一般にODC（Offshore Development Center）と呼ばれる形態は、本記事では「ラボ型開発」と表記を統一します。文脈によりODC/ラボ型/準委任**はほぼ同義として扱います。

請負開発とラボ開発について

請負開発・請負契約とは

請負開発は、あらかじめ成果物の範囲と品質、納期を合意し、その完成と検収をもって契約上の目的を達する形態です。契約前に要件定義やスケジュール、費用（見積り根拠を含む）を取り決め、合意内容に基づいてベンダーが開発を進めます。

支払いは検収後が原則としつつ、契約により着手金/中間金などのマイルストーン払いを設定することもあります。

請負契約のメリット

• 予算/納期の固定化
  事前に合意した範囲と金額、スケジュールに基づき進行でき、社内稟議が通しやすいです。
• 進行責任の明確化
  ベンダー側が詳細計画/進行管理を担うため、発注側の運用負荷を抑えやすくなります。
  社内にエンジニアやPMがいなくても開発を委託することができる点もメリットです。
• 受入基準の明確さ
  受入テスト/品質基準を契約時に定義でき、検収判断がしやすいというポイントがあります。

請負契約のデメリット

• 変更対応の硬直化
  仕様変更や優先順位の入れ替えにより契約の変更や追加費用が発生しやすくなります。
• 想定外への弱さ
  着手後に未知の前提が見つかると、再見積/工程再設計で停滞しやすい。
• 段階学習との相性
  PoC→改善→横展開のように学びを反映し続ける前提の案件では、都度の契約調整が増え、総コストとリードタイムが上振れする可能性が非常に高いです。

ラボ型開発・ラボ契約（準委任）とは

ラボ型開発は、専任メンバーを一定期間確保し、発注側の優先度/学習結果に応じて、短いサイクル単位で取り組み範囲を入れ替えながら進める形態です。
請負に比べ、途中の変更や優先順位の入替に対応しやすい運用を想定します。

ラボ型開発のメリット

• 変更対応の柔軟性
  仕様追加や順序の入替が出ても、計画の再配分で反映しやすい点が挙げられます。
  ラボ型開発は計画差し替えがしやすい一方、費用は稼働量に比例します。
• 継続チームの効率化
  同じメンバーが継続することで、過去決定や背景の共有が効き、説明の往復が減る/共通部品やテスト観点を再利用できるため、立ち上がりが速く、完了スピードが安定します。
• 配分の最適化
  フェーズに合わせて役割の比重を入れ替えることができ、ボトルネックが生じやすい工程にリソースを集中させることができます。

ラボ型開発のデメリット

• 見える化と統制が前提
  事前に進捗の見せ方（例：残作業の推移/週次の完了件数/変更の履歴）を決めて共有しないと、成果の評価が曖昧になりやすい。
• スコープ拡散のリスク
  成果の定義と評価指標が不明確な場合、取り組み範囲が広がり、総コストやリードタイムが上振れしやすくなります。
• 費用は工数比例
  契約自体は止めずに範囲を入れ替えられる一方、稼働した分だけ費用が発生します。

請負開発は成果物に、ラボ型開発はエンジニアリングリソースにお金を払うという仕組み

まとめると、

• 請負＝「成果物に対価を払う」
• ラボ型＝「エンジニアリングリソースに対価を払う」

という違いになります。

そのうえで、ラボは柔軟性・継続性と引き換えに、発注側の主体的な関与（優先度付け・合意した基準での評価）が求められます。
一方、請負は契約範囲が明確で管理負荷は小さくなりやすい反面、途中の変更には弱いと言えます。

それぞれの選択方法

では実際それぞれどういったケースが適切なのかを解説していきます。

請負が向いているプロジェクト

要件が明確に決まっている

機能・非機能・外部連携・テスト観点が仕様書として固まり、合否条件まで文書化できている案件では、請負が最も運びやすい選択です。見積根拠が揃うため金額と工期の確度が高まり、社内稟議や取締役会での説明も行いやすくなります。
ベンダーは確定要件に基づきWBSを組み、品質計画とテスト計画を前倒しで整備できます。
発注側はレビューと受入に集中でき、マイルストーンごとの進捗確認と検収判定が一直線で進みます。
想定外が出る可能性が低いほど、請負の強みは発揮されます。

期日が固定されている

法改正の施行日・既存製品のサポート終了・取引先の切替期限など、動かせない日付がある場合は、逆算で工程を固めやすい請負が適しています。
クリティカルパスとバッファを設計し、マイルストーンに支払いと検収をひも付けることで、関係部門の合意形成が進みます。
遅延時のリカバリーも、契約上の再計画手順に沿って判断できるため、意思決定がぶれにくくなります
期限遵守を最優先する案件ほど、請負の計画駆動が効果的です。

変更が限定的である

開発中の仕様追加や優先順位の入れ替えが稀で、当初スコープで完走できる見込みが高い場合は、請負で固定化するメリットが大きくなります。
変更が生じた際は契約変更と影響評価が必要ですが、その頻度が低ければ全体の手戻りは小さく抑えられます。
結果として、見積精度・工期遵守・品質保証の三点が安定し、社内の予算執行も見通しを持って進められます。

社内体制が薄い

要件を詰める担当や進行管理を担うPM・設計リーダー・レビュー担当が不足しており、工程表の作成から日々の進捗管理・課題のエスカレーション・受入判定までをベンダーに任せたい案件に向いています
請負であれば、進行の主体をベンダー側に置きつつ、発注側は意思決定と検収に専念できます。人材採用や組織整備を待たずにプロジェクトを始動できる点も実務上の利点です。

固定予算で管理したい

年度予算や投資承認の枠組みに合わせ、初期の段階で総額と納期を確定させたい場合は、請負が適合します。範囲・品質・納期の三点を合意し、見積内訳と成果物インベントリを提示することで、社内統制の要件にも沿いやすくなります。
月次で検収できる単位に分割しておけば、キャッシュアウトの平準化や可視化も実現できます。

ラボ開発が向いている場合

優先順位を短いサイクルで変えたい案件

市場や現場のフィードバックを受け、毎週や隔週で取り組む機能を入れ替える必要がある場合、ラボ型が噛み合います。
専任チームを期間で確保し、スプリントごとに「今やるべきこと」を再選定する運用により、チャンスやリスクの変化へ素早く舵を切れます。
契約を止めずに計画だけを更新できるため、意思決定のリードタイムを短縮できます。

仕様が固まっておらず探索が必要な案件

仮説検証を重ねて要件を磨く前提の案件では、ラボ型の柔軟性が活きます。PoCで技術的成立性を確かめ、ユーザー検証でUXを確かめ、学びを踏まえて実装へ進む、といった反復を契約変更なく回せます。仕様を一度で固定できないテーマほど、短いサイクルでの試行と学習が価値につながります。

段階移行が必要な大規模改修

マイグレーション・データ移行・外部サービス切替のように、旧環境と新環境の並行稼働やバックアウト手順が要る案件では、ラボ型が有効です。機能単位で切替を進め、同等性や性能の確認を繰り返しながら波状的に移行できます。
想定外が出てもチームと計画を組み替えて前進でき、停止リスクを低減できます。

長期の継続改善を前提とする案件

性能改善・運用自動化・UIの磨き込みなど、小さな改善を積み上げて成果を高めるロードマップ型のテーマに適しています。
同じメンバーが継続することで、過去の判断や設計の意図を共有したまま改善を重ねられます。説明の往復が減り、共通部品やテスト観点の再利用が進むため、スプリントの立ち上がりが速くなります。

複数テーマを並行で回したい案件

複数プロダクトの小粒開発や保守改修を一本のチームでさばき、月ごとに配分比率を切り替えたい場合に適合します。
優先度の高い領域へ人員を寄せ、収束した領域はスローダウンさせるといった運用を、契約を据え置いたまま実現できます。ポートフォリオ全体でのスループット最適化に向いています。

体制を柔軟に切り替えたい案件

週単位で設計・開発・QA・運用の比重を調整し、詰まりが生じた工程に即座に人を寄せたい意図がある場合に効果的です。
例えば、立ち上げは設計とDB検討を厚く、実装期は開発とQAを厚く、切替前は監視設定やドライランを中心に据える、といった切り替えが可能です。ボトルネックを素早く解消でき、全体のリードタイム短縮に寄与します。

契約を止めずに進めたい案件

外部依存の事情や経営判断に応じて、着手中のテーマを差し替える必要がある組織では、契約の再締結を伴わずに計画だけを更新できる点が武器になります。
費用は稼働量に比例しますが、月額上限や優先度の入れ替えルールを合わせて設計することで、コストの管理性と俊敏性の両立が図れます。

実際のケース

では実際に、オフショア開発を20年近く行ってきたアレクシードベトナムが今までどういった案件を請負開発で行い、どういった案件をラボ開発で行ってきたのかを解説していきます。

請負開発例：ICカード管理システム

• クライアント：ケーブルテレビ関連企業
• システム：業務管理システム
• 対応範囲：要件定義、基本設計、概要設計、詳細設計、UIデザイン、フロントエンド実装、バックエンド実装、単体テストUT、結合テストUT、総合テストST

ICカードの発行・更新・失効・棚卸などを一元管理するシステムは請負で開発しました。

既存システムの有効期限が明確で、前任ベンダーとの契約終了も決まっていたため、動かせない期日に向けて逆算で工程を固定する必要がありました。
社内に専任のエンジニアやPMが少なく、進行管理や品質管理をベンダー側に委ねたい要望もあったことから、成果物と検収基準を事前に合意する請負が適していました。

ラボ開発 : デスクトップアプリのマイグレーション

• クライアント：総合商社系Sler
• システム：基幹系のデスクトップアプリケーション
• 対応範囲：バックエンド実装、デスクトップ実装、単体テストUT

本プロジェクトはWindows 7・VB6からVB.NETへの移行に加え、PostgreSQLとOracleという複数データベースを扱うため、実装後に挙動差の洗い出しと最適化が発生しやすく、短いサイクルでの検証と計画の組み替えが前提だったためラボ型開発のほうが適切でした。
また現行と同等の動作保証・コーディング規約の遵守が明示要件でした。これに対応するため、変換後コードを基準に照らして検証を短いサイクルで反復する運用が不可欠のため、ラボ型開発との相性が良いという点があります。

この案件の詳細はこちら

フェーズによってハイブリッドに使い分けも

これまで請負とラボの違いを整理してきましたが、どちらか一方だけに決める必要はありません。プロジェクトの段階や不確実性に合わせて切り替えるほうが、スピード・品質・コストのバランスを取りやすい場面は多いです。
立ち上げは請負で必須機能を期限どおり出し、運用に入ったらラボで優先度を入れ替えながら改善するやり方もあれば、逆に初期はラボで検証を回し、仕様が固まった塊から請負に移す進め方もあります。
固定したいところは請負、変えながら進めたいところはラボ。フェーズごとに切り替えることでバランスを取りやすくなります。

アレクシードベトナムではプロジェクトにあった方法をご提案させていただきます

アレクシードベトナムではベトナム・ホーチミンで20年のオフショア開発実績を基に、最適な進め方をご提案します。
オフショア開発をご検討の際は是非ご相談ください。

アレクシードベトナムのオフショア開発