ベトナムオフショア開発 ラボ型開発 違い｜契約形態と選び方

ベトナムオフショア開発とラボ型開発の違いとは？

結論から述べます。ベトナムオフショア開発 ラボ型開発 違いを整理すると、この2つは比べる次元が異なります。ベトナムオフショア開発は「開発拠点をどこに置くか」という場所の軸、ラボ型開発は「どの契約形態で進めるか」という契約の軸です。同じ土俵の選択肢として並べると、検討の順序が入れ替わり判断を誤りやすくなります。

まず「ベトナムに委託するか」を決め、次に「請負型かラボ型か」を選びます。この順序で考えると整理しやすくなります。

ベトナムオフショア開発とは

ベトナムオフショア開発とは、日本企業がベトナムの開発会社やベトナム国内の開発拠点にソフトウェア開発を委託する形態です。開発拠点を海外に置くかどうか、という「場所」の判断にあたります。

当社は2020年7月にベトナム・ハノイで設立し、日本企業向けのソフトウェア開発・DX支援を行っています。

ラボ型開発とは

ラボ型開発とは、一定の期間と人数（チーム）を確保し、その枠の中で継続的に開発を進める契約形態を指す一般的な用語です。完成した成果物に対して対価を支払う請負契約と対比して説明されます。

本文で使う用語を整理します。

• BrSE（ブリッジSE）：日本の発注側とベトナムの開発チームの間に入り、要件や仕様の認識のずれを埋める役割の呼称です。
• 請負契約：成果物の完成を約束し、その対価として報酬を受け取る契約形態です。
• 準委任契約：作業そのものに対して対価を支払う契約形態で、ラボ型に近い進め方で用いられることがあります。

対応できる契約形態や、仕様変更時の扱いは会社ごとに異なります。検討の際は、候補社に確認する項目の一つとして整理しておくとよいでしょう。

請負型とラボ型はどう違う？

請負型は完成した成果物に、ラボ型は確保した期間と人数の稼働に、それぞれ対価を支払う考え方です。契約の考え方と成果物の決め方が異なります。

契約・成果物・指示範囲の違い

どちらが優れているという話ではなく、案件の性質に合うかどうかで選びます。単価や期間の目安は案件ごとに異なるため、ここでは一般的な違いの整理にとどめます。

どちらが向くケース

判断の軸は次の3つです。

1. 要件が固まっているか：固まっているなら請負型、これから固めるならラボ型が検討対象になります。
2. 仕様変更がどの程度見込まれるか：変更が多いほど、枠を確保する進め方になじみます。
3. 社内にディレクションできる人材がいるか：指示と優先順位づけができる人がいるかどうかで、ラボ型の向き不向きが変わります。

「多くの企業はこう選んでいる」といった一般化は避け、自社の状況に当てはめて考えるための材料として示しています。

ラボ型開発はどんな案件に向いている？

向いているケースと注意すべきケースの両方を押さえておくと、契約形態の選択で迷いにくくなります。

向いているケース

• 仕様変更が多く見込まれる：要件が固まりきる前に開発を始める場合、枠を確保して進めるほうが調整しやすいと考えられます。
• 継続的に機能改善を続けたい：リリース後の改善を同じチームで回したい場合、期間と人数を確保する形がなじみます。
• 社内に指示・優先順位づけができる人がいる：発注側が方向性を決められる体制があると、この進め方の利点を活かしやすくなります。
• スピードを優先したい：仕様を細かく確定させるより、動くものを見ながら決めたい場合に検討されます。

注意すべきケース

• 成果物が契約上明確になりにくい：何をもって完了とするかを決めておかないと、認識のずれが生じやすくなります。
• 作業範囲が広がりやすい：枠の中で対応できる範囲が広いぶん、優先順位を示さないと工数が分散します。
• 工数管理と定期的なレポート運用が前提になる：稼働の見える化と定例の確認が欠かせません。
• 発注側の窓口が不在になりやすい：判断が遅れると、その分だけ開発が止まりやすくなります。

例えば、社内に仕様を決める担当者がおらず、要件が固まらないまま進めたいという場合には、契約形態を選ぶ前に要件定義の進め方を整理したほうが適切なことがあります。この例は当社の実績ではなく、一般的なケースとして示しています。

ベトナムのオフショア開発会社はどう選ぶ？

選定では、体制とコミュニケーション、品質と保守運用の2つの面を分けて確認すると整理しやすくなります。

体制・コミュニケーション

• 日本語でやり取りできる窓口があるか
• BrSE（ブリッジSE）の役割と人数が定義されているか
• 要件定義をどこまで伴走してくれるか
• 発注側の窓口と開発チームの連絡チャネルが決まっているか
• 稼働時間帯と、緊急時の連絡方法で合意できるか

品質・保守運用

• QA・テストの方針（手動テストから自動化まで、どの範囲か）
• アジャイルテスト、テスト駆動開発、ユーザー受け入れテストの進め方
• 保守運用の範囲と、リリース後の体制
• 成果物として受け取れるドキュメントの範囲
• 選べる契約形態と、仕様変更時の扱い
• 品質・情報セキュリティの運用プロセス

品質・情報セキュリティについて、当社はISOの取得に向けて運用プロセスを整備している段階です（取得済みではありません）。

稼働率や対応時間、保証期間などのSLA（サービス水準に関する取り決め）の条件は会社ごとに異なります。契約前に、条件の有無と範囲を確認しておきたい項目です。

見積もりと工数はどこを確認すればよい？

見積もりは、金額そのものより前提をそろえることが重要です。前提が異なる見積もりを並べても、比較の意味が薄くなります。

見積の前提をそろえる

1. 要件定義が含まれるかどうか
2. 工数の単位と数え方（人月か人日か、何をもって1工数とするか）
3. 仕様変更が発生したときの扱い
4. 検収の条件
5. 成果物としてのドキュメントの範囲
6. リリース後の運用フェーズにかかる費用

複数社を比較する場合は、同じ前提・同じスコープで依頼し、回答の前提条件を突き合わせます。

変更時の扱いを決めておく

仕様変更や追加要望が出たときに、どの時点で見積もりを更新するのか、誰が承認するのかを先に決めておきます。請負型では変更が契約変更になりやすく、ラボ型では枠内で優先順位を入れ替える運用になりやすい、という違いがあります。

金額はスコープと前提によって変わるため、それらが固まった段階で個別にご案内します。

導入までの進め方

検討からリリース、保守運用までの流れを整理します。

1. 目的とスコープの整理：何を実現するか、今回の範囲に何を含めないかを決めます。発注側は決裁者と社内窓口を決めておきます。
2. 契約形態の選択：請負型かラボ型（準委任を含む）かを、要件の固まり具合と仕様変更の見込みで選びます。
3. 要件定義と体制設計：開発範囲、QAの進め方、連絡チャネルを決めます。発注側は仕様の優先順位を用意します。
4. 小規模開発（MVP）での検証：MVP（Minimum Viable Product＝実用最小限の製品）を小さく作って動かし、進め方の相性を確かめます。
5. 開発・QA：アジャイルでの開発と、手動・自動のテストを組み合わせて進めます。発注側は受け入れテストの担当を決めます。
6. リリースと保守運用：運用フェーズの範囲と体制を確認します。

当社のソフトウェア開発は、Webシステム開発、モバイルアプリ開発、API設計・開発、保守運用を、MVPからエンタープライズまで対応する範囲としてご案内しています。詳しくはソフトウェア開発をご覧ください。

スケジュールの保証や納期の断定は行いません。期間の目安が必要な場合は個別にご相談ください。

まとめ

ベトナムオフショア開発は「どこで開発するか」、ラボ型開発は「どの契約形態で進めるか」という別の軸です。まずベトナムに委託するかどうかを決め、次に要件の固まり具合・仕様変更の見込み・社内のディレクション体制という3つの軸で、請負型かラボ型かを選びます。この順序で考えると、判断の根拠を社内で説明しやすくなります。

次に取る行動としては、今回のスコープと「含めないもの」を社内で整理し、候補社に確認する項目を洗い出すことをおすすめします。ベトナムの一般的な情報は、公的機関のページもあわせて参照するとよいでしょう。

ご相談はお問い合わせまたは [email protected] までご連絡ください。