要件が複雑で仕様変更や新機能の追加が頻繁に起こるフルスクラッチ開発は、契約・知財・運用を設計しておくと、長期でも進めやすくなります。
委託時の契約・法務上の論点は、準委任が向く理由、知財とロックインへの備え、契約の組み合わせ、偽装請負を避ける運用です。
▼全体ガイドの記事
・ラボ型契約の完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
仕様変更の多いフルスクラッチに準委任が向く理由
フルスクラッチ開発は独自要件が多く、既製品にない機能をゼロから作ります。要件が複雑なため、開発中は仕様変更や新機能の追加が頻繁に起こります。また、実際に動くものを見て要望が変わるのも自然な流れです。
変更が前提となる開発では、仕様変更への対応が契約形態によって変わり、契約の選び方が進めやすさを左右します。請負と準委任では対応方法が根本的に違います。
請負は初期に仕様固めが必須という制約
請負契約では、仕様が確定した後と、変更が生じたときで扱いが次のように分かれます。
- 契約の前提：特定のシステムを完成させて納めることが目的で、仕様・金額・納期を事前に決める
- 仕様確定後：予算と納期の見通しを立てやすい
- 仕様変更時：影響調査、追加見積もり、再契約が必要
請負では、契約前に作るものの仕様を細部まで固める必要があります。しかし、独自システムは開発前に全仕様を見通すのが困難です。動かして初めて分かることも多いため、苦労して固めた仕様でも、途中で変えたくなる場面が出てきます。
完璧な仕様書を作るだけでも、膨大な時間とコストがかかる場合があります。さらに、追加契約が重なると総額が膨らみ、調整の待機時間（アイドリングタイム）も生じます。その結果、プロジェクトの遅延や想定外のコスト増につながります。
変更が多いフルスクラッチ開発では、初期に仕様を固めきる請負契約の前提そのものが成立しにくくなります。
契約枠内で優先順位を柔軟に変える仕組み
ラボ型契約は一定期間の業務遂行を目的とする準委任契約なので、契約期間内であれば作業の優先順位を入れ替えながら進められます。
- チームの進め方：発注側と相談し、優先順位の高いタスクから開発
- 契約期間内の変更：追加費用なしで、タスクの追加や優先順位の変更ができる
- 改善の進め方：動かして得た気づきを次に活かし、使い勝手に合わせて磨く
ラボ型契約には、完成させて納める義務がありません。仕様が変わった場合でも、次のスプリントで作業を組み替えられるため、追加見積もりや再契約を待たずに新しい方針へ移れます。
また、短い期間で開発と検証を繰り返すアジャイル開発と相性が良く、試行錯誤を前提とするフルスクラッチにも適します。机上の仕様書どおりに作る請負とは、進め方が異なります。
請負では変更に追加費用や手続きが伴うため、改善の妨げになる場合があります。気になる点を我慢すると、満足度の低いシステムになりがちです。
一方で、ラボ型は変更のハードルが低いため、試行錯誤を通じて品質や使い勝手、事業への貢献を高められます。長期の開発では、改善を続けられるかどうかが完成度を左右します。
長期開発でのソースコード・知財の帰属
フルスクラッチ開発のソースコードは、企業独自の業務ノウハウや競争力を表す重要な資産です。長期のラボ型契約では、こうした資産が確実に自社へ帰属するよう、契約で定めておく必要があります。
準委任には原則として納品がなく、知財帰属の扱いも請負とは異なります。そのため、知財帰属の特約と、ベンダーロックインを避ける運用の両方が欠かせません。
知財帰属の特約を明記する必要性
ラボ型契約では納品が原則ないため、請負と同じ前提では知財の扱いを決められません。そこで、契約時点で特約の内容を詰めておく必要があります。
- 請負契約：一般に納品時または代金支払い時に権利が発注者へ移転
- ラボ型契約：納品が原則なく、権利の所在が曖昧になりやすい
- 契約上の備え：業務中に作るコードや文書などの知財を、作成時点で発注者へ譲渡する特約を明記
チームは契約期間中、日々開発を続けます。取り決めがないと、積み上がっていくソースコードの権利が曖昧になり、自社のものか不安が残ります。
特に長期かつ大規模な開発では、知財の量と価値がそれだけ大きくなります。特約の対象には、業務遂行中に作成したソースコードやドキュメントを含めます。
さらに、この特約は、別の会社に保守を頼む場合や、自社の知的財産として活用する場合にも必要です。長期のフルスクラッチ開発では、契約締結時の最重要項目として、この特約を確かめておきます。
ベンダーロックインを回避する運用
長期のチーム委託では、生産性とベンダーロックインの両方を見ながら運用を整える必要があります。
- チームの知識：独自仕様や背景知識（暗黙知）が蓄積し、生産性が上がる
- 依存のリスク：価格交渉力の低下や、契約終了時に引き継ぎ先が見つからない恐れ
- 回避する運用：要件定義や仕様変更、設計理由、議論の経緯を文書にして残す
システムをベンダーだけが理解している状態になると、過度な依存につながります。長期のフルスクラッチ開発では、引き継ぎの備えを先に整えておくことが求められます。
口頭の指示だけに頼らず背景知識を文書に残せば、チームが変わっても別の開発者が引き継げます。また、知財帰属の特約とあわせて、背景知識も自社に残しておきます。
長期開発では、保守に必要な知識を残せるかどうかが要点になります。ラボ型の生産性を活かしながら、文書化でロックインを抑えるバランスが鍵になります。
請負契約とラボ型を使い分けるハイブリッド
フルスクラッチ開発では、ラボ型と請負のどちらか一方に決めなくてもかまいません。そこで、プロジェクトの成熟度やフェーズに応じて契約を切り替えると、コストと柔軟性のバランスを取れます。
仕様が固まらない局面ではラボ型を使い、仕様が確定した後は請負を活かします。自社プロジェクトのどの段階でどちらを使うかを、先に設計しておくことが大切です。
代表的な例は、初期要件定義をラボ型にして開発を請負にする方法と、初期開発を請負にして保守・拡張をラボ型にする方法です。
初期要件定義をラボ型、開発を請負にするパターン
仕様書がなく要件が曖昧な初期はラボ型で進め、仕様が確定した後の開発は請負に切り替えます。各段階の性質に合わせて契約を選べるのが利点です。
- 初期の要件定義：ラボ型で専属エンジニアと試行錯誤し、プロトタイプを作って要件を具体化
- 仕様確定後の開発：請負で一括発注し、範囲を明確にして予算超過を防ぐ
初期は、机上で完璧な仕様書を作るより、手を動かして現実的な仕様へ落とし込みます。そのため、仕様の決め方に柔軟性を持たせられます。
一方で、仕様が精緻に固まった後は、予算と納期の見通しが立てやすくなります。柔軟性と予算管理を両立できるため、大規模・長期の開発で有効です。
初期開発を請負、保守・拡張をラボ型にするパターン
ローンチ時の見通しを確保しつつ、その後も改善を続けるには、開発と運用保守で契約を切り替えます。
- 初期開発：請負で納期に沿って一括構築し、決めた機能でローンチ
- リリース後：追加機能開発や運用保守をラボ型にし、変更する優先順位に対応
要件がある程度固まっていて、まず確実にローンチしたい場合には、初期開発を請負にする方法が合います。
リリース後は、実際に使ってから改善していきます。さらに、同じチームが保守を続ければ、ユーザーの反応を見て機能を磨けます。
どちらを選ぶかは、開始時点の仕様の確定度、納期の厳しさ、リリース後の改善をどれだけ重視するかで変わります。プロダクトのライフサイクルに沿った切り替えは、最初の段階で設計しておきます。
偽装請負を避ける指揮命令・契約運用
ラボ型契約では自社専属のチームとの距離が近いため、発注側が社員のように直接指示や管理をしてしまいがちです。準委任で直接指揮をすると、法的なリスクが生じます。
そのため、実態が労働者派遣や偽装請負とみなされないためには、指揮命令関係がどこにあるかを理解し、適切な運用体制を保つことが重要です。
発注者とエンジニアの指揮命令関係の線引き
偽装請負を避けるには、発注者とエンジニア個人の役割や関係を区別しておく必要があります。
- 雇用と指揮命令：エンジニアは開発会社に雇用され、その指揮命令下で従事
- 発注者の役割：作ってほしいものを伝え、個人への労務指揮は行わない
- 避ける行為：エンジニアへの直接の作業指示や勤怠管理
準委任のラボ型では、発注者のために働くチームであっても、発注者とエンジニア個人の間に雇用関係や指揮命令関係は生じません。たとえば、「何時から何時まで働け」「この作業を今すぐやれ」という指示は、雇用主のような労務指揮に当たります。
直接指示をすると、契約上は準委任でも、実態として労働者派遣や偽装請負とみなされる恐れがあります。偽装請負は、職業安定法や労働者派遣法に抵触します。さらに、発覚すれば行政指導や是正勧告の対象となり、企業の社会的信用にも関わります。
親しくなるほど社員のように指示したくなる場面もありますが、一線は守ります。
PM・ブリッジSEを窓口にする運用体制
偽装請負を避けながら開発を進めるには、ベンダー側のリーダーを窓口にします。
- 窓口を置く：ベンダー側のPMやブリッジSE（BrSE）をチームリーダーにする
- 優先順位を調整：発注者はリーダーとタスクやスケジュールをすり合わせる
- 指示を伝える：メンバーへの詳細な作業指示はリーダーを通す
リーダーは発注者の意向をチーム内に伝えます。このため、発注者の方向性をチームに反映させながら、エンジニア個人への直接指揮を避けられます。ただし、窓口を置くだけでなく、実際の指揮命令関係も含めて判断されます。
窓口を通す運用は、開発管理にも役立ちます。また、個人への直接指示は、指示の錯綜やチームの優先順位の乱れにつながる場合があります。
契約開始時から体制を確立し、習慣として定着させます。専属チームであっても、社員と同じような直接指示は避けます。
窓口を通す決まりを守れば、法的リスクを避けつつ、開発を円滑に進められます。契約の柔軟性を活かすうえでも、この運用は欠かせません。
まとめ
仕様変更が多いフルスクラッチ開発では、契約期間内にタスクを柔軟に変えられる準委任のラボ型が合う場面があります。一方で、請負は初期に仕様を固める必要があります。
ラボ型には納品の概念がないため、知財が作成時点で発注者に帰属する特約を明記しておきます。さらに、要件や変更の経緯を記録し、ベンダーロックインにも備えます。
請負とラボ型は、フェーズに応じて組み合わせられます。また、発注側はエンジニア個人へ直接指示をせず、PMやブリッジSEを窓口にする運用を守ります。
契約形態の特性を踏まえて、知財、指揮命令、契約の使い分けを設計します。なお、フルスクラッチ開発の委託では、信頼できる開発パートナーに相談することも選択肢になります。
▼全体ガイドの記事
・ラボ型契約の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。