1. オフショア開発の「開発体制」の種類
オフショア開発の「開発体制」の種類は以下の2つです。
- 受託型
- ラボ型
それぞれの開発体制について詳しく解説します。
1-1. 受託型
オフショア開発の「開発体制」の1つ目は、受託型です。
受注側企業が発注側企業から開発を受託するため、「受託型」と表現されています。「受託」と書かれていますが、開発する発注側企業にとっては、開発を「委託」することになります。受託型のオフショア開発では請負契約を締結するため、請負型と表現する場合もあります。
契約形態としては、発注側企業は開発を委託し、受注側企業は開発を受託する請負契約です。受注側企業は、発注側企業から提出された仕様書から開発にかかる費用や期間を計算し、見積もりを提示します。契約が成立したあとは、提出された仕様書にもとづいて受注側企業が開発を行い、納期までに完成した製品やサービスを納品します。
基本的には、開発途中での仕様の変更や追加には対応しません。仕様が変わったり追加されたりすると、当初の開発費用や開発期間が変わってしまい、納期までに納品できなくなる可能性があるためです。
発注側企業のプロダクトマネージャーやブリッジSEから、開発の進捗状況についての報告を定期的にもらえますが、発注側企業が開発の進め方などに直接指示を出すことはありません。分かりやすくいえば、開発を丸投げでき、納期までに納品されることが保証された開発体制といえるでしょう。受託型のオフショア開発の具体的なメリット・デメリットについては後述します。
1-2. ラボ型
オフショア開発の「開発体制」の2つ目は、ラボ型です。
受注側企業が発注側企業に対し、開発チームと開発環境を提供します。受注側企業が発注側企業から開発を受託する、発注側企業が開発を委託するという点では、前述した「受託型」と同じです。イメージとしては、受注側企業が海外の拠点に構築した開発ラボを一定期間だけ借りる形となります。
ラボ型のオフショア開発の契約形態は準委任契約です。契約書に記載された期間だけ開発チームと開発環境が提供され、契約書に記載された費用を支払います。提供される開発チームには、プログラマーやデザイナー、プロダクトマネージャー、ブリッジSEなど、さまざまなエンジニアが編成されます。
費用の支払い方法としては、月額払いが採用されるケースが一般的です。提供されるのは開発チームと開発環境だけで、受託型のように完成した製品やサービスが納品されるわけではありません。
ラボ型のオフショア開発の具体的なメリット・デメリットについては後述します。ラボ型オフショア開発の開発チーム編成には、遠隔ラボチームと常駐ラボチームの2種類があります。
遠隔ラボチーム
遠隔ラボチームは、ZoomやSlack、Chatwork、SkypeなどのWEB会議ツールを使用し、発注側企業と開発チームが仕様や進捗状況の確認などのコミュニケーションを取るチーム編成です。
受注側企業が海外の開発拠点に配置したプロダクトマネージャや、ブリッジSEとコミュニケーションを取るケースもあります。主にオンライン上のコミュニケーションを取るため発注側企業は現地へ出向く必要はありませんが、開発を開始する前に現地で確認する場合もあります。
常駐ラボチーム
常駐ラボチームは、発注側企業が日本人エンジニアを海外の開発拠点へ常駐させ、開発チームと一緒に開発を進めるチーム編成です。
自社エンジニアを常駐させるため開発拠点と発注側企業のあいだでのコミュニケーションが取りやすく、仕様のすり合わせや進捗状況の確認を正確に行えます。
初めて開発を委託する場合や開発力がある場合におすすめのチーム編成ですが、常駐させるエンジニアの渡航費や滞在費などのコストがかかる点に注意が必要です。
2. オフショア開発体制「受託型のメリット」
受託型のオフショア開発体制のメリットは以下の2つです。
- 期日までに成果物の納品が保証されている
- 開発工数、コストを削減できる
それぞれのメリットについて詳しく解説します。
2-1. 期日までに成果物の納品が保証されている
受託型のオフショア開発体制のメリットの1つ目は、期日までに成果物の納品が保証されていることです。
受託型のオフショア開発体制では、請負契約を締結します。オフショア開発における請負契約とは、発注側企業が提出した仕様書の通りに受注側が開発を完了させ、納期までに成果物を納品することを約束する契約です。
受注側が仕様書の通りに開発できなかったり、納期までに成果物を納品しなかったりすれば、契約書に記載された違約金を支払います。自社で開発する場合だと、納期までに開発できるか、リリース日までに開発した製品やサービスをリリースできるかは開発する企業次第です。
また、後述するラボ型のオフショア開発の場合は、受注側企業は開発の成果物である製品やサービスを納品する義務はありません。つまり、いつまでに開発できるか正確な期日は分からないということです。受託型のオフショア開発体制であれば期日までに成果物の納品が保証されているため、期日までに開発が完了するか不安に感じる必要がなくなります。
2-2. 開発工数、コストを削減できる
受託型のオフショア開発体制のメリットの2つ目は、開発工数、コストを削減できることです。
開発を委託せずに自社で開発する場合、社内に開発環境するためのスペースを確保したり、必要な機材や備品を購入したり、開発できるだけの技術力を持つエンジニアを採用したりするなど、開発を始めるまでにさまざまな準備が必要です。ゼロから開発環境を構築する場合は、まとまった金額の予算を確保しなければいけません。
一方、受託型のオフショア開発体制なら、自社で仕様書を作成し、発注側企業と契約を締結するだけで、納期までに成果物が納品されます。開発環境を構築する費用やエンジニアを採用する費用は必要ありません。つまり、開発に関する専門的な知識が全くなかったとしても、仕様書や契約書の作成など最低限の手間だけで、自社が求める仕様の製品やサービスを作成できるわけです。
3. オフショア開発体制「受託型のデメリット」
受託型のオフショア開発体制のデメリットは以下の3つです。
- 仕様変更が難しい
- 運用、保守がしにくい
- 開発ノウハウが蓄積されにくい
それぞれのメリットについて詳しく解説します。
3-1. 仕様変更が難しい
受託型のオフショア開発体制のデメリットの1つ目は、仕様変更が難しいことです。
受託型のオフショア開発体制では、契約書に記載された仕様に従って開発を進めます。契約時の仕様と異なる仕様で開発すると契約を履行したことにならないため、発注側企業は仕様の変更を受け付けることはありません。仕様の変更が必要な場合は、受注側企業から了承を受けたうえで契約を破棄し、新たに契約を締結し直す必要があります。
上記の理由から、受託型のオフショア開発体制は、仕様変更が発生する可能性が低い分野で選ばれることがほとんどです。
3-2. 運用、保守がしにくい
受託型のオフショア開発体制のデメリットの2つ目は、運用、保守がしにくいことです。
受託型のオフショア開発体制では請負契約を締結するため、受注側企業が行うのは仕様書に基づいて開発を行い、納期までに成果物を納品するだけです。契約内容にもよりますが、開発によって完成した製品やサービスの運用や保守は行いません。自社で保守・運用ができない場合や保守・運用まで委託したい場合は、別途契約を締結する必要があります。
上記の理由から、受託型のオフショア開発体制では、リリース後に保守・運用が必要となるWEBサイトやWEBアプリ、スマホアプリなどの開発は少ないです。
3-3. 開発ノウハウが蓄積されにくい
受託型のオフショア開発体制のデメリットの3つ目は、開発ノウハウが蓄積されにくいことです。
受託型のオフショア開発体制では、発注側企業は仕様書を提出するだけで、開発に関して直接関与することはありません。どのような開発言語やフレームワークを使用して開発するのか、どのくらいの人数のエンジニアが必要だったのか、完成までにどのくらいの時間がかかったのかといった、開発の現場で起こったことを直接知る機会がありません。結果として、発注側企業に開発ノウハウが蓄積されにくいのです。
4. オフショア開発体制「ラボ型のメリット」
ラボ型のオフショア開発体制のメリットは以下の4つです。
- 長期間エンジニアを確保できる
- 仕様を柔軟に変更できる
- 開発ノウハウを蓄積しやすい
- 複数の案件を委託できる
それぞれのメリットについて詳しく解説します。
4-1. 長期間エンジニアを確保できる
ラボ型のオフショア開発体制のメリットの1つ目は、長期間エンジニアを確保できることです。
前述した受託型のオフショア開発体制では、納期に成果物が納品されるまでしかエンジニアを確保できません。なぜなら、発注側企業へ受注側企業が納期までに成果物を納品する契約だからです。成果物が納品された時点で契約が終わるため、別の仕事を依頼する場合には別案件として契約する必要があります。
一方、ラボ型のオフショア開発体制では準委任契約を締結するため、契約書に記載された期間及び作業時間の範囲内であれば、エンジニアを活用できます。成果物が完成したかどうか、エンジニアに何をさせるのかは契約とは関係ありません。契約が成立している間、エンジニアを確保できるため、長期間にわたりエンジニアを活用できます。
4-2. 仕様を柔軟に変更できる
ラボ型のオフショア開発体制のメリットの2つ目は、仕様を柔軟に変更できることです。
前述した受託型のオフショア開発体制では、契約書に記載された仕様通りに受注側企業が開発し、納期までに成果物を納品する契約なので、開発途中での仕様の変更や追加には対応できません。契約書に記載された仕様とは異なる仕様で開発してもらいたい場合は、契約を破棄して契約し直す必要があります。
一方、ラボ型のオフショア開発体制は受注側企業が発注側企業へエンジニアの技術力・労働力を提供する準委任契約を締結するため、エンジニアに対して何をさせるのかは発注側企業が決められ、仕様の変更や追加も自由に指示することが可能です。
どのような仕様で開発すべきかをエンジニアと相談しながら開発したり、開発途中で仕様を変更したりもできます。ただし、仕様の変更によって開発期間が長くなり、開発のトータルコストが増加する可能性がある点には注意が必要です。
4-3. 開発ノウハウを蓄積しやすい
ラボ型のオフショア開発体制のメリットの3つ目は、開発ノウハウを蓄積しやすいことです。
前述した受託型のオフショア開発体制は、受注側企業が納期までに成果物を納品する契約のため、どのような開発言語・フレームワークで開発したのかといった開発ノウハウを具体的に発注側企業へ伝える義務はありません。
一方、ラボ型のオフショア開発体制では、発注側企業と受注側企業が共同して開発を進めていくため、開発ノウハウを自社に蓄積できます。
4-4. 複数の案件を委託できる
ラボ型のオフショア開発体制のメリットの4つ目は、複数の案件を委託できることです。
前述した受託型のオフショア開発体制では案件ごとに契約を締結するため、複数の案件を委託したい場合は、それぞれの案件で個別に契約を締結する必要があります。複数の案件を委託すること自体は可能ですが、それぞれの案件に対して仕様書や契約書を作成する必要があるため、手間や時間がかかります。
一方、ラボ型のオフショア開発体制では、提供を受けたエンジニアに対し、複数の案件を委託することが可能です。たとえば、スマホアプリの新規開発と並行して既存のWEBサイトの保守・運用を委託することも可能です。ただし、契約時に指定した作業時間を超えてエンジニアに作業をさせることはできません。また、対応する案件が増える分だけ多くのエンジニアが必要となるため、委託する内容によっては委託費用が増加する場合があります。
5. オフショア開発体制「ラボ型のデメリット」
ラボ型のオフショア開発体制のデメリットは以下の3つです。
- 軌道に乗るまでのフォローや準備期間が必要
- 発注が少ない場合は費用対効果が悪い
- 委託側のコミュニケーションコストがかかる
それぞれのデメリットについて詳しく解説します。
5-1. 軌道に乗るまでのフォローや準備期間が必要
ラボ型のオフショア開発体制のデメリットの1つ目は、軌道に乗るまでのフォローや準備期間が必要なことです。
前述した受託型のオフショア開発体制では、発注側企業が個別のエンジニアに対して直接指示したりコミュニケーションを取ったりするなど、開発の準備を行う必要はありません。
一方、ラボ型のオフショア開発体制は、開発環境や開発チームを提供する契約のため、エンジニアに対してどのような仕様で開発をしてもらいたいのかを伝えたり、だれがどの工程を担当するのかを決めたりするといった準備を発注側企業が行う必要があります。開発が軌道に乗るまでに時間がかかったり、仕様を正確に理解できていないエンジニアへのフォローが必要だったりすることもあるでしょう。軌道に乗るまでの準備期間が長くなればサービスを利用する期間も長くなるため、開発コストも増加します。
5-2. 発注が少ない場合は費用対効果が悪い
ラボ型のオフショア開発体制のデメリットの2つ目は、発注が少ない場合は費用対効果が悪いことです。
ラボ型のオフショア開発体制では、一般的にエンジニアの稼働時間と費用を決めて契約を締結します。たとえば、1か月のエンジニアの稼働時間が100時間の契約だと、10時間しか稼働しなかった場合も、100時間きっちり稼働した場合も、発注側企業が支払う費用は同じです。契約内容によりますが、10時間しか稼働しなかったから支払う費用が10分の1で済むわけではありません。つまり、契約時に定めたエンジニアの稼働時間に対して発注が少ない場合は、費用対効果が悪くなるということです。
ただし、エンジニアの稼働時間と費用については、どのような内容で契約を締結したのかによって扱いが変わります。発注側と受注側の双方が合意すれば、エンジニアの稼働時間を定めず、毎月の稼働時間に応じて費用を支払う契約を締結することも可能です。
5-3. 委託側のコミュニケーションコストがかかる
ラボ型のオフショア開発体制のデメリットの3つ目は、委託側のコミュニケーションコストがかかることです。
前述した受託型のオフショア開発体制では、契約を締結した後は納期まで受注側企業へコミュニケーションを取る必要はありません。受注側企業とやり取りを全くしなかったとしても、納期までに仕様通りの成果物が納品されます。
一方、ラボ型のオフショア開発体制では、エンジニアに対してどのような作業をするのか具体的に伝える必要があります。また、発注側がイメージした通りの開発ができているか、計画通りに開発が進んでいるかなど、進捗状況を確認することも必要です。ただし、雇用契約や派遣契約と異なり、ラボ型のオフショア開発体制ではエンジニアを自社の指揮命令下に置くことはできません。
6. オフショア開発の体制はどう選ぶ？
前述したように、受託型のオフショア開発とラボ型のオフショア開発では契約形態やメリット・デメリットが大きく異なるため、自社の開発分野に応じてどちらの開発体制を選択するか検討する必要があります。
開発体制と自社の開発分野がマッチしていないと、余計な費用がかかったり、納期までに製品やサービスをリリースできなかったりするかもしれません。オフショア開発を委託する場合に、受託型開発が向いているケースとラボ型開発が向いているケースを解説します。
6-1. 受託型開発が向いているケース
受託型のオフショア開発が向いているケースは以下の通りです。
- 仕様を変更する可能性がないソフトウェアの開発
- リリース日・予算が決まっている
自動車に搭載するカーナビシステムやエアコンの温度や湿度を調節するソフトウェアなどのように、製品に組み込まれた状態で稼働するシステムやソフトウェアを開発する場合は、受託型のオフショア開発が向いています。製品を出荷したあとは、システムやソフトウェアを改良する余地がないためです。
また、特定の期日までに完成した製品やサービスをリリースする必要がある、決まった予算の範囲内で完成させたいという場合にも、受託型のオフショア開発を採用することをおすすめします。ラボ型のオフショア開発だと、いつまでに完成するか、最終的なトータルコストがどのくらいになるのかが不透明だからです。
6-2. ラボ型開発が向いているケース
ラボ型のオフショア開発が向いているケースは以下の通りです。
- 専門家の意見を聞きながら開発を進めたい
- 製品やサービスをリリースした後でも仕様を変更したい
- 開発だけでなく保守・運用まで委託したい
開発する製品やサービスのイメージはあるものの、具体的な機能や仕組みまでは明確になっていない場合は、ラボ型のオフショア開発が向いています。製品やサービスに関する技術力や開発経験を持つエンジニアからの意見を参考にしながら、流動的に開発を進められるためです。
また、製品やサービスをリリースしたあとで、ユーザーの意見を取り入れながら仕様を変更したい場合にもラボ型のオフショア開発が向いています。受託型のオフショア開発だと開発が終わった時点で契約も終わりますが、ラボ型のオフショア開発なら開発完了後も契約は継続するからです。
クラウド上で稼働するWEBアプリや再インストールが容易なスマホアプリの場合、リリース後に仕様を変更することでユーザーの利便性を高められます。また、自社で保守・運用を行うノウハウがなかったり、保守・運用も委託したい場合には、開発段階からラボ型のオフショア開発を利用することをおすすめします。
7. まとめ
今回は、オフショア開発の開発体制の種類やメリット・デメリット、オフショア開発体制の選び方について解説しました。
オフショア開発の2つの開発体制、受託型/ラボ型のメリット・デメリットは以下の通りです。
| 開発体制 | メリット | デメリット |
|---|---|---|
| 受託型 | 期日までに成果物の納品が保証されている 開発工数、コストを削減できる | 仕様変更が難しい 運用、保守がしにくい 開発ノウハウが蓄積されにくい |
| ラボ型 | 長期間エンジニアを確保できる 仕様を柔軟に変更できる 開発ノウハウを蓄積しやすい 複数の案件を委託できる | 軌道に乗るまでのフォローや準備期間が必要 発注が少ない場合は費用対効果が悪い 委託側のコミュニケーションコストがかかる |
オフショア開発では、受託型開発が向いているケースとラボ型開発が向いているケースがあります。どちらの開発体制が自社にマッチしているかを検討したうえで、オフショア開発の開発体制を選びましょう。
「オルグローラボ」では、ベトナムでのラボ型オフショア開発事業を展開しています。オルグローラボを利用すれば、貴社の開発チームにベトナムの優秀なエンジニアを加え、長期的にプロジェクトにアサインすることができます。お客様のニーズに合わせた柔軟なチーム編成が可能ですし、プロジェクト開始から運用まで、継続的なサポートを提供しています。ぜひお気軽にお問い合わせください！
