システム開発の依頼先を調べていると、「納品のない受託開発」「ラボ型開発」という言葉を見かけることがあります。 月額固定で開発が続き、納品物がない——一括発注に慣れた立場からは、 「何にお金を払うのか分からない」と感じる仕組みかもしれません。
この記事では、受託開発とSESの両方を手がけるCoconutWorksが、 この進め方の仕組みと、一括請負との違い、向くケース・向かないケース、契約前に確認したい点を整理します。 どちらが優れているという話ではなく、自社の状況がどちらの前提に合うかで選ぶための材料として書いています。 具体的な金額は会社や体制で大きく変わるため触れません。
結論: 「成果物に払うか、開発の継続に払うか」の違い
| 比較項目 | 一括請負の受託開発 | 納品のない受託開発（ラボ型） |
|---|---|---|
| 契約形態 | 請負契約が中心。成果物の完成を約束する | 準委任契約。専門家としての業務遂行を約束する |
| 支払いの対象 | 完成した成果物に対して支払う | 月額固定で、開発チームの稼働に対して支払う |
| 仕様の決め方 | 開発前にすべて固める。途中の変更は再見積もり | 毎月の優先順位づけで決めていく。変更が前提 |
| 区切り | 納品・検収で契約が完了する | 納品という区切りがなく、作りながら育て続ける |
| 向く場面 | 作るものが決まっている単発の開発 | 要件が変わり続ける開発・事業と一緒に育てる開発 |
本質的な違いは、完成した成果物に払う（一括請負）か、開発という活動の継続に払う（ラボ型）かです。 納品がない、と聞くと不安に感じますが、正確には「納品という区切りを設けず、動くものを継続的に育てていく」という意味で、 何も受け取れないわけではありません。以下、それぞれの項目を掘り下げます。
「納品のない受託開発」とはどんな仕組みか
仕組みを一言でいうと、月額固定で開発チームの稼働を確保し、 優先順位を毎月見直しながら、少しずつ作って育てていく進め方です。 契約は準委任契約（成果物の完成ではなく、業務の遂行を約束する契約）で結びます。 「納品のない受託開発」という言葉自体は、この進め方を自社サービスの名前として提唱した開発会社によって広まったもので、 一般には「ラボ型開発」や「準委任契約による継続開発」と呼ばれる形態とほぼ重なります。
進め方の典型は、こうです。毎月（あるいは毎週）、発注側と開発側が打ち合わせを行い、 「いま一番価値のあること」を決めます。開発側はその優先順位に沿って開発を進め、 できたものから順に実際の業務やサービスで使い始めます。大きな完成を待たず、小さく作って動かし、使いながら次を決める—— このサイクルが続くことが、この形態の中身です。
「完成がない」ことは欠点のようにも見えますが、見方を変えると、 ソフトウェアの実態に合わせた設計ともいえます。業務もサービスも変化し続けるため、 一度の納品で完成と呼べる状態は長く続きません。 変化のたびに再発注するのではなく、変化への対応そのものを契約に組み込んだ形です。
一括請負と何が違うのか
最も大きな違いは「完成の責任」と「変更への強さ」のトレードオフです。 一括請負では、受注側が決められた仕様の完成を約束します。発注側から見れば「決めた通りのものが手に入る」安心感がある一方、 その安心は「先にすべてを決めきる」ことと引き換えです。開発の途中で「実際に使ってみたら違った」と気づいても、 仕様変更には再見積もりや追加契約が必要になり、変化に弱い構造になります。
ラボ型はその逆で、先に決めきらないことを前提に組み立てるため、 途中の方向転換に強い代わりに、「いつまでに何が完成する」という約束はありません。 受注側が負うのは、専門家として誠実に業務を行う義務（善管注意義務）です。 だからこそ、後述する「進み方の見える化」がこの形態では特に重要になります。
なお、同じ準委任でもSESとは働き方の設計が異なります。SESはエンジニアが発注側の開発体制に加わって働く形、 ラボ型は開発会社側がチームとして進め方を持つ形が一般的です。 契約形態の使い分けはSESと受託開発、どちらで頼むかでも整理しています。
向いているのはどんな場合か
- 新しいサービスを育てながら作りたい — 立ち上げ期のサービスは、使われ方を見て方向を変えることの連続です。仕様を固めてから作る進め方とは相性が悪く、走りながら決める前提の体制が合います。
- 業務改善を続けたいが、社内にエンジニアがいない — 社内システムの改善は一度で終わりません。「直したい所が出るたびに相見積もり」を繰り返すより、毎月の枠の中で順に潰していく方が速く回ることがあります。
- 要件を固めきれない — 何が必要かを完全には言語化できない段階では、一括請負の前提（先に決めきる）を満たせません。小さく作って確かめながら要件を発見していく方が、結果的に近道になります。
- 将来の内製化への橋渡しにしたい — 継続的に一緒に開発する中で、開発の進め方や判断の仕方が社内に蓄積されます。いずれ自社で開発チームを持ちたい会社の移行期にも使われる形です。
共通するのは、「作って終わり」ではなく「作りながら育てる」性質の開発だという点です。 たとえば、予約や顧客管理の仕組みを入れた後も、現場の声を受けて画面や流れを直し続けたい—— そんな会社にとって、毎回の再発注は判断と手続きの負担になります。その負担を月額の枠に置き換えるのがこの形態です。
向かないケースと、よくある誤解
いちばん多い誤解は、「月額で丸投げできる便利な外注」だと考えてしまうことです。 実際はむしろ逆で、この形態は発注側の関与を前提にしています。 毎月の優先順位を決めるのは発注側の役割であり、「何に価値があるか」を判断できる人が社内にいないと、 開発チームは何を作るべきか決められず、稼働だけが消費されていきます。 月額を払っているのに前に進んでいる実感がない——という失敗の多くは、この判断役の不在から起きます。
また、作るものが最初から決まっている単発の開発には向きません。 「この仕様のものを、この期日までに」が明確なら、完成を約束してもらえる一括請負の方が理にかなっています。 ホームページ制作のように成果物がはっきりした案件も同様です。 継続的に育てる予定がないものを月額契約にすると、区切りがないことがかえって不安の種になります。
契約前に確認したいこと
- ①月あたりの稼働量と体制 — 月額に含まれる稼働がどの程度で、誰が（何人が）担当するのか。ここが曖昧だと、後から「思ったより進まない」のすれ違いが起きます。
- ②進み方の見える化 — 週次の報告や、タスク管理ツールの共有があるか。完成の約束がない分、過程が見えることが信頼の土台になります。
- ③優先順位を決める定例の持ち方 — どの頻度で何を決める打ち合わせがあるか。自社側の誰が出るかも先に決めておきます。
- ④成果物の帰属と引き継ぎ — ソースコードやドキュメントの著作権・利用権がどちらに帰属し、契約終了時に一式を引き渡してもらえるか。
- ⑤解約の条件 — 予告期間と、終了時の引き継ぎ協力の範囲。「終わり方」が明確な契約ほど、安心して続けられます。
とくに④と⑤は、続けることが前提の契約だからこそ、先に確認しておきたい項目です。 発注前の準備という点では、開発の依頼全般に共通する持ち込み材料を要件定義の前に発注側が準備することで整理しています。ラボ型でも「いま何に困っているか」を具体的に持ち込めるほど、初月から的確に走り出せます。
よくある質問
まとめ
納品のない受託開発（ラボ型開発）は、成果物ではなく開発の継続に払うことで、 変化に強い開発体制を外部に持つ仕組みです。育てる性質の開発には合いますが、 丸投げの手段ではなく、優先順位を決める役割は発注側に残ります。 単発で完成品が欲しい場合は一括請負、自社の体制に人を迎えたい場合はSESと、 状況によって適した形は変わります。「うちの場合はどの形が合うのか」という切り分けからのご相談も歓迎です。システム開発・業務改善サービスのページもあわせてご覧ください。相談・お見積もりは無料です。
