受託開発とは？ラボ型・アジャイル・SESの違いと自社に合う選び方
「開発を外注したいが、”受託開発”でいいのか、ラボ型やSESとは何が違うのか」——システム開発の発注を検討し始めた経営者やDX推進担当者が、最初につまずくのがこの問いです。言葉は聞いたことがあっても、自社の状況に合うのかどうかは、定義を眺めるだけでは判断できません。
選び方を誤ると、後から仕様変更で揉めるなど、コストにも納期にも跳ね返ります。この記事では、受託開発の定義・メリット・デメリットを整理したうえで、ラボ型開発・アジャイル開発・SESとの違いを一枚の表で比較し、「自社にはどの形態が合うのか」を判断できる状態を目指します。
目次
受託開発とは？意味と請負契約の基本
受託開発とは、システムやソフトウェアの開発を外部の専門会社に委託し、自社の要望に沿ってオーダーメイドで作ってもらう開発形態です。要望のヒアリングから要件定義、設計、開発、テスト、納品までを、受託した開発会社が一貫して担います。既製のパッケージやSaaSでは業務に合わない部分を埋められるのが、基本的な位置づけです。
受託開発の契約形態は「請負契約」｜完成責任と契約不適合責任
受託開発の多くは、法律上「請負契約」にあたります。民法632条は、請負を「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約と定めています。つまり、開発会社は”完成させる”義務を負い、発注者は完成した成果物に対して報酬を支払う関係です。作業に時間をかけたかどうかではなく、成果物が完成したかどうかが報酬の前提になります。
完成物が契約内容に適合しない場合、発注者は開発会社に対して、履行の追完（修補など）・報酬の減額・損害賠償・契約の解除を求められます（契約不適合責任）。ただし、発注者が不適合を知った時から1年以内に通知しないと、これらの権利を失う点に注意が必要です（民法637条1項）。この契約不適合責任は、2020年4月に施行された改正民法で、従来の「瑕疵担保責任」から名称と内容が整理されたものです。なお、どこまでが開発会社の責任範囲になるかは、責任範囲の切り分け方をまとめた記事でも具体的に扱っています。
受託開発のメリット3つ
自社の業務に合わせたシステムをオーダーメイドで作れる
パッケージやSaaSは、多くの企業に共通する業務を前提に作られています。そのため、自社独自の業務フローや、他社と差別化している部分ほど、既製品では埋めきれません。受託開発なら、必要な機能や画面を自社の業務に合わせて設計できます。業務のほうをシステムに合わせて変える必要がない、というのが最大の利点です。
専門性を活用し、採用・育成コストを抑えられる
自社でエンジニアを採用・育成して内製するには、時間もコストもかかります。受託開発なら、必要なプロジェクトに対して、実績のある開発会社の技術力をそのまま借りられます。IT人材の確保が難しい企業でも、短期間で専門チームを立ち上げられるのは大きな利点です。
予算・納期を見通しやすい（請負契約のメリット）
請負契約では、契約時に成果物の範囲と金額、納期が決まります。原則として、契約で合意した報酬以外の費用は発生せず、支払いも検収後という形が一般的です。そのため予算計画やスケジュールを立てやすく、社内の稟議も通しやすくなります。作るものが明確な案件ほど、この利点は効いてきます。
受託開発のデメリットと、その本当の原因
受託開発のデメリットは、「仕様変更がしにくい」「コミュニケーション不足でトラブルになる」と語られがちです。ただ、列挙するだけでは自社では防ぎようがありません。大切なのは、なぜそれが起きるのかを理解することです。
仕様変更・手戻りが起きやすい原因は「要件の曖昧さ」
開発着手後の仕様変更が難しいのは、請負契約が「最初に決めた範囲を完成させる」前提だからです。しかし実務で手戻りが起きる本当の原因は、契約の硬さそのものより、着手前に要件が曖昧なまま進んでしまうことにあります。
「だいたいこんな感じで」という粒度で合意したつもりでも、発注者と開発会社で言葉の解釈がズレていれば、上がってくる成果物は想像と違うものになります。たとえば要件定義の場で「管理画面から売上を確認できるようにしたい」と伝えたとき、発注者は推移グラフを思い描いていても、開発会社は数字の一覧表を想定しているかもしれません。何がどう見られれば「できた」と言えるのかという完成の基準を言葉にしていなければ、テスト段階で初めてズレが露見し、作り直しになります。
さらに、どこまでを今回の範囲に含めるのかという期待値が揃っていないと、費用の面でも食い違いが生まれます。「ちょっとした修正なら追加費用はかからないだろう」という発注者の期待と、「契約範囲外の変更は別見積もり」という開発会社の前提がすれ違えば、請求の場面で揉めます。範囲と追加の線引きを最初に共有していなかったことが原因です。仕様変更の揉め事の多くは、着手前の詰めの甘さが後工程で表面化したものです。
ノウハウが社内に残らず、外部依存になりやすい
開発を丸ごと外部に任せると、技術やノウハウも外部に蓄積され、社内にエンジニアが育ちにくくなります。運用・改善のたびに外部へ依頼する構造になり、外部依存が固定化することもあります。これを避けるには、要件定義やレビューに発注者側も主体的に関わり、プロジェクトの主導権を自社に残す姿勢が欠かせません。
受託開発のデメリットの多くは「上流の要件整理」で防げる
ここまでのデメリットに共通するのは、その原因の多くが着手前——つまり上流工程にあるという点です。要件の曖昧さを減らし、期待値と認識を発注前に揃えておけば、仕様変更の摩擦も、想定外の追加費用も大幅に減らせます。受託開発を選ぶかどうかと同じくらい、”どこまで上流を詰めてから発注するか”が結果を左右します。手戻りが起きる構造とその防ぎ方は、スコープ管理の崩れ方をまとめた記事でも詳しく整理しています。
ここまで読んで、「うちの要件も、まだ固まっていないかもしれない」と感じた方もいるかもしれません。ただ、ここまで見てきた手戻りや追加費用は、いずれも発注前の整理で防げるものです。Enlytでは、要件の可視化や、発注前に詰めておくべき論点をまとめた資料を無料で公開しています。自社の進め方を点検する材料として、お役立ち資料ページからご覧ください。
受託開発とラボ型・アジャイル・SESの違いを比較【一覧表】
受託開発を検討する読者の多くが、ラボ型開発・アジャイル開発・SESとの違いを知りたいはずです。まず、それぞれを一枚の表で比較します。
| 観点 | 受託開発 | ラボ型開発 | アジャイル開発 | SES |
| 契約形態 | 請負契約 | 準委任契約が中心 | 進め方であり契約形態ではない（請負・準委任いずれとも組み合わせ可） | 準委任契約 |
| 費用の考え方 | 成果物単位（案件ごとに見積・固定） | 体制単位（一定期間、月額でチームを確保） | 組み合わせる契約に依存 | 工数・人月単位 |
| 仕様変更への柔軟性 | 低め（着手後の変更は追加交渉になりやすい） | 高め（優先順位を都度調整しやすい） | 高い（変更を前提に反復する） | 体制次第で調整可（完成責任は負わない） |
| 向いているプロジェクト | 仕様が固まり、完成物が明確な開発 | 中長期で継続的に作り続ける開発 | 仕様を試しながら固める新規プロダクト | 自社主導で進めたい・人手を補いたい開発 |
| 発注側に求められる関与度 | 中（要件定義・レビューへの関与が成否を左右） | 高（優先順位付けと継続的な指示） | 高（反復ごとのフィードバック） | 高（自社が主導・進行管理する前提） |
受託開発・ラボ型・アジャイル・SESは「同じ軸」の選択肢ではない
ここで重要な注意点があります。受託開発・ラボ型開発・SESの3つは「契約・体制」の話であり、アジャイル開発は「進め方（開発プロセス）」の話です。つまり、4つは同じ土俵に並ぶ選択肢ではありません。
たとえば「ラボ型開発をアジャイルで進める」というように、体制と進め方は組み合わせて成立するため、「受託かアジャイルか」という二者択一で考えると混乱します。契約形態として並ぶのは受託・ラボ型・SES（準委任）で、アジャイルはそのいずれの体制でも採用しうる進め方だと整理してください。なお、SESは準委任契約（民法656条）にあたり、労働力・工数の提供が中心で、完成責任は負いません。ラボ型開発は、一定期間、自社専任のチームを確保して継続的に開発を進める形態で、案件ごとに契約する受託開発と違い、作るものを走りながら決めていけるのが特徴です。海外拠点のチームを活用するケースも多く、費用感の目安はオフショア開発の費用相場をまとめた記事で整理しています。
開発形態は優劣でなく「要件がどれくらい固まっているか」で選ぶ
4つの形態に優劣はありません。選ぶ基準は、自社の要件がどれくらい固まっているかです。作るものが明確で、仕様が固まっているなら、完成責任のある受託開発が向いています。逆に、これから試しながら仕様を固めたい、継続的に開発し続けたいという段階なら、ラボ型やアジャイルな進め方のほうが噛み合います。確定度が低いうちに無理やり受託で固めると、前述の手戻りや追加費用のリスクを自ら抱え込むことになります。重要なのは、いまの自社がどちらの状態に近いかを見極めることです。
受託開発が向いているプロジェクトの特徴【チェックリスト】
受託開発が自社に合うかどうかは、以下の確認項目を自社の状況に当てはめると見えてきます。数を数えて診断するチェックではなく、それぞれの項目について「自社はどうか」を考える材料として使ってください。
| 確認項目 | 考え方 |
| 完成させたい成果物が明確か | 作るもの・ゴールがはっきりしているほど、完成責任のある受託開発と噛み合う |
| 要件・仕様がある程度固まっているか | 固まっているほど見積・納期がぶれにくい。曖昧なら発注前の要件整理を先に |
| 予算・納期を先に確定させたいか | 請負契約は範囲と金額を先に決めるため、見通しを固めたい案件に向く |
| 発注後も要件定義・レビューに関与できる体制があるか | 丸投げは手戻りの元。自社側で判断・確認できる担当を置けるかが分かれ目 |
| 継続的に作り続ける必要があるか | 一度作って終わりでなく開発し続けるなら、ラボ型など別形態も検討 |
これらに多く当てはまるほど、受託開発との相性は良好です。当てはまらなかった場合は、以下のように読み替えてください。
| 自社の状況 | 検討したい形態 |
| 要件がまだ流動的で、試しながら固めたい | アジャイルな進め方を採用できる体制（ラボ型など） |
| 中長期で継続的に開発・改善し続ける | ラボ型開発 |
| 自社が主導して進めたい・人手だけ補いたい | SES（準委任） |
| 要件を固めること自体に自信がない | まず上流の要件整理から相談できる相手を選ぶ |
いずれの場合も、要件が固まりきっていないこと自体は問題ではありません。固まっていない状態のまま、範囲を決め打ちする契約に進んでしまうことが手戻りを生みます。発注前に何を詰めておくべきかは、発注前に整理すべき論点をまとめた記事が参考になります。
受託開発を成功させる鍵は「発注前の要件整理」
ここまで見てきたとおり、受託開発の成否を分けるのは、契約形態の選択そのものよりも、発注前にどこまで要件を整理できているかです。
曖昧さ・期待値・認識齟齬を、発注前に減らす
大切なのは、「認識を合わせましょう」という心がけで終わらせないことです。何を（機能・仕様・完成の基準）、誰と（発注者・開発会社・現場の利用者）、どの粒度で合意するかを、発注前に具体的に決めておく。この一手間が、後工程での手戻りと追加費用を防ぎます。
具体的には、決定した事項とまだ検討中の事項を分けて書き出す、画面イメージや業務フローを図にして可視化する、「当然入っているはず」と思い込んでいる暗黙の期待を洗い出して一覧にする、といった作業が有効です。曖昧なまま進めた優しさは、たいてい後で揉め事として跳ね返ってきます。
「単なる受託」ではなく、上流から伴走する受託という選び方
受託開発と一口に言っても、仕様が固まった前提で作るだけの会社もあれば、要件が曖昧な段階から一緒に整理し、期待値を揃えたうえで開発に入る会社もあります。要件が固まりきっていない発注者にとっては、後者のように上流工程から伴走してくれる受託開発のほうが、結果的に手戻りが少なくなります。
見極めるポイントは、初回のヒアリングで、機能や画面の話だけでなく、「何のためにそのシステムを作るのか」「どうなれば成功と言えるのか」まで踏み込んで聞いてくれるかどうかです。目的や成功基準を最初に揃えておけば、途中の判断に迷ったときも立ち返る軸ができます。
まとめ｜受託開発の選び方は「要件の固まり具合」で決まる
受託開発は、仕様が明確なシステムをオーダーメイドで作りたい企業にとって、有力な選択肢です。契約は請負契約にあたり、完成責任と契約不適合責任という枠組みのもとで進みます。一方で、ラボ型開発とSESは契約や体制の話、アジャイル開発は進め方の話であり、4つは同じ土俵に並ぶ選択肢ではありません。そのうえで最後の判断軸になるのは、形態の優劣ではなく、自社の要件がどれくらい固まっているかです。仕様変更のしにくさや外部依存といったデメリットの多くも、着手前の要件の曖昧さ・認識齟齬・期待値のズレに端を発しており、上流をどこまで詰めてから発注するかで結果は大きく変わります。
Enlytは、受注前整理や要件の可視化を含めたシステム開発を手がけています。仕様どおりに作るだけの受託ではなく、何を作るべきかを決める段階から関わり、今回の範囲に何を含めるのかを関係者ごとに揃えたうえで開発に入る。要件が固まりきっていない状態からのご相談でも、上流工程の整理から一緒に進めることで、着手後の手戻りを未然に減らします。しかもそれを、担当者個人の力量ではなく、進め方の仕組みとして持っている点が特徴です。
「見積もりを取ってみたものの、どの形態が自社に合うのか判断できない」という状態が続いているなら、それは検討が足りないのではなく、要件がまだ固まりきっていないサインかもしれません。まずは自社の要件がどこまで具体化できているかを、一度棚卸ししてみることをおすすめします。開発形態の選び方から迷っている方や、上流整理から任せられる開発パートナーをお探しの方は、お問い合わせよりお気軽にご相談ください。
