publicdomainq 0016899tde

オフショアでラボ型開発と請負型開発の選択

GCode-image2022/04/01

はじめに

オフショア開発会社に開発依頼をする際には会社の選択だけではなく、どのような契約形態を利用するか検討するかということも重要です。

一般的な開発では請負型開発となりますが、開発の進め方によってはラボ型を利用することもできます。

ここでは「ラボ型開発」と「請負型開発」の違いについて解説をします。

ラボ型開発とは

ラボ型開発ではオフショア開発会社にてクライアント企業の開発規模に応じて専属のチームを用意し、期間を決めて準委任契約として締結した開発形態です。

依頼主企業でエンジニア等を駐在をさせる「SES」も準委任契約がとられており、同様にオフショア開発のラボ型契約でも拘束時間に応じた対価が支払われます。

オフショアのラボ型開発の基本的なチーム構成として、お客様とやりとりを行うブリッジSE(BrSE)とエンジニアの開発チームがいて、ブリッジSEから開発チームにクライアントからの作業内容を指示します。

ラボ型開発においては、請負開発と異なり成果物を提出する義務はありません。

クライアント企業から出される指示に従い開発を進めることになります。

ラボ型開発→アジャイル開発に向いている

ラボ型開発は、アジャイル開発で利用されやすいことが挙げられます。

アジャイル開発では、スプリントと呼ばれる短期のリリースプランを立てて実装をしていくような開発を繰り返し行います。

ユーザーの反応を見ながら開発を進めたい場合にはアジャイル開発が適しているでしょう。

オフショア開発においては、コミュニケーションの課題、品質の課題があり、コミュニケーションの課題については開発の要望を汲み取れているか、品質の課題については十分な体制や対策がとられているかを確認しましょう。

ラボチームのメンバーとは事前に面接をしたりスキルレベルを確認をすることができたほうがよいでしょう。

請負型開発とは

請負型開発とは依頼主企業と開発会社が同意をした仕様・要件に基いて定めた成果物を納める契約をした開発となります。

契約までの手順としては、最初に開発をしたい内容を確認、そして聞き取りに基づいた内容での見積もりと契約書の作成、その後契約手続きというようになります。

見積もりの際には複数会社に同時に見積もりを行う相見積もりをとることで、相場感に比べて高い開発費用となっていないか、また複数の会社から異なった視点での提案を受けることができます。

請負型開発→ウォーターフォール開発に向いている

請負型開発においては、基本的にウォーターフォールで進めていくことになります。成果物の大まかな仕様については契約前に伝えて、ウォーターフォールに従って納品まで一気通貫で開発を行います。

開発会社にとっては手戻りが発生するとクライアントに請求する必要があるため、仕様の変更は新たな見積もりと契約の修正が必要となる場合が多いです。

ラボ型開発と請負型開発の使い分けを解説

ラボ型開発と請負型開発の使い分け

ラボ型開発に向いているケースとして下記のように整理できます。

  • 仕様が確定していない
  • 仕様が変更となる見込みが強い
  • アジャイル開発で進めたい
  • 長期的に続くプロジェクト
  • 連続的に業務が発生する

ラボ型開発と請負型開発では仕様の変更の発生が一番大きな判断の基準となってきます。

開発をしたいプロジェクトの仕様が固まっているものであれば請負開発、そうでなければラボ型開発を利用するとよいでしょう。

ラボ型開発であればプロジェクトの完成形が確定していなくても、ラボ契約の中で柔軟に対応ができます。

また、ラボ開発ではメンバーを契約期間中は固定をさせておくことができるため、プロジェクトが長期となればメンバーとのやりとりもよりスムーズとなっていきます。

ただし、開発期間が伸びるとクライアントの費用負担となってくるので、プロジェクトマネジメントができる人材が社内にいることが重要となります。

社内のプロジェクトが連続して見込まれる場合や長期的な保守が必要な場合、外部のクライアントからの案件が継続して続く場合はラボ契約を検討するとよいでしょう。

事例

アプリ開発の事例で請負型開発、ラボ型開発で行う場合の想定を考えてみましょう。

請負開発
アプリの機能一覧を整理して、開発会社に見積もりをしてもらいます。
契約後に支払いを行い、開発が進みます。そして検収期間後に納品となり開発が終了します。

ラボ型開発
アプリの機能で未確定の機能があっても、ベータ版としてリリースをさせることができます。
ラボ型契約の期間中、ユーザーの意見を聞きながら機能修正を柔軟に行うことができます。

ラボ型・請負型開発を選ぶ際のポイント

下記の点が特にラボ型を選ぶ際に大切なポイントとなります。

  • プロジェクトの開発方針を社内で決めましょう。社内でプロジェクトに関われるリソースを考慮しましょう。
  • 社内でラボ型開発のマネジメントできる人材がいるかどうか見定めましょう。

請負型開発は、要件や期限が決まっている場合には向いているでしょう。

逆に仕様がはっきりと決まっていない場合であればラボ型開発を検討することができます。

一方で、ラボ型開発ではクライアント企業から直接開発者に指示を出す必要があり、プロジェクトをコントロールできる人材がいるかということも大事な判断材料となります。

ラボ型開発のメリットとしては他にメンバーが契約の期間中はチームに組み入れることができるため、ノウハウの蓄積をさせることで新しい技術へのチャレンジもしやすいといえます。

こちらの記事も読まれています

SIer×オフショアの“最小変更管理”—CRルール1枚でスコープと検収を守る|GCode

GCode-image2026/01/05

揉める前に決める。SIer×オフショアの「最小変更管理」—CRルール1枚でスコープと検収を守る|GCode

SIerがオフショアで揉めやすい論点(スコープ/検収/変更/責任境界)を整理し、1枚のCR(変更管理)ルールで最小化する方法を解説。公開サンプルとしてCRルールの見出しを提示し、詳細チェックリスト(DL/同梱ZIP)と面談での当てはめ支援も提供します。

詳細へ GCode-image
SIerが2週間の“試験導入”を通すための最小セキュリティ合意|GCode

GCode-image2026/01/05

監査にしない。SIerが2週間の“試験導入”を通すための最小セキュリティ合意|GCode

SIerがオフショアを試験導入する際に、監査レベルの負荷をかけずに必要最小限のセキュリティ合意をまとめました。必須/推奨チェック(NDA・権限・データ・ログ保持)と、1枚で使える最小合意書テンプレをDLで提供します。

詳細へ GCode-image
SIerがオフショア追加で品質を落とさない方法|GCode

GCode-image2026/01/05

SIerがオフショア追加で会議を増やさず、手戻りを止める|GCode

SIerがオフショアを追加するときに品質と手戻りを抑える「最小QAゲート10」を公開。証跡(テスト・レビュー)と引き継ぎ(リリースノート)に絞り、バグトリアージの重大度・担当・SLA・意思決定線までテンプレ化。

詳細へ GCode-image
#3 会議を増やさず小さく安全に:オフショアを2週間で検証する進め方(SIer向け)|GCode

GCode-image2025/12/26

会議を増やさず、小さく安全に:オフショアを10日で検証する進め方(中小SIer向け)|GCode

会議を増やさず、最小スコープで安全にオフショアを試す「2週間トライアル」の手順。窓口一本化・最小QAゲート・1枚週次レポート。

詳細へ GCode-image
単価で選ばない:オフショアベンダーを15分で見抜く質問10(中小SIer向け)|GCode

GCode-image2025/12/26

単価で選ばない:オフショアベンダーを15分で見抜く質問10(中小SIer向け)|GCode

単価で選ぶ前に、15分でオフショアベンダー“運用適合”を見抜く。中小SIer向けに質問10+レッドフラグ+詳細スコアを1枚に整理。窓口/DoD/変更管理で曖昧ベンダを早期除外できます。

詳細へ GCode-image
オフショア不安5つを“最小対策”に:中小SIer向けチェックリスト|GCode

GCode-image2025/12/26

オフショア不安5つを“最小対策”に:会議を増やさない、中小SIerのための運用設計|GCode

週次会議が終わった直後、チャットに「これも追加で」「確認だけお願いします」が流れてくる。
決める人が曖昧なまま、気づけば“SIer側で吸収”が積み上がる——そんな瞬間、ありませんか。
オフショアの不安は、気合やマイクロ管理で消えるものではありません。
必要なのは、**会議を増やさずに効きやすい“最小の運用セット”**です。
この記事は、よくある不安(管理・品質・セキュリティ・連携・進捗)を、**最小セット(3つの型)** に落として整理します。
増やすべきは会議ではなく、**情報と意思決定の“形”** です。

詳細へ GCode-image
GCode-image-start

開発の 検討に 役立つ

ブログ